[Haskell-cafe] Re: If wishes were horses...

wren ng thornton wren at freegeek.org
Fri Mar 12 22:19:49 EST 2010

Ketil Malde wrote:
> What should the type look like?  If memory serves, Clean allows bangs in
> type signatures, something like:
>   foldl' :: (a -> b -> a) -> !a -> [b] -> a
> but I thought it just added a seq under the hood, much like bang
> patterns like
>   foldl' f !z xs = ...
> do in Haskell, so it's not like !a is a separate type.  Or?

The usual approach I've seen is not to distinguish strict and lazy 
datatypes, but rather to distinguish strict and lazy functions, e.g. by 
having two different arrows: (->) for lazy functions and (!->) for 
strict ones.[1]

There are reasonable reasons for wanting to distinguish strict/lazy 
datatypes instead, though that's usually called distinguishing lifted vs 
unlifted types, which has different effects on the semantics.

I don't recall which approach Clean uses.

> Would something like this work?  It seems to me that strictness doesn't
> apply to result types

Which is one benefit of the two arrows version: there's no way to talk 
about making the result strict.

> and you need to track the
> relationship between a and a', since you probably want to allow a lazy
> value as e.g. the second parameter of foldl'.

Usually, if you're going to be distinguishing lifted and unlifted types 
then you'll want to be able to say that the unlifted values can always 
be coerced into the corresponding lifted type. Whether that involves 
subtyping, autoboxing, etc. will depend on the compiler and the language.

[1] Actually, just having two is insufficiently expressive. What you 
actually want is to make the (->) type constructor take three arguments: 
the parameter type, the return type, and an index belonging to the set 
{Strict,Lazy}. That way you can use type variables to unify strictness 
behaviors of higher-order functions with their function arguments (i.e., 
the HOF is strict or lazy in various arguments depending on the 
strictness properties of the functional arguments).

Live well,

More information about the Haskell-Cafe mailing list