On Tue, Nov 21, 2000 at 10:37:23AM +0000, David Grove wrote:
> I'm not sure that it's possible to do this, or disirable. If Larry wants
> Perl to use different modes, creoles, or ways of interpreting or
> understanding the "perl" language, then we have to let the parser have a
> bit more information.
Yes, but these don't have to be external level calls.
> As a point of clarification, I am seeing the external parser as that part
> of perl that sees the user's script directly.
Likewise.
This is why the "creole" rulesets are *not* external calls.
Syntax definitions, in the form of Perl programs or pragmata, will have to go
through two stages before they can be used. First, they have to be parsed as
Perl code. This is a call to the external API of the parser.
Once this is done, the resulting op tree must be processed so that it can be
turned into a data structure (representing the grammar) which can be
understood by the parser.
So, something's gone into the parser, and the parser has determined that this
is a language definition - the parser then passes it off to the
grammar-processor which constructs a grammar for it, and hands the grammar
back to the parser. At this level, it is not "seeing the user's script
directly", and thus I would say that the communication between the
grammar-processor and the parser was an internal level API.
> I don't think so. In a compiler I don't believe that the intermediate step
> is there,
I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles,
Techniques and Tools".
> and I've never seen any compiler accept multiple input semantics
> and multiple output (meaning binary, bytecode, java, c#) (okay, C++
> Builder can accept pascal... but that's an one).
gcc is a compiler which can receive C, C++, Objective C, and Fortran
input, and produce output for quite an array of architectures.
--
A successful [software] tool is one that was used to do something
undreamed of by its author.
-- S. C. Johnson
