This week's summary
The Perl 6 Summary for the week ending 20030302
Welcome back to another episode in the ongoing saga that is the Perl 6
development process (or at least my attempt to describe it).
We kick off with perl6-internals.
IMCC calling conventions
Piers Cawley attempted to describe tail call optimizations, why they
were a good thing and why a caller saves calling convention made such
optimizations easier (possible?). He wondered if he hadn't just
succeeded in muddying the waters still further. Jerome Vouillon appeared
to understand what Piers was going on about and pointed out that a
caller saves scheme also helps with exception handling. Benjamin
Goldberg wondered about Perl 5's goto func semantics which can be
looked at as a 'sort of' tail call (except you don't actually get much
of an optimization with Perl 5 as it stands) and proposed a callee saves
scheme for doing tail call optimization which didn't optimize away an
unnecessary pair of save/restores. Dan pointed out that, while goto
func (which is sort of like tail call optimization in Perl 5) would
have to be supported, tail call optimization made more sense if you
didn't have to use any special syntax to make use of it.
http://makeashorterlink.com/?J18326AA3
A couple of easy questions...
David (Cuny?) wondered how he could determine the data type of an
arbitrary PMC and whether there were any pre-built Windows binaries of
Parrot available. Leon Brocard pointed him at the typeof operator in
answer to the first question but punted on the second. Leo Tötsch also
pointed at typeof. David noted that it didn't seem to be available in
his 0.0.9 installation and was recommended to use the CVS version, and
discussion drifted toward wondering when Parrot 0.1.0 would see the
light of day. (Not before at least one of either objects or exceptions
is implemented apparently).
Nobody answered the 'pre built Windows binary' part of David's question.
http://makeashorterlink.com/?I59315AA3
More on optimizing the JIT with IMCC
In last week's summary I mentioned that Sean O'Rourke had suggested
getting IMCC to store a control flow graph in bytecode, which the JIT
could use to optimize things more effectively. Sean read this and
pointed out that it wasn't his idea but was actually an area of active
research and gave a pointer to some information. He also pointed to a
USENIX paper which discussed adding a full data-flow compiler into a JVM
which could then generate code that ran faster than a lightweight JIT,
especially for long-running programs. Sean's original link was to a
subscription only site but Jason 'Research wants to be free' Gloudon
found a public version of the paper. Dan was fascinated, but was worried
about availability of engineering time, not wishing to presume on Leo,
Daniel and everyone who's done JIT work.
Dan said that he'd 'rather have a lower-overhead JIT with a win for
shorter programs than a high-overhead one with a win for long-running
programs'. Leo pointed out that, at the moment we already have a high
overhead JIT with most of the cost paid at load time and showed some of
these costs. Dan and Leo then discussed what kind of metadata would be
needed from IMCC (or some external tool) in order to improve matters.
Meanwhile, the original 'Using IMCC as JIT optimizer' thread continued
as Leo committed some more changes both to code and to the documentation
in jit.pod. The new version of the JIT optimizing IMCC should be
platform independent and apparently runs 95% of Parrot's tests on an
i386.
Phil Hassey wondered why we even had a set number of registers in the
JVM in the first place. He wondered if it would be possible to have each
block of code declare 'I need 12 registers for this bloc' and let the
JIT system do the appropriate register spilling magic with the system
registers. Leo said that this is approximately what the JIT optimizer
does at the moment and outlined some of the problems associated with it.
Angel Faus had some questions and suggestions about the optimization
approach that Leo was taking, with particular reference to the amount of
copies to and from memory and proposed an efficient way forward.
Nicholas Clark wondered if some of Angel's suggestions mean that imc
(IMCC source code) had now usurped the role of parrot bytecode and
muttered something about premature optimization and the lack of objects,
exceptions, IO or a Z-code interpreter. Leo bridled slightly at
'premature optimization' and wondered what was important about a Z-code
interpreter ('Z-code interpreter' is, according to Nicholas, 'obfuscated
shorthand for dynamic opcode libraries and reading foreign
bytecode.')
Toward the end of the week, Leo checked in a final patch related to
Re: Object spec, try 2
Peter == Peter Seibel [EMAIL PROTECTED] writes: Hi, I'm new to this list and haven't had a chance to grovel through the old archives yet so please forgive me for jumping in in the middle of things. Anyway, what about languages that don't attach methods to particular classes--languages that support generic functions and multimethods (i.e. a method is dispatched at runtime based on the type of more than one of its arguments.) I ask because I started looking at Parrot (and joined this list) because I was interested in the idea of writing a Common Lisp that runs on Parrot. I had looked at the CLR as a possible target and found it too tied to the single-dispatch model of methods belonging to particular classes. I was hoping things would be more flexible here. Was I hoping for too much? I'd expect defmethod/defgeneric to generate instances of a standard-generic-function and standard-method class, which holds the code and specializations, and whose methods implement CL-style dispatch; this would make for a convenient MOP, as well as providing some chance for interfacing with modules in other languages. Allen pgp0.pgp Description: PGP signature
Re: [RFC] imcc calling conventions
Dan Sugalski wrote:
Benjamin Goldberg wrote:
Jason Gloudon wrote:
Piers Cawley wrote:
I think you're overlooking the restoreall done just before
the jump-no-save-returnaddress operation... I see two savealls
and two restorealls.
But with proper tail call optimization you'd only need *one*
saveall. That's why it's an optimization.
Tail call optimization is a space (stack size) optimization. The
scheme definition only requires space efficiency. The time
optimization is important but a secondary consideration for the
functional language folks.
Here's an idea -- considering that the first op of every sub seems to
be a 'saveall' instruction,
If that's true, we need to thump IMCC some. There's no reason for
this to be the first op--if the caller wanted any registers saved it
had darned well beter have taken care of it itself. That's the point
of caller-save, after all...
Erm, my statement was actually just an assumption that the first op
would be a 'saveall' -- I haven't looked at actual imcc output. By your
comment, I'll assume that my earlier assumption was wildly wrong.
---
Is it possible to divide subroutines into two groups, caller-save and
callee-save? If so, then I *think* that we should be able to make at
least *some* tail-optomizations:
If a caller-save subroutine is going to return the results of another
caller-save subroutine, the first can jump directly into the other.
If a callee-save subroutine is going to return the results of another
callee-save subroutine, the first can jump to the Nth opcode of the
second subroutine, in the manner described down below.
In the other cases (callee-save going to caller-save, or vice-versa), I
suppose (but might be mistaken) that the only tail-call optomization
that can be done is to have the caller skip the step of removeing
results from the stack and then pushing them back on... which might
already be done.
-
There's three or four ways that I can think of for an ordinary
callee-save subroutine to work:
1/ saveall/restoreall
2/ push[ipns]/pop[ipns]
3/ push/pop (with the help of rotate_up)
4/ a combo of 2 and 3.
I assume that most callee-save subroutines have the following stages:
1/ save the registers we're going to be dirtying
2/ (optional, use with methods 34 mentioned above)
rotate_up the stack so that our arguments are on the top.
3/ pop the arguments into registers
4/ do our work
5/ push the return values onto the stack.
6/ (optional) rotate_up the stack
7/ restore the registers we've dirtied.
8/ pop an address off the stack and goto it. (op ret)
If a caller is going to perform a tail-optomized function call, then it
could look like:
1/ save the registers that the callee is going to restore in the
callee's step 7
2/ save any registers that we're using that weren't already saved
3/ rotate_up the stack, if step 2 used push ops.
4/ pop the arguments into registers.
5/ do our work
6/ copy the callee's arguments into whatever registers the callee
would put them into in the callee's step 3.
7/ restore the registers that were saved in our step 2.
8/ branch to step 4 of the callee.
It may be possible for the caller to avoid an explicit step 6, if it can
have it's computations put the arguments in the target registers
directly.
Note that steps 2,7 of the caller can't use saveall/restoreall, since
that would interfere with the registers written to in step 6. (If you
do want to use saveall/restoreall for 2,7, then step 6 becomes push the
arguments for the callee onto the stack, and step 8 becomes branch to
step 3 of the callee). Similarly, if the callee puts arguments into
integer (etc.) registers, you probably can't use savei/restorei.
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0
my$__;s ee substr$;,$,++$__%$,--,1,qq;;;ee;
$__2__}$,=22+$;=~y yiy y;__ while$;;print
Re: [RFC] imcc calling conventions
Jason Gloudon wrote:
On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote:
I think you're overlooking the restoreall done just before the
jump-no-save-returnaddress operation... I see two savealls and
two restorealls.
But with proper tail call optimization you'd only need *one*
saveall. That's why it's an optimization.
Tail call optimization is a space (stack size) optimization. The
scheme definition only requires space efficiency. The time
optimization is important but a secondary consideration for the
functional language folks.
Here's an idea -- considering that the first op of every sub seems to be
a 'saveall' instruction, and in my suggested optomized tail call
example, the one op immediately prior to the 'jsnr _bar' op was a
'restoreall', then the end of _foo might possibly have been written as:
.arg int x # push @_, x
.arg int u # push @_, u
.arg int q # push @_, q
branch (_bar + 1) # goto *second* op of sub _bar.
.end
That is, go to the op immediately after the 'saveall'.
Thus, one saveall is performed, and one restoreall is performed.
The possible problems with this that I forsee are:
1/ If _bar expects some data to be passed in with registers, rather
than with the stack.
2/ If _bar does not have 'saveall' as it's first op.
If _bar is a subroutine generated by the compiler, neither of these
would ever actually occur in practice.
Well, they *could* occur if _bar was written by hand, not compiler
generated. Then for each of the problem cases mentioned above:
1/ If _bar expects some data to be passed in with registers, then
there's no possible way that it could be called by a compiler-generated
function and have behavior that's guaranteed to be consistent -- nor
should we expect this, or worry about it. (Or, we could mark _bar as
expecting to be passed data through registers, and *forbid* it from ever
being called by compiler-generated subroutines, and only allow hand
written subs to call it).
2/ The compiler can easily examine the first op of _bar, and if it
isn't 'saveall', choose not to make the tail call optomization.
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0
my$__;s ee substr$;,$,++$__%$,--,1,qq;;;ee;
$__2__}$,=22+$;=~y yiy y;__ while$;;print
Re: [RFC] imcc calling conventions
At 4:00 PM -0500 3/3/03, Benjamin Goldberg wrote: Jason Gloudon wrote: On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote: I think you're overlooking the restoreall done just before the jump-no-save-returnaddress operation... I see two savealls and two restorealls. But with proper tail call optimization you'd only need *one* saveall. That's why it's an optimization. Tail call optimization is a space (stack size) optimization. The scheme definition only requires space efficiency. The time optimization is important but a secondary consideration for the functional language folks. Here's an idea -- considering that the first op of every sub seems to be a 'saveall' instruction, If that's true, we need to thump IMCC some. There's no reason for this to be the first op--if the caller wanted any registers saved it had darned well beter have taken care of it itself. That's the point of caller-save, after all... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec, try 2
Brent Dax [EMAIL PROTECTED] writes: Dan Sugalski: # Okay, here's another shot at the semantics for objects. If folks, # especially non-perl folks, would look this over and chime in, I'd # much appreciate it. ... # Attributes are local to a class in an object's inheritance hierarchy. # An object can have one foo attribute per class in its inheritance # tree. # # Attributes are considered class-private, so a class will normally # only see its own attributes. There will be a mechanism to see all the # attributes for an object, though. Code outside a class won't see the # attributes--they aren't exposed. ... I honestly don't care much about such languages, but how is Parrot going to support classless languages like JavaScript? Are such languages going to have to fake it with anonymous classes, or will we make sure that you don't *really* need a class behind an object? Hi, I'm new to this list and haven't had a chance to grovel through the old archives yet so please forgive me for jumping in in the middle of things. Anyway, what about languages that don't attach methods to particular classes--languages that support generic functions and multimethods (i.e. a method is dispatched at runtime based on the type of more than one of its arguments.) I ask because I started looking at Parrot (and joined this list) because I was interested in the idea of writing a Common Lisp that runs on Parrot. I had looked at the CLR as a possible target and found it too tied to the single-dispatch model of methods belonging to particular classes. I was hoping things would be more flexible here. Was I hoping for too much? -Peter -- Peter Seibel [EMAIL PROTECTED] The intellectual level needed for system design is in general grossly underestimated. I am convinced more than ever that this type of work is very difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expense. --Edsger Dijkstra
RE: Object spec, try 2 [x-adr][x-bayes]
On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote: From: Erik Bågfors [mailto:[EMAIL PROTECTED] On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? My imperfect understanding is: attribute is only used in an OO context and refers to the data members the class or object encapsulates. property has nothing inherently to do with OO. Properties are tags against variables and values and are compile or run time specific. Hints to the compiler and interpreter... Ok, any example of such a property? Also, how is the difference between a class variable and a object variable? Don't you mean class attribute and object attribute? The first is class-wide and accessible to all objects, whereas the latter is specific the object instance: Ofcourse... you missunderstod me (I see now that my english wasn't very good). After I sent my mail the answer jumped up in my head so just ignore this :) /Erik -- [EMAIL PROTECTED] fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Object spec, try 2
Brent Dax wrote:
Dan Sugalski:
# Okay, here's another shot at the semantics for objects. If folks,
# especially non-perl folks, would look this over and chime in, I'd
# much appreciate it.
[snip]
I honestly don't care much about such languages, but how is Parrot
going to support classless languages like JavaScript? Are such
languages going to have to fake it with anonymous classes, or will we
make sure that you don't *really* need a class behind an object?
Presumably, the similarly to how Java handles JavaScript -- all
JavaScript objects are, from Java's point of view, members of one single
class, the JavaScriptObject class. (Well, something like that,
anyway).
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0
my$__;s ee substr$;,$,++$__%$,--,1,qq;;;ee;
$__2__}$,=22+$;=~y yiy y;__ while$;;print
RE: Object spec, try 2 [x-adr][x-bayes]
Erik Bågfors wrote: On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote: From: Erik Bågfors [mailto:[EMAIL PROTECTED] On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? My imperfect understanding is: attribute is only used in an OO context and refers to the data members the class or object encapsulates. property has nothing inherently to do with OO. Properties are tags against variables and values and are compile or run time specific. Hints to the compiler and interpreter... Ok, any example of such a property? A listing of Perl6 properties was recently covered on perl6-language: http://groups.google.com/groups?selm=20030301205804.GG16784%40shadowed.net -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds RoadMain: 913.384.1008 Mission, KS 66202 Fax:913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Object spec, try 2
At 5:54 PM -0800 3/2/03, Dave Whipp wrote: Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. The thing that I noticed was the lack of semantics for creation and Hence the next missive, Class Spec :) This time I was trying to define just the behaviour of objects that already exist, rather than specifying their creation or how the classes that own the objects behave. I was going to punt on a lot of the rest for now, but I expect I really shouldn't, so I'lll work up try 2.5 tonight. :) destruction. Will there be well defined creation semantics, with separate steps for allocation of memory, binding to a class, and initialization of attributes? In what order are these done (inc multiple inheritance issues)? What is the state of the object if an exception is thrown before construction is complete; and how is it cleaned up? Even with GC, we must ask similar questions with respect to object destruction. Will there be finalizers; in what order are they called, and can they throw exceptions? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec, try 2
At 9:49 AM +0100 3/3/03, Erik Bågfors wrote: On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? Properties are runtime assigned name/value pairs that are stuck on a variable. They're not particularly restricted to objects, though many systems do that. (We aren't going to) A property isn't guaranteed to be on any particular object except perhaps by convention. Attributes, on the other hand, correspond to instance variables or slots in other object systems. They're generally guaranteed to be on any object of a particular class or child of a particular class--if class Foo defines an attribute bar, then all Foo objects will have a slot for the bar attribute. Attributes are often fixed at compile or object creation time, but we're not going to do that as I don't think we can, much as I'd like to. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Object spec, try 2
At 6:29 PM -0800 3/2/03, Brent Dax wrote: Dan Sugalski: # Okay, here's another shot at the semantics for objects. If folks, # especially non-perl folks, would look this over and chime in, I'd # much appreciate it. ... # Attributes are local to a class in an object's inheritance hierarchy. # An object can have one foo attribute per class in its inheritance # tree. # # Attributes are considered class-private, so a class will normally # only see its own attributes. There will be a mechanism to see all the # attributes for an object, though. Code outside a class won't see the # attributes--they aren't exposed. ... I honestly don't care much about such languages, but how is Parrot going to support classless languages like JavaScript? Are such languages going to have to fake it with anonymous classes, or will we make sure that you don't *really* need a class behind an object? Fake it with anonymous classes. It ought to work out OK, I think. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Object spec, try 2 [x-adr][x-bayes]
At 5:30 PM +0100 3/3/03, Erik Bågfors wrote: On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote: From: Erik Bågfors [mailto:[EMAIL PROTECTED] On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? My imperfect understanding is: attribute is only used in an OO context and refers to the data members the class or object encapsulates. property has nothing inherently to do with OO. Properties are tags against variables and values and are compile or run time specific. Hints to the compiler and interpreter... Ok, any example of such a property? readonly, for example. Or color, though that's more a constant property. Truth is another one--whether an object is true or false may be independent of its value, in which case there'd be a boolean property on it. (And if there wasn't a boolean property the truthness would be figured out based on the value) Python's attributes map to parrot properties if I understand them right, as they're global to an object and created dynamically at runtime, rather than mapping to parrot's attributes, but that's OK. Plenty of object model constructs to go around. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec, try 2 [x-adr][x-bayes]
At 12:43 PM -0500 3/3/03, Benjamin Goldberg wrote: AFAIK, though, properties are only attatched to values (not variables), and are entirely run-time things. Nope, they can go on both (or either), which makes things somewhat more interesting. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec, try 2
Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. The thing that I noticed was the lack of semantics for creation and destruction. Will there be well defined creation semantics, with separate steps for allocation of memory, binding to a class, and initialization of attributes? In what order are these done (inc multiple inheritance issues)? What is the state of the object if an exception is thrown before construction is complete; and how is it cleaned up? Even with GC, we must ask similar questions with respect to object destruction. Will there be finalizers; in what order are they called, and can they throw exceptions? Dave. -- mailto:[EMAIL PROTECTED] http://dave.whipp.name
Re: [RFC] imcc calling conventions
Benjamin Goldberg [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Benjamin Goldberg [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[snip]
Um... no. tail call optimization implies being able to replace *any*
tail call, not just a recursive one with a simple goto.
[snip]
In perl5, doing a tail call optimization can be done with just a simple
goto... well, 'goto subname', anyway. (Well, first you'd assign
something to @_, then goto subname).
Ah... this discussion has been done in p5p and elsewhere; whilst goto
sub could, in theory, do tail call optimization, in practice it seems
to be as slow as any other function call.
Really? I did not know that.
However, even if it's not significantly faster, at least it saves
memory, by discarding a level of saved stack information.
Since (supposedly) there's going to be a perl5-parrot compiler, there
needs to be support for perl5's goto subname. ISTM that once we have
figured out an efficient way of implementing that, we'll also have an
efficient way of doing native tail call optimization.
As a wild-ass-guess, an optimized tail call will look something like:
.sub _foo # sub foo(int a, int b)
saveall
.param int a # a = pop @_
.param int b # b = pop @_
...
.arg int x # push @_, x
.arg int u # push @_, u
.arg int q # push @_, q
restoreall
jnsr _bar # goto _bar
.end
.sub _bar # sub bar(int q, int u, int x) {
saveall
.param int q # q = pop @_
.param int u # u = pop @_
.param int x # x = pop @_
...
.return int pl # push @_, pl
.return int ml # push @_, ml
restoreall
ret
.end
The 'jnsr' opcode (JumpNoSaveReturn) might be spelled as 'j' or as
'goto', or something else entirely, depending on what's least confusing,
and most aesthetically pleasing.
The problem here is that you've pushed two loads of registers onto the
register stack, and the return is only going to pop one set off.
I think you're overlooking the restoreall done just before the
jump-no-save-returnaddress operation... I see two savealls and
two restorealls.
But with proper tail call optimization you'd only need *one*
saveall. That's why it's an optimization.
--
Piers
Re: Using imcc as JIT optimizer
Nicholas Clark [EMAIL PROTECTED] writes: On Wed, Feb 26, 2003 at 02:21:32AM +0100, Angel Faus wrote: [snip lots of good stuff] All this is obviously machine dependent: the code generated should only run in the machine it was compiled for. So we should always keep the original imc code in case we copy the pbc file to another machine. Er, but doesn't that mean that imc code has now usurped the role of parrot byte code? I'm not sure what is a good answer here. But I thought that the intent of parrot's bytecode was to be the same bytecode that runs everywhere. Which is slightly incompatible with compiling perl code to something that runs as fast as possible on the machine that you're both compiling and running on. (These two being the same machine most of the time). Maybe we starting to get to the point of having imcc deliver parrot bytecode if you want to be portable, and something approaching native machine code if you want speed. Or maybe if you want the latter we save fat bytecode files, that contain IMC code, bytecode and JIT-food for one or more processors. Aren't there safety implications with 'fat' code? One could envisage a malicious fat PBC where the IMC code and the bytecode did different things... -- Piers
Re: Object spec, try 2
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? Also, how is the difference between a class variable and a object variable? Maybe I would have understod better if I read the last object spec better :) /Erik -- [EMAIL PROTECTED] fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: [RFC] imcc calling conventions
On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote: I think you're overlooking the restoreall done just before the jump-no-save-returnaddress operation... I see two savealls and two restorealls. But with proper tail call optimization you'd only need *one* saveall. That's why it's an optimization. Tail call optimization is a space (stack size) optimization. The scheme definition only requires space efficiency. The time optimization is important but a secondary consideration for the functional language folks. -- Jason
Re: List datatype
Dan Sugalski [EMAIL PROTECTED] writes: At 9:34 PM -0800 2/27/03, David wrote: Is there a List datatype for Parrot? I'm looking for something along the lines of what's in Python. Specifically, it should be able to do the following operations: Not yet, though we do need one. There's not much difference between a list and an array, but the differences that are there are pretty important. Isn't a List just the Pair data structure with a few functions? -- Piers
RE: Object spec, try 2 [x-adr][x-bayes]
From: Erik Bågfors [mailto:[EMAIL PROTECTED] On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? My imperfect understanding is: attribute is only used in an OO context and refers to the data members the class or object encapsulates. property has nothing inherently to do with OO. Properties are tags against variables and values and are compile or run time specific. Hints to the compiler and interpreter... Also, how is the difference between a class variable and a object variable? Don't you mean class attribute and object attribute? The first is class-wide and accessible to all objects, whereas the latter is specific the object instance: obj.population vs obj.birthdate -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds RoadMain: 913.384.1008 Mission, KS 66202 Fax:913.384.2180 www.scriptpro.com garrett at scriptpro dot com
