[m-dev.] Re: for review: big ints

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Apr 7 00:29:20 AEST 1998

On 06-Apr-1998, Bert Thompson <aet at hydra.cs.mu.oz.au> wrote:
> Yes, I know. I deliberately didn't do this since it meant more
> implementation time (not much, admittedly) for not a huge efficiency
> improvement.

Fair enough, but a comment to this effect might be a good idea.

> In short, the bang for buck test failed.
> |The last call to error/1 could be avoided by using a disjunction
> |rather than an if-then-else:
> | 	( CCs = [],
> | 		...
> | 		
> | 	; CCs = [C|Cs],
> |		...
> |	).
> This is a good general rule. Unfortunately, however, there are
> cases where if-then-else must be used instead because the mode
> system can't infer a tight enough mode. (add_pairs and diff_pairs,
> for example.)

In diff_pairs you can avoid the error/1 case by making the different
cases mutually exclusive -- you just have to add "XXs = [_|_]"
to the second case.  I think this is a little bit nicer than using

> |The recursive call for negative numbers means that it allows
> |strings of the form "-------42", which is probably not a good idea.
> This was a deliberate decision. Apart from aesthetic reasons, why do
> you think this not a good idea?

Well, integer__from_string should be consistent with
string__int_to_string; and also the principle of "least surprise"
suggests that these two should both be as close as possible to the
equivalents in other languages, unless there is a good reason to be

> You also mentioned it would be worthwhile to include bit operations
> on the integers. I assume you want us to treat the integers as
> though they were 2's complement bit arrays. This is not particularly
> hard to do, especially if we use base 2^14 as you suggested. However
> I probably should let it go till some later date.


Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at        |     -- the last words of T. S. Garp.

More information about the developers mailing list