[erlang-questions] literal character syntax

zxq9 zxq9@REDACTED
Thu May 15 12:17:02 CEST 2014

On Wednesday 14 May 2014 10:15:37 Fred Hebert wrote:
> I think the argument here is specifically about whitespace characters.
> For example, using:
> starts_with([$  | _]) -> space;
> starts_with([$	 | _]) -> tab;
> starts_with([$
>  |_]) -> newline.
> Is currently allowed, but it is arguably clearer to use:
> starts_with([$\s | _]) -> space;
> starts_with([$\t | _]) -> tab.
> starts_with([$\n | _]) -> newline.
> Vlad here recommends deprecating the former case, while recommending the
> latter form.
> I would tend to agree for the sake of readability, but would like a
> regular deprecation cycle with warnings explaining the recommended
> changes ("The $<space> form is being deprecated, replace with $\s" or
> something).

I can understand the argument about it being confusing, otoh, special casing 
something in the language implementation (the whitespace literals VS every 
other literal) to explicitly disallow them when there is a text-readable way 
of expressing this already (the escape characters) seems like step in the 
wrong direction.

The current implementation is entirely consistent, is not confusing in 
editors/highlight modes which are trained to point out literal whitespace, and 
the readability issue really boils down to clean coding conventions VS trying 
to make the language implementation force a clean coding convention which may 
not fit all cases/editors/communities. If emacs/vi/fooedit evolve in the future 
to the point our conception of "whitespace" changes even a little, this will 
be seen as an awkward wart lingering in the language. I can't think of a case 
of coding convention VS implementation-imposed discipline where "imposed 
discipline" was a good idea unless it was central to the design of the 
language to begin with.

My 2c.

More information about the erlang-questions mailing list