#5419: integer-gmp no longer exports S# and J#
-----------------------------------+----------------------------------------
Reporter: mikhail.vorozhtsov | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries (other) | Version: 7.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-----------------------------------+----------------------------------------
Comment(by simonpj):
Ian is away, until the middle of nex week. You refactoring makes sense to
me.
It's tricky trying to simultaneously support
* Two different implementations of `Integer`. That suggests that the
representation of `Integer` should be opaque.
* Optimisations for small integers, which needs to see the
representation.
The two goals are in tension. I believe the uses of `S#` in client
packages are there to optimise the small-integer case (can anyone
confirm?).
I wonder whether a way to square this circle would be to have an abstract
pseudo-constructor function whose type is that of `S#`:
{{{
smallInteger :: Int# -> Integer
}}}
The idea is:
* The compiler desugars small `Integer` constants into uses of
`smallInteger`.
* Rewrite rules can match on `(smallInteger x)`.
* `smallInteger` is inlined late.
* Two different implementations of the `Integer` API could implement
`smallInteger` quite differently.
As I understan Johan's proposed change, client packages that mentioned
`S#` would not build against a different `Integer` implementation. With
the above idea, they would.
But I've learned that it's easy to miss something in this territory.
Simon Ian and I were already discussing something like
{{{
bigInteger :: ByteString -> Integer
}}}
for big integer constants, to avoid the absurd stuff in #5284. The
`ByteString` (or `MachAddr` or something, I forget what) is supposed to be
the bit representation of the `Integer`. Different implementations of
`Integer` would mangle it in different ways to build their respective
internal representations.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5419#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
