Re: Regexp Alternatives (was Re: Wondering what I'm doing wrong?)

Just tried an experiment in Parseq. It is strictly recursive descent unless you go an extra mile to invoke Packrat parsing. Hence it can’t handle left-recursive grammars.

So, okay, what about right-recursive grammars? There are two ways to write a parser for an integer with interspersed seperator elements,  like comma and underscore:

WIthout recursion, and more like a regexp:

(defrule digits     () (and (+ digit) (* (and sep (+ digit))))
  (:string))

or else, with right recursion:

(defrule digits ()  (or (and (+ digit) sep digits)
                      (+ digit))
  (:string))

These two rules ought to match the same thing. And in isolation they do. Everything seems to work fine. But after doing the Right-Recursive conversion to all such rules, my system freezes up at load time with an error, claiming to have run into a Left-Recursion error.

I’m still tracking that down. I don’t know if I did something wrong (most likely), or else there is some bug that I tickled in the Parseq system.



> On Jun 11, 2026, at 19:14, David McClain <[email protected]> wrote:
> 
>>> Yes, I’ll give it a go. But there is no equivalent for SBCL, and I was trying for portability. 
>> Yabbut we *are* talking on a LW mailing list :)
>> 
> Yes we are. My preferred weapon has always been LW, for the past 35 years. But I’m an old dude, and with inflation raging the way it is, I might not be able to afford my LW Licenses someday. And I don’t want to be caught without some Lisp for me to use.
> 
> I have also found that. when possible, keeping things portable is helpful for others. But some things in LW simply don’t have any equivalent. AFIAK, the Async Socket protocol is a huge one in favor of LW.
> 
> 
>> On Jun 11, 2026, at 18:13, Adam Weaver (as adam at cleversure dot com dot au) <[email protected]> wrote:
>> 
>> Re-arranged, because top-posting is a sin.
>> 
>>>> On Jun 11, 2026, at 17:45, Adam Weaver (as adam at cleversure dot com dot au) <[email protected]> <mailto:[email protected]> wrote:
>>>> 
>>>> DM, I don't suppose you're interested in trying your number parser out 
>>>> using LW's built-in PARSERGEN package?
>> 
>> > On 12/6/26 09:05, David McClain wrote:
>>> Yes, I’ll give it a go. But there is no equivalent for SBCL, and I was trying for portability. 
>> Yabbut we *are* talking on a LW mailing list :)
>> 
>>> Also, IIRC, the Parsergen in LW needs a lexical analyzer built for it. All my other parsers do the lexical analysis in stride as part of the parsing.
>> True, but that's easily fixed with some macrology. **
>> 
>> I might have a crack at this over the weekend - distraction over doing Real Work instead :)
>> 
>>> The one thing I found, about Parseq (dunno yet about ESRAP), unlike a regexp matcher where you can anchor the pattern to the end of the line, you have to manually do your anchoring in the parsing grammar. I do that with an EOS Rule:
>>> 
>>> (defrule eos () (* char)
>>>   (:test (&rest es)
>>>    (null es)))
>> Noice. 
>> 
>> A
>> 
>> ** I did once experiment with some read-macrology to convert a PCRE style regexp into the built-in Lispworks regexp format (which I think was Emacs inspired). It was fuuuuuuuuuuuggggggleeeeeeeeeeee.
>> 
>