--- Eric Northup <[EMAIL PROTECTED]> wrote: > On Sat, 2005-02-05 at 16:26, Shawn Garbett wrote: > > I was thinking more like the following: > > > > +, -, etc all double the word size. > > Unfortunately, this won't work. Efficiency concerns > aside, BitC does not allow arbitrary sized > fixed-precision integers. int8, int16, int32, > int64 are OK. int65536 is not in the current spec. >
I didn't make myself clear. On a side note, I'm still fiddling with getting the environment compiled and absorbing the language documentation. It was my understanding that BitC was static typed. So if + is allowed to have the following types: + :: int8 -> int8 -> int16 + :: int16 -> int16 -> int32 + :: int32 -> int32 -> int64 + not defined for int64. One would be free to use a straight + or -, as long the target variable is of the correct size to handle the result. For other purposes: ring+ :: int8 -> int8 -> int8 does addition with wrap around and no exception bounded+ :: int8 -> int8 -> int8 throws an exception on under or overflow. > Also, the size-increase makes it extremely difficult > to perform arithmetic in bounded storage. How much > storage would an N-iteration loop require for the > loop variable? And what happens if the program > runs out? There would be no size increase. It remains fixed and static. > > The static type > > checker would catch any usage violating this. Then > for > > wrap around, aka a ring, ring+, ring- etc. Then > for > > exceptions on overflow or underflow, have > bounded+, > > bounded-, etc. > > I doubt that a static check is possible in the > general > case. I suspect it will end up being the halting > problem. > For some cases, a proof can be constructed that > overflow > never occurs, and thus need not be checked at > runtime. > But what about the others? I want our type-checker > to > terminate! Agreed in full. > > > If the static type checker could give a custom > message > > for type violations of +, -, then the programmer > could > > be steered toward his possible intentions. The > usage > > of ring and bounded, are somewhat > self-documenting. > > I would slightly prefer 'wrap+' over 'ring+', > because > I get confused thinking about the abstract math > definition of a ring. Wrap is good. It's more common. > > I only see 2 (rather than 3) different classes of > operators: > > -Fixed precision modular integer operations (2's > compliment) which wrap on overflow, and do not throw > exceptions. > > -Fixed or arbitrary precision integers which throw > an > exception on overflow. Arbitrary precision > "overflow" is > the out-of-memory condition, and presumably rare. > But > it is still possible. > > If I recall, the original question was along the > lines of: > "should the (+, -, *, etc.) operators on > fixed-precision > integers be the 'wrap-around' type, or the 'throw- > exception' type?". > > I am leaning towards 'throw-exception'. But I don't > care > too strongly as long as both forms can be read > unambiguously > and typed without contributing to repetitive-stress > injuries. There's a primary consideration, amount of typing in the long run. > > My reasoning for preferring 'throw-exception'-style > operators is that programmers who were not > considering > problems of overflow will be reminded when it gets > the > exception. Programmers who _were_ considering > overflow > have explicitly marked their intention by using the > wrap-around version of the operators. > If the doubling of the word size is almost never used in practice, then this is a good argument for + and wrap+. Shawn __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
