Re: Proposed vtable changes WRT method lookup
Dave Whipp [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
1) rename vtable-data to vtable-class
All current usage of the 'void *data' vtable element is as the object's
class. So it should read PMC *class.
Its a minor thing, but I would try to avoid using identifiers that are
keywords in C++: especially in header files.
Aren't struct members in a distinct namespace? It's like:
typedef struct _vtable {
...
PMC *class;
...
} VTABLE;
But it could of course read Cclass_pmc or such.
Dave.
leo
Re: Proposed vtable changes WRT method lookup
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Below inline attached is a proposal for vtable changes, mainly WRT method lookup. First, a general question: under what circumstances is it OK and/or expected for the opcode Cgetclass and the VTABLE entry VTABLE_get_class to return different results? No. The opcode should just call VTABLE_get_class() and return, what that method returns. At the moment, these return quite different results for all of the standard PMCs. The Cgetclass opcode currently returns, what the type registry Cclass_hash provides. This is ok for the standard PMCs, because the registered class is Cvtable-data. But the opcode should just call VTABLE_get_class(). The more general observation behind this question: if Parrot is going to provide a mechanism by which a class can override get_class, then the runtime should depend on such interfaces instead of bypassing them and attempting to standardize on mechanisms. Yes. The proposed changes are one step towards that goal. I'd like to have a standard interface for classes, a default implementation for Parrot core PMCs and Parrot standard objects, and all the phases of class manipulation should of course be overridable, i.e. the individual methods are all called through vtable functions. - Sam Ruby leo
Re: Proposed vtable changes WRT method lookup
All~ On Tue, 18 Jan 2005 10:18:52 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Below inline attached is a proposal for vtable changes, mainly WRT method lookup. First, a general question: under what circumstances is it OK and/or expected for the opcode Cgetclass and the VTABLE entry VTABLE_get_class to return different results? No. The opcode should just call VTABLE_get_class() and return, what that method returns. At the moment, these return quite different results for all of the standard PMCs. The Cgetclass opcode currently returns, what the type registry Cclass_hash provides. This is ok for the standard PMCs, because the registered class is Cvtable-data. But the opcode should just call VTABLE_get_class(). The more general observation behind this question: if Parrot is going to provide a mechanism by which a class can override get_class, then the runtime should depend on such interfaces instead of bypassing them and attempting to standardize on mechanisms. Yes. The proposed changes are one step towards that goal. I'd like to have a standard interface for classes, a default implementation for Parrot core PMCs and Parrot standard objects, and all the phases of class manipulation should of course be overridable, i.e. the individual methods are all called through vtable functions. It looks like we are creating ourselves a reasonable subset of the Common Lisp Object System here. Given that CLOS was created to allow Lisp programs to modify their objects' semantics to those of a different dialect of Lisp, perhaps we could learn from their structure. We have an mro array just like CLOS, we have a class PMC just like CLOS. If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. Logically this would make some sense as no single class can have the smarts to do MMD since it depends on all objects involved. This also allows each MMD function to dispatch according to the language which defined the function (and thus the MMD_Resolution PMC for that function). Hope that makes sense, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Proposed vtable changes WRT method lookup
Matt Fowles [EMAIL PROTECTED] wrote: ... If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. That was Cvtable-dispatch in the proposal. Cfind_method is just called to query one object or class, if it can do the method. Finding the final (MMD) function is done separately with a distinct vtable method (and probably implemented inside some meta class PMC). Hope that makes sense, Yes. Matt leo
Re: Proposed vtable changes WRT method lookup
Leo~ On Tue, 18 Jan 2005 16:52:52 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Fowles [EMAIL PROTECTED] wrote: ... If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. That was Cvtable-dispatch in the proposal. Cfind_method is just called to query one object or class, if it can do the method. Finding the final (MMD) function is done separately with a distinct vtable method (and probably implemented inside some meta class PMC). That makes sense. If the vtable-dispatch method is attatched to some PMC, what provides that PMC? Is it the MMD function being called (what I would suggest), some environmental one, or something else? Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Proposed vtable changes WRT method lookup
Matt Fowles [EMAIL PROTECTED] wrote: Leo~ On Tue, 18 Jan 2005 16:52:52 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: That was Cvtable-dispatch in the proposal. Cfind_method is just called to query one object or class, if it can do the method. Finding the final (MMD) function is done separately with a distinct vtable method (and probably implemented inside some meta class PMC). That makes sense. If the vtable-dispatch method is attatched to some PMC, what provides that PMC? That PMC is the metaclass PMC of the class system. For standard Parrot objects that's mostly default.pmc or parrotclass.pmc and/or an implementation in src/objects.c. ... Is it the MMD function being called (what I would suggest), some environmental one, or something else? Given a P6 function call (which can be MMD or not): foo($a, $b, $c) If nothing is kwnown about foo, this would be basically: func = a.dispatch(foo)# VTABLE_dispatch(interp, a, foo) invokecc func That ends up in default.pmc's implementation normally, which calls Cfind_method repeatedly according to Cvtable-mro and the algorithm described in MMD and VTABLE_find_method. Matt leo
Name of parrot executable
To implement tcl's [info nameofexecutable] I need to get the name of the exectuable parrot was invoked with. I would have expected to live in interpinfo, but don't see it there. Anyone have a pointer to where this is? (If it's not in yet, I'll add a TODO)
Calling conventions, invocations, and suchlike things
Hi folks. Sorry I've been gone so long. Non-p6i stuff's been well past monopolizing my time. Not much of an excuse, I know, but the Real World intrudes at the most inconvenient times. Things are, I hope, easing up a little, though I apologize in advance if I get a little cranky while I get back into things. Having (very lightly) skimmed the past month of list mail, I'm thinking the best place to start is with the things that've come up about objects and method calls. I want to explain why things are designed the way they are so (hopefully) everyone's on the same page. (And, hopefully, to forestall grumbling when I say things aren't going to change :) The setup, for those following along at home, is that when we make a method call the object is passed out-of-band (that is, not as part of the regular parameter list), and that objects don't actually handle method dispatch -- we split it into a two step affair where we request an invokable method PMC for a named method from an object, and then invoke it as a separate step. The easy one first -- why the object is out-of-band, rather than one of the parameters. (Something that I doubt anyone's that worked up over, and I think everyone's OK with things as they stand, but here are the reasons anyway) Parrot's got the interesting, and somewhat unfortunate, requirement of having to allow all subroutines behave as methods and all methods behave as subroutines. (This is a perl 5 thing, but we have to make it work) That is, an invokable PMC may be invoked as a method call and passed in an object, or as a plain subroutine and not have an object passed in. As far as perl 5 is concerned the object is the first parameter in the argument list, but for everyone else the object is a very distinct and separate thing. Regardless invokable things need to know whether they were called as a method or a sub. We *could* set a flag and have them check, then have some convention where the first parameter is an object if the I'm a method flag is set, but... yech. Having the object be separate and standalone seems cleaner, while still giving us a way to distinguish method/sub invocation. (You check to see if there's an object) This does make things a little tricker for the perl 5 code generator, but not that much trickier and, let's face it, we're below the layer where things are easy. This *also* makes building signature checking into parrot a lot simpler (something we should do), since the signature checking stuff doesn't have to deal with possible parameter shifting based on whether we've a sub or method invocation. Not having objects handle their own method dispatch is less clear-cut, but I do have some reasons, so here they are. First off, one of the things I'm very much concerned about is C stack usage, both because we don't have all that much we can count on (joys of threads -- we'll be lucky to scrape together 10k some places) and because continuations can't cross C stack level boundaries. We're pretty careful about that one (it's the big reason for the limitation that continuations taken from within vtable functions can't escape). I realize we can continue to be careful with it, mandating that the invoke_method vtable function behaves the same as the plain invoke does (that is, returning the address to jump to) but that brings up a separate problem -- transfer of control is a relatively heavyweight thing for us. Method and sub calls can potentially cross bytecode and security boundaries. Doing that right requires (potentially) a fair amount of screwing around inside the interpreter, as well as the invokable thing carrying around enough metadata to properly do the transfer. I'd really prefer to limit the number of PMCs that have that amount of intimate knowledge. Since all methods and subs have the appropriate bits attached to them, I'd as soon just use them. There's also the potential issue of curried methods, where we need to create a new invokable thing and bind some parameters to it. We can certainly do that now with the current scheme so adding an invoke_method to the mix won't get in the way as such, but it does mean we have two near-identical ways of doing the same thing (find_method invoke, and invoke_method) and since we can't toss the find_method way, it doesn't feel like adding invoke_method to the mix will get us anywhere. Anyway, there we go. (I fully expect to find that both topics are dead about an hour after this goes out, but there you go :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Calling conventions, invocations, and suchlike things
Dan Sugalski wrote:
Hi folks.
Welcome back!
Parrot's got the interesting, and somewhat unfortunate, requirement of
having to allow all subroutines behave as methods and all methods behave
as subroutines. (This is a perl 5 thing, but we have to make it work)
That is, an invokable PMC may be invoked as a method call and passed in
an object, or as a plain subroutine and not have an object passed in. As
far as perl 5 is concerned the object is the first parameter in the
argument list, but for everyone else the object is a very distinct and
separate thing.
Python essentially has the same requirement, with a few twists.
Specifically, methods come in be static, class, and regular flavors.
But first, a simple example. Strings in python have a find method, so
and can do the following:
f = Parrot.find
print f(r)
Note that I referenced the method as an attribute, and then called it as
a function. Furthermore, the function remembers what object it is
bound to. This is accomplished by VTABLE_find_method creating a new
PyBoundMeth PMC which contains two references, one to the object, and
one to the method. The sole responsibility of a bound method is to
insert the first parameter into the call, and then to invoke the desired
method.
Static methods differ in that the object is not passed.
Class methods differ in that the object passed is actually the class of
the object in question.
Note: all this is determined by the callee. It is all transparent to
the caller.
Now, compare that to callmethod or callmethodcc in ops:
object = REG_PMC(2);
method_pmc = VTABLE_find_method(interpreter, object, REG_STR(0));
if (!method_pmc) {
real_exception(interpreter, next, METH_NOT_FOUND,
Method '%Ss' not found, REG_STR(0));
}
REG_PMC(0) = method_pmc;
interpreter-ctx.current_object = object;
dest = (opcode_t *)VTABLE_invoke(interpreter, method_pmc, next);
First, observe that I don't have any control over the exception that is
raised when a method is not found (fix: raise the exception within
find_method). Second, observe that this assumes that current object is
the object in all cases. This doesn't work well for static or class
methods (fix: create a PyBoundMeth object which overrides this, and then
call the real method).
This does make things a little tricker for the perl 5 code generator,
but not that much trickier and, let's face it, we're below the layer
where things are easy. This *also* makes building signature checking
into parrot a lot simpler (something we should do), since the signature
checking stuff doesn't have to deal with possible parameter shifting
based on whether we've a sub or method invocation.
Parameter shifting actually is made easier by placing the object in
question in a separate register... no shifting is required. (Note: in
cvs, I actually do the shifting, partially because I'm in the process of
reverting a change, and partially do to the issue raised in the next
paragraph).
My one minor request here is P2 be made available on entry to the
invoked method. This would remove some special case logic for me
requiring the use of interpinfo. I don't expect any guarantees that
this is preserved or restored across sub calls.
Not having objects handle their own method dispatch is less clear-cut,
but I do have some reasons, so here they are.
Just be aware that in order to preserve Python semantics, find_method
will need to return a bound method. This involves creating an object on
the heap, garbage collection, and a minor addition to the number of
instructions executed on invoke (including a nested C stack).
This could all be avoided if there was a VTABLE_callmethod interface as
the code would know that the intent was to only use this found method
exactly once.
*shrug*
Do you plan to choose banana cream again at OSCON 2005?
- Sam Ruby
Perl 6 Summary for 2005-01-11 through 2005-01-18
Perl 6 Summary for 2005-01-11 through 2005-01-18 Welcome to yet another Perl Summary brought to you by music and pizza (although the pizza is late in arriving). Like many summaries before it, we start with an attempt at non sequitur and Perl 6 Language. Perl 6 Language idiomatic Perl 6 Stéphane Payrard expressed a desire for more Perl 6 sample code. Luke Palmer issued the following, possibly foolish, response: post some \how do I\s to the list, and I'll reply with code. Austin Hastings posed a couple, not response yet... http://xrl.us/er2z generalized tainting Yuval Kogman posted an interesting musing about contagious properties (if you get your value from someone with a contagious property, you get the property too). No responses, but it sounds interesting... http://xrl.us/er22 stick/pick Richard H. suggested a new pair of functions stick/pick which would have modifiers such that push, pop, shift, unshift, and splice could all be calls to stick or pick with appropriate modifiers. Unfortunately, I think he posted it to the google groups interface, as it is there but not on the list :-( http://xrl.us/er23 Perl 6 IDE again. Matisse Enzer re-raised the question of the feasibility of an IDE for Perl 6. Unfortunately it was re-raised on google groups (I think). http://xrl.us/er24 1x6 vs 6 The dimension slice issues continue to grind with new suggestions from David Green and Craig DeForest. http://xrl.us/er25 life span of loop counters Joe Gottman wants an easy way to restrict the lifespan of his loop counter to his loop. Some folk (myself included) did not like the answer of wrap it in a scope. Some others (myself excluded) thought the answer don't use loop, use for was a bit of a cop-out. http://xrl.us/er26 forany forall Jonathan Lang wondered how to check if a condition is true for any element of an array or for all elements. The answer are the aptly named junction creaters any() and all(). http://xrl.us/er27 Perl 6 Compiler Already reached p6c and no pizza :-( Ah well, it was a light week. Parrot Internals Already p6i and no pizza :-(. Although it was close, after I wrote the head2 my door buzzed. It was just a neighbor who got locked out, but that would have been impressive timing. blib in 25 seconds Peter Christopher asked for a 25 second summary of the ./blib directory. Apparently this is harder than Hamlet in 30 seconds, as one of the two has been done. http://xrl.us/er28 searching archives Peter Christopher wanted to know if there was a way he could search the mailing list archives. Steve Fink pointed him to groups.google.com and the ever popular discussion topic aardvarks. http://xrl.us/er29 dynclasses with external dependencies Bernhard Schmalhofer wondered if there was a reasonable way to check for external dependencies for dynamic PMCs that does not involve the core Parrot configure step. Later he supplied a patch with his GDBMHash pmc, which motivated the question. Leo applied it and hinted at a mythical multi-stage configure http://xrl.us/er3a -- question http://xrl.us/er3b -- patch s/interpreter/INTERP/g Bernhard Schmalhofer provided a patch making the above clean up all over. Leo and Sam applied different parts of it. http://xrl.us/er3c black-ops parrot Robert Spier posted a link to the new listing for Parrot on CIA. Nicholas Clark dove for cover assuming he was going to be disappeared. http://cia.navi.cx/stats/project/parrot -- CIA http://xrl.us/er3d -- actual post PDD problems on the website Dave Brondsema noticed that PDDs 4-6 were not finding their way to the website properly. Will Coleda fired off a patch. http://xrl.us/er3e cleaning old tickets Will Coleda, in his never ending role as RT janitor, closed out a few obsolete tickets. Thanks Will. http://xrl.us/er3f -- stone-age exceptions http://xrl.us/er3g -- assemble.pl http://xrl.us/er3h -- languages/imcc Scope and Timely Destruction Leopold Toetsch raised the recurring issue of timely destruction. It turns out that timely destruction is hard. Various people made various suggestions. Let me state one thing clearly as if I don't, Dan doubtless will: Parrot will NOT use reference counting of any kind. There are a great many reasons for this some of which Luke Palmer explained. http://xrl.us/er3i ParrotIO* should have been PMC* Peter Christopher provided a patch fixing a pointer declaration bug. Leo applied it. http://xrl.us/er3j questions for the compiler FAQ Some time ago, a compiler faq was started. It was to contain answers to questions that people posted to the list. Will Coleda posted 2 such questions, but got Warnocked.
Re: Perl 6 How Do I? (Was: Perl 6 Summary for 2005-01-11 through 2005-01-18)
Matt Fowles writes:
Perl 6 Language
idiomatic Perl 6
Stphane Payrard expressed a desire for more Perl 6 sample code. Luke
Palmer issued the following, possibly foolish, response: post some
\how do I\s to the list, and I'll reply with code. Austin Hastings
posed a couple, not response yet...
Oh, I thought I replied, but now that I look over the question I guess I
didn't. The question was:
Austin Hasting writes:
How do I concisely code a loop that reads in lines of a file, then
calls mysub() on each letter in each line?
Or each xml tag on the line?
And I guess the answer is the same as in Perl 5. I don't understand
what the problem is with Perl 5's approach:
for {
mysub($_) for .split: /null/;
}
Or:
use Rule::XML;
for {
mysub($_) for m:g/(Rule::XML::tag)/;
}
Luke
Re: Perl 6 How Do I?
LP == Luke Palmer [EMAIL PROTECTED] writes:
LP use Rule::XML;
LP for {
LP mysub($_) for m:g/(«Rule::XML::tag»)/;
LP }
shouldn't that be in the Grammar namespace? not that we have finalized
namespaces but i was under the impression that Grammar was reserved for
full parsing grammars as in Grammar::Perl.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
E, Perl 6, etc.
I recently encountered a language, E, which has some very nifty features for building distributed systems. The current version of E is built on top of Java, but I wonder: * whether E's features will (could) be supported in Perl 6 * whether E could be supported by Parrot Here are some references, for the curious: E language home page http://www.erights.org The E Language in a Walnut http://www.skyhunter.com/marcs/ewalnut.html -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com- Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
