On 25/04/2009, at 22:31, Ian Lynagh wrote:
* 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.
I tend to agree with this. I don't think I have ever consciously used
something like
let I# n# = ... in ...
I would consider this bad style and would be very much in favour of
disallowing it. I do use things like
let n# = ... in ...
sometimes, however, simply because of the obvious convenience. But I
only use this for unlifted computations that can't fail. In fact, I
would love to have the ability to distinguish between total and
partial unlifted computations in the language and not to be able to
let-bind the latter.
* It would make sense to go even further. You should not be able to
say
(g (f x)) where f returns an unlifted type, but would instead have to
say (case f x of !y -> g y).
This I disagree with. I don't see what's wrong with being able to
write (g (f x)).
* Making it less convenient to use unboxed values directly is not
necessarily a bad thing. I have the impression that people resort to
using them too readily. (I imagine that you're using them in dph
code,
and that this point doesn't apply to that).
IMO, if people use unboxed values too much it's because the rest of
language doesn't offer them enough tools to achieve what they want. If
that's the case (and I sometimes feel that it is), the better solution
would be to offer those tool, IMO. In DPH, I use them mostly to
specify strictness and to ensure that some values will indeed be
unboxed in the presence of higher-order functions. If there was a
different way of expressing this, I would use that in a heartbeat.
Roman
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
