Re: [perl #20315] [PATCH] eval
Leopold Toetsch (via RT) wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #20315] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20315 > Attached is a first try towards eval. I have now eval/compile also running inside imcc. There are two registered compregs: "PASM" and "PIR" aka .imc, e.g. set S0, 'set S1, "42\n"' concat S0, "\n" concat S0, "print S1\nend\n" compile P1, S0, "PASM" print "\n" end I still would like to have some design advice. 1) The call function to the compiler/assembler is kept as a NCI. Better would be a subclass of NCI (Compiler.pmc or so), which provides invoke_keyed(key, next) This would look up the compreg "key" and prepare the registers for calling the compiler function. I think such a vtable method would also be handy for the OO stuff: callmethod P1, "foo" which would translate too a invoke_keyed() on the object. For methods known at compile time, the HL could spit out callmethod P1, n which would then be invoke_keyed_int(). 2) The return value of the compile ops should be a pointer to a bytecode segment, already in the interpreter and ready for calling. So how should a "code_segment_PMC" look like and how should the structure in the packfile be defined? Just an array of code pointers containing byte_code and byte_code_size? The code_segment_PMC would probably be a [subclass of]? Sub.pmc, which can then be invoked for actually evalling the code. Comments welcome, leo
Re: Objects, finally (try 1)
If memory serves me right, Dan Sugalski wrote:
> rather than attributes, but I may be incorrect here. Are the current
> python instance attributes both:
>
> *) defined per object rather than per class
> *) Essentially global, that is not hidden from parent classes or
> anything. (Basically one big pool 'o things attached to the object)
Speaking out of turn Python instance stuff is per Object ...
And from the looks of it's just a dictionary lookup in the
obj.__dict__ dictionary ... So the stuff looks essentially global.
eg.
class Foo:
def __init__(self):
pass
def toString(self):
return self.Name
class FooBar(Foo):
def __init__(self,name):
self.Name=name
a=FooBar("hello")
print a.toString()
--
hello
Gopal
PS: considering the fact that non-virtual functions are the only portion
holding out the TreeCC Python plugin , I have had quite some heart burn
with this. (or I need a switch statement :)
--
The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
On Wed, 15 Jan 2003 01:00:59 -0500, Dan Sugalski wrote:
> At 8:53 PM -0800 1/14/03, Adriano wrote:
> >I think what Jonathan asked for was an operator for returning a method
> >(as an object) which can be invoked later with some arguments (or even
> >applied with a partial list of arguments for currying). This would be a
> >lot more useful than a yes-or-no answer about the existence of a method.
>
> I thought about this--it's what the find_method vtable method was for in
> the first place. Unfortunately, as was pointed out to me, there's no good
> way to cache the result, since it could potentially be wrong by the time
> the method is actually called.
Is that such a big deal? The same problem exists in perl 5 with the
following code:
if(my $meth=$obj->can($action)){
# Stuff could happen here which redefines the method in $obj's class
# However, I know it won't get redefined because I wrote the whole system
$obj->$meth();
}else{
die "Some custom error message or appropriate action";
}
Surely it's up to the person/compiler writing the code to decide whether it
matters that the method has been redefined in the meantime. We shouldn't
prevent something useful just because it's not universally applicable.
--
Peter Haworth [EMAIL PROTECTED]
"I can talk on this stuff for hours when given insufficient discouragement."
-- Dan Sugalski
Re: [perl #19610] [PATCH] New language support: Ook!
Jerome Quelin (via RT) wrote: - currently I'm just printing on stdout the resulting parrot code, I lack an eval instruction in Parrot. Dan, Leo? :-) $ diff -ub ~/src/parrot/languages/ook/ook.pasm ook.pasm --- /home/lt/src/parrot/languages/ook/ook.pasm Wed Jan 1 01:34:16 2003 +++ ook.pasmWed Jan 15 16:41:00 2003 @@ -101,7 +101,8 @@ LOOP_END: le I1, I0, LOOP concat S4, "\tend\n" -print S4 +#print S4 + compile P1, S4, "PASM" end $ ../imcc/imcc -r ook.pasm hello.ook Hello World! $ ../imcc/imcc -r ook.pasm test.ook 1..1 ok 1 (compile does eval here for test purposes) Have fun! leo
RE: Objects, finally (try 1)
Peter Haworth wrote:
> Dan Sugalski wrote:
> > Adriano wrote:
> > >
> > >I think what Jonathan asked for was an operator for
> > >returning a method (as an object) which can be invoked
> > >later with some arguments (or even applied with a
> > >partial list of arguments for currying).
> > >
> > >This would be a lot more useful than a yes-or-no
> > >answer about the existence of a method.
Exactly. 'Yes' might be valid one moment, and invalid the next. Not a very
useful operation... Returning a coderef on the other hand is useful.
> > I thought about this--it's what the find_method vtable
> > method was for in the first place. Unfortunately, as
> > was pointed out to me, there's no good way to cache
> > the result, since it could potentially be wrong by the
> > time the method is actually called.
>
> Is that such a big deal? The same problem exists in perl 5 with the
> following code:
>
> if(my $meth=$obj->can($action)){
> # Stuff could happen here which redefines the method in
> # $obj's class However, I know it won't get redefined
> # because I wrote the whole system
> $obj->$meth();
> }else{
> die "Some custom error message or appropriate action";
> }
I don't see it as a problem. In Perl5, you get back a coderef. And despite
whether the method is modified or removed from the class in the meantime,
that code reference is still valid. Sure, if you want to garrauntee you'll
get the "appropriate" method implementation at a given instance in time,
you'll have to code a bit more carefully, but at least you know the method
implementation you've got isn't going to be changed out from under you.
I'm not sure I follow the talk of invalidating method handles. I'm sure
there's some use for method handles. But I hope a reference to method's
implementation isn't going to run the chance of being invalidated before its
called.
I realize with Perl6 we'll have the possiblity of multi-method dispatch. But
my assumption based on Damian's posts to perl6-language is that Perl6's
->can will support passing some form of parameter list specification so that
it'd be possible for ->can to resolve the dispatch and return a coderef to
the implementation before you actually invoke it.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
RE: Objects, finally (try 1)
>> > >I think what Jonathan asked for was an operator for >> > >returning a method (as an object) which can be invoked >> > >later with some arguments (or even applied with a >> > >partial list of arguments for currying). >> > > >> > >This would be a lot more useful than a yes-or-no >> > >answer about the existence of a method. > > Exactly. 'Yes' might be valid one moment, and invalid the next. Not a > very useful operation... Returning a coderef on the other hand is > useful. Er. How could "Is it possible to call this method" become invalid, but the fptr remains valid? I'm not sure that I follow that ... > I don't see it as a problem. In Perl5, you get back a coderef. And > despite whether the method is modified or removed from the class in the > meantime, that code reference is still valid. I think the issue is that Perl is interpreting things, whereas the parrot would be quoting back actual memory locations saying "ok, this is RIGHT HERE. when you want to do it, go RIGHT HERE" and then we up and moved "here" to "there" and all hell breaks loose when I try to "callmethod" on a pure number :o Although, I guess Parrot could still be doing memory management at the VM level and the PASM would still be getting lookup refs instead of actual physical pointers, at which case I'm not sure I see the problem ... I guess if "who's 'foo()' am I calling" is determined by some property of the object, then it's possible to get a fptr P to function F from object O at time T, do stuff with O (some of which might cause P' to be the proper F fptr instead of P), and then calling P is no longer "legitimate" ... But I'm not entirely convinced that's not the coder's problem, since that would, imo, be a side-effect of whatever calls were made between "can" and "call", which means either (a) they're documented properly and the coder missed that step and forgot to get a new P for F (making P <- P') or (b) it's NOT documented, at which point it's still the coder's error, just a different coder :) since the side-effect is important and (possibly) break-a-licious ... --attriel (so, at the level we're talking about right now, are we getting fptr P as a memory location that has the function and we want to jump there (or has the function ref, etc); or is P a ref that parrot will then look up in the object and dig up the right answer (but has already done some level of lookup to make this lookup easy; we've already found where it is in the object the first time; now I have to find out where that is in memory/load that into memory and call it)
Re: [perl #20315] [PATCH] eval
Leopold Toetsch wrote: > 1) > The call function to the compiler/assembler is kept as a NCI. Better > would be a subclass of NCI (Compiler.pmc or so), which provides > invoke_keyed(key, next) Hmm, I don't know what a NCI is. Where (which files) can I find information about them? Jerome -- [EMAIL PROTECTED]
RE: Objects, finally (try 1)
I realize this will vary from language to language, but generally we will need a PMC that encapsulates a method (and responds to the invoke vtable method like Sub, or maybe the Sub PMC could do?). This python code is interesting: class A: def f (self): print "A.f()" def g (self): print "g()" a = A() a.f()# output: A.f() x = a.f # get the method, a limited form of currying # since the first arg (a==self) is stored x() # output: A.f() setattr(A, "f", g) # replace A's f with g a.f()# output: g() x() # output (still): A.f() !!! Which shows that the dispatch (i.e. selecting which method to call) can happen before the invocation. -- Jonathan Sillito > -Original Message- > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > At 8:53 PM -0800 1/14/03, Adriano wrote: > >On Tue, 14 Jan 2003 17:18:22 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > >Dan: > >>You're off. It'll be something like: > >> > >>callmethod Px, "method_name" > >> > >>or > >> > >>jmpmethod Px, "method_name" > > > >Jonathan: > >>Is there going to be any way to (in PASM) find a method with > out invoking > >>it? I am not sure, but it may be useful for currying and some efficiency > >>stuff (like moving dispatch outside of a loop that repeatedly invokes a > >>method). > > > >Dan: > >>Yep. There should be a can operator, though I'm not sure how often > >>one wants to check for the existence of a method in an object > >>without calling it. But no reason not to. More for rev 2. > > > >I think what Jonathan asked for was an operator for returning a > >method (as an object) which can be invoked later with some arguments > >(or even applied with a partial list of arguments for currying). > >This would be a lot more useful than a yes-or-no answer about > the existence > >of a method. > > I thought about this--it's what the find_method vtable method was for > in the first place. Unfortunately, as was pointed out to me, there's > no good way to cache the result, since it could potentially be wrong > by the time the method is actually called. > > We could potentially get around this if we put in place a > notification framework to invalidate these method handles, but that > means we have to have a fair amount of infrastructure in place to do > that. (Though, honestly, I do really like the idea, as it means we > can be faster by default and just pay the price when things change, > but there's that pesky code that needs writing and systems that need > designing to support it...) > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
Re: [perl #19610] [PATCH] New language support: Ook!
Leopold Toetsch wrote: > Jerome Quelin (via RT) wrote: > > - currently I'm just printing on stdout the resulting parrot code, > > I lack an eval instruction in Parrot. Dan, Leo? :-) > $ diff -ub ~/src/parrot/languages/ook/ook.pasm ook.pasm > --- /home/lt/src/parrot/languages/ook/ook.pasm Wed Jan 1 01:34:16 > 2003 +++ ook.pasmWed Jan 15 16:41:00 2003 > @@ -101,7 +101,8 @@ > LOOP_END: > le I1, I0, LOOP > concat S4, "\tend\n" > -print S4 > +#print S4 > + compile P1, S4, "PASM" > end > $ ../imcc/imcc -r ook.pasm hello.ook > Hello World! Hey, I just rsync'd my parrot, applied the mini-patch above in order to compile the string instead of priniting it, and I got: $ make test /usr/bin/perl5.8.0 ../../assemble.pl ook.pasm > ook.pbc Couldn't find operator 'compile_p_s_sc' on line 105. ../../parrot ook.pbc hello.ook > foo.pasm $ ../imcc/imcc -r ook.pasm hello.ook last token = [compile] (error) line 105: parse error Didn't create output asm. You don't seem to have checked in the compile thing... About the eval: you said that compile does eval here. In the future, how should I eval after compile? Jerome -- [EMAIL PROTECTED]
RE: Objects, finally (try 1) [x-adr][x-bayes]
From: attriel [mailto:[EMAIL PROTECTED]]
>
> >> > >I think what Jonathan asked for was an operator for
> >> > >returning a method (as an object) which can be invoked
> >> > >later with some arguments (or even applied with a
> >> > >partial list of arguments for currying).
> >> > >
> >> > >This would be a lot more useful than a yes-or-no
> >> > >answer about the existence of a method.
> >
> > Exactly. 'Yes' might be valid one moment, and invalid the
> > next. Not a very useful operation... Returning a coderef
> > on the other hand is useful.
>
> Er. How could "Is it possible to call this method" become
> invalid, but the fptr remains valid? I'm not sure that I
> follow that ...
Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating
method handles. In Perl5:
package Foo;
sub bar { print "hello world\n" }
package main;
my $cref = Foo->can('bar');
undef *Foo::bar;
Foo->$cref();
Foo->bar();
1;
would result in:
hello world
Can't locate object method "bar" via package "Foo" (perhaps you forgot to
load "
Foo"?) at [...] line 7.
As you can see, this is something you can do this in Perl5. And as Perl6 is
supposed to be able to run Perl5... I'd think this'd be something parrot'd
be required to support.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
RE: Objects, finally (try 1)
> Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating
> method handles. In Perl5:
>
> package Foo;
> sub bar { print "hello world\n" }
> package main;
> my $cref = Foo->can('bar');
> undef *Foo::bar;
> Foo->$cref();
> Foo->bar();
> 1;
>
> would result in:
>
> hello world
> Can't locate object method "bar" via package "Foo" (perhaps you forgot
> to load "
> Foo"?) at [...] line 7.
>
> As you can see, this is something you can do this in Perl5. And as Perl6
> is supposed to be able to run Perl5... I'd think this'd be something
> parrot'd be required to support.
Hrrm. I didn't know that case worked :o
I guess then that we'd be returning a code-object and calling the (nifty
new) compile opcode on it when we wanted to actually run it ... from what
I understood of Dan's last reply, though, we're getting "yes/no" and this
entire subtree got pruned :o
I guess we'd be, effectively, looking at ref counters (like with memptrs
and GC), so we can say "oh, we deleted that, but I have this reference, so
I'll invalidate the real call, but leave it there so the ref works",
effectively like hard links on unix, i guess ...
Would that work as an option to resolve it? I don't know the memory or
data-store values (especially not of objects that are still just words :o)
but would it be possible to keep a refcount for the items, set at 1 (b/c
it's defined :) and then if someone does a can() we increment it until the
$val that can() went into either gets undef'd, descoped, or otherwise
loses it's reference? (those two are static events, I think, and $var
could just tell it's ref that it's going away, quit counting me ... )
random mumblings that I don't really understand how they'd work in parrot:
If we have a FPtr PMC, and we provide it as a return to can(), after
incrementing the internal refcount ...
Then on an "undef *Foo::bar;" it invalidates the name in the PMC (and
Foo's meth tables?) and decreases it's refcount ...
Then set whatever kinds of traps (I guess they'd be compiler level) so
that whenever the value of the $var that took the result of can() is
changed, it decrements the refcount ... I think that's compiler level, so
it just takes longer to compile, while it tosses in the extra opcodes for
decrements ...
and then if the refcount == 0 we just mark it for GC and forget about it
entirely ...
Like i said, no idea how all that ACTUALLY works out in parrot, though :o
--attriel
Re: Objects, finally (try 1)
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote: > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote: > >But who knows, maybe it could be made modular enough (i.e., more > >interface-oriented?) to allow the best of both worlds -- I'm far too > >novice wrt Parrot to figure out what it'd look like, unfortunately. > > It'll actually look like what we have now. If you can come up with > something more abstract than: > > callmethod P1, "foo" > > that delegates the calling of the foo method to the method dispatch > vtable entry for the object in P1, well... gimme, I want it. :) > I'll add "define method dispatch more" to the list o' stuff for the > next edit of the proposal. I'll help you along by offering this explanation of how instance methods work in Python. (sorry if you're already familiar with this stuff, but it's in my best interest to make sure you are ;-)) When you say something like `o.foo()', it translates into these steps: 1) LOAD_NAME 'o' 2) LOAD_ATTR 'bar' 3) CALL_FUNCTION #2 has extra magic. What I mean is, when you LOAD_ATTR a function from a *class*, you just get back a plain old `unbound method'. When you LOAD_ATTR from an *instance*, and (after failing to find an instance attribute) the attribute is found on its class, you get a `bound method', which basically means that Python has "curried" that method so the first argument is automatically passed -- that first argument is the instance which you LOAD_ATTRd from. This is why you see all those python methods with the first argument being `self', and rarely see code which explicitly passes that first argument. Now, like I said, this magic is done in LOAD_ATTR, not CALL_FUNCTION, so you can take that bound method object and do whatever you want with it before calling it. Here's an interesting code snippet which also demonstrates the fact that methods are just attributes. >>> def toot(): print "hello" ... >>> class Foo: pass ... >>> # binding a method *to the instance* -- this prevents magic >>> o = Foo(); o.toot = toot >>> o.toot() hello >>> # binding method *to the class* -- just the same as if we defined >>> # `toot' in the class definition >>> Foo.toot = toot >>> o2 = Foo() >>> o2.toot() Traceback (most recent call last): File "", line 1, in ? TypeError: toot() takes no arguments (1 given) That traceback happened because, as I explained above, when the `toot' attribute was LOAD_ATTR'd from the instance and found on the class, it was turned into a bound method that would have the instance automatically passed to it. HTH, -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project -+ http://twistedmatrix.com/users/radix.twistd/
Re: Objects, finally (try 1)
At 7:11 PM +0530 1/15/03, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: rather than attributes, but I may be incorrect here. Are the current python instance attributes both: *) defined per object rather than per class *) Essentially global, that is not hidden from parent classes or anything. (Basically one big pool 'o things attached to the object) Speaking out of turn Python instance stuff is per Object ... And from the looks of it's just a dictionary lookup in the obj.__dict__ dictionary ... So the stuff looks essentially global. In that case they'd correspond to our properties, and I can already feel a massive terminology disconnect looming. Maybe we should rename properties and attributes to frobs and thingies, just so there's no overlap. :( At least getting to obj.__dict__ is simple enough, as we can map that to the property hash fetch opcode. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #20315] [PATCH] eval
At 8:27 PM + 1/14/03, Leopold Toetsch (via RT) wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #20315] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20315 > Attached is a first try towards eval. - interpreter has a new data member Parrot_compreg_hash - parrot registers the PASM1 type i.e. what PDB_eval can parse - the new B opcode (ab)uses nci to build a function for calling PDB_eval - nci is extended (jit/i386 only), to understand an 'I' param as interpreter - the string is evaled immediately, we don't have multiple byte code segments yet No registers, which nci uses, are preserved, no error checking and so on, but works ;-) Yow, Cool! We *have* to get IMCC built into parrot now. Some questions arise here: - Should the B opcode also have a form with a label to build PASM compilers, ook? I think you've confused me here. (No, I'm wrong--you've definitely confused me here) More explanation? - is using the NCI interface ok for evals purpose? Sure. We can rejig it later if we need to, but I expect most compilers will involve a trip into C code, so that's fine. - how should a byte code segment (PMC) look like? Ah, the big question. I'm not quite sure yet--let's try and work that out while I'm churning over objects. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 3:10 PM + 1/15/03, Peter Haworth wrote: On Wed, 15 Jan 2003 01:00:59 -0500, Dan Sugalski wrote: At 8:53 PM -0800 1/14/03, Adriano wrote: >I think what Jonathan asked for was an operator for returning a method >(as an object) which can be invoked later with some arguments (or even >applied with a partial list of arguments for currying). This would be a >lot more useful than a yes-or-no answer about the existence of a method. I thought about this--it's what the find_method vtable method was for in the first place. Unfortunately, as was pointed out to me, there's no good way to cache the result, since it could potentially be wrong by the time the method is actually called. Is that such a big deal? The same problem exists in perl 5 with the following code: Right, but the example is showing a programmer's error. The folks using parrot have to make their own subtle mistakes--we can't make the mistakes on their behalf. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #20315] [PATCH] eval
In perl.perl6.internals, you wrote: > Leopold Toetsch wrote: >> 1) >> The call function to the compiler/assembler is kept as a NCI. Better >> would be a subclass of NCI (Compiler.pmc or so), which provides >> invoke_keyed(key, next) > Hmm, I don't know what a NCI is. Where (which files) can I find > information about them? Native Call Interface. s. nci.c, build_nativecall.pl, classes/nci.pmc, the docs and Dan's announcement on the list. > Jerome HTH leo
Re: [perl #19610] [PATCH] New language support: Ook!
In perl.perl6.internals, you wrote: > Leopold Toetsch wrote: >> $ ../imcc/imcc -r ook.pasm hello.ook >> Hello World! > You don't seem to have checked in the compile thing... No, its not ready yet. > About the eval: you said that compile does eval here. In the future, how > should I eval after compile? Probably by invoke-ing the created PMC. > Jerome leo
Re: Objects, finally (try 1)
On Wed, Jan 15, 2003 at 11:17:17AM -0500, Dan Sugalski wrote: > In that case they'd correspond to our properties, and I can already > feel a massive terminology disconnect looming. Maybe we should rename > properties and attributes to frobs and thingies, just so there's no > overlap. :( We could call them houses and hotels - you'd only be allowed attributes after you had 4 properties, and if you want to mortgage, er serialise the object you'd have to hand them all back to the bank, er GC system. Mmm. Maybe that's taking the analogy well beyond breaking point. I've had a look in a thesaurus for words similar to property and attribute, and I can't see much that's good. "idiosyncrasy" is a nice word, but it's 6 syllables, and hard to spell. "satellite" seems quite good for objects and "stuff" that are hangers-on, as does "chattels". I quite liked the idea of "virtue" for a quality, although I'm not sure if Larry would sanction PMCs having vices as well :-) The downside of finding completely new names for these two concepts is that everyone would have to learn what they meant. The upside is that there would be no confusion with every other language's contradictory definitions. Nicholas Clark
Re: Objects, finally (try 1)
On Wed, Jan 15, 2003 at 01:00:59AM -0500, Dan Sugalski wrote: > At 8:53 PM -0800 1/14/03, Adriano wrote: > >I think what Jonathan asked for was an operator for returning a > >method (as an object) which can be invoked later with some arguments > >(or even applied with a partial list of arguments for currying). > >This would be a lot more useful than a yes-or-no answer about the existence > >of a method. > > I thought about this--it's what the find_method vtable method was for > in the first place. Unfortunately, as was pointed out to me, there's > no good way to cache the result, since it could potentially be wrong > by the time the method is actually called. > > We could potentially get around this if we put in place a > notification framework to invalidate these method handles, but that > means we have to have a fair amount of infrastructure in place to do > that. (Though, honestly, I do really like the idea, as it means we > can be faster by default and just pay the price when things change, > but there's that pesky code that needs writing and systems that need > designing to support it...) How much infrastructure do you need? I thought perl5 cached method lookup, but had a global (per interpreter) generation count, which went up by one every time you (re)defined a method. So for parrot you return a "thingy" that is initially implemented as the direct pointer, a generation count, plus enough other stuff to redo the search. If at the time of calling the generation count is the same, wehay, go for it. Otherwise redo the search there and then, and update. Later on you can add in the notify system, if that's faster. (It may well be, as at that point the pointer will always be valid, even if it's now pointing to some placeholder bytecode that just throws an exception if called.) Hmm. That's a cheat idea. You could keep track of all these "thingies", and make sure the jump pointer was always valid. You just arrange that it is replaced with a pointer into a relookup routine every time something "relevant" gets redefined. (Initially a global counter, but it can get more specialised later). That trades faster call speed each time (because the pointer is now always valid, so you never need to check the generation count at each call) for more maintenance time for each method redefine. Although in turn you could then maintain you backpointers to all the "thingies" in two sets - ones that are currently pointing to the "lookup" code, and ones that point to real methods. Every time the "world" is updated with code (re)definition you convert all the real methods to point to the "lookup" code. Every time a "lookup" code routine is called it finds the real method, and moves itself back to the the real set. This would actually let you defer the method lookup - when you create one of these pointers it's actually lazy, pointing to the "lookup" code, and the lookup is really only done the first time you call it. Am I rambling too much? Nicholas Clark
Re: [perl #20315] [PATCH] eval
Dan Sugalski wrote: At 8:27 PM + 1/14/03, Leopold Toetsch (via RT) wrote: Yow, Cool! We *have* to get IMCC built into parrot now. You do get this wrong - always ;-) imcc = parrot + assemble.pl - pre-processor + PIR-assembler + optimizer/10#yet & now & already With the help of assemble.pl -E (preprocess only, spitting out PASM) imcc runs *all* parrot tests. - Should the B opcode also have a form with a label to build PASM compilers, ook? I think you've confused me here. (No, I'm wrong--you've definitely confused me here) More explanation? I was thinking of assembler/compilers implemented in PASM, as languages/ook/ook.pasm is a "ook" compiler. It could register a compreg with type "Ook", which uses the registered "PASM" compiler to run ook code ;-) - is using the NCI interface ok for evals purpose? Sure. We can rejig it later if we need to, but I expect most compilers will involve a trip into C code, so that's fine. Ok, then this needs some twigging. I did use signature 'I' for pushing a Parrot_Interp. The return value needs still work. - how should a byte code segment (PMC) look like? Ah, the big question. I'm not quite sure yet--let's try and work that out while I'm churning over objects. I did have a closer look at struct PackFile. I think we have some possiblities to actually eval()/invoke() the code, depending on the HL: - new interpreter, nothing shared (unlikely) - new interpreter, context shared - meaning also constants - same interpreter, everything shared So it seems, that for multiple code segments, we'll have to take the PackFile_ConstTable out of the structure and include file/line/debug/whatever information. This would look like: packfile aka interpreter->code: - constants - code_segment[] - byte_code - byte_code_size - [ more of current packfile ] - filename - lines[] - [ more aditional stuff ] - prederefed_code - jit_info (jitted code) - fixups The return value of B would then be a pointer to such a code_segment. BTW a PackFile_Constant should be a union IMHO, currently each type has its own storage. leo
RE: Objects, finally (try 1)
Sounds like we want objects *and* classes to support: static_attribs - which are defined at compile time and accessed by offset probably stored in an array. dynamic_attribs - which come and go at run time and are generally accessed by name and likely stored in a hash. -- Jonathan Sillito > -Original Message- > From: Nicholas Clark [mailto:[EMAIL PROTECTED]] > Sent: January 15, 2003 12:41 PM > To: Dan Sugalski > Cc: Gopal V; [EMAIL PROTECTED] > Subject: Re: Objects, finally (try 1) > > > On Wed, Jan 15, 2003 at 11:17:17AM -0500, Dan Sugalski wrote: > > In that case they'd correspond to our properties, and I can already > > feel a massive terminology disconnect looming. Maybe we should rename > > properties and attributes to frobs and thingies, just so there's no > > overlap. :( > > We could call them houses and hotels - you'd only be allowed attributes > after you had 4 properties, and if you want to mortgage, er serialise the > object you'd have to hand them all back to the bank, er GC system. > > Mmm. Maybe that's taking the analogy well beyond breaking point. > > I've had a look in a thesaurus for words similar to property and > attribute, > and I can't see much that's good. "idiosyncrasy" is a nice word, > but it's 6 > syllables, and hard to spell. "satellite" seems quite good for objects and > "stuff" that are hangers-on, as does "chattels". I quite liked the idea of > "virtue" for a quality, although I'm not sure if Larry would sanction PMCs > having vices as well :-) > > The downside of finding completely new names for these two > concepts is that > everyone would have to learn what they meant. The upside is that > there would > be no confusion with every other language's contradictory definitions. > > Nicholas Clark >
Re: Objects, finally (try 1)
> "JS" == Jonathan Sillito <[EMAIL PROTECTED]> writes: JS> Sounds like we want objects *and* classes to support: JS> static_attribs - which are defined at compile time and JS> accessed by offset probably stored in an array. JS> dynamic_attribs - which come and go at run time and are JS> generally accessed by name and likely stored in a hash. that isn't a bad idea. describe them in parrot by their lower level use (or implementation) and map them to the high level lang and its own OO/property terms. i would use shorter names like dyn_attr and stat_attr. but where they are stored is also an issue. are they instance specific or class only? there are several combinations of those features too. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
