- Haskell-Cafe - Haskell.org

Newbie Q: composeMaybe :: (a -> Maybe b) -> (b -> Maybe c) -> (a -> Maybe c)
by Dmitri O.Kondratiev 09 Nov '06

09 Nov '06

I am trying to solve a problem from "The Craft of Functional Programming" book: 14.38 ... define the function: data Maybe a = Nothing | Just a composeMaybe :: (a -> Maybe b) -> (b -> Maybe c) -> (a -> Maybe c) using functions: squashMaybe :: Maybe (Maybe a) -> Maybe a squashMaybe (Just (Just x)) = Just x squashMaybe _ = Nothing mapMaybe :: (a -> b) -> Maybe a -> Maybe b mapMaybe f Nothing = Nothing mapMaybe f (Just x) = Just (f x) As a first step to the solution I defined auxilary function: f1 f g x = mapMaybe f (g x) GHCi gives the following type for this function: f1 :: (a -> b) -> (t -> Maybe a) -> t -> Maybe b ^^^ Q: I don't quite understand this signature. I would expect this instead (by mapMaybe definition): f1 :: (a -> b) -> (t -> Maybe a) -> Maybe b >From where does the second 't' come from? What are the arguments and what f1 returns in this case?

2 2

StateT and modify
by Peter Steiner 09 Nov '06

09 Nov '06

hi haskellers, i have a basic question regarding StateT encapsulating IO and the modify function. my scenario is similar to the following simple code snippet: > import Control.Monad.State > > type MyState = StateT Int IO > > test = evalStateT foo 0 > > foo = do > modify $ (+) 1 > get i would like to be able to debug what's happening inside the modifier function. that's why i want to be able to use a modifier that's in the IO monad, like in the following, obviously defunct snippet: > test = evalStateT bar 0 > > bar = do > modify $ myAdd 1 > get > > myAdd :: Int -> Int -> IO Int > myAdd x y = do > putStr "in myAdd\n" > return $ x + y this fails because (myAdd :: Int -> Int -> IO Int) does not match the required modify argument type (Int -> Int -> Int) for MyState. Couldn't match expected type `Int' against inferred type `IO Int' In the second argument of `($)', namely `myAdd 1' In the expression: modify $ (myAdd 1) In a 'do' expression: modify $ (myAdd 1) is it possible to 'lift' StateT modify into the inner monad (IO in my case)? regards, peter.

5 9

How to design default implementations of type class methods?
by Henning Thielemann 09 Nov '06

09 Nov '06

I like to hear some opinions about how to implement class method defaults. Let's consider the following example: I want to classify types which allow for computation of the greatest common divisor. The greatest common divisor can be computed by Euclid's algorithm in some cases (integers, univariate polynomials) but not in all cases (integer matrices, multivariate polynomials). So maybe it's a good idea to set the Euclidean algorithm as default implementation for the GCD method. Say, I have already implemented both the normal Euclidean algorithm as "euclid", which only emits the GCD, and the extended Euclidean algorithm "extendedEuclid" which also determines a and b in "gcd(x,y) = a*x + b*y" for given x and y. Now I have two choices for implementing default methods: 1. Implement a method by calling other methods of the same class. class (Units a) => PID a where extendedGCD :: a -> a -> (a,a,a) extendedGCD = extendedEuclid divMod gcd :: a -> a -> a gcd x y = let (g,_,_) = extendedGCD x y in g Advantage: User must implement only few methods, here extendedGCD, the other ones work automatically. Disadvantage: User must know, how the default methods call each other, in order to not introduce cycles. 2. Implement a method by calling custom code, preferably a public function according to http://www.haskell.org/haskellwiki/Slim_instance_declaration class (Units a) => PID a where extendedGCD :: a -> a -> (a,a,a) extendedGCD = extendedEuclid divMod gcd :: a -> a -> a gcd = euclid mod Advantages/Disadvantages are negated with respect to the first item. :-) Ok, this example class is not well chosen, because in the case of multivariate polynomials, not only extended Euclidean algorithm fails, but it is in many cases not possible to represent the GCD of x and y as a linear combination of x and y. My question is not limited to this case: I want to know, what reasons exist pro and cons each alternative. Currently I prefer the first way, because it reduces the work of implementing instances to the things that are essential for the particular type. People who want specialized and more efficient methods, must implement all methods.

3 2

Re: ANN: System.FilePath 0.10
by Ashley Yakeley 08 Nov '06

08 Nov '06

Neil Mitchell wrote: > I am hereby announcing System.FilePath 0.10, which hopefully is pretty > close to final now. This library manipulates FilePath's correctly on > both Posix and Windows. How do I manipulate a Windows file path on a POSIX machine (something relating to Samba, for instance)? -- Ashley Yakeley

2 1

Re: Fractional/negative fixity?
by Robert Dockins 08 Nov '06

08 Nov '06

On Nov 8, 2006, at 3:58 AM, apfelmus(a)quantentunnel.de wrote: > Lennart Augustsson wrote: >> >> On Nov 7, 2006, at 11:47 , >> apfelmus(a)quantentunnel.de wrote: >> >>> Henning Thielemann wrote: >>>> On Tue, 7 Nov 2006, Simon Marlow wrote: >>>> >>>>> I'd support fractional and negative fixity. It's a simple >>>>> change to >>>>> make, but we also have to adopt >> [...] >>> >>> I think that computable real fixity levels are useful, too. A >>> further >>> step to complex numbers is not advised because those cannot be >>> ordered. >> >> But ordering of the computable reals is not computable. So it could >> cause the compiler to loop during parsing. :) > > Actually, that's one of the use cases ;) A turing-complete type-checker isn't enough! Our work is not complete until the parser is a universal machine as well! > Regards, > apfelmus Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

1 0

Re: ANN: System.FilePath 0.10
by Simon Marlow 08 Nov '06

08 Nov '06

Neil Mitchell wrote: > ANNOUNCEMENT: > > I am hereby announcing System.FilePath 0.10, which hopefully is pretty > close to final now. This library manipulates FilePath's correctly on > both Posix and Windows. > > http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath > > (Includes a darcs repo, a .tar.gz, haddock documentation etc) > > In this version I have made reasonably large changes: > > * Lots of functions gone (temporary file handling, canonicalization, > drive manipulation, directory creation, directory enumeration) - > pretty much down to only pure (non-IO methods) left. > > * 3 new methods (asFile, isFile, asDirectory - look up the docs for > their meanings, but they are pretty small) > > * Renamed functions to follow the scheme replace/take/drop instead of > set/get/drop - as suggested by Simon Marlow (since set/get implies > state operations in Haskell) Looks good! I have a few small further suggestions: - remove addFileName: it does the same thing as combine, or rather the difference is subtle and not mentioned in the docs. It's subsumed by combine, anyway. - remove isDirectory. I think its presence is confusing, e.g forall x. isDirectory (takeDirectory x) == False! Also it's not really correct; "/bin/" means something subtly different to "/bin" on Unix systems. Similarly isFile, asFile, asDirectory could be removed, I think. - Use the terminology "search path" consistently for anything to do with $PATH. i.e. fileSeparator => searchPathSeparator, isFileSeparator => isSearchPathSeparator, splitFiles => splitSearchPath also, move fileSeparator, isFileSeparator into the $PATH section in the docs (or change "basic functions" to "separator predicates"). - remove splitPath: splitDirectories is enough. I'd rename it to splitPathComponents, though. - shortPath => relativeToCurrentDirectory shortPathWith => makeRelativePath Cheers, Simon

2 1

Re: Livecoding music in Haskell
by Rohan Drape 08 Nov '06

08 Nov '06

On Tue Nov 7 16:32:11 EST 2006, alex wrote: > Latency I deal with by calculating everything a second or so ahead of > time, and timestamping my OSC packets with times in the future. Then on > the other side I have some scheduling stuff to trigger sounds at the > right moment, for example in SuperCollider's sclang: A second seems excessive? Working directly with ghc <-> scsynth latencies of ~ 0.075 do not seem to be and issue with even relatively heavy scheduling loads. > response = { > arg time, responder, message; > if (message[1] == 'on', > { > SystemClock.sched(time - Date.getDate.rawSeconds, > {Synth("noisebox", > [\lgain, message[2] / 100, > \rgain, message[3] / 100, > \ts, message[4] / 100, > \browndel, message[5] / 100, > \filter, message[6], > \envtype, message[7] > ] > ); nil; > }; > ); > }); > }; > o = OSCresponder(nil, '/noise', response); > o.add; Even sclang, remarkable as it is, will need to be sending time-stamped bundles for reliable sample-accurate timing? Even to avoid perceptible jitter under high load? Regards, Rohan

2 2

Fun with Num instances of functions
by Henning Thielemann 08 Nov '06

08 Nov '06

Some people have argued, that Num instances of (->) would be nice in order to add functions nicely, say for f, g :: Num a => b -> a you would define (f+g) x = f x + g x With an according definition of fromInteger fromInteger = const numeric literals would also denote constant functions. This allows f+2 == \x -> f x + 2 . Even nicer, the mathematically established notation of omitting the multiplication dot 2(x+y) :: Integer will now be parsed by a Haskell compiler to the most obvious meaning 2 :: Integer ! :-)

1 0

Re: Fractional/negative fixity?
by Lennart Augustsson 08 Nov '06

08 Nov '06

On Nov 7, 2006, at 11:47 , apfelmus(a)quantentunnel.de wrote: > Henning Thielemann wrote: >> On Tue, 7 Nov 2006, Simon Marlow wrote: >> >>> I'd support fractional and negative fixity. It's a simple change to >>> make, but we also have to adopt >>> >>> http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/ >>> FixityResolution >>> >>> I've added the proposal to the end of that page. In fact, the page >>> already mentioned that we could generalise fixity levels, but it >>> didn't >>> mention fractional or negative values being allowed. >> >> Maybe that page could also mention earlier proposals and the >> solutions >> without precedence numbers. I prefer the non-numeric approach with >> rules >> like "(<) binds more tightly than (&&)", because it says what is >> intended >> and it allows to make things unrelated that are unrelated, e.g. infix >> operators from different libraries. Consequently a precedence >> relation to >> general infix operators like ($) and (.) had be defined in each >> library. > > I think that computable real fixity levels are useful, too. A further > step to complex numbers is not advised because those cannot be > ordered. But ordering of the computable reals is not computable. So it could cause the compiler to loop during parsing. :) -- Lennart

2 1

Livecoding music in Haskell
by dons＠cse.unsw.edu.au 07 Nov '06

07 Nov '06

Alex McLean has kindly put up a screencast of him creating *music via live coding in Haskell* ! http://doc.gold.ac.uk/~ma503am/alex/haskellmusic And a .avi version of the screencast, playable in mplayer (for those not flash inclined). http://yaxu.org/20/hs.avi The code is running in hs-plugins, and being reloaded on the fly as he edits the source, changing the rhythms that are produced. More on this on Alex's blog: http://doc.gold.ac.uk/~ma503am/alex/ Cool stuff! -- Don

4 4