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 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 off
> this chunk. No, you may not play wit
At 05:07 PM 11/22/00 +, Nicholas Clark wrote:
>On Wed, Nov 22, 2000 at 11:02:16AM -0600, Jarkko Hietaniemi wrote:
> Dan:
> > > This strikes me as an excellent candidate for a custom scalar type. I
> like
> > > the idea, and it could be really useful in some circumstances, but
> I'd not
> >
At 09:17 AM 11/22/00 -0800, Dave Storrs wrote:
>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 gre
Nicholas Clark <[EMAIL PROTECTED]> writes:
> How does the regexp replacement engine cope with this? By implementing
> all replacements as substr() type ops?
> [or behaving as if it implements... whilst cheating and doing it direct for
> scalars it understands?]
>
> Or don't we need to work this
On Wed, Nov 22, 2000 at 02:57:09PM +0100, Roland Giersig wrote:
> I posted a RFC for something like that a while ago but got no reaction
> from the crowd. It is not an internal optimisation like the one
I don't think that there's a crowd here.
> Take this HTML for example:
>
> Text with a
On Wed, Nov 22, 2000 at 12:29:55PM -0500, Dan Sugalski wrote:
> At 09:17 AM 11/22/00 -0800, Dave Storrs wrote:
>
>
> >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 m
> 2) An attached table of attributes and ranges to which they apply?
>Uses less memory for sparse attributes, but means that it's hard work
>every time we have to interrogate or shuffle characters as we need to
>check all the ranges each time to see if the characters we are
>manipu
At 10:45 AM 11/22/00 -0600, Jarkko Hietaniemi wrote:
> > 2) An attached table of attributes and ranges to which they apply?
> >Uses less memory for sparse attributes, but means that it's hard work
> >every time we have to interrogate or shuffle characters as we need to
> >check all the
> >I believe this alternative has been discussed once in a while. Which
> >ranges an operation affects is a log(N) operation on the character
> >position (binary search), and the ranges can also be kept sorted among
> >themselves on (primary key start position, secondary key end
> >position), so
On Wed, Nov 22, 2000 at 11:02:16AM -0600, Jarkko Hietaniemi wrote:
Dan:
> > This strikes me as an excellent candidate for a custom scalar type. I like
> > the idea, and it could be really useful in some circumstances, but I'd not
> > want to burden the default scalar with the code for this.
>
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> 2) An attached table of attributes and ranges to which they apply?
>> Uses less memory for sparse attributes, but means that it's hard work
>> every time we have to interrogate or shuffle characters as we need to
>> check all the rang
On Wed, Nov 22, 2000 at 01:24:50PM -0500, Chaim Frenkel wrote:
> I'd offer the possiblity that there are two (or perhaps more)
> different problems here. One is the current bunch of bytes (string,
> executable to be twiddled) Another which the attribute on strings
> seems to be structured data.
>
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> Have I misunderstood you if I suggest that "two or more" is actually a
NC> continuous range of representation from
NC> 1 (contiguous linear) string data with 0 or more attribute attached to each
NC> character where the string's text
Dan Sugalski <[EMAIL PROTECTED]> writes:
> More often vice versa. INN embeds perl, for example, and uses it for
> spam detection. When it builds scalars for perl to use, it uses the copy
> of the article already in memory to avoid copies. (Given the volume of
> news and the size of some news arti
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, 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
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
hi,
I don't know very much about internals or about how the parser works in
reality but something like this can be helpfull I think !! What I have in
mind ? Micro-perl-parser may be this is external interface (written in
perl).
rule:do {
/do/ and "{" call(token) and "}" and action
}
rule:t
"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
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
> "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
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
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 03:35 PM 11/22/00 +, raptor wrote:
>hi,
>
>I don't know very much about internals or about how the parser works in
>reality but something like this can be helpfull I think !! What I have in
>mind ? Micro-perl-parser may be this is external interface (written in
>perl).
>
>
>rule:do {
>/
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
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
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)
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
30 matches
Mail list logo
