[Haskell-cafe] Defining a Strict language pragma

Clark Gaebel cgaebel at uwaterloo.ca
Tue Nov 6 14:55:22 CET 2012


What if the strict code were to assume nothing is ever _|_, and result in
"undefined behavior" if it is? Kind of like a NULL pointer in C.


On Tue, Nov 6, 2012 at 8:36 AM, Jan-Willem Maessen <jmaessen at alum.mit.edu>wrote:

> On Mon, Nov 5, 2012 at 5:52 PM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> The tricky part is to define the semantics of this pragma in terms of
>> Haskell, instead of in terms of Core. While we also need the latter, we
>> cannot describe the feature to users in terms of Core. The hard part is to
>> precisely define the semantics, especially in the presence of separate
>> compilation (i.e. we might import lazy functions).
>>
>> I'd like to get the Haskell communities input on this. Here's a strawman:
>>
>>  * Every function application f _|_ = _|_, if f is defined in this module
>> [1]. This also applies to data type constructors (i.e. the code acts if all
>> fields are preceded by a bang).
>>
>>  * lets and where clauses act like (strict) case statements.
>>
>
> What ordering constraints will exist on let and where clauses?  Is the
> compiler free to re-order them in dependency order?
>
> Must they be strictly evaluated in the context in which they occur?
>  Haskell syntax readily lends itself to a style a bit like this:
>
> f x y z
>   | p x = ... a ... b
>   | q y = ... a ... c
>   | otherwise = ... d ...
>   where a = ...
>               b = ...
>               c = ...
>               d = ...
>
> This tripped us up a lot in pH and Eager Haskell, where we at least wanted
> to be able to float d inwards and where it was sometimes surprising and
> costly if we missed the opportunity.  But that changes the semantics if d =
> _|_.  It's even worse if d = _|_ exactly when p x || q y.
>
> Part of the answer, I'm sure, is "don't do that", but it might mean some
> code ends up surprisingly less readable than you'd expect.
>
>  * It's still possible to define strict arguments, using "~". In essence
>> the Haskell lazy-by-default with opt-out via "!" is replaced with
>> strict-by-default with opt-out via "~".
>>
>> Thoughts?
>>
>
> I found myself wondering about free variables of lambdas, but realized
> that would be handled at the point where those variables are bound (the
> binding will either be strict or lazy).
>
> -Jan
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121106/118cad24/attachment.htm>


More information about the Haskell-Cafe mailing list