[m-dev.] Adding standard integer types

[Ian MacLarty]

On Thu, Sep 18, 2008 at 5:33 AM, Julien Fischer
<juliensf at csse.unimelb.edu.au> wrote:
>
> Hi,
>
> This actually a response to Pete's original post rather than to Paul's
> comments since my spam filter decided that the former was spam and
> deleted it.
>
> On Wed, 17 Sep 2008, Paul Bone wrote:
>
>> On Wed, Sep 17, 2008 at 02:07:50PM +1000, Peter Ross wrote:
>>>
>>> I'm looking at adding the type int8, int16, int32 and int64 to Mercury
>>> and the equivalent unsigned versions.
>>>
>>> The way I'm currently imagining doing it is to add the following
>>> module to the library.
>>>
>>> :- module stdint.
>>> :- interface.
>>> :- type int8.
>>> :- foreign_type(c, int8, "int8_t").
>
> You will definitely want a can_pass_as_mercury_type attribute for int8,
> int16 and int32.  int64 is a bit tricky, on 32-bit machines it will have
> to be boxed but it should be unboxed on 64-bit machines.  I suggest
> adding a new foreign type attribute:
>
>        unbox_bit_threshold(<Threshold>)
>
> that causes a foreign_type to be unboxed (passed as a Mercury type)
> if sizeof(MR_Word) * 8 >= Threshold.
>
>>> :- func to_int8(int) = int8.
>>>
>>> I will then add to the runtime the following portable stdint.h renamed
>>> to mercury_pstdint.h
>>>
>>> http://www.azillionmonkeys.com/qed/pstdint.h
>>>
>>> and add to configure a test for stdint.h and if that doesn't exist we
>>> would fall back to using mercury_pstdint.h.
>>>
>>> Does anyone have any objections/improvements to this plan?
>
> * How will all this be implemented for the other backends?  It should
> be fairly trivial for the .NET and Java backends (although unsigned
> integers don't exist in the latter.)  The Erlang backend?
>
> * It may be worth considering whether the new types should be implemented
> as additional builtin types rather as a library module.
>

Doing them as builtins would play better with the mode system.  For
example you could do something like:

:- pred decode(uint8::in, code::out) is semidet.

decode(1, code1).
decode(2, code2).
decode(3, code3).

which wouldn't be possible if they were foreign types, (without first
casting them to ints which might not be possible in the case of int64
or uint64).

Also you could read them in using io.read if they were builtins.

float32 and float64 would be nice too.

Ian.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------