[Haskell-cafe] Re[2]: strict Haskell dialect

[Brian Hulley]

Robin Green wrote:
> On Fri, 3 Feb 2006 19:33:12 -0000
> "Brian Hulley" <brianh at metamilk.com> wrote:
>> I've been thinking along these lines too, because it has always
>> seemed to me that laziness is just a real nuisance because it hides a
>> lot of inefficiency under the carpet as well as making the time/space
>> behaviour of programs difficult to understand...
>>
>> One question is how to get some kind of "do" notation that would work
>> well in a strict setting.
>> The existing "do" notation makes use of lazyness in so far as the
>> second arg of  >> is only evaluated when needed. Perhaps a new
>> keyword such as "go" could be used to use >>= instead ie:
>>
>> go {e1;e2;e3}   ===           e1 >>= (\_-> (e2 >>= (\_->e3)))
>
> That's not necessary. >> has something in common with if', where
>
> if' True x _ = x
> if' False _ y = y
>
> - in both cases, it makes sense to evaluate the arguments lazily.
>
> So simply make strictness the default and have laziness annotations
> (for arguments), instead of making laziness the default and having
> strictness annotations.

Where would you put these laziness annotations?
If you put them in the function declaration eg as in:

     if' :: ~a -> ~b -> Bool

presumably you'd want the compiler to pass the args as thunks instead of 
evaluated values. However this means that all args to every function would 
have to be passed as thunks, even though for strict functions these thunks 
would immediately be evaluated. The problem is that there is no way for the 
compiler to optimize out the thunk creation / evaluation step because it 
occurs across the "black box" of a function call, thus we wouldn't get the 
same efficiency as in a language such as ML where no thunks are created in 
the first place.

Ie there is a fundamental asymmetry between lazy annotations and strict 
annotations - it is trivial to go from lazy to strict before the function 
body is evaluated but impossible to unevaluate from strict back to lazy...

Regards, Brian.