Re: To get things started...

Dan Sugalski <[email protected]> wrote:

 > At 07:36 AM 11/21/00 -0500, David Grove wrote:
 > >However, one thing is seriously lacking in this theory... if the
parser is
 > >perl, how does the perl parse? (Sort of a woodchuck chucking wood type
of
 > >thing.) Somehow, the external parser API thingy has to know enough
perl
 > >(through the chosen language) to be able to handle the parsing.
 > 
 > Nope. We do it in two phases. The end result will not actually parse
perl 
 > code to build the parser (we'll provide bytecode for that) but to start
we 
 > can run the parser through perl 5 to get a syntax tree until the perl 6

 > engine's capable of doing it itself.

Hmmm, that sounds familiar...

</me ducks>

 > >To quote my perl elders, whatever can be done without regexen should
be
 > >done with index() (within limits, since some regexen can be quite
 > >optimized).
 > 
 > No, not really. regexes are generally easier to comprehend than their
 > index 
 > couterparts, and often faster. (There's a lot of code that needs to go
 > into 
 > backtracking...) While index might be better sometimes we can't force
 > folks 
 > to use it. Almost all of perl is up for grabs.

I won't argue the point as long as it works, the point being that we do it
with whatever method is capable of the greatest efficiency.

 > >The parser API needs to know both regexen and index() in order to
work.
 > 
 > The parser will have a fully-functional interpreter to work with. All
of 
 > perl will likely be there for it. (Modules and threads might not, but 
 > that's still up in the air)

But that "interpreter" will be in the form of API, right?

 > >  > * The parser will have an active interpreter structure handy
 > >
 > >Is this the perl that parses the perl?
 > 
 > Yup. In fact we might have two--the interpreter structure for the 
 > interpreter running the parser, and the structure for the end-result
 > parsed 
 > program. Or we might just use one and squirrel all the interpreter bits
in 
 > a private (and deletable) namespace somewhere.

It's pretty clear that we're to purposely put in a distinct separation
between the two, unless I misunderstood Larry on this. I'm cautious about
dual-purposing anything here, since he said that this is a major problem
in Perl 5 today (the lack of flexibility between either end).

I'd like to ask for a clarification of the following terms as they apply
here:

1. External API
2. Internal API
3. Parser
4. Interpreter
5. What seems to be my "toplevel" parser (the creole parser)
6. Bytecode
7. Syntax Tree

And what language they should be in (if Larry's undefined language, just
say C-Larry or something), what they input, and what they output, what
what they input from and output to in terms of the next level of
functionality. I think we're on the same wavelength, but not speaking the
same language.

I'd also like to offer an explanation. As I mentioned earlier, I've
already been working on a perlish to perl translator, so the "toplevel
creole parser" as is particularly interesting to me as something that I've
basically already worked on, so it's where my head is. The different
output modes as well, because they're just the top turned upside down...
forgive my lack of attention to (and understanding of) the middleparts.

p