October 2003 - Haskell-Cafe

Re: Read and Write to Same File
by kuq32tr02＠sneakemail.com 05 Oct '03

05 Oct '03

> > main = do text <- readFile "test" > > let something = somefunc text > > writeFile "test" $! something > > There is no guarantee that $! will force evaluation of the entire > 'something', so you can start writing to file before you finished > reading from it. Hopefully it will cause an exception (like in GHC), > otherwise you could damage your data (like in Hugs). > > PS. How does it behave in NHC? This is the version I've been using for a while now. It runs perfectly fine in both GHC and Hugs. I've used it many, many times with no noticeable problems. Should I be seeing errors (like exceptions in GHC)? I don't have NHC installed, so I can't test it. Thanks!

1 0

Re: IO behaves oddly if used nested
by Derek Elkins 05 Oct '03

05 Oct '03

On Sat, 04 Oct 2003 13:13:59 +0200 "blaat blaat" <l4t3r(a)hotmail.com> wrote: [moved to Haskell-Cafe] > > Neither example is odd behavior, unless > >you consider Hugs providing a perfectly reasonable instance of Show > >for IO a odd. > > True, every program behaves exactly as according to the definition of > the run-time behavior of Haskell programs. (Hugs deviates a bit from > ghc but ah well) The odd is not in the run-time behavior. > > The odd is in the conceptual explanation. If I give a description of > some f x = y function in Haskell I expect that some program f x is > reduced to y and the result is given back (possibly printed). A good > story to sell to students. Then use an impure language like Scheme. This is exactly what the IO monad avoids. > This is almost everywhere the case except for the IO monad. This is never the case. You can -only- print things via the IO monad. > In the former example, the inner putStr is _not_ evaluated but a > message is shown (hinting that a IO has some structure we can observe > before evaluation). The message shown doesn't expose any structure, let alone suggest that you can observe it. The message is independent of the actual IO action it only uses the type. You could write the Show instance yourself. instance Show (IO a) where show _ = "<<IO action>>" > In the latter example, it is shown that we are not > interested in a result of a IO program, but only in its (lazily > generated) side-effects. The effects aren't lazily generated. Monads are independent of evalution order. They would work just as well in a strict language. This is what makes them pure. (See Amr Sabry's "What is a Purely Functional Language?") > The monad behaves oddly with respect to the f > x = y behavior. Not really. If f x were, f x = \_ -> unsafePerformIO (putStr "Hello") would you be surprised that f 5 doesn't print "Hello"? > I think I observe the following reactions when I explain IO: Perhaps because you don't explain it properly? > * Why is an IO a evaluated if I am not interested in it's result? > (opposite to the f x = y lazy behavior) It isn't. If you are interested in it's result, then the result is an action which will do whatever -when run-, -not- the side-effects. If you aren't interested in it's result it will never be evaluated in Haskell, but even if it were (by adding a seq or using a strict language) the result would -still- be an action that will do something -when run-, and since you aren't interested in it it will be discarded without ever executing; a good thing as this maintains purity. > * Why is in the putStr "hello world" example Hello World not shown? > (opposite to expected f x = y eval-first-then-show behavior) Because it is never run. > * Why is in the IO (IO ()) example the inner IO () not evaluated? Because it is never run. > (somewhat opposite to expected f (f x) behavior - I personally wonder > if it is even sound in a category theoretical setting) As for the Category Theoretic behavior, it's perfectly sound. The RTS just discards the result, given that in a sense it's type is IO a -> something where 'a' is not free in something, all it -can- do is discard the result by parametricity. It doesn't matter if it 'a' is Int, (), IO FooBar, Char-> Int or anything else, any more than it matters in what type or value the first argument is in f _ = () or the "return" type of the monad action m in do_ <- m;return() (or written another way, m >>= \_ -> return ()). If you think of IO actions as state transformers (which has it's faults but works for this), then the observed behavior makes perfect sense. None of the IO actions -can- execute because they don't have the state of the world to process. It's just like with the State monad, execState (do x <- get;put (x+5);return (put 10)) 0 returns 5 not 10, the state (0 then 5) is never passed to put 10. This can be seen by unfolding this into the standard state-passing definition. If we take out the execState, -nothing- happens and we just get functions that will transform a state once it's provided; they won't and -can't- do anything until that state is provided. So putStr "foo" is IO () is World -> ((),World), it is not surprising that f _ = 10, f (putStr "foo") does not print "foo", anymore than it is surprising that f (\x -> undefined) does not cause an error, or f (put 10) does not change some state somewhere.

2 1

Newbie qustion about monads
by Juanma Barranquero 04 Oct '03

04 Oct '03

I have an extremely-newbie question about monads and how to interpret the monadic laws; I asked that same question yesterday on IRC and the answers were interesting but non-conclusive (to me anyway). I'm trying to learn monads by reading "All About Monads", version 1.0.2. I though of defining a monad like that: data Counted a = Ct Int a instance Monad (Counted) where return x = Ct 1 x Ct n x >>= f = let (Ct n' x') = f x in Ct (n+n') x' -- fail as default The intent is that Counted objects "count" the number of times an operation is applied to them. (For the purpose of the question, that's irrelevant anyway: the problem would be the same if I assigned a random number to the Int on each calling of >>=.) According to "All About Monads", the first monadic law says: (return x) >>= f == f x In my case, let's suppose I define: reverseCounted :: [a] -> Counted [a] reverseCounted x = return (reverse x) so I do: c1 = return "xxx" >>= reverseCounted -- c1 == Ct 2 "xxx" c2 = reverseCounted "xxx" -- c2 == Ct 1 "xxx" Now comes the question: In what sense should I interpret the "==" in the monadic law? Obviously, c1 and c2 are not structurally equal. If I can accept that two Counted things are "equal" even if they are not identical, is enough for me to define: instance Eq a => Eq (Counted a) where Ct _ x == Ct _ y = x == y to satisfy the first law? Yesterday I was said that it'd work if c1 and c2 are mutually substitutable. They are, for the purposes of equality, though evidently not for every purpose. A simple: count (Ct n _) = n allows me to distinguish between them. Juanma

5 13

Why does this work - haskell mysteries?!
by ,,, 04 Oct '03

04 Oct '03

Hi; the proof of the pudding does lies in the eating... but I still wonder why this code is working (it is taken from the book "The Craft of functional programming"). The program connects a variable-name to value. The fun initial gives the initial state, update sets a variable & value reads a value). I evaluate value my_store 'b' to 5 and value my_store 'a' to 3 as expected from the text in the book. But I can't see what is happening here. The book has a parallel example where the data is held in a list, and this version is easy to follow, but this trick with storing a lambda-function inside a newtype beats me. The problem is that I do not understand where the accumulated data is stored (not in a list - it seems like something like a chain of functions which can be pattern-matched, but I am not sure). And why does not the lambda-function (\w -> if v==w then n else sto w) start a endless loop? (This is not homework - I am a programmer who is curious about Haskell!) Any clues, anyone? Cheers, Petter -- Var is the type of variables. type Var = Char newtype Store = Sto (Var -> Int) -- initial :: Store initial = Sto (\v -> 0) value :: Store -> Var -> Int value (Sto sto) v = sto v update :: Store -> Var -> Int -> Store update (Sto sto) v n = Sto (\w -> if v==w then n else sto w) -- testit -- my_store = update (update (update initial 'a' 4) 'b' 5) 'a' 3)

1 0

Haskellsupport in KDevelop
by Peter Robinson 04 Oct '03

04 Oct '03

Hello, I've begun to write a plugin that provides basic support for Haskell in KDevelop 3.0 alpha. (http://www.kdevelop.org) It is already included in the CVS and the latest alpha7 release. Screenshots: http://www.thaldyron.com/snap1.png http://www.thaldyron.com/snap2.png http://www.thaldyron.com/snap3.png At the moment it's only possible to create a new project and to build/run it with GHC. What's really missing is a (primitive) background parser written that reports syntax errors. It can be written in yacc, antlr, etc., anything that produces C/C++ code. The only parsers for Haskell I could find are written themselves in Haskell. Does anyone know about one or must I write it from scratch? Regards, Peter

3 3

RE: "interact" behaves oddly if used interactively
by Simon Marlow 03 Oct '03

03 Oct '03

> Yes, the presence of lazy IO makes optimistic evaluation more > complicated, but I do not see that it compromises the purity of the > language in anyway (whatever purity is ;-). So, we're agreed that the presence of lazy evaluation makes implementing optimistic evaluation (and other evaluation strategies) more complicated. Personally, I find it disturbing that the presence of this family of library functions affects something as low-level as the evaluation strategy of the language. Or, to put it another way, it enforces a particular evaluation strategy on a part of the language, when the rest of Haskell makes no such restrictions. I would expect, in a pure language, that I could reduce any expression in a program to HNF (or _|_) without affecting the meaning of the program. In Haskell, I can only do this so long as the expression doesn't involve any lazy I/O. The real problem is that lazy I/O injects side effects into the pure world of expressions. Haskell has a perfectly good system for encapsulating side effects - the IO monad. So why put these sneaky side effects into pure values? Cheers, Simon

5 4

RE: "interact" behaves oddly if used interactively
by Simon Marlow 02 Oct '03

02 Oct '03

> > The real problem is that lazy I/O injects side effects into the pure > > world of expressions. Haskell has a perfectly good system for > > encapsulating side effects - the IO monad. So why put > these sneaky side > > effects into pure values? > > I fear one problem is that the word "side effect" is not properly > defined. > > Actually both getContents and interact are in the IO monad. Since the > action "interact" is not terminated until the input stream ends, I do > not see any problem there. Yes, it is probably true that you cannot observe any non-referential-transparency using only interact. The side effects are only visible in the IO monad, and since as you say interact doesn't let you back into the IO monad until it has finished, it is probably safe. The unsafety is only visible using the other lazy I/O operations, principally hGetContents. > Evaluation never leaves the IO monad until > termination. getContents is more strange. However, you can just define > its semantics to yield a random string. When you are not > careful you may certainly get something nearly random ;-) So... you agree that getContents in its current form should really be called unsafeGetContents? Unless perhaps we redefine its semantics to either (a) yield a random string or (b) eagerly slurp the entire stream contents? Cheers, Simon

4 3

RE: "interact" behaves oddly if used interactively
by Simon Marlow 02 Oct '03

02 Oct '03

[ taking this one to haskell-café... ] > I still do not quite agree with Simon that 'interact' exposes anything > but non-strictness. Non-strictness means that > > map toUpper _|_ = _|_ > map toUpper ('a':_|_) = ('A':_|_) > map toUpper ('a':'b':_|_) = ('A':'B':_|_) > > and 'interact (map toUpper)' is a great way to experience > this property. > > However, you can also experience the property without 'interact', > evaluating expressions like > > take 2 (map toUpper ('a':'b':undefined)) Certainly you can observe non-strictness, that's not the point. The point is that you can also observe more than just non-strictness using interact, and I don't think that is desirable. For example: interact (\xs -> let z = length xs in "Hello World\n") Now, Haskell is a pure language, so it shouldn't matter whether the implementation evaluates z or not, as long as it is careful not to violate the non-strict semantics by turning a terminating program into a non-terminating one. A parallel Haskell implementation might happily spawn off another thread to evaluate z for example. An optimistic implementation might evaluate z for a fixed amount of time before continuing with the main thread of evaluation. BUT in the presence of lazy I/O this simply isn't true any more. Why? Because z is not pure; evaluating it has a side-effect. And yet it has type Int. Am I the only one who thinks this is wrong? Cheers, Simon

8 11

Question about Type Checking
by Clement 02 Oct '03

02 Oct '03

Hi i am doing a type checker. and how can i check if the Expn that i have is a Prim Function = ("f",[([Arg "x"],Simple (Int 2))]) type Function = (Name, [Equation]) type Equation = ([Expn], Body) {- (the body of) either a simple equation: f a1 .. an = e or a conditional equation: f a1 .. an | b1 = e1 ... | bm = em data Body = Simple Expn | Conditional [(Expn, Expn)] deriving (Show, Read) data Expn = Int Int | Char Char | Bool Bool | Arg Name | Prim Name | Func Name | Appn Expn Expn | Tuple [Expn] and how can i group the Expn together for Appn? __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

Pre-Call for Contributions -- HC&A Report (November 2003 edition)
by C.Reinke 02 Oct '03

02 Oct '03

[apologies for multiple copies - experience has shown that not all Haskellers can be reached via the main Haskell list anymore] An entry for your diaries (no other action required right now): ------------------------------Pre-Call-------------------------------- Your contributions to the November 2003 edition of the Haskell Communities & Activities Report will be invited soon. http://www.haskell.org/communities/ Submissions are welcome between 20th and 31st of October ---------------------------------------------------------------------- The real Call for Contributions will follow closer to the submission window, in about two weeks. This is just an early warning. You will need to plan about 15 minutes for composing your contribution, which would be a brief, ASCII-format, description of your Haskell activities (see earlier editions for plenty of examples). Cheers, Claus (current editor of HC&A Reports)

1 0