new syntax - a provocation

[Mike Williams]

The best way to "kill" a language is to make continuous additions.
If people believe a language is in the process of change, they 
won't use it. The problem is not the additions per se, it is that fact
that it is very hard to remove older, often not so well thought out,
constructs. For example I would very much like to see "catch/throw"
removed, I would like to remove "records" and replace them with some other
construct. But this would break a huge amount of existing code.
Every addition will make Erlang biger and more cumbersome to learn and
use.

So please, if we want Erlang to spread, let's keep the language stable
and have a moratorium on new constructs, new bif's etc.

/mike


In article <Law12-OE52BXx4XFKpR00001991@REDACTED>,
 you write:
|> Hi,
|> 
|> Since new syntax constructs have been discussed, I have some ideas that I'd
|> like to present here. The intention is to spur some more ideas, and maybe
|> some will find a growing ground.
|> 
|> * I have found myself wishing to be able to build data structures other than
|> tuples or lists, in the same elegant way as tuples and lists, directly in
|> the code. The most acute need was for bitsets/integer sets, where using the
|> binary syntax is very cumbersome when there are many such sets to be
|> declared. It would be super-nice to be able to write something like
|>     #[0011010001]
|> or
|>     &[3, 45, 27, 39],
|> where the first is a bit representation, and the latter a set containing the
|> specified integers. The implementation would be as binaries, so just the
|> syntax is new.
|> 
|> * I thought this could be solved with a parse transform, but I think the
|> lexer should be able to cope with new tokens too, since overloading existing
|> ones would only make a mess out of it. That's why I thought "why not
|> introduce something similar to Lisp's reader macros?" We could have a
|> special char (for example, @) to use in constructs like
|>     @[....]
|> that will be transformed into something like (in this case)
|>     mylexer:'['(....)
|> and evaluated at compile time into "real" Erlang.
|> 
|> * Having come this far, and remembering Tobbe's (I think) call for Erlang2,
|> and also Luke's Lisp parallels, there is one more small step to take, for
|> those that like to play on the edge: Why not replace the whole Erlang syntax
|> to a more Lispy one? (or more correctly, closer to CoreErlang) A
|> different-looking language, but the same BEAM code and runtime. There are
|> many aspects of such a syntax that add plenty of power to Lisp, why not use
|> that power?
|> 
|> Note: I am too aware of some of the (many) downsides. I tried to be a little
|> provocative by leaving them out, and also any examples and possible
|> advantages.
|> 
|> regards,
|> Vlad
|>