Re: rfc: curvbol - a lisp language for processing text (long)

Klaus Harbo <[email protected]> writes:

> Since it seems that I have been struggling with similar challenges as
> Marco's, I thought I'd chip in with the approach I've taken to deal
> with the horrors of using regular expressions to do text pattern
> matching.  I've put a (thin) syntactical layer on top of Edi Weitz'
> cl-ppcre package which enables the definition and use of (Perl)
> regular expression abstractions.

my comments:

0) nice, very nice. had i known about it a few weeks ago i probably
   wouldn't have bother with curvbol.

1) we both re-invented the GOTO/GOPAST or UPTO/UPTO+
   abstraction. someone should think about what this means.

2) curvbol is not easy to understand. i don't know whether this is due
   to some intrinsic quality of the curvbol approach or due to the
   fact that it's a new language. however you were able, eventually,
   to figure out exactly what text that curvbol program was supposed
   to match.

3) regexps are a great foundation, but they aren't enough for complex
   (aka Real World) problems.

There are only three differences between defpatt and curvbol i think are
still worth mentioning:

- The REVERSE and BACKWARDS operators. These are, in perl terms, non
  constant length positive/negtive look-behinds, they make certain
  operations much simpler to write (even though they can always
  (afaict) be re-written as a regular expression).

- The curvbol env is an alist, when extending the environment we don't
  actually change the alist, we just push new a cons, this means that
  our "registers" are more like stacks than registers. the curvbol
  equivalent of (.)* would return in the environment every character
  in the text.

- defpatt is much, much, faster than curvbol. :)

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen