The size of things

Ketil Z. Malde
15 Feb 2002 11:20:03 +0100

"Simon Marlow" <> writes:

> Actually no... but perhaps it's time to turn it on.

Yeah, I noticed a slight saving by turning an Int into an !Int, but
only when using -funbox-... option.

>> So the array shouldn't be too costly, I think - but perhaps an
>> UArray would reduce cost from three words to one word per element?

> It already costs one word per element (think of nullary constructors
> as free - we only have one copy of each nullary constructor which
> everybody points to).

*slap forehead* Ah, of course.  However, with a small number of
constructors, I might be able to squeeze things into less than a word
(i.e. pointer at 32 bits).  I could e.g. use an UArray over Word32 and
represent a sequence of my nullaries in each word.

(> If the array is the same for each element, why store it in the list at
 > all?

I realise this, but eventually I want to have my Bar's referring to a
(much smaller than my n) set of arrays.)

>> This isn't too far from what I observe, so I hope my analysis is
>> somewhat correct. :-)

> Yes, sounds right.

Cool.  That means there's a potential here; I'll get to it.

>> This is assuming the compiler doesn't do any of this on its own...

> The compiler won't do any of this on its own.  Remember that you can't
> pass a BarList to standard list functions like length, for example,

Yes, I see.  Would it be possible to have a standard strict list,
i.e. something equivalent of

        data SList a = SNil | SCons !a SList

(which could be a member of the same class as the normal lists, and
have the usual functions (length, ++, isPrefixOf...) overloaded)?

If I haven't seen further, it is by standing in the footprints of giants