John Hughes [EMAIL PROTECTED] wrote,
should always have is unfortunately ambiguous: does it mean you should
ensure that..., or we believe that..., but we're not completely sure. I
suggest changing the last phrase to
...; to avoid this, the programmer should ensure that the result of
Ross Paterson [EMAIL PROTECTED] wrote,
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
- 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.
Or maybe it
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)
Ross Paterson [EMAIL PROTECTED] wrote,
In 3.3, after the sin example, add:
+ Such a declaration asserts that the external entity is a true function,
+ i.e. when applied to the same argument values it always produces the
+ same result.
Done.
In 5.1, change:
- Furthermore,
John Hughes [EMAIL PROTECTED] wrote,
If the \code{IO} computation wrapped in \code{unsafePerformIO} performs side
effects, then the relative order in which those side effects take place
(relative to the main \code{IO} trunk, or other calls to
\code{unsafePerformIO}) is
On Fri, Jun 06, 2003 at 09:32:18AM +0100, Simon Peyton-Jones wrote:
Yes! Yes! Advice is good!
OK, how about avoid unsafePerformIO like the plague?
Why is it the business of the FFI spec to document unsafe uses of
unsafePerformIO?
I'd like to second Ross here. Advice is good at the right
On Thu, Jun 05, 2003 at 09:25:11AM +0200, John Hughes wrote:
On Wed, 4 Jun 2003, Ross Paterson wrote:
+ \item[unsafePerformIO ::\ IO a - a]
+ Return the value resulting from executing the \code{IO} action.
+ This value should be independent of the environment;
+ otherwise, the system
That is, document
unsafePerformIO enough to serve the FFI, but stipulate limits to preserve
equational reasoning.
I think this is very hard to do.
When we use unsafePerformIO in the ffi, we are using the IO monad to
sequence [un]marshalling side-effects. For example, peeking and poking
Ross Paterson [EMAIL PROTECTED] wrote,
On Fri, May 23, 2003 at 07:33:05AM +1000, Manuel M T Chakravarty wrote:
Dear Haskell Folks,
Release Candidate 10 of the H98 FFI Addendum 1.0 is now
available from
http://www.cse.unsw.edu.au/~chak/haskell/ffi/
I have an ideological
10 matches
Mail list logo
