Re: [Haskell-cafe] Re: Order of Evaluation
On Fri, May 9, 2008 at 3:46 PM, Achim Schneider [EMAIL PROTECTED] wrote: Miguel Mitrofanov [EMAIL PROTECTED] wrote: Oh, you sure? I was, until you wrote that. But then, I am, as I wouldn't use unsafePerformIO together with IORef's, it's giving me the creeps. So.. what do you use unsafePerformIO together with? In uses where I'm not just debugging stuff, I _usually_ use it with IORefs, for more complex caching behavior than I can get out of the language. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Order of Evaluation
Hello Luke, Sunday, May 11, 2008, 1:24:04 PM, you wrote: So.. what do you use unsafePerformIO together with? when i call function that in general case depends on the execution order (so it's type is ...-IO x), but in my specific case it doesn't matter. typical example is hGetContents on config file, GetSystemInfo just to get number of processors, string processing via C functions -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Order of Evaluation
Miguel Mitrofanov [EMAIL PROTECTED] wrote: As I understand it Haskell does not specify an order of evaluation and it would therefore be a mistake to write a program which relies on a particular evaluation order. This is the 'unsafe' aspect of unsafePerformIO. Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type errors in runtime. At least, that seems to be much more dangerous. Nope. That'd be unsafeCoerce#, which you never heard of, and I did not mention it in this post. Go away. This is not the function you are looking for. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Order of Evaluation
Oh, you sure? quote src=http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html It is less well known that unsafePerformIO is not type safe. For example: test :: IORef [a] test = unsafePerformIO $ newIORef [] main = do writeIORef test [42] bang - readIORef test print (bang :: [Char]) This program will core dump. This problem with polymorphic references is well known in the ML community, and does not arise with normal monadic use of references. There is no easy way to make it impossible once you use unsafePerformIO. Indeed, it is possible to write coerce :: a - b with the help of unsafePerformIO. So be careful! /quote That's the reason why f has sometimes LESS general type than \x - f x in OCaml. On 10 May 2008, at 01:34, Achim Schneider wrote: Miguel Mitrofanov [EMAIL PROTECTED] wrote: As I understand it Haskell does not specify an order of evaluation and it would therefore be a mistake to write a program which relies on a particular evaluation order. This is the 'unsafe' aspect of unsafePerformIO. Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type errors in runtime. At least, that seems to be much more dangerous. Nope. That'd be unsafeCoerce#, which you never heard of, and I did not mention it in this post. Go away. This is not the function you are looking for. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Order of Evaluation
Miguel Mitrofanov [EMAIL PROTECTED] wrote: Oh, you sure? I was, until you wrote that. But then, I am, as I wouldn't use unsafePerformIO together with IORef's, it's giving me the creeps. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Order of evaluation
Jon Harrop wrote: If you have a boolean-or expression: a || b will a be evaluated before b in Haskell as it is in other languages? Yes, although the meaning of the phrase evaluated before is a bit tricky in a lazy language, so it's probably better to state it with denotational semantics alone: _|_ || b = _|_ Maybe you also want to know whether the second argument is evaluated. This is answered by True || _|_ = True False || _|_ = _|_ Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
re: order of evaluation ?
konst writes:
my question is, if i have an expression such as ((Const False) ::
subexp), will subexp be reduced first (according to the definition
'simplify (x :: y) = simplify' ((simplify x) :: (simplify y))') or
will laziness do the right thing, and emit (Const False) without looking
into exp?
i think the latter, but would appreciate a word from an expert.
Hi Konst,
There is an easy way to check, try making subexp an erroneous
computation. There is such a value in the Prelude, it is called
undefined:
simplify ((Const False) :: undefined)
If this bombs then you know that simplify wasn't as lazy as you thought, since
it must have tried to evaluated 'undefined'. On my version of hugs I get:
Program error: {undefined}
The important bits of code are:
simplify (x :: y) = simplify' ((simplify x) :: (simplify y))
simplify' (x :: (Not y)) | x==y = Const False
simplify' ((Const False) :: _) = Const False
The order of the equations for simplify' is important. Effectively pattern
matching causes evaluation in Haskell. To determine whether the first
equation for simplify' should be used, the second argument of :: must
be evaluated to what is called weak head normal form (whnf). This means
that the outermost constructor of that argument must be computed.
Hence the computation with undefined fails in this case.
However, what happens if you swap the order of the equations for simplify'?
Doing so will give you the lazyness that you originally expected (for this
particular example).
Swapping the order of equations is not a silver bullet however, and you must
be very careful with how you order them.
One of the best places to learn about the operational semantics of languages
like Haskell is The Implementation of Functional Programming Languages
by Simon Peyton Jones. I think it is out of print, but you may find copies
in your local uni library if you are lucky.
For this particular example, pay close attention to the Pattern Matching
Compiler section, which I think was done by Wadler.
Cheers,
Bernie.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
