Bools are not unboxed

Simon Marlow simonmar at microsoft.com
Wed Oct 6 09:09:24 EDT 2004


On 06 October 2004 11:36, Josef Svenningsson wrote:

> Simon Marlow wrote:
> 
>> On 06 October 2004 00:53, John Meacham wrote:
>> 
>> 
>> 
>>> This seems like it could be nicely generalized such that all
>>> enumeration types unbox to the unboxed integer of their offset. so
>>> 
>>> data Perhaps = Yes | Maybe | No
>>> 
>>> can unbox to an Int# with 0# == Yes 1# == Maybe and 2# == No.
>>> 
>>> 
>> 
>> Yes, a strict enumeration should be implemented as an Int#, both in
>> the strictness analyser and also when you {-# UNPACK #-} a
>> constructor field.  This is something we'd like to try, but haven't
>> got around to it yet.  Maybe a good bite-sized project for a budding
>> GHC hacker? :-) 
>> 
>> 
>> 
> Would it really be correct to translate it to Int#? AFAIK, unboxed
> values may not contain bottom while a data type most certainly can. I
> would imagine translating it to Int, and then relying on GHC's
> optimiser to optimize this into Int# whenever possible.

Note I said a *strict* enumeration.  You're right that in general it
wouldn't be correct to implement Bool by Int#.  Only when the strictness
analyser has determined that a function argument of enumeration type is
strict, or the programmer has added a strictness annotation to a
constructor field.

Certainly right now you can use Int everywhere instead of enumeration
types, and perhaps get better performance because GHC will unbox the Int
whenever possible.

Cheers,
	Simon


More information about the Glasgow-haskell-users mailing list