Re: extension and interoperability

For what it’s worth, I don’t agree that pragmas are a subclass of comments, and I wouldn’t agree with any wording to that effect in the spec. I tried to word that fairly carefully in today’s call, and say only that comments can be made readable by the processor with the {[…]} syntax. This syntax would, in my view, not be an implementation of pragmas. 

All that aside, the suggested solution is already a huge compromise as regards what most of the CG has expressed that they want. Since it goes against the majority’s preferences on the question, I believe it should require unanimous agreement if we’re to hold our noses and go ahead with it. Since we don’t have that, I’m withdrawing my support for the proposal I made in the meeting and, as far as I’m concerned, this question is back on the table. 

Sent from my iPhone

> On 1 Feb 2022, at 19:21, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
> 
> This morning's call makes me think that some members of the CG believe
> we face a choice between writing the spec so as to have interoperable
> processors that do not extend the spec and writing it in a way that will
> lead to non-interoperable extensions.  I think this is a misconception.
> 
> Like all spec writing groups, we face a three-way choice:
> 
>  - write the spec in such a way that there is controlled extensibility
>    and controlled extension
> 
>  - write the spec in such a way that there is uncontrolled extension
> 
>  - write the spec in such a way that no one uses it
> 
> I think failing to adopt a serious pragmas proposal puts the first out
> of our reach, leaving us hoping for the second rather than the third.
> At the moment I am unable to consider the two-line pragma specification
> (specify delimiters and say erroneously that pragmas are comments) as a
> serious proposal.
> 
> Michael
> 
> -- 
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> http://blackmesatech.com
>

Received on Tuesday, 1 February 2022 19:41:39 UTC