Oh... now I understand the nature of your fix. I had thought you were
suggesting implementing Int64 as integer at the Hugs end. I guess I don't
really need a Hugs change for now.
- Conal
-----Original Message-----
From: Sigbjorn Finne (Intl Vendor)
Sent: Tuesday, June 08, 1999 11:59 PM
To: 'Mark P Jones'
Cc: hugs-bugs; Conal Elliott
Subject: RE: Int64 in Hugs?
Alastair implemented Int64 a while ago for STG Hugs
(as a prim ty), so it'll at least be supported when
that is out.
Conal is coming across the lack of Int.Int64 support via
HaskellDirect generated code, so as a workaround, it now
lets you map longlongs to Integer instead of Int64.
--sigbjorn
Mark P Jones [mailto:[EMAIL PROTECTED]] writes:
>
> Hi Conal,
>
> | Would it be reasonably easy to add Int64 (long long)
> support to the Hugs
> | implementation of the GHC/Hugs shared Int module
> (lib/exts/Int.hs)? I
> | need it for a HaskellDirect-generated interface?
>
> I can think of two ways that this might be accomplished. The
> first would be to add a new primitive datatype, and corresponding
> operations. I don't know if long long is supported on all the
> platforms that we target, but it could be a build-time
configuration
> option. The second would be to code things up in Haskell, for
> example using:
>
> data Int64 = I64 Int32 Int32
>
> (or perhaps just using Integer). This would probably be slower,
and
> more painful to implement, but perhaps more portable.
>
> A third alternative would be simply to define:
>
> type Int64 = Int32
>
> Of course this would be dangerous if you thought that your
particular
> application might need more than 32 bits of each Int64 value. But
it
> might also be a quick workaround in some situations until
> somebody finds
> the time to build a proper Int64 implementation.
>
> All the best,
> Mark
>
