Re: [Haskell-cafe] Defining a Strict language pragma
On Mon, Nov 5, 2012 at 5:52 PM, Johan Tibell johan.tib...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Defining a Strict language pragma
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 jmaes...@alum.mit.eduwrote: On Mon, Nov 5, 2012 at 5:52 PM, Johan Tibell johan.tib...@gmail.comwrote: 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Defining a Strict language pragma
On Mon, Nov 05, 2012 at 02:52:56PM -0800, Johan Tibell wrote:
Hi all,
I would like to experiment with writing some modules (e.g. low-level
modules that do a lot of bit twiddling) in a strict subset of Haskell. The
idea is to remove boilerplate bangs (!) and instead declare the whole
module strict. I believe this would both make code that needs to be strict
more declarative (you say what you want once, instead of putting bangs
everywhere), less noisy, and more predictable (no need to reason about
laziness in places where you know you don't want it). The idea is to
introduce a new language pragma
{-# LANGUAGE Strict #-}
that has the above described effect.
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.
* 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 ~.
Did you mean here it's still possible to define _lazy_ arguments? The
duality of !/~ makes sense, indeed.
I personally have no idea what implications this might have, but I would
be very interested to see how existing code (which doesn't require
laziness) would behave when run under this new pragma.
regards,
iustin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Defining a Strict language pragma
On Mon, Nov 5, 2012 at 3:28 PM, Iustin Pop iu...@k1024.org wrote: Did you mean here it's still possible to define _lazy_ arguments? The duality of !/~ makes sense, indeed. Yes, it would be nice to still make arguments explicitly lazy, using ~. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
