| > * The fact that you are even allowed to let/where-bind values with
| > unlifted type is surprising. Making it clearer that something odd is
| > going on is a good thing. If it were up to me I think I would
| > disallow them completely.
GHC "grew" let-bindings for unlifted types almost by accident; it was not a
carefully designed feature.
It does seem odd to me that the meaning of
let x = e in b
(and of course its desugaring) varies dramatically depending on the *type* of
x. Normally it's
(A) "evaluate b, and evaluate e if necessary".
But if x has unlifted type you get
(B) "evaluate e then evaluate b"
Now (B) is precisely what you get if you say
let !x = e in b
regardless of the type of x. So the change we're discussing [requiring a !
when x is unlifted] makes the evaluation order consistent with the syntax,
rather than only with the (invisible) type.
As another example consider this
fix (\~(C x y) -> e)
If you omit the ~, the knot tied by fix will go into a black hole, so it's very
important. OK, so now suppose 'x' changes type and becomes unlifted. Black
hole!
Under the new rules you'd get an error, because a variable of unlifted type is
bound by a lazy pattern.
Remember that let/where bindings behave very like lazy patterns. (See the
desugaring in the Report.)
Anyway, that's why I think this change is a good thing. IAN: we need to make
sure the user manual reflects all this!
| Suppose I have
|
| foo :: (Int# -> Int#) -> Array Int -> Array Int
|
| I don't see a good way of getting this semantics without using unboxed
| types.
Max is working on a this very point. Stay tuned.
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
