[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nyacc question: [found] where are the actions bound?

From: Matt Wette
Subject: Re: Nyacc question: [found] where are the actions bound?
Date: Sat, 14 Mar 2020 07:31:10 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 3/14/20 4:59 AM, address@hidden wrote:
On Sun, Mar 08, 2020 at 08:10:50AM -0700, Matt Wette wrote:

On 3/8/20 3:14 AM, address@hidden wrote:

My question is: where is the stuff resolved which is mentioned
in grammar actions?
Hah. Managed to answer my own question by reading the source.

For the benefits of others who might have a similar question
(without knowing how to articulate it, like it happened to
me), here's the answer:

Yes, the actions are "resolved" wrt the (calling) module's
top level environment. The magic happens here (that's wrt the
all-fresh V1.01.2), around lines 47 ff, in module/nyacc/parse.scm:

   (define (make-xct av)
     (if (procedure? (vector-ref av 0))
         (vector-map (lambda (ix f) (eval f (current-module)))
       (vector-map (lambda (ix actn) (wrap-action actn)) av))))

It's the (eval f (current-module)) which does the trick. The
trick happens in make-lalr-parser.

Background: I envisioned something like

   (let ( ...some environment for the actions...)

and have make-lalr-parser pick up the bindings in the lexical

but had to realize that make-lalr-parser ignores the lexical
environment. That's now clear to me, because (eval ... (current-module))
looks at the caller's module's top-level bindings.

One would have to call local-eval (from (ice-9 local-eval)) and
explicitly pass (the-environment) (from the same module) to
achieve what I had in mind.

Not that I'm proposing that, mind you. I still barely know what
I'm doing at this point. Probably there are very good reasons
to resort to the (top-level) module bindings.

I just wanted to understand, and I think I do now :-)

As to your other proposal (writing out the pre-compiled parser
with write-lalr-*), I think it's orthogonal to my issue. This
might come in handy when the parser is heavy enough that it
takes a significant time constructing it (which it is not in my
little use case for now)

Thanks & cheers
-- tomás
I get it now.  What you expect makes much sense.
 I will think about that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]