Dan~ I was originally going to say do them all or do the integer division/no overflow check option, but then something occurred to me. We already have I registers. If someone wants speed they should be using them anyway. If someone doesn't care about speed, but wants those semantics, their compiler can emit code of the form
set I0, P0 set I1, P1 add I2, I0, I1 set P2, I2 and even then the code should not slow too much (I hope) Thus, I think that I will vote for int/int -> float and int*int -> [big]int What I vote against is float + float -> int. I don't care if the result float happens to be an int, I have an unreasoning dislike of it. Also, if people are not satisfied with the options they can (and probably will) write their own PMCs to extend them. Actually that might be an argument for implementing everything, cause someone surely will so we might as well provide it. But I don't really like that, so I am sticking with my first answer. Matt On Mon, 23 Aug 2004 21:13:46 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > Leo's been nudging me to get the behaviours of the basic types > defined, so I'm working on updating PDD 17 with them. > > The unary behavior of the types is reasonably straightforward. What > I'm puzzling over right now is the binary behavior. It's the edge > cases that are troublesome, of course -- what to do on overflow, and > what to do with fractional results. > > Fractions are an issue mainly with integer division -- in the case of > int/int, should the result be an int, or a float of some sort? > > Overflow's an issue to some extent with addition and subtraction, but > moreso with multiplication. Should the result be promoted to a larger > type (either unconditionally, or on overflow), which one, and what > counts as overflow? (Is it exceeding the limits of the type, or > losing precision?) > > I'm up for some discussion on this one. I'm tempted to leave integer > binary ops integers, binary ops with one or two floats a float, and > binary ops with a bignum as a bignum and to heck with overflow, but I > can see arguments for a more precise answer, as well as providing a > way to specify whether you want accuracy or speed (potentially with > or without throwing an exception where promotion'd otherwise take > place and we don't). We could do them all, but... that seems more > than a little excessive. Besides the MMD table entries, there'd be a > lot of flag checking (or a *really* big set of MMD tables) which is > sub-optimal. > > This'd be a good time to make cases, folks! > -- > Dan > > --------------------------------------it's like this------------------- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk > -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
