[Haskell-cafe] Small question

[Andrew Coppin]

Stefan O'Rear wrote:
> I like pretty pictures.
>   

...and have lots of spare time, apparently. ;-)

[I actually meant to write (Bool,Bool), but anyway...]

>> Whereas my Quad object is going 
>> to be a pointer to one of 4 values... so it looks like Quads save space. 
>> (And they're more strict.) OTOH, I'm not sure what the time penalty is 
>> like...
>>     
>
> Probably none.  The STG-machine was designed to make user-defined
> algebraic types very fast.
>   

My program needs to make decisions based on a pair of boolean values. 
Encoding both values as a single algebraic data type means I have to 
keep "taking it apart" so I can work with it. I'm not sure how much time 
this wastes...

>> It would be nice if there were some general mechanism for turning a bunch 
>> of Bool flags into a single machine word. E.g., if I did a
>>
>>  data Foo = Foo {flagX, flagY, flagZ :: !Bool}
>>
>> and it ends up that a Foo value is just a single machine word, and GHC 
>> picks which bit each flag is... I guess if you want that at present you'd 
>> have to code it all by hand. Hmm, I think this might work out better than 
>> my current Quad thing... I could do something like
>>
>>  type Quad = Word8
>>
>>  foo q = let
>>    x = if testBit 0 q ...
>>    y = if testBit 1 q ...
>>
>> That should be quite fast... (?)
>>     
>
> Probably. I wound up doing something similar with vty, to considerable
> gain.  (I did however use .&. instead of testBit - probably makes no
> difference, but I'm reminded of the (^2) being much slower than join(*)
> case...)
>   

Well, perhaps I could define a pair of constants representing the bit 
masks? (OTOH, won't GHC optimise "testBit <constant>" into something 
faster anyway?)

>> Heh. I'll have to pester you more often. :-P
>>     
>
> :)
>   

Like that time yesterday, I compiled from program and got a weird 
message about GHC about "ignored trigraphs" or something... What the 
heck is a trigraph?

(I compiled the program again later, and it compiled just fine. Weird...)

>> PS. Somewhere they should write a page entitled "Optimisations that GHC 
>> does (and doesn't) do"...
>>     
>
> Good idea!  Maybe it could be fit into the GHC Performance Resource
> somehow?  (http://www.haskell.org/haskellwiki/Performance/GHC)
>   

OK. But it'll probably contain a lot of guessing to start with... ;-)