[Haskell-cafe] Defining a Strict language pragma
jmaessen at alum.mit.edu
Tue Nov 6 14:36:52 CET 2012
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe