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

[Richard O'Keefe]

>> There's no getting away from strings in practice,
>> and some strings have many escapes in them.
>>
>>
>> Going back to the OP, the string "(?<!\\\\)#" can of course
>> already be expressed in Erlang without escaping issues:
>>
>> [40,63,60,33,92,92,41,35]


One of the most thought-provoking ideas I heard about programming
came from Xerox PARC:  "A program is not a listing."  Tie that in
with the notion of "resources" from Classic MacOS, now widespread
(in Java, for example).

Accepted that a regular expression is needed.
Accepted that it is needed in a particular module.
But why does it have to be WRITTEN in that module?

One of the reasons for "resources" is so that they can be
revised (localised or otherwise maintained) without having
to modify the program, perhaps even without access to the
source code.  And yes, I _have_ edited the resources of a
Classic C program that I didn't have the sources for.  (I
found that using Cmd-Q to mean "query" when I expected it
to mean "Quit" was just too confusing; there were quite a
number of issues like that with it.)  Many of you will have
had similar experiences.

So if you have complex regular expressions, which because of
their complexity are very likely to need maintenance, why not
get them from a resource bundle?

I'll skip over the reduction to absurdity of a position I don't
hold and haven't even hinted at.  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.

I have as little to do with SQL as I can, and even so, I've
seen so much SQL-generation done wrong with strings that whenever
anyone talks about wanting something strange done to strings to
make it easier to embed some other language in string literals
that I immediately think of SQL.  And of course the really rather
nasty way that the DOM reveals *comments* of all things in XML,
because of the way people used to hide scripts inside comments
so they wouldn't have to turn < into <.

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.

There are *lots* of things we can do in the mean time.
- trees
- preprocessors
- resource bundles
- the sky is your limit IF you aren't fixated on string literals.

>> Perhaps we can agree that there can be differences in opinion
>> as to whether there is still room for more syntactic sugar
>> regarding strings in Erlang?

I am having difficulty interpreting that statement in any way that
doesn't have the answer "NO, it is a simple fact that there is
plenty of room."  The question is what to DO with that room, and
in particular, whether to spend any of it on a clunky NON-solution
to a pervasive and important problem.
>>
>>
>> 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.  People who are unhappy with the
current convenience level of (doing the wrong thing) are correctly
unhappy.  It _is_ inconvenient.  Nor are they "simply confused".
They may be ignorant, or unimaginative, or simply seduced by other
languages that have gone down the immediately easy but long term
worthless route.  They may even simply be concentrating on the
problem at hand so much that they aren't _looking_ for a general
approach.  Mental "set" is a well known issue in problem-solving.
None of these things is "simple confusion".  But yes, if your
head is hurting from banging against a brick wall, maybe you should
stop the head banging instead of asking for a softer wall.

It is NOT 'subjective' that simply adding something like Lua's
unquoted string literals "[" "="^n "[" <char>* "]" "="^n "]"
-- though Erlang would have to require n>=1 instead of n>=0 --
would only help with ONE level of notation nesting, so it
won't help with an SQL pattern inside an SQL string inside an
Erlang string.