[erlang-questions] Adoption of perl/javascript-style regexp syntax

[Richard O'Keefe]

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

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
*non*-syntax.

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


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
	rex:seq([rex:bol(),rex:id(),rex:space()])
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
run-time parsing.


>
>
> best regards,
> Vlad
>