bison-patches
[Top][All Lists]
Advanced

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

Re: scanning actions twice in Bison


From: Paul Eggert
Subject: Re: scanning actions twice in Bison
Date: 14 May 2003 12:50:17 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

On 28 Mar 2003 Akim Demaille <address@hidden> writes:

> | I agree with decoupling scanning from type checking, but I'm not sure
> | I agree with scanning twice.  We should be able to design a system
> | that needs to scan only once.  This is not primarily for efficiency
> | reasons: it's because we need an easy-to-describe-to-users system
> | where the scanner is independent of the levels of software above it.
> 
> I don't understand your point here.  I'm precisely saying that the
> scanner does not depend on the higher levels, I'm claiming that
> everything should be parsed the same way, then an AST of the grammar
> should be built, and then, a traverse (very similar to type checking)
> would handle the context dependent issues such as how a "token" is
> handled (in the current case, how the $$ and other special markers in
> the actions, are translated).

OK, but then we need to tokenize the actions as we scan them.  That
can be done, but it'll require some hacking.  In the meantime I'd
rather live with the current solution than to go with an inferior
approach where the actions are scanned twice.

> | I am worried about the prospect of scanning the input twice, with
> | different scanners that use different scanning algorithms, and which
> | issue diagnostics in different ways.  In the end I think we'd have to
> | confess this stuff to the user, just as the GCC documentation
> | confesses to the user how many times GCC actually scans the input.
> 
> I don't see that.  Just as I never had to face the GCC documentation
> you are referring to.

Worse: I had to maintain one of the scanners, and it was always
slightly out of sync with the other one.  Eventually the GCC
maintainers incorporated cpp as part of gcc (rather than as a separate
process); this simplified maintenance.  Also, it removed one big
maintenance task from my list of volunteer work (yayy!).




reply via email to

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