[m-dev.] Adding standard integer types

Julien Fischer juliensf at csse.unimelb.edu.au
Fri Sep 19 00:48:32 AEST 2008


On Thu, 18 Sep 2008, Paul Bone wrote:

> On Thu, Sep 18, 2008 at 11:04:19PM +1000, Julien Fischer wrote:
>>
>> Here is a proposed extended set of integral builtin types for Mercury:
>>
>> Type        Description
>> ----        -----------
>>
>> int         word sized signed
>
> Is this the current 'int' type we already have.  Changes to it may break
> things.

Yes, but I'm not proposing any changes to it.

>> uint        word sized unsigned
>>
>> int8        8-bit signed
>> int16       16-bit signed
>> int32       32-bit signed
>> int64       64-bit signed
>>
>> uint8       8-bit unsigned
>> uint16      16-bit unsigned
>> uint32      32-bit unsigned
>> uint64      64-bit unsigned
>>
>> I have been intending to add uint as a new builtin for some time now.
>> (There are quite a lot of places in the runtime, debuger and deep
>> profiler where we use unsigned quantities in C code and then have to convert
>> them to signed values in Mercury which could be simplified by the
>> addition of uint.)
>>
>> For uints, literals would be as they are for the signed versions
>> except that would have either `u' or`U' appended.  For the fixed size
>> types something like the following might be used:
>>
>> 	42s8	- signed 8-bit integer with decimal value 42
>> 	42U64	- unsigned 64-bit integer with decimal value 42
>> 	42S32	- signed 32-bit integer with decimal value 42
>>
>
> Urgh, that's a little clumbsy,

It's less clumsy than not providing type-specific integer literals.
Then you have to use type qualifiers to resolve ambiguities.  It
has the additional advantage that literals that are out of range
for a specific type can be caught during lexing rather than at
a later stage.

> can we infer this information from how
> the constant is used?

Hopefully.

> If we can infer it 95% of the time why not
> require this markup in the remaining 5% only?

Sure, but you still need something to handle that 5%.  In a sense it
shouldn't be that different to how C handles it.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list