Re: Exposing the Garbage Collector (Iterating the live set)
Luke Palmer [EMAIL PROTECTED] writes:
On 7/26/05, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote:
Piers Cawley wrote:
I would like to be able to iterate over all the
objects in the live set.
My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing the namespace owner.
for ::Namespace - $instance
{
if +$instance != 0 { reconfigure $instance }
}
Oh, so a namespace can behave as an array then. Well, to avoid
auto-flattening problems in other, more common places, we ought to
make that:
for *::Namespace - $instance {...}
However, this is very huffmanly incorrect. First of all, what you're
doing may take a quarter of a second or more for a large program
(which isn't a short amount of time by any means). Second, the fact
that you're using it means you're doing something evil. Third, only a
fraction of 1/omega perl programmers will be using this feature.
Therefore, it should probably look like:
use introspection;
for introspection::ALL_INSTANCES(::Namespace) - $instance {...}
And if my proposal or something like it were accepted, the implementation could
simply look like:
module introspection {
class Class is extended {
method all_instances($class:) {
fail unless $*PLATFORM.GC.can_iterate_over_liveset;
$*PLATFORM.GC.grep - $instance { $instance.isa($class) }
}
}
sub ALL_INSTANCES($class) {
$class.all_instances
}
}
The point about my proposal to have the garbage collector or something like it
expose methods to iterate over the live set isn't that it's syntactically
gorgeous, but that it's a useful minimal behaviour that can be used to
implement nicer syntaxes which can be loaded as required. If we're going to
allow such reflective stuff (on platforms that can do it) then there needs to
be some minimal core functionality that other modules can use. The point about
iterating over the live set is that it's essentially free until you use it; the
garbage collector must *already* hold onto the information needed to do the
iteration.
Re: Exposing the Garbage Collector (Iterating the live set)
On 7/26/05, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote:
Piers Cawley wrote:
I would like to be able to iterate over all the
objects in the live set.
My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing the namespace owner.
for ::Namespace - $instance
{
if +$instance != 0 { reconfigure $instance }
}
Oh, so a namespace can behave as an array then. Well, to avoid
auto-flattening problems in other, more common places, we ought to
make that:
for *::Namespace - $instance {...}
However, this is very huffmanly incorrect. First of all, what you're
doing may take a quarter of a second or more for a large program
(which isn't a short amount of time by any means). Second, the fact
that you're using it means you're doing something evil. Third, only a
fraction of 1/omega perl programmers will be using this feature.
Therefore, it should probably look like:
use introspection;
for introspection::ALL_INSTANCES(::Namespace) - $instance {...}
And it might even be platform-specific, given the constraints of some
of our targets.
Luke
Re: Exposing the Garbage Collector (Iterating the live set)
Luke Palmer wrote:
On 7/26/05, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote:
Piers Cawley wrote:
I would like to be able to iterate over all the
objects in the live set.
My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing the namespace owner.
for ::Namespace - $instance
{
if +$instance != 0 { reconfigure $instance }
}
Oh, so a namespace can behave as an array then. Well, to avoid
auto-flattening problems in other, more common places, we ought to
make that:
for *::Namespace - $instance {...}
Well, even more huffmanized would be
for Namespace - {...; use $_}
might be what you expect after
my @array = (0,1,2,3);
::Namespace ::= @array;
However, this is very huffmanly incorrect. First of all, what you're
doing may take a quarter of a second or more for a large program
(which isn't a short amount of time by any means). Second, the fact
that you're using it means you're doing something evil. Third, only a
fraction of 1/omega perl programmers will be using this feature.
Therefore, it should probably look like:
use introspection;
for introspection::ALL_INSTANCES(::Namespace) - $instance {...}
This is why I wonder how writeable the namespace is, and when.
On some platforms it might actually not even be readable because
it was compiled away or stripped from the excecutable ;)
All that remains then is the possible behaviour as it is constrained
by the types of souls/daemons the creator happened to *choose*.
I guess you should re-read $Luke::Bible or watch the
$*::Movies::WarnerBrothers::Matrix again :))
If both refs are undef in your namespace, go and bind them!
If the above is insulting, feel free to invoke my .apologize with
you as topic. You know, I'm the $/ of this $email.
And it might even be platform-specific, given the constraints of some
of our targets.
The platform is yet another restriction on Space::Search::Solution.
Interestingly namespace lookup is big endian...
--
$Language::Perl6::TSa.greeting
(somehow we are all part of it or was that $_?)
Re: Exposing the Garbage Collector
TSa (Thomas Sandlaß) [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Let's say I have a class, call it Foo which has a bunch of attributes, and
I've
created a few of them. Then, at runtime I do:
eval 'class Foo { has $.a_new_attribute is :default10 }';
Assuming I've got the syntax right for defaulting an attribute,
I think you need a 'class Foo is extended' to re-open the class.
Otherwise you produce a redefinition error if the scope you call
eval in already contains---or is that extains because of the name
search beeing *outwards*---one you start from scratch.
Oh for heaven's sake! That's the last time I go trying to come up with concrete
examples for this sort of thing. Of course, you're right, I should have said
'is extended', but if I were doing it for real, the eval would fail and I'd
have a meaningful error message.
[ An explanation of why this particular case doesn't require iterating over the
live set ]
I really shouldn't go picking concrete examples that can be worked around
should I? Suffice to say that sometimes (say for debugging purposes, or program
analysis -- Smalltalk can do some cunning typer inferencing tricks by examining
the live set for instance) I would like to be able to iterate over all the
objects in the live set. ISTM that exposing the Garbage Collector at the
Language level is the neatest way of doing this (or coming up with something
like Ruby's ObjectSpace, but conceptually I reckon the GC is the right place to
hang it).
Re: Exposing the Garbage Collector (Iterating the live set)
Piers Cawley wrote:
I would like to be able to iterate over all the
objects in the live set.
My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing the namespace owner.
for ::Namespace - $instance
{
if +$instance != 0 { reconfigure $instance }
}
Hmm, how would that be written inside the owning class?
for :: - $instance {...} # or perhaps ::_ or ::0
H, and the current actor/owner is $/ which gives the expanded
method call syntax:
.method # really means: $/.method($_)
Then we need to distinguish between the owner of a block and
the topic of the block. In methods the owner is called invocant,
of course. This also nicely unifies rules and methods. But with
the drawback that the brawl then shifts from topic versus invocant
to rules and method competing for ownership :)
ISTM that exposing the Garbage Collector at the
Language level is the neatest way of doing this (or coming up with something
like Ruby's ObjectSpace, but conceptually I reckon the GC is the right place to
hang it).
To me the GC is an implementation detail for rendering the
illussion of infinite memory :)
For example +::Int could return the number of instances in use
not the potential Inf many ones. Adding the infix namespace wildcard
could allow to retrieve attributes as arrays indexed by object id:
@instvalues = ::SomeClass::*::attr;
The access control on a level behooves its owner/origin that
is ::NameSpace::0. This gives in the end a virtual tree of all
static information. As a fallout, structured rule matches can also
be queried with :: and as such nicely blend strings into the
type system. E.g. after successfull recognition an object could
be created by simply reparenting it from the rule to its class/owner.
The referential fabric and the call chains are hang-off this
structure somehow, as well. Everything else is basically garbage.
Too far off the mark? If not, I've ideas for ?? and :: beeing
top precedence namespace query ops. Only effect is that the
current meaning needs parens like ($condition ?? $value :: $other)
for preventing strange tokenization. OTOH would the barebone
structure of Perl6 revolve around ?? :: ::= () ; and namespace lookup.
--
TSa (Thomas Sandlaß)
Re: Exposing the Garbage Collector
Piers Cawley wrote:
Let's say I have a class, call it Foo which has a bunch of attributes, and I've
created a few of them. Then, at runtime I do:
eval 'class Foo { has $.a_new_attribute is :default10 }';
Assuming I've got the syntax right for defaulting an attribute, and lets assume
I have, the Perl runtime needs to chase down every instance of Foo or its
subclasses and add an attribute slot (adding a method to a class is nowhere
near as interesting, because every instance of the class shares a single class
object).
But adding an attribute is simply defining a new method in the Class'
instance methods. And you don't need to chase down the objects for that.
What you wrote could be implemented as;
class Foo {
has $a_new_attribute is :default(10);
sub a_new_attribute is accessor
:FETCH{ $a_new_attribute },
:STORE - $val { $a_new_attribute = $val },
}
}
So this way the extra attribute can be lazily added. The other ways of
finding out that the property should be there, such as the visitor
pattern interface, will trip the part that adds the slot to the object.
However I think this is somewhat besides your original point.
Sam.
Re: Exposing the Garbage Collector
Piers Cawley [EMAIL PROTECTED] wrote:
It seems to me, that the way to get at all the instances of a class is to ask
the Garbage Collector to do the heavy lifting for us, and ideally I'd like to
see this exposed at the Perl level.
It's entirely possible that Perl will be used on virtual machines
where this can't be done.
I'd suggest that we simply declare that every metaclass must support a
.all method which returns an arrayish thing containing all active
objects it is managing:
grep { .isa($class) } MetaClass.all;
Whether this works by interfacing with the garbage collector, keeping
an array of weak references, or waving a wooden wand and yelling
Accio objects is completely up to the metaclass in question.
(Sorry, been reading too much Potter lately...)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Exposing the Garbage Collector
On Sat, 2005-07-23 at 20:41 -0700, Brent 'Dax' Royal-Gordon wrote: Piers Cawley [EMAIL PROTECTED] wrote: It seems to me, that the way to get at all the instances of a class is to ask the Garbage Collector to do the heavy lifting for us, and ideally I'd like to see this exposed at the Perl level. It's entirely possible that Perl will be used on virtual machines where this can't be done. Will those VMs support string eval? If not, Piers' *specific* problem here mostly goes away. How much introspection and intromanipulation should Parrot guarantee on small or limited platforms in general? -- c
