new syntax - a provocation
Richard A. O'Keefe
Tue Sep 23 07:59:50 CEST 2003
"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> wrote:
* 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
&[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.
If we want to construct values of such types at run time, there had
better be a function which can convert a list of run time values.
Suppose it is
bitset([X,Y,Z,W]) -> a binary with bits X, Y, Z, and W set (all >= 0).
Then the only syntax you need is
*except* that you might want to use it in pattern matches and guards.
All it takes is a declaration. For argument's sake,
with the interpretation
(A) "Do the same as -import with the same arguments"
(B) "Quit compiling now if the module is not loaded into the compiler"
(C) "working from the leaves of the parse tree to the root,
whenever you see a call to a literal import function with
constant arguments, call the function and use the value it
(D) "if there is a call to such a function in a pattern or guard which
is _not_ resolved at compile time, provide an intelligible error
message and reject the module."
This could be prototyped using a transformation module, but
- it is the smallest change to Erlang syntax I can think of that would
achieve the goal
- it requires the least change to Erlang-processing tools such as
- it completely solves the specified problem
- it doesn't require new token-level syntax
- it makes the link to the module that provides the conversion explicit
- lots of other good stuff.
* 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?
I have found that a Haskell-like syntax for Erlang would fairly consistently
yield modules with only 5/8 as many SLOC. I'm a Lisp fan, implementor, and
user from way back, but in this case it's exactly the opposite of the right
Lisp doesn't get its power from its *concrete* syntax but from its
More information about the erlang-questions