[Haskell-cafe] GHC.Ptr, Foreign.Storable, Data.Storable.Endian, looking for good examples of usage

[John Lato]

On Mon, Jan 10, 2011 at 3:45 PM, Aaron Gray <aaronngray.lists at gmail.com>wrote:

> On 10 January 2011 13:49, John Lato <jwlato at gmail.com> wrote:
>
>> From: Aaron Gray <aaronngray.lists at gmail.com>
>>>
>>> On 9 January 2011 21:30, Henning Thielemann
>>> <lemming at henning-thielemann.de>wrote:
>>>
>>> >
>>> > On Sun, 9 Jan 2011, Aaron Gray wrote:
>>> >
>>> >  I am trying to work out how to use GHC.Ptr, Foreign.Storable,
>>> >> Data.Storable.Endian, and
>>> >> am looking for good examples of usage.
>>> >>
>>> >
>>> > What do you intend to do with them?
>>> >
>>> >
>>> An (ABC) ActionScript Byte Code backend for Haskell.
>>>
>>> Basically I need to write little-endian binary to a file, and was
>>> wondering
>>> the best way to do this; I need various types including a 24bit type.
>>>
>>
>> You could use my "word24" package[1] (GHC only) to provide non-aligned
>> 24-bit word and int types with Storable instances.  You should be able to
>> write a binary instance (or whatever blaze-builder needs) fairly simply from
>> this.  Little-endian only ATM, but BE could be added if necessary.
>>
>> John Lato
>> [1] http://hackage.haskell.org/package/word24
>>
>
> This is interesting, what does the following line do :-
>
>     data Int24 = I24# Int# deriving (Eq, Ord)
>
> regarding the I24# and Int#, are these inbuilt ?
>

The Int# is built-in to GHC; it's an unboxed Int type (C long int, see
http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/primitives.html#glasgow-unboxed
). I24# is not built-in; it's just a normal constructor. Although it has a
hash suffix, that's just a convention (as documented under the MagicHash
pages); it behaves exactly like any other constructor.

This means that an Int24 works just like an Int, Int16, etc. It can be lazy,
but will also be unboxed by GHC when appropriate. Arithmetic on the unboxed
type will result in machine ops. This isn't strictly necessary; Int24 could
be nearly equivalently defined as

data Int24 = Int24 {-# UNPACK #-} !Int32

but using unboxed types is perhaps more efficient. The UNPACK pragma wasn't
available when I wrote Int24, which is why I did it this way. I may revisit
this decision in the future; unboxed types are tied closely to GHC, and the
UNPACK/strict combination would be more portable and easier to maintain.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110110/89fdf6dd/attachment.htm>