[erlang-questions] literal character syntax

[zxq9]

On Thursday 15 May 2014 12:36:43 you wrote:
> $ 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:str
> ing_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

Some work in the emacs mode calling?

> 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?

Some tools work well, other don't. That is a tooling issue, not a language 
one. The tooling argument will never satisfy me, especially when it is 
centered around a single language mode in a single editor no matter how 
popular. In my experience most flaws that tend to matter are inherent in the 
coder's conception or the project at hand (standards or lack of them), hence 
my point about coding practices trumping tooling and syntactic rules in all 
cases.

> What do you mean by « our conception of whitespace »? How can that change?
> Whitespace is whitespace.

No. "Whitespace" means a whole slew of things, including, in this case, "non 
printable characters". "Whitespace" and "non-printable characters" are 
uselessly broad definitions in the days of unicode Erlang.

Were you taught how to write a space in school? How about how to write a tab? 
Columnar delimitation? How large is a space in a file? Is that a property of 
the character or the way in which it is displayed? Is whitespace even a 
"character (set)"? Where I live kids actually are taught precisely how large a 
space is supposed to be in handwritten text -- but only when writing 
Kana/Kanji (and this difference extends to source files -- double-width space is 
a pain to find the codepoint for, but its different than a normal ASCII space).

Back when most of us started with computers we were subject to whatever 
monospace fonts could print in ASCII in an arbitrarily delimited screen mode. 
Most of us still code that way. But some terminals don't use monospace, some 
editors let you use "printer" fonts, some delimit tabs in something radically 
different than the size of N-spaces, etc. There are a huge number of 
interpretations of what "whitespace" means -- just ask a typesetter.

If our conception of the meaning of "whitespace" in source changes even a 
little then this outlawing of whitespace literals will likely appear backward  
(but fortunately undoable without breaking backward compatibility in the way 
the change under consideration will).

Vlad brought up an excellent point about some editors which automatically 
replace spaces with tabs and vice-versa. This is an issue in several 
communities (Python, for example), and one that has been well addressed by 
coding practices, not language restrictions. It is also a tooling issue, not a 
language one.

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

I don't really see Erlang as a language that imposes discipline on the 
programmer. I do see a lot of other languages trying to impose discipline on 
programmers and failing marvelously for the simple reason that it will always 
be possible to write obfuscated or old-fashioned bad code.

My intention was to point out that while using "$ " or "$       " is a stupid 
thing 
to do in most cases when "$\s" and "$\t" are available as alternatives, this 
is a tribal/coder issue not a problem inherent in the language waiting for a 
parsing solution. Should certain types of guards be similarly disallowed when 
pattern matches are clearly more readable? How about other situations where 
equivalent representations are available, but one is clearly more expressive 
by the standards of the people who frequent this list (but perhaps not all 
others)?

Sound coding practices trump syntax rules. If we agree that coding practices 
are usually more tribal/situational than they are provably superior, then I 
think its rather obvious that instead of tweaking the parser to introduce a 
backward-incompatible change in the language implementation (or definition!) 
the proper thing to do is note that the "standard" way to note non-printable 
characters is with backslash escapes, perhaps by amending 
http://www.erlang.se/doc/programming_rules.shtml. This leaves the option for 
projects operating under different constraints with different tooling to do 
things appropriate for themselves.

It seems like the general feeling is to impose a new restriction in the 
language. Its not a game-changer either way, but I wanted to present a case 
for not introducing special-case rules that outlaw a rather broader category 
of characters than the OP may have realized in one very specific circumstance 
-- just to make sure this is thoroughly considered before someone spends time 
tinkering with the parser yet again.