Front page | perl.perl6.internals |
Postings from January 2002
RE: Some random design notes
From: Dan Sugalski
January 8, 2002 15:38
RE: Some random design notes
Message ID: email@example.com
At 01:47 PM 1/8/2002 -0800, Brent Dax wrote:
># This is just a collection of random notes I put together while serving
># jury duty. There's not much coherence here, but better to get it down
># than not.
>"Is this case worthy of the death penalty?"
>"Hmm? Yeah, sure, whatever."
># Global namespaces need to be multilevel the way lexical spaces
># are. Ruby and Python both require this. (Well, it's not required but
># it makes things easier)
Python has no lexicals (well, yet--they might be in now, though), but it
has three levels of global variables. Ruby, while it has lexicals, also has
class and object 'globals'. If we chain the tables, the lookup op can find
it in one go potentially walking tables. (Like the lexical lookup op will)
If not, we have to manually wal, which is OK but more ops.
># Each object might have its own private variables. We'll know at
># compile-time, though.
>I imagine we can just store an array (PMC or C-level is uncertain)
>behind an Object and work from there.
I was thinking of either an attribute, or a separate hash for these private
># Attributes are done as a hash of hashes. Each interpreter has a
># pointer to an attribute hash, whose keys are the attribute names. The
># values will be hash pointers. Those hashes will each have a key which
># is a PMC pointer (hashed up somehow) and the value is the attribute
>If you're talking about 'is'-style attributes, why not have them be
>attached to the PMCs themselves?
D'you want an attribute pointer for each PMC? (I've considered it, but for
the moment I think it'll be too expensive. Might be wrong)
># We need private methods for objects.
>Call stack examination should handle that.
Maybe. I'm not sure.
># There are three types of interpreters:
># 1) Standalone
># 2) Concurrent (multiple interpreters that share some data, may run
># simultaneously with threads)
># 3) Linked (multiple interpreters that access the same data, only one
># can run at once, and only switch at safe times)
>Cooperative multitasking (with data sharing).
Mostly, yup. (For cheating and easy coroutines, especially)
># There are actually three (at least) groups of parameters that need to
># be taken independently.
># 1) The object a method's called on
># 2) The parameters passed to the sub/method
># 3) The yield block. (A ruby thing, which is really kind of cool)
> From what I've been reading, at least 1) and 2) are two sides of the
>same coin. Larry and Damian seem to be expecting that you'll be able to
>put a colon anywhere in a list and it should Just Work. (And I did
>confirm at some point that : will be the separator between the object
>and its parameters.)
Right, but that's from the language level. Under the hood things need to be
more explicit for the inter-language calling conventions.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
firstname.lastname@example.org have teddy bears and even
teddy bears get drunk