# New Ticket Created by Rob Hoelz
# Please include the string: [perl #122631]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122631 >
=begin finish makes the parser seemingly entire an infinite loop. Thanks to
Ovid++
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #115282]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=115282 >
r: (;)
rakudo 8a07b8: OUTPUT«===SORRY!===Method 'returns' not found
for invoca
hi,
I see nobody is talking here ... so !
Anyone to have idea how the Parser will work... I mean mostly at the
language-developer side (not the internals).
It will be written in Perl, right ?! some striped-version of Perl ?! i.e.
what will be allowed and will not ?
Will it support lookahead
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:05 PM 12/12/00 +, David Mitchell wrote:
> >Also, some of the standard perumations would also need to do some
> >re-invoking, eg
> >($int - $num) would invoke Int->sub[NUM](sv1,sv2,0), which itself would
> >just fall
> >through to Num->sub[INT](
At 12:43 PM 12/17/00 -0500, Bradley M. Kuhn wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > and the above can come from
> > * memory (C's zero terminated strings, blocks with lengths, other things
> >native to other languages
> > * files (by filename, file/socket handle, C FILE*, C++ i
er else)
> * bytecode (which could be done as in perl5.6 with something like
> use Byteloader;..)
I am unclear why the parser would take bytecode as input. Wouldn't that be
direct input for the virtual machine?
> and the above can come from
> * memory (C's zero ter
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I was under the impression that ANSI C required that a void * be large
> enough to store any pointer type in it. Whether that's true or not's
> irrelevant at the moment, though we can work something out at some poi
At 02:36 PM 12/13/00 +, Nicholas Clark wrote:
>Ah. Digest system tells me some messages for me bounced.
>
> > From: Damien Neil <[EMAIL PROTECTED]>
> > On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
> > >int perl6_parse(PerlInterp *interp,
> > >void *sour
At 06:05 PM 12/12/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > > If we assume that ints and nums are perl builtins, and that some people
> > > have implemented the following external types: byte (
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> That is a Language and not an internals issue - Larry will tell us.
> But I suspect the answer is that it should "work" without any special
> stuff for simple perl5-ish types - because you need to be able to
> translate 98% of 98% of perl5 programs.
On Thu, Nov 30, 2000 at 06:43:35PM +, David Mitchell wrote:
> * do values ever get demoted - eg an expression inolving bigints that evaluates
> to 0: should this be returned as an int or a bigint?
[I may have mailed this already]
Experimentation on perl5 says yes.
Making the sv_setuv actuall
Ah. Digest system tells me some messages for me bounced.
> From: Damien Neil <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: The external interface for the parser piece
> Message-ID: <[EMAIL PROTECTED]>
> Mime-Version: 1.0
> Content-Type: text/plain; cha
On Tue, Dec 12, 2000 at 06:05:30PM +, David Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > > If we assume that ints and nums are perl builtins, and that some people
> > > have implemented the following externa
David Mitchell <[EMAIL PROTECTED]> writes:
>
>I think this this boils down to 2 important questions, and I'd be interested in
>hearing people's opinions of them.
>
>1. Does the Perl 6 language require some explicit syntax and/or semnatics to
>handle multiple and user-defined numeric types?
>Eg "my
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> > If we assume that ints and nums are perl builtins, and that some people
> > have implemented the following external types: byte (eg as implemented
> > as a specialised array type), bigre
On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
> If we assume that ints and nums are perl builtins, and that some people
> have implemented the following external types: byte (eg as implemented
> as a specialised array type), bigreal, complex, bigcomplex, bigrat,
> quaternian; the
On Thu, 07 Dec 2000, Dan Sugalski <[EMAIL PROTECTED]> mused:
> >My original suggestion was that scalar types provide a method that says
> >how 'big' it is (so complex > bigreal > real > int etc),
> >and pp_add(), pp_sub() etc use these values to call the method associated
> >with the biggest oper
At 02:01 PM 12/7/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > > All the math is easy if the scalars are of known types. Addition and
> > > > mul
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > > All the math is easy if the scalars are of known types. Addition and
> > > multiplication are easy if only one of the scalars involved i
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > All the math is easy if the scalars are of known types. Addition and
> > multiplication are easy if only one of the scalars involved is of known
> > type. Math with both of unknown type
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Dave M wrote:
> >That was probably me. (Which means it was probsbly a daft proposal,
> >and everyone rightly ignored it ;-)
> >The basic idea was that all numeric SV types must provide methods
> >that extract their vlaue as an integer or float of a size
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Is all that really necessary? Why not a non-vtbl function that knows how
>> to add numeric types?
DS> Which numeric types? Int? BigInt? Num? BigNum? Complex numbers? One of the
DS> reasons to go with the vtable stuff is to allow for smal
At 11:24 AM 12/1/00 +, David Mitchell wrote:
>and Buddha Buck <[EMAIL PROTECTED]> wrote:
>
> > I seem to remember a suggestion made a long time ago that would have the
> > vtable include methods to convert to the "standard types", so that if the
> > calls were b->vtable->add(b,a) (and both ope
At 03:02 PM 11/30/00 -0500, Buddha Buck wrote:
>At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>>At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>>> > (Moved over to -internals, since it's not really a parser API thing)
>>> >
>>
At 04:05 PM 11/30/00 -0500, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> The "add" op would, in C code, do something like:
> >>
> >> void add() {
> >> P6Scaler *addend;
> >> P6Scaler *adder;
> >>
> >> addend = pop(); adder = pop();
> >> push addend->vtable-
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I would have wanted to limit the vtbl to self manipulation functions.
> Set, get, convert, etc. Cross object operations would/should be
> outside the realm of the object. (It seems like trying to lift yourself
> by the bootstraps.)
There is a certainly
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> The "add" op would, in C code, do something like:
>>
>> void add() {
>> P6Scaler *addend;
>> P6Scaler *adder;
>>
>> addend = pop(); adder = pop();
>> push addend->vtable->add(addend, adder);
>> }
>>
>> it would be up to the addend->vta
At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>> > (Moved over to -internals, since it's not really a parser API thing)
>> >
>> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wro
At 01:51 PM 11/30/00 -0500, Buddha Buck wrote:
>At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>
>(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>
>>$a=1; $b =3; $c = $a + $b
>>
>>
>> > If they don't exist already, th
At 05:59 PM 11/30/00 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
> > (Moved over to -internals, since it's not really a parser API thing)
> >
> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >Presumably. But why are you then still talkin
At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>$a=1; $b =3; $c = $a + $b
>
>
> > If they don't exist already, then something like:
> >
> > newscalar a, n
uated then promoted to a bigreal; or does
$c end up being whatever $a+$b is, and not necesarily a bigreal?
Or is the expression ($a+$b) now evaluated in the context of knowing that
a bigreal is expected???
* How are scalar constants handled?
eg does this work as expected?
use bigreal;
my $br = 1E
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On a related note: a wrapper not completely unlike
JH> union sv_any_aligned_s {
JH> IV iv;
JH> NV iv;
JH> PV pv;
JH> void *vp;
JH> int (*dummy)(void) *fp;
JH> /* any others? */
JH> };
JH> should be used aroun
On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
> (Moved over to -internals, since it's not really a parser API thing)
>
> At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >Presumably. But why are you then still talking about "the IV slot in
> >a scalar"...? I'm slow today.
(Moved over to -internals, since it's not really a parser API thing)
At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>Presumably. But why are you then still talking about "the IV slot in
>a scalar"...? I'm slow today. Show me how
>
> $a = 1.2; $b = 3; $c = $a + $b;
>
>is going to
On Thu, Nov 30, 2000 at 04:15:24PM +, Nick Ing-Simmons wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> >
> >We're trying to make this an easy embedding API.
>
> Yes, and we are in danger of "premature optimization" of the _interface_.
Amen.
Tim.
> > > Huh? You're not talking about using this union around, say, the IV slot in
> > > a scalar, I hope...
> >
> >You hope in vain :-) If we still want to in perl6 to do (disgusting)
> >things like (we do in perl5)
> >
> > - "intercast" pointers and integers
> > - "intercast" integ
At 10:54 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> > At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > > On a related note: a wrapper not completely u
On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > On a related note: a wrapper not completely unlike
> > >
> > > union sv_any_aligned_s {
> > > IV iv
At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > On a related note: a wrapper not completely unlike
> >
> > union sv_any_aligned_s {
> > IV iv;
> > NV iv;
> > PV pv;
> > void *vp;
> > int (*du
On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> On a related note: a wrapper not completely unlike
>
> union sv_any_aligned_s {
> IV iv;
> NV iv;
> PV pv;
> void *vp;
> int (*dummy)(void) *fp;
> /* any others? */
> };
>
> should be used ar
Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>We're trying to make this an easy embedding API.
Yes, and we are in danger of "premature optimization" of the _interface_.
What we need to start with is a list of "what we need to know" - they may
as well be separate parameters at this point - the
Nicholas Clark <[EMAIL PROTECTED]> writes:
>> Counted strings should probably just have either a platform-native int in
>> front, or a 32-bit int in network format, both of which should be doable on
>> any platform that perl deals with.
>
>I agree it's do-able.
>What seems to me a good idea not
On a related note: a wrapper not completely unlike
union sv_any_aligned_s {
IV iv;
NV iv;
PV pv;
void *vp;
int (*dummy)(void) *fp;
/* any others? */
};
should be used around SVs to ascertain that everything fits everywhere.
--
$jhi++; # http://ww
On Tue, Nov 28, 2000 at 04:47:42PM -0500, Dan Sugalski wrote:
> At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
Not sure:
Dan:
> is treated as if it points to a stream of bytes, where the first four are
> the length o
At 07:29 AM 11/30/00 -0800, Dave Storrs wrote:
>On Wed, 29 Nov 2000, Dan Sugalski wrote:
>
> > At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> > >I have a feeling this is a stupid question, but I have to ask anyway.
> > >
> > >Do we really need to pass in a PerlInterp pointer? Or can perl6_par
On Wed, 29 Nov 2000, Dan Sugalski wrote:
> At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> >I have a feeling this is a stupid question, but I have to ask anyway.
> >
> >Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
> >just create one for itself if/when it needs one? I
On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Count me in with the people who prefer:
int perl6_parse(PerlInterp *interp, Perl
n Cozen's argument that it should
>be easy to embed somewhere else, in which case why do we want to make
>the parser have a dependency on the IO library?
>
>Bah. Can't have them both at the same time.
Sure we can. There's no reason the API exposed to programs that embed per
On Wed, Nov 29, 2000 at 09:51:07AM -0800, Dave Storrs wrote:
> I have a feeling this is a stupid question, but I have to ask anyway.
> Do we really need to pass in a PerlInterp pointer?
Yes. Threads. There's a reason for all the PERL_EXPLICIT_CONTEXT anxiety.
--
Old Japanese proverb:
T
At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
>I have a feeling this is a stupid question, but I have to ask anyway.
>
>Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
>just create one for itself if/when it needs one? If created, it could of
>course be kept around so that
I have a feeling this is a stupid question, but I have to ask anyway.
Do we really need to pass in a PerlInterp pointer? Or can perl6_parse
just create one for itself if/when it needs one? If created, it could of
course be kept around so that it didn't need to be re-created later.
>>>>> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> But on the other hand I also liked Simon Cozen's argument that it should
NC> be easy to embed somewhere else, in which case why do we want to make
NC> the parser have a dependency on
;> The problem with that is we're potentially getting the filehandle from
>> something that isn't perl. Or so my thinking went at the time. Right
>> now I'm thinkng that I need to rethink things.
That was my point. The Parser API should stick to PerlIO * - which is
an
something complicated but
fast. (and I belive Nick's p5p perlio is suggesting that PerlIO could open
a handle that sits atop the FILE *)
But on the other hand I also liked Simon Cozen's argument that it should
be easy to embed somewhere else, in which case why do we want to make
the pars
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>
> >FILE * is not a good idea. PerlIO * is fine.
>
> The problem with that is we're potentially getting the filehandle from
> something that isn't perl. Or so my
At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >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
Dan Sugalski <[EMAIL PROTECTED]> writes:
>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 secon
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 woul
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
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(
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
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.
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
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
with a handle on a syntax tree. And ways of adding and removing
these pieces.
These are abstract functions that would be needed on the interior of the
parser, but a bottom up approach may be more appropriate here.
I also like the suggestion that rather than supply flags, we should
follow the lea
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'
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
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
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
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
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
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
--- 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
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
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
s being a repository for any
variables that compiled code may set. (Standard stash stuff) The syntax
tree the parser generates will also be embedded here. (One fewer parameter
to deal with, and one fewer thing for an embedding program to track)
The second parameter is a pointer to the source to
On Mon, Nov 27, 2000 at 01:29:27PM -0500, Rocco Caputo wrote:
> Text::Trie is an amazing little module. I've abused it in a macro processing
> source filter to build optimum regexps out of lists of tokens.
Have you tried out Regex::PreSuf?
I tried making a monster regexp out of /usr/dict/words
Text::Trie is an amazing little module. I've abused it in a macro processing
source filter to build optimum regexps out of lists of tokens.
I've attached a proof-of-concept/benchmark program using the interesting bits
from POE::Preprocessor to build, test, and time regexps. Results of a sample
At 05:17 PM 11/27/00 +, Nicholas Clark wrote:
> > > "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
> > ST> Perhaps we really need a new kind of regex that works by-design against
> > ST> streams of bytes?
>
>I don't think any change is needed in the regex syntax. I think just being
>carefu
81 matches
Mail list logo
