Bob Rogers [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Wed, 30 Mar 2005 08:57:55 +0200
... , is that you are assuming (as I did not) that each and
every language built on top of Parrot will define its own PMC classes,
even for primitive arithmetic types,
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Thu, 31 Mar 2005 09:38:15 +0200
Bob Rogers [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Wed, 30 Mar 2005 08:57:55 +0200
... , is that you are assuming (as I did not) that each and
every
Bob Rogers [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
..., since I assume an
Int+String=Number method will exist that coerces the string to a number
first. I imagine you could do this by creating a subclass of Int,
e.g. LispInt, and then defining a LispInt+String
Matt Fowles [EMAIL PROTECTED] wrote:
Leo~
Why bother with the IS_NULL check if we have the n_ variant already?
Why not have one option unconditionally use the destination pmc and
the other unconditionally create a new destination pmc?
I think, we can just have one method with the same
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Mon, 28 Mar 2005 11:27:58 +0200
Bob Rogers [EMAIL PROTECTED] wrote:
IMHO, one can have too much overloading. It seems cleaner to
distinguish between +, the (sometimes overloaded) HLL operator and
add, the Parrot addition
Bob Rogers [EMAIL PROTECTED] wrote:
I guess I was hoping for access to a lower-level mechanism. FWIW,
Common Lisp is an example of a dynamic HLL that doesn't allow certain
ops to be overloaded (at least not directly).
Overloading is a syntactic construct that the compiler supports (or
not).
Bob Rogers [EMAIL PROTECTED] wrote:
IMHO, one can have too much overloading. It seems cleaner to
distinguish between +, the (sometimes overloaded) HLL operator and
add, the Parrot addition operator so that compiled code can opt out of
the overloading when the compiler knows that it really
Matt Fowles [EMAIL PROTECTED] wrote:
Leo~
On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
5) infix method signature change:
METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
if (!dest)
dest = pmc_new(INTERP, SELF-vtable-base_type);
Leopold Toetsch [EMAIL PROTECTED] wrote:
5) infix method signature change:
METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
if (!dest)
dest = pmc_new(INTERP, SELF-vtable-base_type);
...
return dest;
}
If the destination PMC is passed in, it's used
Leo~
On Mon, 28 Mar 2005 12:22:29 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote:
5) infix method signature change:
METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
if (!dest)
dest = pmc_new(INTERP,
Leo~
On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
5) infix method signature change:
METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
if (!dest)
dest = pmc_new(INTERP, SELF-vtable-base_type);
...
return dest;
}
If
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Sun, 27 Mar 2005 16:37:41 +0200
1) Mixed infix operations
Opcodes that take one PMC and one native type argument, like:
op add(in PMC, in PMC, in INT)
should probably become plain vtable methods again. There isn't much
12 matches
Mail list logo
