Bart Lateur wrote:
>
> On Tue, 21 Nov 2000 17:24:49 +, Simon Cozens wrote:
>
> >I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles,
> >Techniques and Tools".
>
> AKA "The Dragon Book". You're not the only one to mention this book on
> this list.
>
> IMO, this book is rea
Dan Sugalski wrote:
>
> You're not wrong, but I don't think this is a huge problem. Lots of systems
> do it like this at the moment--GCC comes to mind as a first one, but there
> are lots of others. Granted it does mean that we'll need to ship a
> bytecode-compiled version of the parser as part o
Dan Sugalski wrote:
>
> At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
> >Dan Sugalski wrote:
> > >
> > > It's also possible we'll do the parser mainly in C with perl hooks, but
> > > that's not the direction I've been poin
Dan Sugalski wrote:
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Given that other things may want to be streamable in similar fashion (eg
the regular expression engine), why not have a Per
Dan Sugalski wrote:
>
> Sure. Suggestions?
int perl6_parse(PerlInterp* interp, PerlIO* input);
PerlIO* make_memory_stream(char* buf, ssize_t length); // length=-1 for
nul-terminated
int close_stream(PerlIO* stream);
then if you read further, you'll eventually see:
PerlIO* make_callback_stream(
Tom Hughes wrote:
>
> In message <[EMAIL PROTECTED]>
> Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > In a sense, though, you're right; this is a general problem. I'm currently
> > trying to work out a design for a tokeniser, and it seems to me that
> > there's going to be a lot of comm
Chaim Frenkel wrote:
>
> >>>>> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
>
> SF> Handling the parser's state can be done in a backtracking DFA-like or a
> SF> direct NFA-like way. The NFA way is to keep track of all possible parse
&
Dan Sugalski wrote:
>
> At 04:16 PM 11/28/00 -0800, Steve Fink wrote:
> >Perl5 is parseable with a single token of lookahead and lots of
> >parser/lexer communication. Sort of. It would be nice to prevent it from
> >getting any worse.
>
> I'm really t
I'm wondering if we should explicitly break out the languages that
comprise perl today. That'd be at least toplevel perl, regular
expressions, and pack. Maybe tr// and the second half of s/// are
sufficiently different too. If nothing else, it would highlight the
problems in switching languages mi
That is way cool.
Though I'm not sure that all of the constructs of another language are
going to be that easy to map into perl opcodes. Arithmetic, sure. But
perl opcodes aren't exactly a universal intermediate language.
Just in looking at your example, it seems like some complex replacements
w
10 matches
Mail list logo
