[erlang-questions] reserved word guaranteed to be atom if single-quoted?

[Robert Virding]

On 22 February 2010 17:30, David Mercer <dmercer@REDACTED> wrote:
> On Sunday, February 21, 2010, Richard O'Keefe wrote:
> ...
>
> If you're willing to go beyond just tweaking the lexer, you could use
> parsing logic like the following:
>
>        When a keyword is reached, assume it is an atom.  If parsing fails,
>        back off to the last keyword which was assumed to be an atom and
>        change your assumption to a keyword.  Continue.
>
> The opposite logic also works (and also might be more efficient):
>
>        When a keyword is reached, assume it is a keyword...
>
> This works with all reserved words except (I think) "catch", which can be
> indistinguishable from a function call.  One solution to this might be to
> make catch a BIF as well.

This is pretty much how prolog does it, except that prolog doesn't
have reserved words but operators instead. In some places you first
try and parse the input assuming the operator is an operator but if
that doesn't work you backtrack and try again assuming it is a normal
atom.

However, this does not require backtracking in the lexer, it is all
done in the parser. The lexer just returns an atom and it is the
parser which recognises that this atom may actually be an operator and
tries both cases. It is simpler in a way and more versatile but means
the parser most likely cannot be automatically generated by a parser
generator like yeec. If this can be done please let me know.

Translating this to work with reserved words shouldn't pose any
problems. Though you might a get weird results on old code if you add
a new reserved word.

Robert

>> That being said, I know my proposed solution is more complicated than it
> looks, since it requires backtracking into the lexer, and may well
> complicate error messages somewhat.  My first logic is probably less
> efficient (since most uses of reserved words are for their keyword meaning),
> but would likely result in better error messages (since the last error in
> that case will be based on the keyword interpretation).  On the other hand,
> it could really screw up your error message if there was an earlier keyword
> correctly interpreted as an atom, which got reversed on review...
>
> Maybe ROK's approach is better.  It just requires spaces after reserved
> words before parentheses, and prohibits spaces between invoked function
> names and their arguments.  I.e., "frob (Arg)" would not be future-proof,
> since "frob" could later be declared a reserved word; "frob(Arg)" would be
> OK.
>
> Done rambling.  Cheers,
>
> David