[erlang-questions] literal character syntax

Anthony Ramine n.oxyde@REDACTED
Thu May 15 12:36:43 CEST 2014


$ gg -i "stupid emacs" -- \*.erl
lib/compiler/src/cerl.erl:994:    io_lib:write_string(atom_name(Node), $'). %' stupid Emacs.
lib/compiler/src/core_scan.erl:96:string_thing($') -> "atom";    %' stupid emacs
lib/compiler/src/core_scan.erl:97:string_thing($") -> "string".  %" stupid emacs
lib/dialyzer/test/opaque_SUITE_data/src/modules/opaque_erl_scan.erl:313:string_thing($') -> "atom";   %' Stupid Emacs
lib/dialyzer/test/options1_SUITE_data/src/compiler/cerl.erl:843:    io_lib:write_string(atom_name(Node), $'). %' stupi
lib/edoc/src/edoc_wiki.erl:238:expand_triple([$', $', $' | Cs], L, As, _L0) ->      % ' stupid emacs
lib/hipe/cerl/erl_types.erl:4798:        true -> io_lib:write_string(atom_to_list(X), $'); % stupid emacs '
lib/stdlib/src/erl_scan.erl:331:string_thing($') -> "atom";   %' Stupid Emacs
lib/syntax_tools/src/erl_prettypr.erl:1011:               lay_string_1([$" | S2], L - W + 1, W))  %" stupid emacs

The whole point of Erlang was always to make silly things quite hard to do. Allowing a literal newline is a silly thing to do that can be forbidden easily. Claiming that tools currently work correctly is irrelevant, and also wrong. And why would that be related to editors anyway? What do you mean by « our conception of whitespace »? How can that change? Whitespace is whitespace.

I also have troubles understanding how Erlang doesn’t already impose *A LOT* of things.

-- 
Anthony Ramine

Le 15 mai 2014 à 12:17, zxq9 <zxq9@REDACTED> a écrit :

> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list