Interpretation of Reserved Keywords in Poetic Assignments

[cwfitzgerald]

Premise

A friendly debate between me and @yanorestes has arisen regarding some language-lawyer-ey crap :). The question at hand is: What is the correct interpretation of My wallet is without.

The Opinions

Set my wallet to 7

The opinion of me and the rockstar-webpiler is that because this situation is not ambiguous within a parser (it is not an alias for true, false, or null which would make it a type literal) it should be interpreted as a normal numeric literal.

Set my wallet to 0

@yanorestes and rockstar-py translate this as an invalid sequence, changing without to -, creating a numeric literal of zero (no alphanumeric characters). The reasoning behind the invalid sequence is the following quote from the standard (emphasis mine):

A poetic number literal begins with a variable name, followed by the keyword is, or the aliases was or were. As long as the next symbol is not a reserved keyword, the rest of the line is treated as a decimal number in which the values of consecutive digits are given by the lengths of the subsequent barewords, up until the end of the line.

Because without is a reserved keyword within the context of a math expression, it stands to reason that it is an invalid sequence.

Error

Neither of us error in this situation, but the reasoning listed above can also lead to the conclusion that we should really be erroring if we encounter this situation, and if an implementation accepts this in any form, it is non-conforming.

Thoughts?

Come one, come all, give your opinions! :smile:

[palfrey]

I vote for "Error". without is a keyword, so it's not a poetic number literal, and it's also not any other valid sequence AFAIK.

[young-steveo]

I vote for My Wallet equals 7, and that's how thrash handles it (though, the spec currently does not allow it).

There should be a difference between "all reserved keywords" and "literal keywords".

[dylanrenwick]

I agree with My Wallet equals 7, simply because, in my opinion, poetic numeric literals should any reserved keyword that would not cause other behaviour in that position.

Reserved keywords are only valid in certain usages and places within the code, and would error or be invalid elsewhere. In my opinion these keywords, if they are not valid as a keyword following My Wallet is, should be treated as a poetic numeric literal

[dylanbeattie]

I think this should set my wallet to 7, but it highlights the need for a distinction between constants and keywords. Type aliases like true, lies, nothing, nobody are syntactically distinct from keywords like the arithmetic and flow control operators, and should be specified accordingly - if anyone wants to take a stab at it and send in a PR, be my guest, otherwise I'll look at it next week when I'm finished moving house :)

[yyyyyyyan]

I dislike @gunnerwolf's point because it creates inconsistency. If ambiguity is the question, then there is no question - My wallet is nothing sets my wallet to null and My wallet was nothing should set my wallet to 7 (what would be terrible).

I think it's okay to only disallow type aliases on poetic number literals, but the justification can't be put on interpretation ambiguity, as there are none either way (allowing these keywords or not)

[cwfitzgerald]

@yanorestes No matter what, My wallet is nothing will always be setting my wallet to null. I don't think we are debating about if constant (and their aliases) should be interpreted as normal literals, just if keywords from other contexts are allowed.

[yyyyyyyan]

Yes, that's not my point! I'm talking about "poetic numeric literals should any reserved keyword that would not cause other behaviour in that position.". There is no other possible behaviour if we allow type aliases on poetic number literals too. I am now in favor of allowing other keywords, but this justification above is flawed

[cwfitzgerald]

Ah, I see! I think the best thing is to make a distinction between the type literals words and keywords as @dylanbeattie suggested, which would make wording the spec easier.

[yyyyyyyan]

Yes!! Agreed ;)

[cwfitzgerald]

I'll write up a PR sometime today.

[yyyyyyyan]

Just updated rockstar-py so now it follows this :D. Thanks, @cwfitzgerald

[cwfitzgerald]

:metal: