Dave Storrs <[EMAIL PROTECTED]> writes:
>On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
>
>> Yet another bummer of the current SVs is that they poorly fit into
>> 'foreign memory' situations where the buffer is managed by something
>> else than Perl. "No, thank you, Perl, keep your greedy fingers
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
> >On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
> >
> >> Yet another bummer of the current SVs is that they poorly fit into
> >> 'foreign memory' situations where the buffer is managed by something
> >> else tha
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I doubt it; I get the feeling that what Dan is talking about is infinite
> look-*behind*. Nine times out of ten, you won't need to redo your parsing,
> so having an infinite lookahead will just slow everything down
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The third parameter is the flags parameter, and it's optional. If omitted
> or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> null-terminated string. If set to PERL_COUNTED_SOURCE, the sec
On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second parameter is treated as a sta
On Tue, Nov 28, 2000 at 06:58:57PM +, Tom Hughes wrote:
> I didn't say that having infinite lookahead was better than allowing
> backtracking. I simply said that the two were equivalent and that any
> problem that can be solved by one can be solved by the other.
Fair enough.
> That's quite a
At 06:58 PM 11/28/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > I doubt it; I get the feeling that what Dan is talking about is infinite
> > look-*behind*. Nine times out of ten, you won't need to redo your parsing,
> > so hav
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
On Mon, 27 Nov 2000, Dan Sugalski wrote:
> ---
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
>
> The third parameter is the flags parameter, and it's optional. If omitted
> o
At 07:03 PM 11/28/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> > null-t
At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > Applying the maxim that any software design problem can be solved
> > with sufficient levels of abstraction I'd suggest that passing some
>
>A related warning sign is trying to cra
At 09:10 AM 11/28/00 -1000, Tim Jenness wrote:
>On Mon, 27 Nov 2000, Dan Sugalski wrote:
>
> > ---
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
> >
>
> > The third para
On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > is treated as if it points to a stream of bytes, where the first four are
I spy magic number.
> > > the length of the source to be read followed by the
Bart Lateur <[EMAIL PROTECTED]> writes:
>
>But what if you choose wrong, forgat a really important one, and this
>instruction gets a multibyte representation? We're stuck with it
>forever...?
>
>I have had some thoughts on "dynamic opcodes", where the meaning of
>opcode bytes needn't be fixed, but
On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > Applying the maxim that any software design problem can be solved
> > > with sufficient levels of abstraction I'
Err, this seems a little too Swiss Army Knife.
This reads like a utility function. (i.e. A function that handles the
most common scenerio.)
Shouldn't a set of lower level visible API be visible? One that seems
to pop out at me is some way of actually parsing a piece of code and
ending up with a
On Tue, Nov 28, 2000 at 03:15:35PM -0600, Jarkko Hietaniemi wrote:
> On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim that any software
At 03:15 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim that any software design problem
At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > > is treated as if it points to a stream of bytes, where the first
> four are
>
>
>I spy magic number.
Nicholas Clark <[EMAIL PROTECTED]> writes:
>On Mon, Nov 27, 2000 at 05:17:47PM +, Nicholas Clark wrote:
>> On Mon, Nov 27, 2000 at 11:09:03AM -0500, Chaim Frenkel wrote:
>> > > "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
>>
>> > Look throught the RFCs this was one of Damian Conway's.
>
At 04:23 PM 11/28/00 -0500, Chaim Frenkel wrote:
>Err, this seems a little too Swiss Army Knife.
>
>This reads like a utility function. (i.e. A function that handles the
>most common scenerio.)
What it's supposed to be is the highest-level interface to the parser, and
so it's supposed to handle
> Is there any reasonable case where we would need to backtrack over
> successfully parsed source and redo the parsing? I'm not talking about the
> case where regular expressions run over text and ultimately fail, but
> rather cases where we need to chuck out part of what we have and restart?
]-
At 09:48 AM 11/28/00 -0800, Steve Fink wrote:
>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 fash
--- Steve Fink <[EMAIL PROTECTED]> wrote:
> 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 f
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(
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right, and I called my abstract stream "void *source". :)
It isn't really abstract though as it only understand types of streams
that the parser author had thought of. An abstract stream would have a
vtable or som
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Parsing Perl is not easy. :)
You can say that again ;-)
> At some points, you have to say, well, heck, I don't *know* what this token
> is. At the moment, perl guesses, and it guesses reasonably well. But
> guess
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
On Tue, 28 Nov 2000, Dan Sugalski wrote:
> >I also like the suggestion that rather than supply flags, we should
> >follow the lead and supply a Perl* something that would return an
> >appropriate bunch of text to the parser.
>
> I'd really rather not, since that would place the burden of knowing
29 matches
Mail list logo
