Tue Jun 2 23:54:00 CEST 2009
On 2 Jun 2009, at 7:08 pm, Vlad Dumitrescu wrote:
> As a programmer I like this way of handling this kind of issues
> because it works now and it's easy.
> As developer of a source handling tool I can't help but cringe at the
> prospect of getting requests to support all kinds of homegrown
You mean like regular expression syntaxes?
I've lost count of the number of different variations of
regular expression syntax I've seen in UNIX.
The point of the wee tool I mentioned of course was to provide
> Another problem with external processing of the source files is that
> it is at the same level as the preprocessor,
Well, no, it understands far less of Erlang syntax than the
Erlang preprocessor does, and operates way before it. But
*any* program that computes source code by *any* means can
be called a "preprocessor". I have a Smalltalk-to-C compiler.
You could call that a preprocessor if you like. I don't think
the word itself helps our understanding very much.
> which many people would
> like to see replaced with one that understands Erlang code.
Up to the word "replaced" I was happy. We have parse transforms.
We have Lisp-Flavoured Erlang. If you want preprocessing that
can "intelligently" deal with Erlang source code, LFE is _it_.
But that leaves complicated backslashy regular expressions where
There is of course a much better way to deal with regular
expressions in a language like Lisp or Erlang. One of my pet
slogans is "STRINGS ARE WRONG". The way to represent something
like "^[[:alpha:]_][[:alnum:]_]*:[[:space:]]" is
where regular expression syntax is replaced by Erlang syntax.
This is so much more powerful than fancy quoting schemes for
strings that it just isn't funny: you can compute any subexpression
at any time you find useful _without_ new syntax, and without any
> best regards,
More information about the erlang-questions