[Haskell-cafe] Defining a Strict language pragma
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
>> . 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 "~".
> 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).
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe