On Sun, Jun 08, 2003 at 10:36:48PM +1000, Manuel M T Chakravarty wrote:
> Done.
> Done.
> Done.
Thanks, that's much safer. It's just nitpicking now, but:
> > Having washed our hands of unsafePerformIO applied to non-deterministic
> > actions, we no longer need the third paragraph, which (though scary)
> > provides no useful guidance:
> >
> > - Great care should be exercised in the use of this function. Not only
> > - because of the danger of introducing side effects, but also because
> > - \code{unsafePerformIO} may compromise typing, for example, when it is used
> > - in conjunction with polymorphic references.
>
> I don't quite agree with this. John's IORef example is
> indeed outlawed by the determinism requirement. However, it
> is possible to construct examples that are deterministic,
> but still dubious from a typing perspective. Let's assume a
> C routine
>
> void *foo();
>
> that *always returns the same pointer* to a buffer area. To
> bind this in Haskell as
>
> foreign import ccall foo :: Ptr a
>
> is problematic[1].
I wouldn't consider that an environment-independent value.
> Great care should be exercised in the use of this function. Not only
> because of the danger of introducing side effects, but also because
> \code{unsafePerformIO} may compromise typing; in particular, the result of
> \code{unsafePerformIO} should always have a monomorphic type.
Unlike the other restrictions, this one could be checked by a compiler,
but perhaps it's too strict. The problem isn't polymorphism as
such, but polymorphic storage references, and I claim they're either
environment-dependent or ill-typed. I also suspect there may be some
perfectly reasonable polymorphic examples, though I can't think of a
realistic example offhand.
In any case, it's not accurate to call it a function.
> Moreover, we could use a stable pointer to store a reference
> to an IORef in C land and use this to construct something
> not unlike John's example. In contrast, to John's example,
> we would always get the same IORef (so the function is
> deterministic), but could still give it the polymorphic type
> that it shouldn't have.
I don't see how this will fly.
Typo: in 6.2 CTypes, the second and third bulleted paras have T for CT.
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
