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