On 1/28/15 10:37 AM, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:
>> On 1/28/15 10:19 AM, Jonathan Marler wrote:
>>> On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
>>>> On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
>>>>
>>>>> PLUS, this would be very simple to implement!
>>>>
>>>> Then I recommend you submit a pull request.
>>>>
>>>> Mike
>>>
>>> I would but Walter said no.  I'm certain he misunderstood my proposal
>>> and I tried to explain it to him but I couldn't get him to address it.
>>
>> Was that the proposal leading to this state of affairs (quoting from
>> your post on 2015/01/26 16:05 PST?
>>
>>> Here's what would change
>>> -----------------------------------------------------------------
>>> void myfunc() nogc; // VALID (Only if this proposal is accepted)
>>> void myfunc() safe; // VALID (Only if this proposal is accepted)
>>>
>>>
>>> Here's what WOULD NOT change
>>> -----------------------------------------------------------------
>>> nogc myfunc(); // STILL INVALID: invalid unless it can be verified
>>>               //          that this wouldn't result in ambiguity
>>>               //          in the grammar
>>> void myfunc() @nogc; // STILL VALID (no change)
>>> @nogc myfunc(); // STILL VALID (no change)
>>
>>
>> Andrei
>
> You can follow this thread:
> http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep@forum.dlang.org
>
> I explained my proposal 3 or 4 times but each time Walter seemed to be
> misunderstanding my proposal saying it was going to create
> "context-sensitive" tokens and so he would immediately dismiss it.  I
> tried to understand what he meant by "context-sensitive" tokens because
> my proposal didn't have anything to do with them (at least my definition
> of them), but even after he defined them my proposal clearly does not
> create them.
>
> Walter "[A context-sensitive token is] A keyword in one context and an
> identifier in another"
>
> Anyway, I'll restate my proposal again:
>
> 1. Modify the SYNTAX of function to allow it to be decorated with
> IDENTIFIER tokens on the right hand side
>
> void foo() x; // valid SYNTAX (note: has not semantic meaning)
> void foo() safe; // valid SYNTAX and valid SEMANTICS
>
> 2. Modify the code that interprets the syntax tree to recognize these
> identifiers as function attributes.
>
> A simple solution that would allow us to standardize where we put the
> function attributes and allow us to remove the '@' character from all
> non-keyword function attributes.  Seems like a no-brainer to me.

That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei

On Wednesday, 28 January 2015 at 18:37:48 UTC, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:
>> On 1/28/15 10:19 AM, Jonathan Marler wrote:
>>> On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
>>>> On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
>>>>
>>>>> PLUS, this would be very simple to implement!
>>>>
>>>> Then I recommend you submit a pull request.
>>>>
>>>> Mike
>>>
>>> I would but Walter said no.  I'm certain he misunderstood my proposal
>>> and I tried to explain it to him but I couldn't get him to address it.
>>
>> Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?
>>
>>> Here's what would change
>>> -----------------------------------------------------------------
>>> void myfunc() nogc; // VALID (Only if this proposal is accepted)
>>> void myfunc() safe; // VALID (Only if this proposal is accepted)
>>>
>>>
>>> Here's what WOULD NOT change
>>> -----------------------------------------------------------------
>>> nogc myfunc(); // STILL INVALID: invalid unless it can be verified
>>>              //          that this wouldn't result in ambiguity
>>>              //          in the grammar
>>> void myfunc() @nogc; // STILL VALID (no change)
>>> @nogc myfunc(); // STILL VALID (no change)
>>
>>
>> Andrei
>
> You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep@forum.dlang.org
>
> I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create "context-sensitive" tokens and so he would immediately dismiss it.  I tried to understand what he meant by "context-sensitive" tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them.
>
> Walter "[A context-sensitive token is] A keyword in one context and an identifier in another"
>
> Anyway, I'll restate my proposal again:
>
> 1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side
>
> void foo() x; // valid SYNTAX (note: has not semantic meaning)
> void foo() safe; // valid SYNTAX and valid SEMANTICS
>
> 2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes.
>
> A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the '@' character from all non-keyword function attributes.  Seems like a no-brainer to me.

I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum.

>> On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:
>
> That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei

I don't have a problem with letting things go.  What I have a problem with is poor communication.  Walter never gave me a "valid" reason for why he didn't like the proposal.  I'm totally ok if it gets rejected, but I have no idea why it was rejected.  If anything, I just want to understand so that I make better decisions in the future.

When I say he misunderstood I say that because the reason he gave for disliking the proposal doesn't make sense.  He's using the "Straw Man" logical fallacy.  He's attacking my proposal by assuming it's something that it isn't.  He keeps mentioning keywords and "context-sensitive" tokens but my proposal has nothing to do with those things (even by his own definition of them).  Quite frustrating.

I hope you see that I'm just trying to understand.  I don't care if I'm wrong, I just want someone to tell my why I'm wrong.  And when someone asks me why we weren't able to make function attributes that weren't keywords, I can give them an answer.

On 1/28/15 10:59 AM, Jonathan Marler wrote:
>>> On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu
>>> wrote:
>>
>> That's not a misunderstanding. Your proposal has been understood. It
>> can be made to work. That doesn't necessarily make it desirable. I
>> don't think it's particularly helpful and Walter is against it, so
>> simply put it won't happen. Let it go. Thanks for it and keep the good
>> ideas coming. -- Andrei
>
> I don't have a problem with letting things go.  What I have a problem
> with is poor communication.  Walter never gave me a "valid" reason for
> why he didn't like the proposal.  I'm totally ok if it gets rejected,
> but I have no idea why it was rejected. If anything, I just want to
> understand so that I make better decisions in the future.
>
> When I say he misunderstood I say that because the reason he gave for
> disliking the proposal doesn't make sense.  He's using the "Straw Man"
> logical fallacy.  He's attacking my proposal by assuming it's something
> that it isn't.  He keeps mentioning keywords and "context-sensitive"
> tokens but my proposal has nothing to do with those things (even by his
> own definition of them).  Quite frustrating.
>
> I hope you see that I'm just trying to understand.  I don't care if I'm
> wrong, I just want someone to tell my why I'm wrong.  And when someone
> asks me why we weren't able to make function attributes that weren't
> keywords, I can give them an answer.

It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- Andrei

On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote:
> I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum.

This is actually a valid argument against my proposal.  Thank you! lol.  I don't agree with it but at least it's valid :)  Your reasoning depends on how you define a keyword.  You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning.  I define a keyword as a word that the lexer recognizes as a keyword token.

I see what you mean by saying that the word is a function attribute in one place and an identifier in another.  But what's wrong with that?  if I define a struct named mystruct...I could declare one like this:

mystruct mystruct;

The first appearance is a type and the second is an identifier.  I'm sure there are many examples of this in the language.

Anyway, I disagree with your conclusion, however, I agree that this could be a concern.

On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:
> It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- Andrei

Ok now we're getting somewhere.  I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another?

I would think the reason would be it could make the grammar ambiguous.  That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity.  Other then that, I don't see any reason why it's a bad thing.  It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.

Note: keep in mind...I'm not asking why it's bad to have a keyword (recognized as a keyword by the lexer) also be an identifier, I'm asking why it's bad to have a function attribute also be an identifier.

On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote:
> I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere.

That's a reserved word. A reserved word cannot be used as an identifier. A keyword is a phrase that has a special semantic meaning in a context. That does not make it context sensitive if the language can be recognized by a context free grammar...

Confusing? I guess...

Some languages would allow this:

"if if = 0 then ... fi", it is not context sensitive because it can be recognized by a CFG.

The first "if" is a keyword. The second "if" is an identifier.

Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:13 +0000:
> On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:
> > It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- Andrei
> 
> Ok now we're getting somewhere.  I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another?
> 
> I would think the reason would be it could make the grammar ambiguous.  That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity.  Other then that, I don't see any reason why it's a bad thing.  It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.

Thats not possible:

@safe {
    void some func() // now valid
}

safe:
    void some func() // now valid



safe {
    void some func() // could not be valid
}

safe:
    void some func() // could not be valid


So you need more places where keyword needs to be contextual keyword

And this is a path I am not sure we want to go.

On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
>> I would think the reason would be it could make the grammar ambiguous.  That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity.  Other then that, I don't see any reason why it's a bad thing.  It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.
>
> Thats not possible:
>
> @safe {
>     void some func() // now valid
> }
>
> safe:
>     void some func() // now valid
>
>
>
> safe {
>     void some func() // could not be valid
> }
>
> safe:
>     void some func() // could not be valid
>
>
> So you need more places where keyword needs to be contextual keyword
>
> And this is a path I am not sure we want to go.

None of those cases would valid.  Non-Keyword attributes without a '@' must be on the right hand side of the function parameters.

void some func(); // some is not a keyword, so it is invalid

On 1/28/15 11:13 AM, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:
>> It may be the case you're using different definitions of the term
>> "contextual keyword". Far as I can tell you want the identifier "nogc"
>> be recognized in certain places by the compiler as special, and
>> otherwise just not be special at all. That's a contextual keyword. If
>> that's the case you were well understood by both Walter and myself. I
>> happen to recognize the merit of contextual keyword in general, but
>> Walter has a stronger opposition to it. It doesn't seem to me this
>> particular application is compelling enough to warrant the precedent.
>> -- Andrei
>
> Ok now we're getting somewhere.  I guess the next thing I'd like to ask
> is what is the argument against having a word be a function attribute in
> one instance and a regular identifier in another?
>
> I would think the reason would be it could make the grammar ambiguous.
> That's why I proposed it only be valid on the right hand side of the
> function to guarantee it doesn't introduce any ambiguity.  Other then
> that, I don't see any reason why it's a bad thing.  It doesn't make the
> syntax more complicated, it doesn't maker it harder to parse, I just
> don't see why its bad.
>
> Note: keep in mind...I'm not asking why it's bad to have a keyword
> (recognized as a keyword by the lexer) also be an identifier, I'm asking
> why it's bad to have a function attribute also be an identifier.

I'd say we just drop it. It's a waste of time to talk about it. There's no proof on why the idea isn't accepted, and there's no need for one.

I just wrote out of empathy. As a newcomer to language communities (including this one) I've had literally dozens of ideas on how they can be improved. All looked great to myself at the time, and of them some felt actually unassailably good. So good, in fact, that I'd attach a sense of importance to them and was convinced that explaining and advertising them well was essential, and that opponents didn't really understand their advantages. For the most part they were in reality weak ideas of a n00b, ideas of greatly overstated merit, and acknowledging that has made me better.


Andrei