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.
>
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 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.
> >
> > =~ /RFC/
>
> http://dev.perl.org/rfc/9
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
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.
>
> =~ /RFC/
http://dev.perl.org/rfc/93.html
I know I read it, I just don't remember reading it.
IMPLEMENTATION
At 12:29 AM 11/25/00 -0500, Sam Tregar wrote:
>On Fri, 24 Nov 2000, Nicholas Clark wrote:
>
> > I think Dan was suggesting that the (user side) regex doesn't change at all
> > (so that's no new syntax there)
> > It's just that the innards of perl gains a tied scalar that doesn't
> actually
> > re
Look throught the RFCs this was one of Damian Conway's.
=~ /RFC/
> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
ST> On Wed, 22 Nov 2000, Dan Sugalski wrote:
>> Probably the easiest thing is to implement some sort of file-tied scalar or
>> something that can provide bytes to the regex eng
On Fri, 24 Nov 2000, Nicholas Clark wrote:
> I think Dan was suggesting that the (user side) regex doesn't change at all
> (so that's no new syntax there)
> It's just that the innards of perl gains a tied scalar that doesn't actually
> read in and buffer the file immediately, but defers it as lon
On Fri, Nov 24, 2000 at 01:01:29AM -0500, Sam Tregar wrote:
> On Wed, 22 Nov 2000, Dan Sugalski wrote:
>
> > Probably the easiest thing is to implement some sort of file-tied scalar or
> > something that can provide bytes to the regex engine until it stops asking
> > for them. Some magic or other
On Wed, 22 Nov 2000, Dan Sugalski wrote:
> Probably the easiest thing is to implement some sort of file-tied scalar or
> something that can provide bytes to the regex engine until it stops asking
> for them. Some magic or other, though, will get us what we need.
That might be the easiest thing f
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 pointed in.
> >
> >Write it entirely in perl, but have native C implementations
At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
>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
At 08:51 PM 11/21/00 -0500, Sam Tregar wrote:
>On Wed, 22 Nov 2000, Nicholas Clark wrote:
>
> > Are we hoping that we can mmap() most scripts, so read isn't hugely a
> > problem? And slrp the rest in one? [doesn't feel good]
> > Are we going to have "lazy scalars" which collude with the rege
At 09:06 AM 11/22/00 +, David Grove wrote:
>Anyway, I'm trying to fit the definitions Dan offered yesterday with what
>has been said so far. Not everything seems to fit. One obvious question is
>that "the functions that are presented to the world" refers to functions
>like SvPV() (C language)
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
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
On Wed, Nov 22, 2000 at 08:51:08PM +0100, Bart Lateur wrote:
> On Wed, 22 Nov 2000 14:15:57 -0500, Dan Sugalski wrote:
>
> >>We bootstrap on perl5 to get a bytecode stream, and then that bytecode
> >>stream had better stay supported.
> >
> >Yup. It's one way to ensure backwards compatibility... :
On Wed, 22 Nov 2000 14:15:57 -0500, Dan Sugalski wrote:
>>We bootstrap on perl5 to get a bytecode stream, and then that bytecode
>>stream had better stay supported.
>
>Yup. It's one way to ensure backwards compatibility... :)
I assume a byte is still 8 bits? So you have a max of 256 different (1
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> 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 par
At 01:50 PM 11/22/00 -0500, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> 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 c
"Rocco Caputo" <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Nov 2000 12:45:50 +0100, Bart Lateur wrote:
> >
> >AKA "The Dragon Book". You're not the only one to mention this book on
> >this list.
> >
> >IMO, this book is really thick to crawl through, and in the end, it's
> >all just theory, y
On Wed, Nov 22, 2000 at 12:45:50PM +0100, Bart Lateur wrote:
> Heh. In short: are there
> any more *practical* "how do I build my own compiler" books, that people
> can wholeheartedly recommend?
"Modern Compiler Design in C" (or "... in ML" if you so desire) by Appel.
Bit weird in places - excel
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 really thick to crawl through, and in the e
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:45 PM 11/21/00 +, Tom Hughes wrote:
>
> >Given that it isn't a valid C identifier, yes... Unless you're
> >using VAXC or DECC of course, which was your point I assume ;-)
>
> Odd. The Dec C docs don't men
On Tue, Nov 21, 2000 at 09:39:16PM -0500, Dan Sugalski wrote:
> At 11:45 PM 11/21/00 +, Tom Hughes wrote:
> >In message <[EMAIL PROTECTED]>
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > At 10:18 AM 11/21/00 -0800, Benjamin Stuhl wrote:
> > >
> > > >Well, it would (IMHO) make
At 11:45 PM 11/21/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 10:18 AM 11/21/00 -0800, Benjamin Stuhl wrote:
> >
> > >Well, it would (IMHO) make more sense to have
> > >perl6_parse_script (I do tend to follow
> > >{subsys
On Wed, 22 Nov 2000, Nicholas Clark wrote:
> Are we hoping that we can mmap() most scripts, so read isn't hugely a
> problem? And slrp the rest in one? [doesn't feel good]
> Are we going to have "lazy scalars" which collude with the regexp engine
> so that if the regexp engine hits the cu
On Mon, Nov 20, 2000 at 06:01:52PM -0500, Dan Sugalski wrote:
> * The parser will be written mostly in perl, so you have regexes and such
> to work with
> * It's possible that the whole set of parsing rules may change on the fly,
> so don't get hung up on constants like "{"--stick to symbolic t
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:18 AM 11/21/00 -0800, Benjamin Stuhl wrote:
>
> >Well, it would (IMHO) make more sense to have
> >perl6_parse_script (I do tend to follow
> >{subsystem,verb,object} naming...)
>
> Or Perl$parse_script, but th
At 01:04 PM 11/21/00 +, David Grove wrote:
>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 t
> Okay, you're more confused here than I though.
I can't deny that, but at least I helped get this group talking. The
silence was deafening.
Participation feels good though, when I'm not getting yelled at for being
technically inarticulate (P5P). Maybe if we can keep up the good
attitudes, we c
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 thin
At 12:46 PM 11/21/00 +, David Grove wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 10:37 AM 11/21/00 +, David Grove wrote:
> > >Thanks for the clarifications, Simon.
> > >
> > >Simon Cozens <[EMAIL PROTECTED]> wrote:
> > >If we were simply feeding it perl with a single synt
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 21, 2000 at 10:37:23AM +, David Grove wrote:
> > I'm not sure that it's possible to do this, or disirable. If Larry
wants
> > Perl to use different modes, creoles, or ways of interpreting or
> > understanding the "perl" language, then
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:37 AM 11/21/00 +, David Grove wrote:
> >Thanks for the clarifications, Simon.
> >
> >Simon Cozens <[EMAIL PROTECTED]> wrote:
> >If we were simply feeding it perl with a single syntax, we could get
away
> >with a "one call" scheme. But sin
At 10:18 AM 11/21/00 -0800, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 10:37 AM 11/21/00 +, David Grove wrote:
> > >Thanks for the clarifications, Simon.
> > >
> > >Simon Cozens <[EMAIL PROTECTED]> wrote:
> > >If we were simply feeding it perl with a single synta
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:37 AM 11/21/00 +, David Grove wrote:
> >Thanks for the clarifications, Simon.
> >
> >Simon Cozens <[EMAIL PROTECTED]> wrote:
> >If we were simply feeding it perl with a single syntax,
> we could get away
> >with a "one call" scheme. But since
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 langua
At 10:37 AM 11/21/00 +, David Grove wrote:
>Thanks for the clarifications, Simon.
>
>Simon Cozens <[EMAIL PROTECTED]> wrote:
>If we were simply feeding it perl with a single syntax, we could get away
>with a "one call" scheme. But since we're dealing with almost certainly
>mutually exclusive s
On Tue, Nov 21, 2000 at 10:37:23AM +, David Grove wrote:
> I'm not sure that it's possible to do this, or disirable. If Larry wants
> Perl to use different modes, creoles, or ways of interpreting or
> understanding the "perl" language, then we have to let the parser have a
> bit more informati
On Tue, 21 Nov 2000, David Grove wrote:
> If we were simply feeding it perl with a single syntax, we could get away
> with a "one call" scheme. But since we're dealing with almost certainly
> mutually exclusive syntax and semantics, it probably needs more
> information.
Perhaps the "one call" ca
Thanks for the clarifications, Simon.
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 21, 2000 at 07:36:11AM -0500, David Grove wrote:
> > > 1) The API presented to the rest of the world. This is likely one
> call,
> >
> > These are almost two separate things entirely. (I don't get t
At 12:44 PM 11/21/00 +, Simon Cozens wrote:
>On Tue, Nov 21, 2000 at 07:36:11AM -0500, David Grove wrote:
> > > * The parser needs to be reentrant
> > No clue what this means. I need this defined in context.
>
>While parsing text, you should be able to dive into a separate bit of text,
>parse
On Tue, Nov 21, 2000 at 07:36:11AM -0500, David Grove wrote:
> > 1) The API presented to the rest of the world. This is likely one call,
>
> These are almost two separate things entirely. (I don't get the "one call"
> thing. What do you mean?)
A parser does, essentially, one single thing: it ta
I'm still not sure where to start from a technical standpoint, so I'll
just comment and brainstorm until someone more used to this tells me
whether my common cents should be in US Dollars or South African ZAR.
Please forgive a bit of rambling, I'm not purposely off topic if I am.
Dan Sugalski <[
Hi folks, and sorry about the delay. (And extended silence)
This list is here to design the internal and external API for the
parser/tokenizer/lexer part of perl. Basically we need two bits:
1) The API presented to the rest of the world. This is likely one call,
though if folks want to split i
48 matches
Mail list logo
