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. # URL: 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: 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 stdin, 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. # URL: 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 Bcompile 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 Bcompreg 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 Bcompreg 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 Bcompile 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
Re: Array Questions
[EMAIL PROTECTED] (Michael Lazzaro) writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; I think at this stage it's probably worth reminding everyone that not every string of characters *needs* to be syntactically valid Perl 6, despite our best efforts. -- Do not meddle in the affairs of cats, for they are subtle and will piss on your computer. --Bruce Graham
Re: L2R/R2L syntax (was Re: Everything is an object.)
[EMAIL PROTECTED] (Mr. Nobody) writes: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've done that. -- COBOL is for morons. -- E.W. Dijkstra
Re: L2R/R2L syntax (was Re: Everything is an object.)
[EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. -- A witty saying means nothing. -Voltaire
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 12:05 AM + 1/16/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. I was shooting for the good old days of sarcasm that people noticed, but alas I missed. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
