On Thu, Aug 10, 2000 at 06:26:24PM -0400, Chaim Frenkel wrote:
> > "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.
Well perl5 already do
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "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.
perl5 does that.
>
>And adding a direct pointer
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... :)
> >
Bryan C . Warnock <[EMAIL PROTECTED]> writes:
>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
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> I thought I was saving the constant search along the @ISA, do it only
>> once.
GB> Well perl5 already does that. The first time a method is called it searchs
GB> ISA, but it caches the result in the package the object is blessed
GB> into,
From: Nick Ing-Simmons [mailto:[EMAIL PROTECTED]]
>
> In order to make that work you have required the lexer to
> pass you the {space}markers. That makes the parser do a lot
> more work throwing them away.
>
> It can also easily stop grammar being LALR(1) and hence yacc/bison
> parsable - you b
Dan Sugalski wrote:
> 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 fe
On Thu, Aug 10, 2000 at 06:30:01PM -0400, Chaim Frenkel wrote:
> > "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 ha
At 06:29 PM 8/10/00 -0700, Matthew Cline wrote:
>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 wed
At 03:11 PM 8/11/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 06:30:01PM -0400, Chaim Frenkel wrote:
> > Leave a stub behind at the old address that would trigger the repointing.
> > (I'm not clear what to do for refcounting the old address)
>
>That will only work if the sub being defined
On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> I think we're going to have to have a doubly-linked list going for @ISA, so
> when a parent package changes the child packages get changed too. It'll
> make updates to @ISA more expensive, but if you do that then you ought to
> be
At 03:28 PM 8/11/00 +0100, Graham Barr wrote:
>On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> > I think we're going to have to have a doubly-linked list going for
> @ISA, so
> > when a parent package changes the child packages get changed too. It'll
> > make updates to @ISA more
At 12:10 AM 8/12/00 +1000, Jeremy Howard wrote:
>Dan Sugalski wrote:
> > I dunno. If someone tells perl an array's sparse, I'd tend to believe they
> > knew what they were doing. Wouldn't hurt to have some sort of debugging
> > analysis messages that's notice you declared an array sparse but it re
At 09:34 PM 8/10/00 -0400, Bradley M. Kuhn wrote:
>Three notes on the Syntax tree (which I would probably call Intermediate
>Representation, or IR, but the name is irrelevant :).
Yep. It's more a MI, with bytecodes being an LI. (And both are IRs) I've
been browsing through compiler design books,
At 12:26 PM 8/11/00 +0200, Bart Lateur wrote:
>(I am *not* familiar with the current system behind arrays; reading the
>source to extract the idea doesn't sound smart. If somebody could point
>me to an explanation on how it works, I would be much obliged.)
Currently arrays have an array of pointe
On Fri, Aug 11, 2000 at 10:54:43AM -0400, Dan Sugalski wrote:
> At 03:28 PM 8/11/00 +0100, Graham Barr wrote:
> >On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> > > I think we're going to have to have a doubly-linked list going for
> > @ISA, so
> > > when a parent package changes
At 04:51 PM 8/11/00 +0100, Graham Barr wrote:
>On Fri, Aug 11, 2000 at 10:54:43AM -0400, Dan Sugalski wrote:
> > At 03:28 PM 8/11/00 +0100, Graham Barr wrote:
> > >On Fri, Aug 11, 2000 at 10:20:55AM -0400, Dan Sugalski wrote:
> > > > I think we're going to have to have a doubly-linked list going f
"Bryan C. Warnock" wrote:
>
> 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 poin
Dan Sugalski wrote:
>
> On Thu, 10 Aug 2000, David L. Nicol wrote:
>
> > Two fields.
> >
>
> This'll cause issues both with GC and thread synchronization. (Besides,
> don't skimp on fields in the base variable structure. Memory's reasonably
> cheap, and shaving a few bytes off isn't worth it an
Dan Sugalski wrote:
>
> 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
Garrett Goebel <[EMAIL PROTECTED]> writes:
>From: Nick Ing-Simmons [mailto:[EMAIL PROTECTED]]
>>
>> In order to make that work you have required the lexer to
>> pass you the {space}markers. That makes the parser do a lot
>> more work throwing them away.
>>
>> It can also easily stop grammar bei
At 02:20 PM 8/11/00 -0500, David L. Nicol wrote:
>Redefining a method during run time --- is that even a feature that
>needs to be supported?
Yes.
Also, the problem with vtables holding object methods objects is that
vtable functions are at fixed, small offsets, while methods are named. This
w
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
>>> I thought I was saving the constant search along the @ISA, do it only
>>> once.
>
>GB> Well perl5 already does that. The first time a method is called it searchs
>GB> ISA, but it caches the resul
At 04:02 PM 8/11/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
> >
> > 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]
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> The optree needs to know what to perform. an op_call_method needs
GB> to know which method.
I was hoping that the optree (or whatever) would have a static offset
into the vtbl.
You seem to think that that's not feasible. If the optree n
Dan Sugalski wrote:
>
> I'm thinking instead of proposing that lists become first-class data
> elements themselves, lazily evaluated. That way we don't flatten until
> someone actually references the list, which makes returns cheaper too. In
> this case we'd push two array markers on the stack, s
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... :)
>
> Dan
And for the i
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> It was a thought, yes.
>> While it would make method lookup faster, it's only benefit over the current
>> method is faster lookup of the first call to a method but at the cost
>> of extra processing at startup time to cache methods that
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
>GB> The optree needs to know what to perform. an op_call_method needs
>GB> to know which method.
>
>I was hoping that the optree (or whatever) would have a static offset
>into the vtbl.
If it has
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>I was hoping that the vtbls would be self-operating. Without much need
>to work hard on them.
They would be if you just did not expect so much of them - there is
an intrinsic cost on way Perl method calls work - we can push it about
but eventually ha
At 04:44 PM 8/11/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> It was a thought, yes.
>
> >> While it would make method lookup faster, it's only benefit over the
> current
> >> method is faster lookup of the first call to a method but at the cost
>
At 04:31 PM 8/11/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
> >
> > I'm thinking instead of proposing that lists become first-class data
> > elements themselves, lazily evaluated. That way we don't flatten until
> > someone actually references the list, which makes returns cheaper too.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:20 PM 8/11/00 -0500, David L. Nicol wrote:
>> Redefining a method during run time --- is that even a feature that
>> needs to be supported?
DS> Yes.
DS> Also, the problem with vtables holding object methods objects is that
DS> vt
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> If it has to be static then name => index has to be global across all classes
NI> as ISA tree adds leaves and reconverges.
Run this one by me again. Why isn't it enough to have the integers depend
only on the _current_ @ISA? So it wo
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>> Well, we could preload the vtbl with a _replace_me_ stub to do the
>> cacheing.
NI> Just leave vtable blank and fill it when we need it - that part of perl's
NI> mechanism is not the problem.
Aha, we're looking at to differnt dispatc
Dan Sugalski wrote:
>
> I'm not sure. Given the mushy state of my brain at the moment, that doesn't
> ring any bells. Details? (Keeping in mind I'm not on the PDL list)
>
> Dan
>
Here it is again
It is "radical"
Note this is purely my idea - some PDL
Graham Barr wrote:
>
> On Thu, Aug 10, 2000 at 06:26:24PM -0400, Chaim Frenkel wrote:
> > > "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 onl
At 05:53 PM 8/11/00 -0500, David L. Nicol wrote:
>Graham Barr wrote:
> > Well perl5 already does that. The first time a method is called it searchs
> > ISA, but it caches the result in the package the object is blessed
> > into, so next time it finds it without searching ISA
>
>
>One assumes that
Dan Sugalski wrote:
not work.
>
> I think we're going to have to have a doubly-linked list going for @ISA, so
> when a parent package changes the child packages get changed too. It'll
> make updates to @ISA more expensive, but if you do that then you ought to
> be prepared to take a hit.
>
>
On Fri, 11 Aug 2000, David L. Nicol wrote:
[...]
> Redefining a method during run time --- is that even a feature that
> needs to be supported?
I think so. A couple of examples are the Memoize module, which
works by rewriting your memoized function into something that uses
caching, th
On Fri, 11 Aug 2000, Nick Ing-Simmons wrote:
> In order to make that work you have required the lexer to pass you the {space}
> markers. That makes the parser do a lot more work throwing them away.
>
> It can also easily stop grammar being LALR(1) and hence yacc/bison
> parsable - you burn off yo
At 06:29 PM 8/11/00 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
> > I think we're going to have to have a doubly-linked list going for @ISA, so
> > when a parent package changes the child packages get changed too. It'll
> > make updates to @ISA more expensive, but if you do that then you oug
On Fri, Aug 11, 2000 at 02:16:31AM -0700, Nathan Wiger wrote:
> [cc'ed on internals as FYI]
>
> > =item 36 (v1): Structured Internal Representation of Filenames
>
> I think this should be discussed a good amount. I think URIs are cool,
> but too much trouble for simple stuff. I don't want to hav
Here's a list of attributes that I found in my old Symbolics Reference
Guide to Streams, FIles, and I/O. (March 1985)
Host
Device
Directory
Name
Type
Version
Plus it needs to handle cross-system support. How to specify the name
of a unix file when
On Thu, 10 Aug 2000 05:03:38 +0200, Bart Lateur wrote:
[description of a mechanism for storing sparse arrays:]
>Imagine
>that it will be traversed based upon the groups of bits in the array
>index. Say, with 32 bit indices, subdivided into 4 bytes. You can start
>with the lower byte, which can g
[cc'ed on internals as FYI]
> =item 36 (v1): Structured Internal Representation of Filenames
I think this should be discussed a good amount. I think URIs are cool,
but too much trouble for simple stuff. I don't want to have to write
"file:///etc/motd" everytime I want to address a file. Too cumb
46 matches
Mail list logo
