Re: figuring out behaviour of peg

[Arun Isaac]

Hi Malte,

> Multiple consecutive module definitions also are parsed into a
> list. This *should* also not be the case. So is there a way to avoid
> this? I guess it has something to do with ()* clauses in the grammar
> definition?

This is another pain point with peg, but I don't know if it can be
helped. Like you noted, it has to do with the ()* clauses from the
following definition in your grammar.

> list       <-- listlb ws? listrb / listlb ws? comment* ws? value (comma 
> comment* ws? value)* comma? ws? comment* listrb

I normally handle this by post processing the parse tree using
pre-post-order. See below for code snippet.

> (pretty-print (peg:tree (match-pattern blueprint *bp*)))

--8<---------------cut here---------------start------------->8---
(pretty-print
 (pre-post-order
  (peg:tree (match-pattern blueprint *bp*))
  `((list *macro* . ,(lambda (_ . values)
                       (filter list? (keyword-flatten '(value) values))))
    (*text* . ,(lambda (_ value) value))
    (*default* . ,(lambda tree tree)))))
--8<---------------cut here---------------end--------------->8---

You could also see my use of macro-process-address-list in guile-email
at https://git.systemreboot.net/guile-email/plain/email/email.scm

> (define *bp*
>   (read-delimited "" (open-input-file (cadr (command-line))) 'concat))

A minor nitpick: You could use call-with-input-file instead of
open-input-file. call-with-input-file automatically closes the port
after use.

signature.asc
Description: PGP signature