[erlang-questions] Binary string literal syntax

[zxq9@REDACTED]

On 2018年6月5日火曜日 19時51分32秒 JST Sean Hinde wrote:
> I’ve been writing a lot of Elixir over the last few months (plus Swift, Java, C) and just came back to Erlang. There are a few things I’ve come to very much like about Elixir I think might be quite useful to bring to Erlang.
> 
> The first, and topic of this email, is arguably trivial, but having to surround <<“modern”>> string literals with <<>> is irritating and not getting any less so.

I like ideas such as this but believe the core language is not the place to implement them.

Syntax is like ocean plastic -- it lingers forever, works its way into unexpected places and interacts with the metabolism in surprising ways. Adding syntax to an existing language, especially syntax that represents something that is already one can represent, is *dangerous*. It makes the overall language less useful and each addition dramatically increases the cognitive overhead of learning the language.

Typing two different characters two times each, as in <<>> does not exhibit much advantage in keystrokiness over typing a widely gapped sequence ~s''. Magical quote interpretation, as in Python, to avoid the need to escape one or the other kinds of quote literals within a string is handy, but doesn't change much about the difficulty of the language. As Erlang already makes a distinction between single and double quotes, though, diddling with this is a dangerous change (adding syntax) in the interest of glyphy familiarity.

Erlang is a small language. A large part of its utility stems from the fact that the core language is TINY and not littered with a ton of conveniences. This should be strongly protected. Compare the universal readability of C vs the wetware-level incompatibilty among various styles of C++ (or Haskell, for that matter); that's astonishing and sad about C++.

If Elixir does what you like, then use it. There is a strong chance that Elixir will explore so much in terms of language conveniences that it will blow up the way C++, Ruby, and Perl have. That's fine, because we'll learn a lot and Elixir's grandchildren will really be something! Introducing Elixirisms into Erlang, a stick-in-the-mud, traditional, old, venerable language with a very low learning curve at the level of language complexity, is purely a risk.

I would argue that there are *many* places Erlang could benefit from changes, but that inside Erlang is not the place to make them.

I'd like to create a "nearly Erlang" language -- 99% "readable as Erlang" but not actually Erlang -- to advance changes like the one you propose. It could compile on its own or simply rewrite to Erlang proper.

- Semantic whitespace (no more ant-poop or weirdness with terminators before 'end' or 'after' or 'catch')
- Syntactic representation of pipeline checks (or a stdlib pipeline function) to avoid a string of checks forcing newbies into writing highly nested 'case'
- Removal of 'if'
- A reworking of quote representations to make UTF-8 atoms, strings, binary strings, etc. a bit less noisy (maybe the approach you propose, actually, but I would require a lot of time to think about it to get it right).
- A '-pure' declaration (but this could be implemented already in Dialyzer, but just isn't)
- etc.

The place to do these changes is not in Erlang, but in another language that compiles to Erlang or to BEAM.

I'm an Erlang conservationist. Don't corrupt the pristine Erlagnessness with your stays-around-forever-like-marine-plastic syntactic litter!

-Craig