September 2006 - Haskell-Cafe

Advantages of using qualified names and a uniform naming convention
by Brian Hulley 04 Sep '06

04 Sep '06

Hi - There's lots of great Haskell libraries available, but little standardization regarding naming conventions or code organization. In this post I try to illustrate some dimensions of the question of how to form names for things and offer my opinion on specific examples knowing that this of course only represents my own personal view but may nevertheless be of objective interest as an *example* of a view and a possible starting point for discussion/ unification of naming conventions in Haskell code if such a thing is even desired/desireable at all. It would be helpful to build up a more rigorous algorithm for determining names, but I think the first step is to try and isolate aspects of the problem thus the following is an initial attempt in this direction... Firstly, I found the following advice by Henning Thielemann very useful in my own code [1]: In the style of Modula-3 I define one data type or one type class per module. The module is named after the implemented type or class. Then a type is named T, and a type class C. I use them qualified, e.g. Music.T or Collection.C. Similarly, if a type has only one constructor then I call it Cons and use it qualified MidiFile.Cons [I don't agree with this last suggestion]. This style also answers the annoying question whether the module name should be in singular or plural form: Always choose singular form! where the only thing I change is that the name of the value constructor for a type with only one value constructor should be the same as the name of the type constructor eg newtype T a = T (a->Int) which seems to be the normal convention anyway and seems better imho than introducing a different identifier for the value constructor when the namespaces for values and types/classes are already distinct. The advantage of such a strict rule is that code becomes deliciously uniform and neat, even if you just follow the part of it that deals with types and modules and use some different convention for classes. It's also particularly nice if you're used to object oriented languages, since it preserves the intuition that you can deal with one thing at a time just as you would put each object into its own separate file or C++ unit. Of course, not all modules can have just one type but I find that most only need to export one type and in any case the (main) exported type can be called "T". The exception is when the types are mutually recursive, so that different types which should really have their own module have to be put into the same module due to limitations of the compiler being used (eg GHC does not yet support mutually recursive modules involving types declared using newtype deriving and also requires hs-boot files which is imho a horrible mess as bad as the need to write separate header files in C and keep decls in sync therefore I avoid them at all costs). Consider the following: import Data.IORef main = do x <- newIORef (0::Int) writeIORef x 3 compared to: import qualified Prime.Data.IORef as Ref main = do x <- Ref.new (0::Int) Ref.write x 3 To my mind the latter is infinitely cleaner looking, because the names of the functions just specify their purpose and nothing else, and it is immediately clear which module they have come from, and there is also the advantage that a shorter prefix could be used if required eg "R". In contrast, the first code example is polluted with mutiple repetitions of "IORef" - we already know we're in the IO monad so why keep stressing the point that we're using IORefs as opposed to STRefs etc? - and there is not even any certainty that the functions so named even come from that module (unless we're already familiar with the contents of the other modules of course). Not only does the latter code look startlingly beautiful, but there is a significant advantage when using an editor which is sophisticated enough to make use of it: after typing the dot in "Ref.", it should be possible for an editor to then display a pop-up list of the visible contents of the module (various possible patent issues aside :-( ) ie the programmer just needs to know the module alias name rather than the names of each individual function/value/type/class when coding. Furthermore (see there's almost no end to the advantages of this convention! ;-)) if the implementation of IORef's was improved later, the whole module can be instantly ported to use the improved implementation just by changing the one import line rather than a painful search and replace of "newIORef" by "newBetterIORef" etc. I think the current presence of names like "newIORef" in the base library is perhaps a result of historical development - qualified names or aliases may not yet have been invented so there was probably a need to follow a convention of appending the type to the purpose when creating a function/value name, but now that we have the ability to use qualified names it would seem to be a lot better if everything could be changed to use them ie Data.Set should export T not Set so you would use foo :: Set.T -> Int foo = Set.size instead of import Data.Set as Set and trusting to luck that there is no other data type in scope with the name Set, or having to use Set.Set which looks wierd. It probably goes without saying that with the use of qualified imports, symbols are absolutely gross and should be avoided at all costs. They're totally unreadable, not just because they're a squiggly unpronouncable mess, but because you need to simulate an operator parser in your head to discover what's being applied to what. Someone could even define <+> to bind tighter than <*>, so it's not even safe to rely on normal conventions, and different modules in a program could use the same symbol in totally different ways with different precedences, leading to a real headache and unnecessary bugs when jumping between code in an editor. For readable code, plenty of descriptive words and parentheses are surely preferable. The only exception I'd make is the use of >>=, >> (which is so fundamental the alternative do notation is built into the language), ($), ($!), (.), and common arithmetic ops. Returning to Data.Set, let's now consider some of the names that are used: null :: Set a -> Bool empty :: Set a (null) tests to see whether or not a set is empty, and (empty) is the empty set. The relationship between the words "null" and "empty" can only be found by looking in an English dictionary. I propose that linguistic relationships should never feature in names used in programming. Instead the relationships should always be expressed as far as possible in the forms of the identifiers as sequences of characters. Having a clear unified framework to create names would also help not only the library author but also library users. Thus I propose that (null) should actually have been called "isEmpty", so that the relationship with the use of (empty) to denote the empty set is immediately apparent, and the use of the word "is" would immediately tell you that the function is a predicate. It might even be advantageous to reserve more characters for use in identifiers (since the infamous ASCII symbols are so abhorrent anyway ;-) ) so we could have a similar rule to Scheme, that predicates would end with a question mark thus relieving us of the need to decide between "is" and "has" (to try and eliminate as much of the messiness and indecision caused by natural language as possible), though of course this would be a more long term idea eg: -- So related things appear alphabetically together... empty? :: Set a -> Bool empty :: Set a It could be argued that it would be more in keeping with left-to-right thinking to put the '?' first but then we'd lose the "related things should be together in any alphabetical list of functions/values", though such a compromise is already necessary when using "isEmpty" rather than "emptyIs" which would perhaps just sound too unnatural ;-) Moving on to Data.List, we find a confusion of different spatial, temporal, and historical viewpoints jostling valiantly for supremacy in the programmer's mind: head tail -- funny cartoon-like image of a list last init -- temporal foldl foldr -- spatial (left to right) Despite the fact that (last, init) is somehow the dual of (head, tail), we have to switch from a temporal conception of a list to a historical "cartoon" conception to move between them. Then we come to foldl, foldr where we think in terms of left and right. Also, with foldl, foldr, it is just lucky that we already know there is a word called "fold" so that we know the trailing "r" or "l" is intended to be a suffix - it's not nearly so clear in cases like "reducer" and "reducel" where "reducer" is also a single word in English. Therefore I propose that for a list there should only be one underlying concept, that of a spatial sequence going from left to right, and that all functions should be named in accordance with this alone ie: atL atLs -- similar to (x:xs) atR atRs foldL foldR thus there would only be one concept (the spatial sequence) to grasp which the programmer could then map internally onto another concept such as time if required, without being forced by the names in Data.List to jump confusingly between them. A discussion of naming in Data.List would certainly be incomplete without a mention of (nub). It must surely rank as one of the most peculiar identifiers in the whole history of programming. The documentation thankfully explains that it means "essence", but then goes on to say that it is in fact just a function for removing duplicates from a list. The mind can only convulse in the most tortuous configurations to try and reverse engineer this strange correspondence. Would the simple name (removeDuplicates) or even (asSet) not be much easier all round? Related to lists, we of course have sequences and there, instead of cons and snoc, we could just have pushL and pushR which are nice logical names that don't conjure up images of candles and devils crawling out of mirrors etc like the use of reversed spelling in "snoc". In case the above seems overly critical of other people's hard work and good intent, I'd like to confess that I myself am often tempted off the path when it comes to the creation of identifiers involving adjectives eg: type BlueCar = ... type RedCar = ... The problem here is that these names, presumably both to do with "Car", are not going to appear next to each other in any alphabetical listing (if there are other names too), whereas: type CarBlue = ... type CarRed = ... will. Thus the position of the adjective in natural language (in this case English) has to be ignored if you want a programming environment to display related things together. Finally, as a piece de resistance :-), consider the following two definitions of (>>=) for the continuation monad: newtype Cont r a = Cont { runCont :: (a -> r) -> r } m >>= k = Cont $ \c -> runCont m $ \a -> runCont (k a) c -- (1) Cont a_r_r >>= a_C_b_r_r = Cont $ \ b_r -> a_r_r (\a -> runCont (a_C_b_r_r a) b_r) -- (2) In (1), we have to know what the associativity of ($) is (and this is a real fire bed of controversy!) and the variable names, apart from (a), don't give us the faintest clue what's going on, and in fact are doubly confusing because (m) is used to represent a value of type (m a) so there is a kind of kind error in the value name. In contrast, (2) uses the simple convention that the type is reflected more or less directly in the name so that a_r_r means a value of type (a->r)->r (there is unfortunately no way to indicate bracketing in the name). Thus by reading the definition we can understand what's going on just by cancelling out components of the name thus: a_C_b_r_r a gives us C_b_r_r and runCont (C_b_r_r) gives us b_r_r and (b_r_r b_r) gives us (r) so it's obvious that we're supplying an argument of type a->r to a_r_r as required. A great thing about Haskell is that it's quite simple to start renaming things already without having to change existing modules. In my own code I've simply just created new modules for IORef and Unique that re-export the original module contents but with the unsuffixed names, then I import from a hierarchy optimistically called "Prime" instead of the normal hierarchy :-) Having said all this, it's nevertheless an open question to me, regarding the meeting between human psychology and the desire for consistent logical naming conventions, if perhaps the rapid jumping between different viewpoints encountered in the functions in Data.List etc has a stimulating effect on the imagination in terms of encouraging mobility of thought and a danger with fully rationalised names could be that they may make one dry and brittle - though at least there would be no danger of a headless fire breathing dragon emerging from a mirror because you've just typed "cons" backwards.... :-) Regards, Brian. [1] http://haskell.org/hawiki/UsingQualifiedNames (bottom of the page) -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

2 3

Problems trying to understand the BSD license
by Brian Hulley 04 Sep '06

04 Sep '06

Hi - I'm not sure if this is the right place to ask this question but since a lot of Haskell code is under the BSD license I think the answer could be useful for other people as well. The question I have is if I want to redistribute a binary executable under my own proprietary license that uses code from various BSD libraries, what exact text do I need to add to my license to satisfy the BSD licenses that came with the libraries? Is the code that is part of the executable considered to be a redistribution of the library in binary form? Also consider this apparent contradiction: Copyright (c) 1988 XYZ ... 1) Redistributions of source code... 2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3) Neither the name of XYZ nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. In order to comply with 2), it suggests I'd need to insert something along the lines of: Portions of this software are copyrighted by XYZ, PQR, STU, ... Portions of this software are provided by XYZ, ..., "as is" and any express or implied warranties ... but does this infringe on 3), which states that the name of XYZ should not be used to endorse the product? Ie is the mention of XYZ's name in the license considered to *not* be an endorsement? And what about "this list of conditions"? Does that also include the first condition ("Redistributions of source code ...") even though only a binary executable is being supplied to the licensee? I also don't want the licensee to get confused and think the whole executable is being distributed under BSD. Also what about the application's "about" dialog or help pages? Would an acknowledgement of libraries used in the code and their authors be considered to be using them to endorse my product or would it be regarded as a welcome acknowledgement for their hard work in making the libraries available? Is this required or prohibited by the BSD license? Surprisingly, although I have looked at several websites which discuss the BSD license, none of them actually say what the practical down to earth text of a proprietary license of a binary executable using BSD licensed components is supposed to look like. Any ideas? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

2 2

A free monad theorem?
by Benjamin Franksen 04 Sep '06

04 Sep '06

I'd like to know if the following reasoning can be made more precise: As we all know, the monadic bind operation has type: bind :: Monad m => m a -> (a -> m b) -> m b My intuition says that in order to apply the second argument to some non-trivial (i.e. non-bottom) value of type a, the bind operator needs to be able to somehow 'extract' a value (of type a) from the first argument (of type m a). I would like to argue that this is because bind is polymorphic in a, which makes it impossible to construct values of type a 'out of thin air' (besides bottom). Thus, however bind is defined, the only place where it can obtain a 'real' value of type a is from its first argument. Although one might think that this implies the existence of some function extract :: Monad m => m a -> a it is obvious that this is too limiting, as the IO monad plainly shows. Even monads that can be implemented in Haskell itself (the vast majority, it seems) usually need some additional (monad-specific) argument to their 'extract' (or 'run') function. However, even a value of type IO a /does/ produce a value of type a, only the 'value producing computation' is not a (pure) function. But how can all this be made more precise with less handwaiving? The background for my question is an argument I had some time ago with someone about what the 'real nature' of monads is. He argued that monads are mainly about 'chaining' (somehow wrapped up) values in an associative way, refering to the monad laws. I argued that monadic values get 'chained' in a very specific way and that in order to get an intuition about what this monadic chaining really means on the most general level, the standard model of 'computation that returns a value of type a' is the appropriate one. I tried to use the above (handwaving) argument to convince him (and myself) that this model is indeed 'the right one'. Furthermore, if it really is, then one might conjecture that for /every/ monad there must be some natural interpretation as the representation of some kind of computation (effectful or not). So my second question is: Are there known 'counter-examples' where this intuition breaks down, i.e. monads for which a computational interpretation is unknown or at least obscure enough not to qalify as 'natural'? Cheers, Ben

12 27

Re: [Haskell-cafe] practice problems?
by Paul Johnson 03 Sep '06

03 Sep '06

"Brian Hulley" <brianh(a)metamilk.com> wrote: What about a library for interval arithmetic [1]? I'd imagine it could start something like: data Interval a = Interval !a !a deriving (Eq, Show) instance Num a => Num (Interval a) where Interval llow lhigh + Interval rlow rhigh = Interval (min llow rlow) (max lhigh rhigh) The Interval type would probably need to explicitly represent several kinds of intervals eg (-infinity, x] etc and there are some tricky issues about what to do with the operations whose result sometimes needs to be represented by more than one interval to be useful such as division by an interval containing zero eg you might want to use a list of intervals to deal with these cases: instance Num a => [Interval a] where ... ie [Interval 5 5] / [Interval -1 1] = [FromNegInfinityTo -5, ToPosInfinityFrom 5] Take a look at my Ranged Sets library at http://sourceforge.net/projects/ranged-sets Paul.

2 1

beginner's problam with a monad
by Julien Oster 03 Sep '06

03 Sep '06

Hello, after succeeding in implementing my first monad (Counter, it increments a counter every time a computation is performed) I though I'd try another one and went on to implement "Tracker". "Tracker" is a monad where a list consisting of the result of every computation is kept alongside the final value, kind of a computation history. It really just serves me as an exercise to implement monads. However, the following source code fails: {-------------------------------------------------} data Tracker a b = Tracker [a] b deriving Show instance Monad (Tracker a) where m >>= f = let Tracker l x = m in let Tracker l' x' = f x in Tracker (x':l) x' return x = Tracker [] x bar = do x <- Tracker [] 12 y <- return (x*2) z <- return (y*3) return (z+3) {-------------------------------------------------} Of course, style recommendations and the like are always appreciated. (by the way, I don't really understand why I have to type instance Monad (Tracker a) instead of instance Monad Tracker which may very well be the problem. If it's not, can someone tell me anyway?) Trying to load this piece of code leads to the following error message: Hugs.Base> :load Test.hs ERROR "Test.hs":30 - Inferred type is not general enough *** Expression : (>>=) *** Expected type : Monad (Tracker a) => Tracker a b -> (b -> Tracker a c) -> Tracker a c *** Inferred type : Monad (Tracker a) => Tracker a b -> (b -> Tracker a a) -> Tracker a a Why does the interpreter infer Tracker a a instead of the more general Tracker a c? Thanks, Julien

4 5

[JOKE] Foozles: anatomy of a programming language fad
by Stephane Bortzmeyer 02 Sep '06

02 Sep '06

http://hope.cs.rice.edu/twiki/pub/WG211/M3Schedule/foozles.pdf I hope many Haskellers will have laugh here :-)

1 0

Re: [Haskell-cafe] state and exception or types again...
by Andrea Rossato 02 Sep '06

02 Sep '06

Il Wed, Aug 30, 2006 at 11:24:45AM +0100, Brian Hulley ebbe a scrivere: > Thanks, glad to be of help. I met Haskell a couple of months ago, when I switched my window manager to Ion. Tuomo Valkonen, its developer, uses darcs. Moreover he develops a small PIM, riot, written in Haskell. I wanted to play around with it but the source code was literally unreadable, for me. I could not understand a single line. I do some php. Lately I discovered Javascript and Lua, and I fell in love with their object-oriented capabilities. I'm not a real coder (though I develop a wiki in php), but I like getting to know new programming practices. I've been intrigue with functional programming for quite sometime but I just knew a bit of Scheme, because it's used as a scripting language in LilyPond (a package for writing music sheets). So I decided to spend my August holidays to study Haskell. I started reading some tutorial but could not understand what was going on. I then thought to take the long way: I watched the Abelson and Sussman's lectures and used ghci to (sort of) follow what they were doing. Coming from dynamic typed languages (I know very little C) the type system was horrible. Monads seemed mysterious objects. I've read in the "Yet Another..." that the Haskell community is very supportive. With your help I have now a different perspective. Playing with Haskell is like completing a puzzle, whose pieces' shapes are made up with rules that, at first, you seem not be able to grasp. You keep pushing the last piece, and it just doesn't fit in. Then you realize that shapes are actually types. And when you start understanding the rules of type construction and type matching, now you can recognize the shapes of the pieces you are playing with. And start making rational guesses on where they should go. Now, when I see "Compiling ... Ok, modules loaded: " I feel like I ended up solving the puzzle. It's an amazing pleasure... Haskell and functional programming. Without you I couldn't do it. Thank you so much! The tutorial will have this outline: first we build a monad adding output, exception, and state. Then we use monad transformer to take out state and output and add debug, doing lifting, put(ing) and get(ing) by hand, to understand the central role of type matching/construction. We end up with the following code, that should clearly show all the previous (hand made) steps should lead. No lambda calculus inhere! Once again, thanks! Andrea -----The Final Evaluator---- module MyStateT where import Control.Monad.State hiding (State) data Term = Con Int | Add Term Term deriving (Show) type IOStack = [Output] type Output = String type Debug = [String] data EvalST = State {getIOS :: IOStack, getDebug :: Debug, getCount:: Int} deriving(Show) type Exception = String data MT a = Fail Exception | Done {unpackDone :: a } deriving (Show) type Eval s a = StateT s MT a instance Monad MT where return a = Done a m >>= f = case m of Fail e -> Fail e Done a -> f a instance Functor MT where fmap _ (Fail a) = Fail a fmap f (Done a) = Done (f a) emptyState = State [] [] 0 stopExecT exc = lift $ Fail exc catchT e = do st <- get let s = getCount st let es = getDebug st let o = getIOS st let exc = "Debug msg at Iteration " ++ show s ++ ": " ++ e put $ State o (exc:es) s printT :: Output -> Eval EvalST () printT o = do st <- get let s = getCount st let e = getDebug st let os = getIOS st let out = show s ++ " - " ++ o put $ State (out:os) e s incTcounter :: Eval EvalST () incTcounter = do st <- get let s = getCount st let e = getDebug st let o = getIOS st put $ State o e (s+1) evalT :: Term -> Eval EvalST Int evalT (Con a) = do incTcounter printT (formatLine (Con a) a) return a evalT (Add t u) = do a <- evalT t b <- evalT u incTcounter let out = formatLine (Add t u) (a + b) printT out case (a+b) of 42 -> do catchT "The Ultimate Answer Has Been Computed!! Now I'm tired!" return (a+b) 11 -> stopExecT "11.... I do not like this number!" otherwise -> return (a + b) formatLine :: Term -> Int -> Output formatLine t a = "eval (" ++ show t ++ ") <= " ++ show a printAll :: [String] -> IO () printAll [] = return () printAll (a:xs) = do print a printAll xs eval :: Term -> IO () eval exp = case execStateT (evalT exp) emptyState of Fail e -> print e Done (State a b c ) -> do printAll $ reverse a print $ show $ unpackDone $ evalStateT (evalT exp) emptyState case b of [] -> print $ "Iterations: " ++ show c _ -> do printAll $ reverse b print $ "Iterations: " ++ show c {- Some runs: *MyStateT> eval (Add (Add (Add (Add (Con 40) (Con 2)) (Add (Con 12) (Con 3))) (Con 3)) (Con 10)) "1 - eval (Con 40) <= 40" "2 - eval (Con 2) <= 2" "3 - eval (Add (Con 40) (Con 2)) <= 42" "4 - eval (Con 12) <= 12" "5 - eval (Con 3) <= 3" "6 - eval (Add (Con 12) (Con 3)) <= 15" "7 - eval (Add (Add (Con 40) (Con 2)) (Add (Con 12) (Con 3))) <= 57" "8 - eval (Con 3) <= 3" "9 - eval (Add (Add (Add (Con 40) (Con 2)) (Add (Con 12) (Con 3))) (Con 3)) <= 60" "10 - eval (Con 10) <= 10" "11 - eval (Add (Add (Add (Add (Con 40) (Con 2)) (Add (Con 12) (Con 3))) (Con 3)) (Con 10)) <= 70" "70" "Debug msg at Iteration 3: The Ultimate Answer Has Been Computed!! Now I'm tired!" "Iterations: 11" *MyStateT> *MyStateT> eval (Add (Add (Add (Add (Con 10) (Con 2)) (Add (Con 12) (Con 3))) (Add (Con 5) (Con 2))) (Con 2)) "1 - eval (Con 10) <= 10" "2 - eval (Con 2) <= 2" "3 - eval (Add (Con 10) (Con 2)) <= 12" "4 - eval (Con 12) <= 12" "5 - eval (Con 3) <= 3" "6 - eval (Add (Con 12) (Con 3)) <= 15" "7 - eval (Add (Add (Con 10) (Con 2)) (Add (Con 12) (Con 3))) <= 27" "8 - eval (Con 5) <= 5" "9 - eval (Con 2) <= 2" "10 - eval (Add (Con 5) (Con 2)) <= 7" "11 - eval (Add (Add (Add (Con 10) (Con 2)) (Add (Con 12) (Con 3))) (Add (Con 5) (Con 2))) <= 34" "12 - eval (Con 2) <= 2" "13 - eval (Add (Add (Add (Add (Con 10) (Con 2)) (Add (Con 12) (Con 3))) (Add (Con 5) (Con 2))) (Con 2)) <= 36" "36" "Iterations: 13" *MyStateT> *MyStateT> eval (Add (Con 5) (Con 6)) "11.... I do not like this number!" *MyStateT> -}

2 3

Rewriting a Python application to Haskell
by basvandijk＠home.nl 02 Sep '06

02 Sep '06

Hello, The company I work for [1] develops highly sensitive trace gas detectors. We also develop software that is used to control these detectors from a PC or laptop. With this software a user can setup an experiment, execute it and analyse and visualise the data in real-time. While executing, the application gives commands to the detector and gets concentrations from the detector which it plots. See [5] for a screenshot. The application is written in Python and uses wxPython for its GUI. The software is highly threaded; The experiment executor, the analyzer, the communication system and the GUI all have their own threads. In order to synchronise these threads we make extensive use of locks [2]. This thread synchronisation mechanism worked fine in the beginning. However, as the application becomes more complex, it is increasingly difficult not to introduce bugs that are caused by forgetting to release or acquire locks. Also the use of locks makes the code hard to understand. Finally it's hard to compose functions that use locks. I've long been interested in Haskell and played around with it for some time. Recently I became aware of the Haskell STM implementation [3]. I think STM can solve my thread synchronisation problems. Because of this and because I would like to know how suitable Haskell is for developing real-world GUI applications, I would like to rewrite our application in Haskell (in my free time of course ;-) ). I think I need to use wxHaskell for the GUI because it's runs on a lot of platforms and we are currently using wxPython which should make the transition easier. 1) I would like to know if its difficult to use wxHaskell and STM side by side and if there are any issues I need to know about. 2) Also, we use pySerial [4] for serial communication with the detector. Is there something like that for Haskell or is it easy to make it yourself? 3) How portable is Haskell? We like to run our application on Mac, Windows and Linux. Greetings, Bas van Dijk [1] http://www.sensor-sense.nl [2] http://docs.python.org/lib/lock-objects.html [3] http://haskell.org/ghc/docs/latest/html/libraries/stm/Control-Concurrent-ST… [4] http://pyserial.sourceforge.net [5] http://members.home.nl/basvandijk/vc-screenshot.png

4 4

Re: [Haskell-cafe] getContents and lazy evaluation
by Donn Cave 01 Sep '06

01 Sep '06

Quoth Julien Oster <haskell(a)lists.julien-oster.de>: ... | But what happens when two processes use the same file and one process is | writing into it using lazy IO which didn't happen yet? The other process | wouldn't see its changes yet. That's actually a much more general problem, one that I imagine applies to hPutStr et al. too. Application level writes are ordinarily buffered in process space by the I/O library, so output from an ordinary C program may not appear on disk (or in kernel space disk I/O buffer) until just before the program exits. | As for two processes writing to the same file at the same time, very bad | things may happen anyway. Sure, lazy IO prevents doing communication | between running processes using plain files, but why would you do | something like that? Quite a few reasons, depending on how you define communication. You might even be tempted to use hGetContents in such cases. For example, one common way to share a file is to interlock around some resource, and when you acquire the lock, you read the file (get its contents) and release the lock. Donn Cave, donn(a)drizzle.com

1 0

Re: Exercise in point free-style
by John Hughes 01 Sep '06

01 Sep '06

> From: Julien Oster <haskell(a)lists.julien-oster.de> > Subject: [Haskell-cafe] Exercise in point free-style > > I was just doing Exercise 7.1 of Hal Daumé's very good "Yet Another > Haskell Tutorial". It consists of 5 short functions which are to be > converted into point-free style (if possible). > > It's insightful and after some thinking I've been able to come up with > solutions that make me understand things better. > > But I'm having problems with one of the functions: > > func3 f l = l ++ map f l > > Looks pretty clear and simple. However, I can't come up with a solution. > Is it even possible to remove one of the variables, f or l? If so, how? > > Thanks, > Julien Oh, YES!! Two ways to remove l: func3a f = uncurry ((.map f).(++)) . pair func3b f = uncurry (flip (++).map f) . pair And just to make sure they're right: propab new f l = func3 f l == new f l where types = f :: Int->Int quickCheck (propab func3a) quickCheck (propab func3b) If you don't mind swapping the arguments, then propc f l = func3 f l == func3c l f where types = f :: Int->Int func3c l = (l++) . (`map` l) With the arguments swapped, you can even remove both! propd f l = func3 f l == func3d l f where types = f :: Int -> Int func3d = uncurry ((.(flip map)) . (.) . (++)) . pair MUCH clearer! The trick is to observe that l is duplicated, so you need to use a combinator that duplicates something. The only one available here is pair, which you then have to combine with uncurry. It would be nicer to have (f &&& g) x = (f x,g x) available. (&&& is one of the arrow combinators). Then you could remove l by func3e f = uncurry (++) . (id &&& map f) which is sort of readable, and remove both by func3f = (uncurry (++).) . (id &&&) . map John

3 2