add(out INT, in INT, in INT)
add(out NUM, in NUM, in INT)
add(out NUM, in NUM, in NUM)
add(in PMC, in PMC, in INT)
add(in PMC, in PMC, in NUM)
add(in PMC, in PMC, in PMC)
This kind of ties into the 'set vs assign' issue.
Add behaves differently depending on whether
the first parameter is an integer/float or a PMC.
If it's a PMC, then it changes the value of the PMC,
but if it's a integer or float, it just puts a
new value in the register.
When I say in IMCC:
$P0 = $P1 + $P2
, I expect it to create a new value and store it in
$P0, not give me a segfault because I didn't say
$P0 = new <figure out what the heck type
$P0 is supposed to be based
on the types of $P1 and $P2>
first. Now
$P0 <- $P1 + $P2
(or whatever)
, that'd be a different story :-) Maybe ops that
operate by changing the values of existing PMCs
should be postfixed somehow, kind of like
Ruby's (and Lisp's?) conventions of postifixing
functions that modify values with "!". So then
there would be 2 add (and sub, and mult, and incr,
etc, etc.) ops:
add(out PMC, in PMC, in PMC)
which puts a new value in $1 just like the
integer and float variants, and
add!(in PMC, in PMC, in PMC)
which alters the PMC in $1.
Using the first version would allow PMCs
to decide for themselves what kind of
thing you should get as a result, which is
probably what you actually want to happen
most of the time.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
