new syntax - a provocation

[Richard A. O'Keefe]

"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
	    #[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.
	
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
    bitset([3,45,27,39])
*except* that you might want to use it in pattern matches and guards.

All it takes is a declaration.  For argument's sake,

    -import_literal(my_stuff, [bitset/1]).

with the interpretation

(A) "Do the same as -import with the same arguments"
AND
(B) "Quit compiling now if the module is not loaded into the compiler"
AND
(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
     returns."
AND
(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
  editor modes
- 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
direction.

Lisp doesn't get its power from its *concrete* syntax but from its
*abstract* syntax.