[erlang-questions] literal character syntax
Fri May 16 16:30:51 CEST 2014
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
> ing_thing($') -> "atom"; %' Stupid Emacs
> 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
> 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
> 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
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
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.
More information about the erlang-questions