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

[Ulf Wiger]

Richard O'Keefe wrote:
> 
> I'll skip over the reduction to absurdity of a position I
 > don't hold and haven't even hinted at.

On the other hand, you have put forth a number of
absurdly complex examples of expressions represented
as strings that certainly all people involved in this
particular thread would attack using a structured data
type rather than strings. ;-)

This time, the example included SQL. Yariv Sadan wrote
a very nice library called ErlyDB which made it possible
to express SQL queries as simple erlang terms.

As elegant as it was, it also had limitations. For the
longest time, it only supported MySQL. I would guess that
for many applications, it would have been possible to
instead use ODBC and formulate SQL queries that were
regular enough that they would work against just about
any DBMS.

(Sure, Yariv could e.g. have built ErlyDB on top of ODBC
and used text as an intermediate representation. This
would have made ErlyDB just as compatible as ODBC is,
but I'm sure he had lots of good reasons for not doing
this. As ErlyDB isn't (?) actively maintained anymore,
perhaps parts of it could indeed be converted into a
library on top of OTP's ODBC and made available as a
library for simpler handling of SQL queries? I'm
shooting from the hip here - there may be reasons I'm
not aware of why this would be a lousy idea.)

Regarding the examples with XML and the suggestions
that it is *much* better to generate XML from structured
erlang terms than to write them as strings, surely you are
aware that I wrote the library that is now in OTP for doing
just that. I remember that you were even at the EUC when I
first presented it. My recollection is backed up by the
fact that you even presented right before me (EUC 00).
Granted, this was long ago, but given your almost unlimited
capacity for anectodal references (which I admire and appreciate
btw), I thought it might not have escaped your memory.

When I last had reason to deal with large volumes of
imported text, which was to be translated into compiled
erlang code, I used Joe's ML9 for storing the text chunks
on disk, thereby avoiding all escaping issues, and built
abstract forms that I pretty-printed as-needed for
debugging purposes.

So, of course, when the problem calls for it, most of us
would do just what you suggest.

> I'm not against additions to
> Erlang syntax.  I've proposed quite a few myself.  I'm against
> *THIS* one because it doesn't actually solve the problem it has
> been proposed for, and because there are simpler, cleaner, more
> powerful techniques already available
> 
>     once you get over the idea that non-Erlang stuff
>     has to be string literals in source code.

And this seems to me the source of the disconnect.
Neither Vlad, Mats or I have any hangups of the sort.
I don't believe there has been any evidence on the list
to suggest that we do. On the contrary, I would say.

Granted, Mats might be a suspect since he was one of the
early advocates of including a fast regexp library in
Erlang. OTOH, his work on gtknode is a great example of
how some clever compile-time processing can eliminate
a huge amount of complex and error-prone programming.

> Please, by all means, LET'S have an addition to Erlang 
 > syntax that makes it easy to deal with the regular
 > expression problem *AND* the XML problem *AND* the
 > SQL program *AND* ... *AND* all of them together.
 > But let's NOT waste our time with clunky
> incomplete solutions.

Sure, by all means.

But I'm not sure I have been able to glean from your
posts so far what is "clunky" about the slight additional
sugar that I proposed (essentially taking the LaTex \verb
command and replacing \verb with some suitable token - I
suggested `, which is perhaps a bit too quiet, but "clunky"?)

Incomplete - yes of course. It is not a complete solution by
any reasonable definition of 'complete'. Nor was it ever
advertised as such. It was intended as a lightweight way of
simplifying the use of e.g. the re library (but not being
limited to regexps in any way.)

>>> The claim that anyone who's unhappy with the current convenience
>>> level is simply confused, and in need of the therapeutic pain
>>> caused by rubbing up against double escaping in complex strings,
>>> is subjective. Wouldn't you agree?
> 
> Again, I'm having trouble with that.  To start with, as far as I
> know, nobody has made that claim. 

I'm glad if that is the case. It may have been my misinterpretation
of something you wrote earlier:

> That pain level is there
> for a good reason:  if the Erlang string syntax is giving you
> that much of a headache, it's because STRINGS ARE WRONG and you
> should almost certainly be using trees instead.

But then you go on and appear to back up that claim.

 > People who are unhappy with the current convenience level
 > of (doing the wrong thing) are correctly unhappy.

Am I not to interpret this as "they deserve to be unhappy"?

 > It _is_ inconvenient.  Nor are they "simply confused".
> They may be ignorant, or unimaginative, [...]

...or neither, but simply accepting the fact that stringy
representations of e.g. regexps are more or less a fact of
life. They may be working hard against a tight deadline
and unwilling to spend a significant portion of that
writing a support layer, or introducing special scripts
or macros that they will then have to convince the customer
to use. There may be all sorts of good reasons why they
would think that a tiny bit of added sugar on top of the
string syntax would be *just the thing* to solve 90% of
their headaches. For the remainder, I'm pretty sure they
would, just like you and I, resort to a more structured
way of addressing the problem, rather than banging their
heads against the wall.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com