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

[Jan-Willem Maessen]

On Feb 3, 2006, at 2:33 PM, Brian Hulley wrote:

> Bulat Ziganshin wrote:
>> Hello Wolfgang,
>>
>> Friday, February 03, 2006, 1:46:56 AM, you wrote:
>>>> i had one idea, what is somewhat corresponding to this discussion:
>>>>
>>>> make a strict Haskell dialect. implement it by translating all
>>>> expressions of form "f x" into "f $! x" and then going to the
>>>> standard (lazy) haskell translator. the same for data fields - add
>>>> to all field definitions "!" in translation process. then add to
>>>> this strict
>>>> Haskell language ability to _explicitly_ specify lazy fields and
>>>> lazy evaluation, for example using this "~" sign
>
> [Apologies for replying to a reply of a reply but I don't seem to  
> have received the original post]
>
> 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...

I pointed out some problems with strict Haskell in a recent talk, but  
I think it'd be worth underscoring them here in this forum.

First off, I should mention that I was one of the main implementors  
of pH, which had Haskell's syntax, but used eager evaluation.  So  
what I'm about to say is based on my experience with Haskell code  
which was being eagerly evaluated.

There is one very difficult piece of syntax in a strict setting: The  
*where* clause.  The problem is that it's natural to write a bunch of  
bindings in a where clause which only scope over a few conditional  
clauses.  I'm talking about stuff like this:

f x
   | p x               = ..... a ...a . a .... a ...
   | complex_condition = ......... b .. b ... b ......
   | otherwise         = ..... a ....... b .....
   where a = horrible expression in x which is bottom when  
complex_condition is true.
         b = nasty expression in x which doesn't terminate when p x  
is true.
         complex_condition = big expression which
                              goes on for lines and lines
                              and would drive the reader
                              insane if it occurred in line.

Looks pretty reasonable, right?  Not when you are using eager or  
strict evaluation.  I think a strict variant of Haskell would either  
end up virtually where-free (with tons of lets instead---a pity as I  
often find where clauses more readable) or the semantics of where  
would need to change.

This came up surprisingly more often than I expected, though it was  
hardly a universal problem.  The more "interesting" the code, the  
more likely there would be trouble in my experience.

A bunch of other stuff would have to be added, removed, or modified.   
The use of lists as generators would need to be re-thought (and  
probably discarded), idioms involving infinite lists would have to  
go, etc., etc.  But this is a simple matter of libraries (well, and  
which type(s) get(s) to use square brackets as special builtin  
notation).

-Jan-Willem Maessen