[mercury-users] Tagged datatypes and boxing

[Richard A. O'Keefe]

	I think I would like to see the following types in Mercury:
	int8, int16, int24, int32, int64, and let plain int be
	implementation dependent (e.g. 30 bits + 2 for tagging).  Use of
	the intXX types would be subject to the standard mod 2^XX
	behaviour, while the int library could specify upper and lower
	bounds and the number of bits used as it does at present.

I'm quite sure I _wouldn't_ like to see them.

To start with, it's not clear to me what "the STANDARD mod 2^XX behaviour"
is supposed to refer to.  There is certainly nothing in the *C* standard
that guarantees wrap-around-wrong-answers for signed integers of ANY size.
And yes, there ARE C compilers that do the Right Thing and trap signed
integer overflow at run time; I only wish there were more.  I'm not
opposed to packing, I'm just opposed to wrong answers.

To continue, why the h--l should we humans be forced to count bits?
Quickly now:  how many bits does 1073741828 require?
This is one of the things Pascal (and better still, Ada) got RIGHT:
if you want integers of a particular size, state the bounds in a
*human* oriented way.  What's a good way?  Well, assertions.

type nat8 = X:integer where 0 <= X & X <= 255.
type odd8 = X:integer where 0 < X & X < 512 & X mod 2 =:= 1.

(Yep.  odd8 values can be fitted quite nicely into 8 bits.)

We've had >20 years of experience with C, more than enough to tell
us that machine-oriented sizes are *dreadful* to program with;
we've had >15 years of experience with Ada, more than enough to
tell us that human-oriented bounds are *easy* to program with,
and can give you *better* packing as well as better quality.

I'm sick of "C envy".
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------