1. Your message is definitely too long for a mailing list format (too
much inline code? put it in an attachment file, if it makes sense).
It was not too long
2. You are rambling too much. Stick to the point in the subject and open
a new thread to discuss other ideas.
I was not "rambling" at all, and up to the point of the topic "future of annotations".
All was about ambiguity of parsing (and the problems they already cause in Lua or the possible cost/complexity in implementations, and possible caveats/errors for programmers trying to use them).
We've got various proposals already, we need to evaluate them in the context of "future of annotations", and that's what I did.
For now the "*" notations, used in a prefix-ish style, do not cause major problems (even if they look C-ish and related to "pointer" types, which they are not in Lua) in their current limited scope of use (in "local" variable declarations in which they are still safe, not requiring extra parentheses to define their scope of application which is however not very well precise: does it extend to all variables declared in a comma-separated list being an annotation of "local", or variable by variable that they annotate?)
And several leading tokens have already been discussed: "*", "<" (in a pair), ":", "@". I compared them and look at those that cause problems, which are notably those that can be used also syntactically as binary operators ("*", "/", "+", "-", "^", "div", ":", "<", etc) or separators (",", ";", "(", ")", etc.)
But it is not dramatic (we may still use "*") if we can surround annotations when needed (including their leading token) by parentheses, to avoid the ambiguity with currified function calls, which potentially occurs in "sin -30" where the unary operator "-" becomes 'unexpectedly' a binary substraction without these parentheses.
Also the placement (prefix or postfix) of the annotation has an important syntaxic distinction that must be disambiguated, related to their scope of application (what they annotate) and I tend to prefer the prefix placement which behaves better with other unary operators, but does not change the existing 'problem' with currified function calls except if the annotations cannot be confused with a binary operator.
For now, only "@" does not have any one of these problems (when used as a prefixed annotation) simply because it cannot be used also as a binary operator (for now, but most probably never...).
