new syntax - a provocation

[Vlad Dumitrescu]

From: "Richard A. O'Keefe"
> 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."

A good idea! Why not let the calls that can't be resolved at compile time expand
into a run-time constructor call? Well, at least where this is meaningful.

> 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.

Good points. My original goal was to be able to introduce new types, and to be
able to initialize and build the data easily (from a source code point of view).
Your way would work fine too, I think. Is it extensible to other similar
problems? I think it is.

But I still think it might be a good thing to mark in some way that these
constructs are special ;-)

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

True, but in Lisp's case the two are the same :)

/Vlad