Date: Thu, 15 Apr 2021 12:50:32 +0200
Ville,
on Thu, 15 Apr 2021 13:22:05 +0300 you (Ville Voutilainen
<ville.voutilainen_at_[hidden]>) wrote:
> On Thu, 15 Apr 2021 at 13:06, Jens Gustedt <jens.gustedt_at_[hidden]>
> wrote:
> >
> > Ville,
> > your answer shows a sufficient amount of bad faith, I find.
>
> I have the exact same thoughts about your dismissal of concerns about
> deployment and editing
> of source code as "culture wars".
I am not dismissing them, I just said that we had them often
enough. And that I wanted to hear about the other part.
> But fine. If you wish to shut your eyes
Why would you say that?
Just because I *also* at one point want to collect the other
information?
> about anything besides the implementation and specification aspects
> of this, go ahead. You need to describe how these new punctuators
> fit into operator precedence,
no, these operators are not new, they would just be different
spellings
(and I described how I see that this fits into the C specification in
several papers, you could have a look at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2644.pdf, for example)
> and add them as alternative spellings of some existing semantic
> descriptions. Overall, I think there's not much specification
> difficulty, at least not for things that are just alternate
> spellings.
That's the kind of information that I was after, thank you.
> I don't know whether you envision adding new operators,
no
> which is then a completely different ballgame, because in order to
> evaluate the difficulty of that, we'd need to know what the intended
> semantics are.
sure
> Based on how you deal with comments related to this idea,
Have you other examples for that, or is this just about this
conversation here, and my reaction to your reaction?
> especially when they're not exactly the comments you wished to have,
> I recommend against wasting committee time on this. Discussing
> those matters is inevitable, and trying to cover just a subset of
> the problems in this problem space while ignoring the others isn't
> going to get us anywhere.
I think it would effectively be a waste of time to discuss these
things if in the end they were difficult to implement (in the standard
or in compilers). Your statement above (and my experience implementing
this) seems to indicate that this isn't the case. But I'd also like to
hear from others, that perhaps have insight in implementations that
feature non-Unicode characters sets, for example.
So then, and if others agree about this assertion, we could have the
discussion about cultural differences, cultural dominance, personal
preferences, language imposed coding style, free speech ...
Thanks
Jens
on Thu, 15 Apr 2021 13:22:05 +0300 you (Ville Voutilainen
<ville.voutilainen_at_[hidden]>) wrote:
> On Thu, 15 Apr 2021 at 13:06, Jens Gustedt <jens.gustedt_at_[hidden]>
> wrote:
> >
> > Ville,
> > your answer shows a sufficient amount of bad faith, I find.
>
> I have the exact same thoughts about your dismissal of concerns about
> deployment and editing
> of source code as "culture wars".
I am not dismissing them, I just said that we had them often
enough. And that I wanted to hear about the other part.
> But fine. If you wish to shut your eyes
Why would you say that?
Just because I *also* at one point want to collect the other
information?
> about anything besides the implementation and specification aspects
> of this, go ahead. You need to describe how these new punctuators
> fit into operator precedence,
no, these operators are not new, they would just be different
spellings
(and I described how I see that this fits into the C specification in
several papers, you could have a look at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2644.pdf, for example)
> and add them as alternative spellings of some existing semantic
> descriptions. Overall, I think there's not much specification
> difficulty, at least not for things that are just alternate
> spellings.
That's the kind of information that I was after, thank you.
> I don't know whether you envision adding new operators,
no
> which is then a completely different ballgame, because in order to
> evaluate the difficulty of that, we'd need to know what the intended
> semantics are.
sure
> Based on how you deal with comments related to this idea,
Have you other examples for that, or is this just about this
conversation here, and my reaction to your reaction?
> especially when they're not exactly the comments you wished to have,
> I recommend against wasting committee time on this. Discussing
> those matters is inevitable, and trying to cover just a subset of
> the problems in this problem space while ignoring the others isn't
> going to get us anywhere.
I think it would effectively be a waste of time to discuss these
things if in the end they were difficult to implement (in the standard
or in compilers). Your statement above (and my experience implementing
this) seems to indicate that this isn't the case. But I'd also like to
hear from others, that perhaps have insight in implementations that
feature non-Unicode characters sets, for example.
So then, and if others agree about this assertion, we could have the
discussion about cultural differences, cultural dominance, personal
preferences, language imposed coding style, free speech ...
Thanks
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2021-04-15 05:50:36