[erlang-questions] some language changes

[ok]

About '<atom> "<not really a string>", including 'subst',
On 22 May 2007, at 1:58 pm, Vladislav Titov wrote:

> These two sound like they'd be perfectly matched by something like
> CL's reader macro concept.

The problem with read-macros is that they tie the *syntax* of the
programming language to *user-defined* functions in the *same*
language.  As a result, it is technically impossible to write a
program (such as a helpful editor!) which can decipher Common Lisp
source files without providing a full implementation of Common Lisp.
You can't even lexically analyse Common Lisp without *being* Common
Lisp.

The only thing that saves Common Lisp in practice is that these days
people tend to be very very wary of using this facility.  Common uses
are
  - using ? to introduce some kind of logical or pattern variable
    (or, of course, to provide some degree of compatibility with Emacs
     Lisp)
  - defining [...] and/or {...} to do something useful (example in CLtL)

One reason they are reluctant to make larger changes is that
they would have to abandon editor support.  (Not every CL programmer
uses an editor written in CL.)

Common Lisp read macros are of course far worse than Erlang parse
transforms, because (a) you can't even *lex* Common Lisp without
being Common Lisp and (b) the (re)definition of a read-macro character
may be in the very same file that you are reading.

All of this stuff was present in Pop-2 years and years ago.  It's easy
enough to implement.  The problem is what it does to you when you USE  
it.
I suspect that most Pop programmers were delighted to abandon Pop's
low-level macrology for the 'forms' facility; I know I was.

> This would allow for a range of nice features, from extending the
> language with new literal type (:pid <0,1,2>), to some fancy
> metaprogramming tricks (:bitcount(X) would turn into element(X,
> {0,1,1,2,1,...})). It brings in some of the functionality of CL macros
> without all the nasty AST stuff.
>

This is completely back to front.  The "AST stuff" is *far* less trouble
to tools than read-level stuff.  At least you can *lex* the stuff; at
least parenthesis-balancing still works!