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

David Mercer <>
Mon Feb 22 17:30:40 CET 2010

On Sunday, February 21, 2010, Richard O'Keefe wrote:

> (2) New keywords have been added to Erlang over time.
>      There is no reason to believe that we have the final set yet.
>      It would be nice if Erlang code could be "future-proofed".
>      One approach (which I've tried in a tokeniser, and seems to
>      work tolerably well) is that
>   -  an identifier *immediately* followed by '(' is always a
>      plain function name
>   -  an identifier preceded by one of
> 	( [ { , | ; -> =
>      and followed by one of
> 	) ] } , | ; -> =  end
>      is always a plain atom even if it would otherwise be a keyword.

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.

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

Done rambling.  Cheers,


More information about the erlang-questions mailing list