- Haskell - Haskell.org

RE: [Haskell] threading mutable state through callbacks
by Simon Marlow 14 Oct '04

14 Oct '04

On 13 October 2004 03:36, Wolfgang Thaller wrote: > b) Some predetermined order, with semantics like mdo: > > John Meacham wrote: > >> The basic idea is that your entire program behaves as if in a giant >> 'mdo' block, ordered in module dependency order. I also like the mdo idea - in fact it occurred to me yesterday, but I wasn't sure whether there would be any gotchas when the details were worked out, and it looks like John has established that things work out nicely. GHC already has an initialisation procedure for each module in the program which could be adapted to run the initialisation-time IO actions, with a little effort. I'm more worried about what other changes we have to make to the compiler: if we can avoid having to flag top-level bindings as monadic/non-monadic all the way through the compiler, then we could avoid a pervasive change to the compiler. At the moment I can't see an obvious way to do that. > What is module dependency order? There's no such thing when there are > circular dependencies, and when there aren't any, it might still > depend on the order of import directives, which is probably not > something I want program semantics to depend on. > I feel that In a large program, you'll probably get more surprises > from this. > The good thing is that you can always use unsafeInterleaveIO to get > the other semantics back, so we should probably investigate this > further. GHC's init blocks are run in dependency order, picking an arbitrary depth-first traversal when there's a recursive module dependency. Seems as good a choice as any. Cheers, Simon

2 1

is $ a no-op?
by Johannes Waldmann 13 Oct '04

13 Oct '04

In a *lot* of places in my programs, I am using notation f $ g $ h x in favour of f (g (h x)) (that's the '$' as defined in the Prelude: right-associating infix application operator) as it avoids parentheses, and makes the code more manageable (you can write "(upward) pipes" with one "$ f" per line, etc) I liked to think of it as just a syntactical convention (for years ...) but is it really at no cost? It does introduce extra function calls, that is, extra closures etc.? Can these be removed by ghc's optimizer? Or am I totally wrong here ... Actually, looking at the Prelude (now), there is '$!' as well - is that supposed to answer my question? -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- ------ http://www.imn.htwk-leipzig.de/~waldmann/ ---------

7 7

Re: [Haskell] threading mutable state through callbacks
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

>its almost commutative Does that have something to do with splitting the supply? >newIORef why not use 'newSTRef' and use the ST monad... Keean.

4 3

RE: [Haskell] is $ a no-op?
by Kevin Millikin 13 Oct '04

13 Oct '04

On Wednesday, October 13, 2004 11:25 AM, Jacques Carette [SMTP:carette@mcmaster.ca] wrote: > > > -- It's kind of like an converse map. > > > > I have attempted, unsuccessfully, to write flist above in a point-free > > manner. Is it possible? > > > Of course it is, but why? > > flist = flip (map . flip ($)) > > Some functions are simpler point-free, others are simpler with points. I > was curious about this one (I like the pointwise version better). > > Also, the statement "It's kind of like a converse map" becomes quite clear > from the point-free way to write it, while still not so obvious in the > pointwise version. I haven't proven it, but I think that this is the same function on lists: > flist = (. return) . ap -- Kevin

1 0

Re: [Haskell] threading mutable state through callbacks
by Wolfgang Thaller 13 Oct '04

13 Oct '04

Well, Wadler's Law of Language Design has been disproved. We seem to agree on the syntax, that is, global "foo <- bar" bindings, and we're actually discussing semantics. That's great! Just for the record, I want exactly what Adrian proposed. There seem to be two interesting points about the semantics: 1) To prevent unwanted typecasts, all toplevel "<-" bindings must be monomorphic. This restriction should be sufficient to keep everything perfectly safe (does anyone disagree?), except for... 2) Evaluation order. That's what everyone has been fighting about. So what are our options? a) unsafePerformIO - like. This has some potential for abuse, but it works. Lazy initialization is a good thing for large programs - and that includes side effects. People deliberately do that in OO programs - you'll find methods that look like getSomeMemberVar accessor methods, but the first time they're invoked, they'll actually initialize a part of the program. I'd actually like to abuse this feature that way. Anyway, the non-determinism this introduces is not nearly as bad as what you get from concurrency or even signal handlers... b) Some predetermined order, with semantics like mdo: John Meacham wrote: > The basic idea is that your entire program behaves as if in a giant > 'mdo' block, ordered in module dependency order. What is module dependency order? There's no such thing when there are circular dependencies, and when there aren't any, it might still depend on the order of import directives, which is probably not something I want program semantics to depend on. I feel that In a large program, you'll probably get more surprises from this. The good thing is that you can always use unsafeInterleaveIO to get the other semantics back, so we should probably investigate this further. Is there some option c) that I overlooked? Another question is, if the order is to follow program order, what do we still need main for? Ugh... Cheers, Wolfgang

4 3

[ANNOUNCE] Hacle
by Matthew Naylor 13 Oct '04

13 Oct '04

Dear Haskellers and Cleaners, You may be interested in the results of my final-year student project at the University of York. It involved the development of a translator from Haskell to Clean; an idea that probably won't be too unfamiliar to most of you. The project's homepage is: http://www.cs.york.ac.uk/~mfn/hacle/ I hope that you enjoy the read, and find the results of interest. Kind regards. -- Matthew

1 0

Re: [Haskell] threading mutable state through callbacks
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

>All we really need is a 'unique value monad' to give us unique values This sounds a lot like Clean's unique-types? Keean.

2 1

lazy constructors
by Serge D. Mechveliani 13 Oct '04

13 Oct '04

Dear Haskellers, I try to organize a `lazy' output in my program, so that the data are accumulated, step by step in a pair (String, String) (a contrived simplified example). And the first component is a `story' to be printed out in a `lazy' manner, the first steps need to print without waiting for the whole data field to be ready. If the program returns String, then I can arrange this. But with (String, String), I do not know how to do. And in the real progam, it is a more complex labeled record, carried along through the program. Probably, the obstackle is in the very Haskell language. Consider a simple example: --------------------------------------------------------------- bottomStr :: String bottomStr = let xs = xs in xs bottomSPair :: (String, String) bottomSPair = let p = p in p bound = 10^8 :: Int -- some large number f1, f2, g1, g2 :: Char f1 = head ('a' : (if last [1 .. bound] > 0 then "b" else "c")) f2 = head ('a' : bottomStr) g1 = head $ fst $ addToSPair 'a' (if last [1 .. bound] > 0 then ("b", "") else ("c", "")) g2 = head $ fst $ addToSPair 'a' bottomSPair addToSPair :: Char -> (String, String) -> (String, String) addToSPair c (xs, ys ) = (c:xs, ys ) main = putStr [ f1, '\n' ] -- f2 -- g1, g2 --------------------------------------------------------------- g1 is similar to f1, g2 similar to f2. f1 and f2 are evaluated immediately to 'a'; g1 evaluates to 'a' after a long computation; g2 evaluates to Fail: <<loop>> As g2 is similar to f2, should it have a value 'a' ? In head $ fst $ addToSPair 'a' bottomSPair bottomSPair is of type (String, String). addToSPair is declared as returning (String, String). Hence, the complier knows ab initio that after addToSPair the result is of kind ('a': _, _) :: (String, String) Hence, applying further head $ fst yields 'a'. This is in the air of a `lazy' computation. In a more clear presentation, the computation should (?) be head $ fst $ addToSPair 'a' bottomSPair = head $ fst $ addToSPair 'a' (bottomStr, bottomStr) = head $ fst (`a':bottomStr, bottomStr) = head (`a':bottomStr) = 'a' So, similarly as head ('a' : bottomStr) = 'a', (1) it should be head $ fst $ addToSPair 'a' bottomSPair = 'a' (2) Probably, Haskell-98 does not put so. Right? Question 1 ---------- What may be the consequences for the language (let us call it HCLazy) if it treats the data constructors like in (2), like more `lazy' ones? For example, fst (bottom :: (a,b)) = (bottom :: a) Question 2 ---------- How to arrange the above `lazy' output? The whole result story is ready in several hours, or days, and each step should be displayed immediately as it is ready. So far, I see no other way as to compile the program together with the Trace library, inserting there the calls \ step ... -> trace (show step) $ ... (?) Thank you in advance for the explanations. Copy, please, the answer to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Re: [Haskell] lazy constructors
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

You can only return a list of pair's lazily, not a pair of lists. If the two strings are independant, then generate each in a separate function, and pair off the results lazily. Keean.

1 0

Re: [Haskell] threading mutable state through callbacks
by Udo Stenzel 13 Oct '04

13 Oct '04

Wolfgang Thaller <wolfgang.thaller(a)gmx.net> schrieb am 13.10.04 04:36:43: > 2) Evaluation order. > > That's what everyone has been fighting about. > > So what are our options? > > a) unsafePerformIO - like. > b) Some predetermined order, with semantics like mdo: c) same as b) plus unsafeInterleaveIO In fact, I think a specified order for side-effecting initialisation is a good thing. Initialisation should happen in order of declaration and in order of module dependecies. An initialisation that is to be performed lazily is simply wrapped in unsafeInterleaveIO. Anything wrong with that aproach? Regards, Udo. ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

1 0