Re: Stupid module and pregexp questions

[Tom Lord]

    > From: Thien-Thi Nguyen <address@hidden>

    >    From: Tom Lord <address@hidden>
    >    Date: Sun, 4 May 2003 23:18:08 -0700 (PDT)

    >    Guile-dialect regexp choices should be (imho) no less casual than,
    >    say, number-tower choices.

    > but a tower is an abstract model that is supported to varying degrees
    > when it comes to compilation down to the the physical layer.  

That's equally true of regexps.

    > why are surface regexp syntaxes different?  

I believe I said they were similar, not different -- so I'm not sure
why you ask me why they are different.

    > sure, there are non-dfa-friendly approaches, so provide
    > non-dfa-requiring compilation for those.  

Although you're mostly posting ink-blots to the list today (or because
of that) I'll say (loosely, but I think it could be tighted up):

The chomsky hierarchy points to some platonic truth that has real and
practical implications for programs.   If you stick to the lower
levels of the hierarchy, you get better performance guarantees than if
you don't.

In the history of the design of programming language, including regexp
languages, we have on the one hand that abstract observation about
performance along the chomsky hierarchy, and on the other hand the
historical accident of standard regexp languages ignoring that
observation.   It's easy to tweak a backtracking "true regular
expression" engine to add, for example, subexpression position capture
and backreferencing.    Perl regexps are an example of what happens if
you plop yourself down on a sled at the top of that slippery slope.

The history is easy to understand:  on dinky-little 1970s hardware
(for example) a dynamic pattern matching pretty much has to be
implemented as a backtracking engine.   If I give you source code to a
backtracking engine, it's easy to make incremental tweaks to it which
are very convenient -- but which also raise the nature of that engine
on the scale of the chomsky hierarchy.

The so-far (mostly) unasked question is whether we can achieve similar
(practical, not theoretic) expressivity to those tweaked matchers
_without_ climbing the chomsky hierarchy:  can we be fast and
convenient at the same time?



    > at the bottom it's all just fixed-width NANDs and NORs
    > (logically speaking)...

What's your point?   I don't see how that observation relates to
choices in language or run-time system design.    Are you off your
meds?

"nothing really matters, to me" -- Queen (Bohemian Rhapsody)
-t