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 <[email protected]>wrote: > On Mon, Nov 5, 2012 at 5:52 PM, Johan Tibell <[email protected]>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 > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
