At 09:34 PM 8/10/00 -0400, Bradley M. Kuhn wrote:
>Three notes on the Syntax tree (which I would probably call Intermediate
>Representation, or IR, but the name is irrelevant :).
Yep. It's more a MI, with bytecodes being an LI. (And both are IRs) I've
been browsing through compiler design books,
At 06:29 PM 8/10/00 -0700, Matthew Cline wrote:
>On Thu, 10 Aug 2000, Dan Sugalski wrote:
>
> > With each box being replaceable, and the process being freezable between
> > boxes. The lexer and parser probably ought to be separated, thinking about
> > it, and we probably want to allow folks to wed
On Thu, 10 Aug 2000, Dan Sugalski wrote:
> With each box being replaceable, and the process being freezable between
> boxes. The lexer and parser probably ought to be separated, thinking about
> it.
Not necessarily. It might be dangerous to change what the lexer think
is a token. You might b
Dan Sugalski wrote:
> At 10:01 PM 8/9/00 -0600, Nathan Torkington wrote:
> >Would it make sense for the parsing of a Perl program to be done as:
> > - tokenize without rewriting (e.g., use stays as it is)
> > - structure without rewriting (e.g., constant subs are unfolded)
> > - rewrite for opt
On Thu, 10 Aug 2000, Dan Sugalski wrote:
> With each box being replaceable, and the process being freezable between
> boxes. The lexer and parser probably ought to be separated, thinking about
> it, and we probably want to allow folks to wedge at least C code into each
> bit. (I'm not sure whethe
At 03:36 PM 8/10/00 -0400, Chaim Frenkel wrote:
>You may also want to be able to short circuit some of the steps.
>Especially where the startup time may outweigh the win of optimization.
The only one that's skippable is the optimizer, really. I'd planned on
having to pass it some indicator of h
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> - source filters munge the pure source code
NT> - cpp-like macros would work with token streams
NT> - pretty printers need unmunged tokens in an unoptimized tree, which
NT>may well be unfeasible
I was thinking of macros as be
You may also want to be able to short circuit some of the steps.
Especially where the startup time may outweigh the win of optimization.
And if there could be different execution engines. Machine level,
bytecode, (and perhaps straight out of the syntax tree.)
Hmm, might that make some debugging
At 10:01 PM 8/9/00 -0600, Nathan Torkington wrote:
>Would it make sense for the parsing of a Perl program to be done as:
> - tokenize without rewriting (e.g., use stays as it is)
> - structure without rewriting (e.g., constant subs are unfolded)
> - rewrite for optimizations and actual ops
The
At 09:57 PM 8/9/00 -0700, Matthew Cline wrote:
>On Wed, 09 Aug 2000, Nathan Torkington wrote:
> > It seems to me that a perl5 program exists as several things:
> > - pure source code (ASCII or Unicode)
> > - a stream of tokens from the parser
> > - a munged stream of tokens from the parser (e.g
On Wed, 09 Aug 2000, Nathan Torkington wrote:
> It seems to me that a perl5 program exists as several things:
> - pure source code (ASCII or Unicode)
> - a stream of tokens from the parser
> - a munged stream of tokens from the parser (e.g., use Foo has
>become BEGIN { require Foo; Foo->im
It seems to me that a perl5 program exists as several things:
- pure source code (ASCII or Unicode)
- a stream of tokens from the parser
- a munged stream of tokens from the parser (e.g., use Foo has
become BEGIN { require Foo; Foo->import })
- an unthreaded and unoptimized optree
- a thr
12 matches
Mail list logo
