On Thu, 10 Aug 2000, David L. Nicol wrote:
> Two fields.
>
> First is type, which is 0 for a double-precision FP
>
> 1 for a string and higher than that for a defined type in the
> defined type table.
>
> Second is the number, for type 0, and a pointer to
> the beginning of the object for ever
On Thu, 10 Aug 2000, David L. Nicol wrote:
> Within a perl instance, every object type must register itself on
> loading. At registration, a number is assigned, the jump table
> of common functions that that object type overloads is filled, and also
> a pointer to the association for uncommon met
On Thu, 10 Aug 2000, Dan Sugalski wrote:
> With each box being replaceable, and the process being freezable between
> boxes. The lexer and parser probably ought to be separated, thinking about
> it.
Not necessarily. It might be dangerous to change what the lexer think
is a token. You might b
Dan Sugalski wrote:
> At 10:01 PM 8/9/00 -0600, Nathan Torkington wrote:
> >Would it make sense for the parsing of a Perl program to be done as:
> > - tokenize without rewriting (e.g., use stays as it is)
> > - structure without rewriting (e.g., constant subs are unfolded)
> > - rewrite for opt
On Thu, 10 Aug 2000, Dan Sugalski wrote:
> With each box being replaceable, and the process being freezable between
> boxes. The lexer and parser probably ought to be separated, thinking about
> it, and we probably want to allow folks to wedge at least C code into each
> bit. (I'm not sure whethe
Why not a direct pointer to the vtbl?
And not having a defined type table, one avoids the bookkeeping
overhead of having to register each type. No need to play with
assigning type numbers (no IANA needed.)
Any object can alter its behavior to a non-defined type by simply
creating a vtbl and usin
Two fields.
First is type, which is 0 for a double-precision FP
1 for a string and higher than that for a defined type in the
defined type table.
Second is the number, for type 0, and a pointer to
the beginning of the object for everything else. Objects will
fit in contiguous memory or wi
Michael Fowler wrote:
> > > Which then raises a few more problems (whew): how do you coax user input
> > > (which is an SV) into a value $foo can accept with very-strict on?
> >
> > You run it through an explicit conversion process, like using C in
> > a C program
>
> Unfortunately, this involv
Dan Sugalski wrote:
> Strong typing and sparse arrays are orthogonal--no reason we shouldn't use
> them if someone does:
>
>$foo[time]
>
> or something of the sort. (People like huge arrays with few scalars in
> them too... :)
>
Good point. It also occurs to me that we would want some syntax t
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
>> At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
>> >You just re-invented "look up the name in a hash table" ;-)
>> >
>> >You now have one big hash table rather than severa
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> You just re-invented "look up the name in a hash table" ;-)
I thought I was saving the constant search along the @ISA, do it only
once.
And adding a direct pointer for constant methods. ($foo->aMethod).
*sigh*
--
Chaim Frenkel
At 07:57 AM 8/11/00 +1000, Jeremy Howard wrote:
>Dan Sugalski wrote:
> > Strong typing and sparse arrays are orthogonal--no reason we shouldn't use
> > them if someone does:
> >
> >$foo[time]
> >
> > or something of the sort. (People like huge arrays with few scalars in
> > them too... :)
> >
At 10:00 PM 8/10/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> > At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
> > >You just re-invented "look up the name in a hash table" ;-)
> > >
> > >You now have one big hash table rather than several small
On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
> >You just re-invented "look up the name in a hash table" ;-)
> >
> >You now have one big hash table rather than several small ones.
> >Which _may_ give side benefits - but I doubt i
At 08:31 PM 8/10/00 +, Nick Ing-Simmons wrote:
>You just re-invented "look up the name in a hash table" ;-)
>
>You now have one big hash table rather than several small ones.
>Which _may_ give side benefits - but I doubt it.
If we prefigure a bunch of things (hash values of method names, stor
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>I just realized, that this isn't an original idea. Objective-C does this.
>
>>From what I recall (hmm, must be close to 10 years now) it had the
>same problem in finding the correct c routine to call for any
>selector. Where the selector could be impleme
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>Each sub has a unique number.
(A hash of its name)
>
>Each object would then have a compact representation of only the methods
>that are accessible via method call. (Dynamically generated methods,
>would be added at the end of the vtbl.)
>
>There only
At 08:16 PM 8/10/00 +, Nick Ing-Simmons wrote:
> >The first runtime reassignment of @ISA shoots this one down hard. Sorry.
> >(MI also makes it more difficult, since dependency trees will have to be
> >built...)
>
>Yes - this is why Malcolm dodged MI with 'fields' module.
I'm not sure we can,
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 03:35 PM 8/9/00 -0700, Damien Neil wrote:
>>On Wed, Aug 09, 2000 at 03:32:41PM -0400, Chaim Frenkel wrote:
>>
>>Each sub is assigned an index. This index is unique for the package
>>the sub is in, and all ancestor packages.
Add all sibling packages of
At 03:36 PM 8/10/00 -0400, Chaim Frenkel wrote:
>You may also want to be able to short circuit some of the steps.
>Especially where the startup time may outweigh the win of optimization.
The only one that's skippable is the optimizer, really. I'd planned on
having to pass it some indicator of h
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> - source filters munge the pure source code
NT> - cpp-like macros would work with token streams
NT> - pretty printers need unmunged tokens in an unoptimized tree, which
NT>may well be unfeasible
I was thinking of macros as be
You may also want to be able to short circuit some of the steps.
Especially where the startup time may outweigh the win of optimization.
And if there could be different execution engines. Machine level,
bytecode, (and perhaps straight out of the syntax tree.)
Hmm, might that make some debugging
At 10:01 PM 8/9/00 -0600, Nathan Torkington wrote:
>Would it make sense for the parsing of a Perl program to be done as:
> - tokenize without rewriting (e.g., use stays as it is)
> - structure without rewriting (e.g., constant subs are unfolded)
> - rewrite for optimizations and actual ops
The
At 09:57 PM 8/9/00 -0700, Matthew Cline wrote:
>On Wed, 09 Aug 2000, Nathan Torkington wrote:
> > It seems to me that a perl5 program exists as several things:
> > - pure source code (ASCII or Unicode)
> > - a stream of tokens from the parser
> > - a munged stream of tokens from the parser (e.g
On Thu, 10 Aug 2000, Jeremy Howard wrote:
> > At 07:07 PM 8/9/00 -0400, Karl Glazebrook wrote:
> > >Dan Sugalski wrote:
> > > >
> > > > At 11:27 PM 8/9/00 +1000, Jeremy Howard wrote:
> > > > >5- Compact array storage: RFC still coming
> > > >
> > > > I hope this RFC will be "Arrays should be spar
I couldn't determine if this involves just language, or just internals, so
I'm posting to both. Let me know if this discussion is inappropriate for
one or the other (or both?!).
On Thu, Aug 10, 2000 at 05:08:39AM +, David L. Nicol wrote:
>
> The other advantage of typed languages is that t
26 matches
Mail list logo
