Re: Wondering what I'm doing wrong?

Now this is interesting… staying in Lisp for the moment… I looked at ESRAP. 

I am crossing the boundary between lexical analysis and parsing, and the ESRAP parser is very readable compared to the “line noise” of regular expressions.

Thanks for pointing this out...

> On Jun 10, 2026, at 13:37, Paul Tarvydas (as paultarvydas at gmail dot com) <[email protected]> wrote:
> 
> aside: 
> 
> I tend to fool around with syntaxes and have given up on regex and LR stuff. I use PEG parsing for everything ("ESRAP" in CL ; OhmJS is even better since it comes with a grammar REPL called "ohm-editor". The "JS” in the name doesn't matter much if you just want to map any syntax to some other syntax (JS or not). My first use of OhmJS was to map a Scheme program to node.js (Nils Holm's "Prolog Control in 6 Slides" code))
> I have given up on the 20th century definition of "efficiency". In the 21st century, "efficiency" takes on different meanings when applied to development vs. production code. In the 20th century, machines were so expensive that we couldn't afford to waste cycles on development tools. That issue has evaporated.
> I'm using OhmJS to create lisp-like macros for text-based languages.
> pt
> 
>> On Jun 10, 2026, at 3:49 PM, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> I think I may have discovered why named patterns have been so hidden or non-existent…
>> 
>> In reading through the documentation on the main Perl site, I found this snippet in the section discussing the (?&xxx) syntax along with DEFINE for named patterns:
>> 
>> "Also, it's worth noting that patterns defined this way probably will not be as efficient, as the optimizer is not very clever about handling them.”
>> 
>> It should be noted that the named registers mentioned yesterday are indeed what I suspected - simply a way of naming a submatch span which could be used in the body of a Perl program to refer to the submatch. Not at all the same as a named pattern.
>> 
>> I wrote my NFA pattern matcher about 30 years ago, using the info I had from Ulman and some famous algorithm for transforming a RE matcher into an NFA. I don’t know if that is more or less efficient than what Perl and CL-PPCRE perform. 
>> 
>> Reading hints in the source code for CL-PPCRE indicates that, if given free reign, CL-PPCRE could use very fast algorithms and soak up large space with character class tables. That probably allows it to speed along at the cost of memory. 
>> 
>> But unless you specify the correct global settings to allow the compiler to produce these fast matchers, you end up getting the default matcher for less memory consumption. My bet is that the result is about as fast as an NFA matcher.
>> 
>> As for the LW regexp system, it seems pretty anemic in comparison to CL-PPCRE, and its regexp pattern strings are much noisier with \(, \|, and \), all over the place (meaning strings that have to look like “^\\(xyz\\|uvw\\)+$” — too many \\. Makes me crosseyed). Seems more like Emacs regexps. And since SBCL does not have any regexps, it looks like staying with my "(?&…)” augmented CL-PPCRE is the way to go.
>> 
>> 
>> 
>