From tomahawkins at gmail.com Tue Dec 1 00:44:27 2009 From: tomahawkins at gmail.com (Tom Hawkins) Date: Tue Dec 1 00:19:14 2009 Subject: [Haskell-cafe] Re: Timing and Atom In-Reply-To: <1DA71E97-3B3F-434F-8061-E2D1AE2E0C9D@gmail.com> References: <1DA71E97-3B3F-434F-8061-E2D1AE2E0C9D@gmail.com> Message-ID: <594c1e830911302144r11126fc0rdd40c9d5ffd1a42e@mail.gmail.com> On Tue, Dec 1, 2009 at 2:24 AM, Lee Pike wrote: > Tom, > > I have a (hopefully) easy question about timing and Atom in the use-case > where you're handling all your own scheduling without relying on a RTOS > (where you get preemption). ?Suppose I want a rule to fire every 2ms. > ?Naturally, I'd want to set a timer. ?But timers in Atom are based on the > __global_clock, and the rate of the __global_clock is not a constant > time-reference: it depends on the rule complexity of each rule as well as > when rules are scheduled. > > So do you try to do do a WCET analysis for Atom-generated code running > without an RTOS and tweak periods/timers based on that to get regular > timing. This is a hard problem if you have a lot of periods that are > relatively prime (I'm assuming at Eaton, this is rarely the case). In our application, the RTOS runs the Atom generated function in a foreground task at 1KHz. It turns out this is the only task the RTOS has to schedule. So in our case, __global_clock is accurate to about 1ms. We only use an RTOS because we're stuck with a poor set of development tools. This scheduling could have been easily implemented by polling a hardware counter. This has the added benefit of easily checking for execution overruns: void main() { unsigned long long nextTime = 0; while (1) { while (hardwareCounter < nextTime); nextTime = hardwareCounter + delta; atomFunction(); if (hardwareCounter > nextTime) reportExecutionOverrun(); } } If you need greater timing resolution than what is provided by the main loop, then I think the only option is to reference a hardware counter. But this will only allow you to tweak a control law or a signal processing algorithm. It won't give you execution timing guarantees. This one limitation of Atom: everything has to be scheduled as a function of a base period. The trick is to select the right period. Too course grained and computations will take too long. Too fine grained and you'll spend a lot of effort breaking up computations into several tiny rules just to meet timing. It's the same tradeoff ASIC designers have when selecting a clock rate. I never considered running Atom generated functions in an asynchronous loop until you posted your "Atomic Fibonacci Server" example (http://leepike.wordpress.com/2009/05/05/an-atomic-fibonacci-server-exploring-the-atom-haskell-dsl/). I'm curious how such a system would behave if it referenced a hardware clock to enable and disable rules. I can see how this could be problematic for hard real-time, safety critical stuff. But there is a wide field of applications where this approach would work just fine -- not having to worry about meeting a hard loop time would certainly simplify the design. Could some form of static analysis be applied to provide the timing guarantees? From atheist.diehard at yahoo.com Tue Dec 1 03:12:18 2009 From: atheist.diehard at yahoo.com (newbie2009) Date: Tue Dec 1 02:47:05 2009 Subject: [Haskell-cafe] Function composition questions from a newbie Message-ID: <26587250.post@talk.nabble.com> I am a newbie. Consider this code: square x = x * x add3 x y z = x + y + z leledumbo wrote: > > > what about (square . add3) 1 2? > > It doesn't work since add3, when curried (arguments of square "blended" > with add3's) with 1 argument becomes: > > add3 :: Num a => a -> a -> a > > which is a function that accepts 2 arguments and it's not compatible with > square's a. > Thank you so much for your clarification. To understand better, I tried some definitions 1) composition = (square . add3) 5 -- illegal as you had explained 2) composition x = (square . add3) 1 2 3 -- legal, but why? what is the significance of x 3) composition x = (square . add3) x -- legal, but why? 4) composition x y = (square . add3) x y -- legal, but why? 5) composition x = (square . add3) x 3 -- legal, but why? I dont understand why the above functions are legal, and what arguments they need. Could you please give an example of how to invoke it? -- View this message in context: http://old.nabble.com/Function-composition-questions-from-a-newbie-tp26570201p26587250.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From semanticphilosopher at googlemail.com Tue Dec 1 03:58:51 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Tue Dec 1 03:33:42 2009 Subject: [Haskell-cafe] Re: Timing and Atom In-Reply-To: <594c1e830911302144r11126fc0rdd40c9d5ffd1a42e@mail.gmail.com> References: <1DA71E97-3B3F-434F-8061-E2D1AE2E0C9D@gmail.com> <594c1e830911302144r11126fc0rdd40c9d5ffd1a42e@mail.gmail.com> Message-ID: <8C9C1B93-4717-4194-9E97-D2572F78CA11@gmail.com> On 1 Dec 2009, at 05:44, Tom Hawkins wrote: .... > I never considered running Atom generated functions in an asynchronous > loop until you posted your "Atomic Fibonacci Server" example > (http://leepike.wordpress.com/2009/05/05/an-atomic-fibonacci-server-exploring-the-atom-haskell-dsl/ > ). > I'm curious how such a system would behave if it referenced a > hardware clock to enable and disable rules. I can see how this could > be problematic for hard real-time, safety critical stuff. But there > is a wide field of applications where this approach would work just > fine -- not having to worry about meeting a hard loop time would > certainly simplify the design. Could some form of static analysis be > applied to provide the timing guarantees? Yes this is possible. I work with Stochastic Process Algebras that have these properties. With them it is possible to get strong probabilistic guarantees and, when combined with carefully chosen priority and preemption model, you can have both 'hard' (i.e response within a given time with probability 1) and softer guarantees (yet with known time CDF). The really nice property is that, given that your problem will permit it, you can even create systems that can go into saturation (arrival rate exceeds processing rate) and define how they will gracefully degrade. We use this for constructing and analysing large scale distributed systems and reasoning about, and controlling, their emergent properties including under overload and when the communications is lossy. Neil From leledumbo_cool at yahoo.co.id Tue Dec 1 04:02:28 2009 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Tue Dec 1 03:37:17 2009 Subject: [Haskell-cafe] Function composition questions from a newbie In-Reply-To: <26587250.post@talk.nabble.com> References: <26570201.post@talk.nabble.com> <26584871.post@talk.nabble.com> <26585840.post@talk.nabble.com> <26587250.post@talk.nabble.com> Message-ID: <26588093.post@talk.nabble.com> > I dont understand why the above functions are legal, and what arguments they need. Could you please > give an example of how to invoke it? Huh? None of them are legal, at least in my WinHugs they're not. What tools are you using? Some good reading I found: http://learnyouahaskell.com/higher-order-functions http://www.uni-bonn.de/~manfear/haskell-functions.php -- View this message in context: http://old.nabble.com/Function-composition-questions-from-a-newbie-tp26570201p26588093.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From atheist.diehard at yahoo.com Tue Dec 1 04:32:24 2009 From: atheist.diehard at yahoo.com (newbie2009) Date: Tue Dec 1 04:07:10 2009 Subject: [Haskell-cafe] Function composition questions from a newbie In-Reply-To: <26588093.post@talk.nabble.com> References: <26570201.post@talk.nabble.com> <26584871.post@talk.nabble.com> <26585840.post@talk.nabble.com> <26587250.post@talk.nabble.com> <26588093.post@talk.nabble.com> Message-ID: <26588106.post@talk.nabble.com> leledumbo wrote: > > None of them are legal, at least in my WinHugs they're not. What tools are > you using? > 1) I am using GHCi. I put the following into a file named composition.hs and typed ":l composition.hs" in GHCi. I also did a ":browse Main" 2) Next, I installed WinHugs, and loaded the same hs file. It failed with an error when processing the definition for composition2 3) is GHC the standard Haskell implementation or should i be using WinHugs? -----------8<----------- square x = x * x add x y = x + y add3 x y z = x + y + z composition1 = add . square -- composition1 5 6 == 31 -- composition2 = square . add -- wont work composition2 x = (square . add) x -- to make it work, make composition2 take an argument -- composition2 5 9 == 196 composition3 x y = square . (add3 x y) -- composition3 1 2 3 == 36 composition4 x y = square . add3 x y -- composition4 1 2 3 == 36 composition5 x y = (square . add3) x y -- TODO: what does this mean?? how do we invoke composition5 composition6 x = (square . add3) x -- TODO: what does this mean?? how do we invoke composition5 composition7 x = (square . add3) x 8 composition8 x = (square . add3) 1 2 x composition9 x = (square . add3) x composition10 x = (square . add3) 1 2 3 -----------8<----------- -- View this message in context: http://old.nabble.com/Function-composition-questions-from-a-newbie-tp26570201p26588106.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From apfelmus at quantentunnel.de Tue Dec 1 05:29:24 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Tue Dec 1 05:04:37 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: <1259578923.4896.85252.camel@localhost> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> Message-ID: Duncan Coutts wrote: > On Mon, 2009-11-30 at 06:08 +0000, Malcolm Wallace wrote: >> However, if you really want to terminate the stream at >> the first error, and to reflect this in the type, then I guess you can >> define your own list type: >> >> data ListThenError e a = Cons a (ListThenError e a) >> | Error e >> >> Of course this has the disadvantage that then your consumer must >> change to use this type too. > > I've been using this list type quite a lot recently. It's in the 'tar' > package for example. It comes with variants of the standard functions > foldl, foldr, unfoldr that take into account the error possibility. > > At some point we should probably make a package to standardise and > document this lazy error handling idiom. I propose to (trivially) generalize this type to "list with an end" data ListEnd a b = Cons a (ListEnd a b) | End b because it may have other uses than just lazy error handling. For mnemonic value, we could call it a "train": data Train a b = Wagon a (Train a b) | Loco b as it is in analogy with a sequence of wagons of the same type followed by the locomotive which has a different type. This data type naturally turns up as the differential of the lists d [x] = Train x [x] and the usual zipper ([x],[x]) is actually an optimization: Train a b == ([a] , b) Incidentally, this isomorphism corresponds to the alternative approach you mentioned: > Another approach that some people have advocated as a general purpose > solution is to use: > > data Exceptional e a = Exceptional { > exception :: Maybe e > result :: a > } As for other uses of Train , I remember seeing the following fold operation fold1 :: (a -> b -> b) -> (a -> b) -> [a] -> b fold1 f g [a] = g a foldl f g (a:x) = f a (fold1 f g x) (from Oege de Moor, Jeremy Gibbons. "Bridging the Algorithm Gap: A Linear-Time Functional Program for Paragraph Formatting" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.3229 ) which is of course the natural fold for the Train data type: fold :: (a -> c -> c) -> (b -> c) -> Train a b -> c fold f g (Loco b) = g b fold f g (Wagon a t) = f a (fold f g t) Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From apfelmus at quantentunnel.de Tue Dec 1 05:33:40 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Tue Dec 1 05:09:50 2009 Subject: [Haskell-cafe] Re: Help mixing pure and IO code In-Reply-To: <7ca3f0160911301953l307380f5u2f958a38d714552d@mail.gmail.com> References: <1181501691.1695221259503883865.JavaMail.root@spooler9-g27.priv.proxad.net> <4B128BD8.5020502@xiscosoft.es> <20091130225653.048927d4@free.fr> <4B145674.8010701@xiscosoft.es> <20091201014300.203da5b2@free.fr> <69630b260911301936h2804a661md893308b81d3c0ef@mail.gmail.com> <7ca3f0160911301953l307380f5u2f958a38d714552d@mail.gmail.com> Message-ID: Luke Palmer wrote: > Hector Guilarte wrote: >> >> f:: [int] -> (a,[Int]) >> f randomList = >> let (usedRandomNumber,newRandomList) = g randomList >> in (usedRandomNumber,newRandomList) > > This pattern can be encapsulated in a monad: > > newtype RandM a = RandM { unRandM :: [Int] -> (a,[Int]) } > > instance Monad RandM where > [...] > > See the similarity? > > Of course, there is no need to implement this yourself. It is already > implemented as State [Int]. And as long as you are doing that, you > might as well use Rand from the MonadRandom package. In fact, I have > argued that you should use MonadRandom instead of the lower-level > System.Random whenever possible: > http://lukepalmer.wordpress.com/2009/01/17/use-monadrandom/ The rationale being that RandM a has a natural interpretation as "random variable of type a" with no reference to how it's actually implemented. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From duncan.coutts at googlemail.com Tue Dec 1 07:22:39 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Dec 1 06:57:33 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> Message-ID: <1259670159.4896.91431.camel@localhost> On Mon, 2009-11-30 at 20:10 -0800, John Millikin wrote: > On Mon, Nov 30, 2009 at 03:02, Duncan Coutts > wrote: > >> data ListThenError e a = Cons a (ListThenError e a) > >> | Error e > >> > >> Of course this has the disadvantage that then your consumer must > >> change to use this type too. > > > > I've been using this list type quite a lot recently. It's in the 'tar' > > package for example. It comes with variants of the standard functions > > foldl, foldr, unfoldr that take into account the error possibility. > > > > At some point we should probably make a package to standardise and > > document this lazy error handling idiom. > > Wow, this is perfect! I've extracted that type out into the > "failable-list" library[1], with a few added instances for common > classes (Monad, Applicative, Traversable, etc). > > [1] http://hackage.haskell.org/package/failable-list Nice. The one I've felt is missing in the tar package was a foldl. This is used to fully consume a failable list. It wants to return either the normal foldl result or an error encountered. When consuming with a foldr, the main use case is that you're translating into another lazy data structure which has it's own place to annotate errors. When consuming with a foldl, the main use case is that you're strictly consuming the list and purging out the errors because you want to construct a type that does not have room in it for errors. There seem to be a number of possibilities though: for reference, standard list foldl: foldl :: (b -> a -> b) -> b -> [a] -> b foldl :: (b -> a -> b) -> b -> -> FailableList e a -> Either e b or the final result as Either (e, b) b foldl :: (b -> a -> b) -> b -> (b -> e -> b) -> FailableList e a -> b foldl :: (b -> a -> b) -> b -> (b -> c) -> (b -> e -> c) -> FailableList e a -> b This last one is basically the church encoding of Either (e, b) b. Do we want the partial result at the point the list ended in error? If not then it's a little simpler. Duncan From nicolas.pouillard at gmail.com Tue Dec 1 07:38:34 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue Dec 1 07:13:21 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> Message-ID: <1259671018-sup-4320@peray> Excerpts from Heinrich Apfelmus's message of Tue Dec 01 11:29:24 +0100 2009: > Duncan Coutts wrote: > > On Mon, 2009-11-30 at 06:08 +0000, Malcolm Wallace wrote: > >> However, if you really want to terminate the stream at > >> the first error, and to reflect this in the type, then I guess you can > >> define your own list type: > >> > >> data ListThenError e a = Cons a (ListThenError e a) > >> | Error e > >> > >> Of course this has the disadvantage that then your consumer must > >> change to use this type too. > > > > I've been using this list type quite a lot recently. It's in the 'tar' > > package for example. It comes with variants of the standard functions > > foldl, foldr, unfoldr that take into account the error possibility. > > > > At some point we should probably make a package to standardise and > > document this lazy error handling idiom. > > I propose to (trivially) generalize this type to "list with an end" > > data ListEnd a b = Cons a (ListEnd a b) > | End b > > because it may have other uses than just lazy error handling. For > mnemonic value, we could call it a "train": > > data Train a b = Wagon a (Train a b) > | Loco b > > as it is in analogy with a sequence of wagons of the same type followed > by the locomotive which has a different type. > > > This data type naturally turns up as the differential of the lists > > d [x] = Train x [x] > > and the usual zipper ([x],[x]) is actually an optimization: > > Train a b == ([a] , b) > > Incidentally, this isomorphism corresponds to the alternative approach > you mentioned: > > > Another approach that some people have advocated as a general purpose > > solution is to use: > > > > data Exceptional e a = Exceptional { > > exception :: Maybe e > > result :: a > > } > > > As for other uses of Train , I remember seeing the following fold operation > > fold1 :: (a -> b -> b) -> (a -> b) -> [a] -> b > fold1 f g [a] = g a > foldl f g (a:x) = f a (fold1 f g x) This proposition looks quite nice and gently subsume the ListThenError type. type ListThenError e a = Train a (Maybe e) Anyone to put this on Hackage? -- Nicolas Pouillard http://nicolaspouillard.fr From markl at glyphic.com Tue Dec 1 10:35:48 2009 From: markl at glyphic.com (Mark Lentczner) Date: Tue Dec 1 10:10:35 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> Message-ID: <9AD99613-B4B0-43FB-87F5-C8D918650A99@glyphic.com> On Dec 1, 2009, at 2:29 AM, Heinrich Apfelmus wrote: > data Train a b = Wagon a (Train a b) > | Loco b Surely that should be: data Train a b = Wagon a (Train a b) | Caboose b ? - MtnViewMark Mark Lentczner http://www.ozonehouse.com/mark/ mark@glyphic.com From daniel.is.fischer at web.de Tue Dec 1 10:48:52 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 10:25:07 2009 Subject: [Haskell-cafe] Function composition questions from a newbie In-Reply-To: <26588106.post@talk.nabble.com> References: <26570201.post@talk.nabble.com> <26588093.post@talk.nabble.com> <26588106.post@talk.nabble.com> Message-ID: <200912011648.52453.daniel.is.fischer@web.de> Am Dienstag 01 Dezember 2009 10:32:24 schrieb newbie2009: > leledumbo wrote: > > None of them are legal, at least in my WinHugs they're not. What tools > > are you using? > > 1) I am using GHCi. I put the following into a file named composition.hs > and typed ":l composition.hs" in GHCi. I also did a ":browse Main" > 2) Next, I installed WinHugs, and loaded the same hs file. It failed with > an error when processing the definition for composition2 That's because composition2 has the context (Num (a -> a), Num a), which isn't allowed by Haskell98 [A type class constraint must have the form (T a1 a2 ... an), where T is a type constructor of arity n and the ai are *distinct* type variables; so (Num (a -> b)) would be legal, but (Num (a -> a)) isn't because it uses the same type variable twice]. If you enable extensions (I don't know how to do it in WinHugs, in hugs you'd pass the flag -98 on the command line: hugs -98 composition.hs) it will work. ghci has by default a few extensions enabled, so it accepts such a context *if it infers it itself* - if you want to give such a context in a type signature, you must enable FlexibleContexts ({-# LANGUAGE FlexibleContexts #-} in the source file or -XFlexibleContexts on the command line). > 3) is GHC the standard Haskell implementation or should i be using WinHugs? Depends on for what you'll be using it. For any serious programmes, you'll need GHC to compile. And GHC implements more (seriously useful) extensions. And most code will run significantly faster in ghci than in hugs/WinHugs. But hugs/WinHugs loads the code faster. If you're working on a large project, it can be bothersome to wait for ghci to load the code again after making changes, so testing the changes in hugs/WinHugs is preferred by some (I've never worked on a project that took more than a few seconds to load in ghci, which is more than compensated by the faster execution, so I don't use hugs much). While learning Haskell, it's probably good to use hugs/WinHugs at least alongside ghci because hugs' error messages are often more newbie-friendly. > > -----------8<----------- What does ghci tell us is the type of things, and why does it tell us that? > square :: (Num a) => a -> a Obvious, isn't it? > square x = x * x add :: (Num a) => a -> a -> a That too. > add x y = x + y add3 :: (Num a) => a -> a -> a -> a And that. > add3 x y z = x + y + z composition1 :: Integer -> Integer -> Integer This - not. > composition1 = add . square Why is the type of composition1 not composition1 :: (Num a) => a -> a -> a as one would expect from the types of square, add and (.) ? Welcome to the wonderful world of "The dreaded Monomorphism Restriction". (http://haskell.org/onlinereport/decls.html#sect4.5.5 , http://www.haskell.org/haskellwiki/Monomorphism_restriction ) Indeed, (Num a) => a -> a -> a *is* the type determined by type inference. But since it is defined with neither type signature nor argument, the monomorphism restriction says the type variable a must be resolved to a plain type. By the defaulting rules, the type variable a is replaced by Integer. To give composition1 the more general type, a) give a type signature b) define it with an argument: composition1 x = (add . square) x c) pass -XNoMonomorphismRestriction to ghci on the command line (or put ":set -XNoMonomorphismRestriction" in your .ghci file). a) is good practice anyway b) is a good way if you define functions at the interactive prompt c) is especially good if you don't want to write type signatures > -- composition1 5 6 == 31 > > -- composition2 = square . add -- wont work > composition2 :: (Num (a -> a), Num a) => a -> a -> a Okay, (square . add) x = square (add x) = (add x) * (add x); If x has type a (belonging to the Num class), add x has type (a -> a), since we want to apply square to that, its type also must belong to the Num class, hence the inferred type > composition2 x = (square . add) x -- to make it work, make composition2 > take an argument Without the argument, we'd enter MR-land again, but now the constraint (Num (a -> a)) prevents the assignment of a monomorphic type (its form violates the demands of the defaulting rules, http://haskell.org/onlinereport/decls.html#sect4.3.4), so it doesn't work. Again, it would work with a type signature or with the monomorphism restriction turned off. The same (with minor modifications) applys to the "square . add3" variants. > -- composition2 5 9 == 196 > > composition3 x y = square . (add3 x y) -- composition3 1 2 3 == 36 > composition4 x y = square . add3 x y -- composition4 1 2 3 == 36 composition4 is exactly the same as composition3, function application has higher precedence than composition, so both are parsed as square . ((add3 x) y) > composition5 x y = (square . add3) x y -- TODO: what does this mean?? how > do we invoke composition5 To invoke it, we need an instance Num (a -> a -> a) for some type a belonging to Num (or for all a belonging to Num). It's possible to declare such instances, but you really shouldn't. > composition6 x = (square . add3) x -- TODO: what does this mean?? how do > we invoke composition5 > composition7 x = (square . add3) x 8 > composition8 x = (square . add3) 1 2 x > composition9 x = (square . add3) x > composition10 x = (square . add3) 1 2 3 > > -----------8<----------- I suspect that what you want are functions sqadd x y = square (x+y) sqadd3 x y z = square (x + y + z) , first apply add/add3 to the appropriate number of arguments and then square it. If that is correct, the following may help: sqadd x y = square (add x y) = square ((add x) y) = (square . (add x)) y hence sqadd x = square . add x = (.) square (add x) = ((.) square) (add x) = (((.) square) . add) x hence sqadd = ((.) square) . add or, nicer IMO, sqadd = (square .) . add Similarly, sqadd3 = ((square .) .) . add3 For each argument you want the right hand function to consume, you need one composition (.). From jfoutz at gmail.com Tue Dec 1 10:56:43 2009 From: jfoutz at gmail.com (Jason Foutz) Date: Tue Dec 1 10:31:30 2009 Subject: [Haskell-cafe] Great Programs to Read? In-Reply-To: <5f8b37690911300422i4f8787aaj96c9152b73bdd239@mail.gmail.com> References: <5f8b37690911300422i4f8787aaj96c9152b73bdd239@mail.gmail.com> Message-ID: <008074D7-AECB-4AD5-B1F1-549D18B17CD7@gmail.com> I'd suggest the Prelude and Data.List The code is very clear and thoroughly documented. Knowing what is there will pay off again and again. - Jason On Nov 30, 2009, at 5:22 AM, Michael Lesniak wrote: > Hello, > > In terms of > > "to become a great programmer, you need to read great programs"[1] > > what are "great" programs written in Haskell (for your personal > definition of great), which source code is freely available on hackage > or somewhere else on the net? > > I'm personally also interested in your definitions of great; for me, a > great programs is defined by one of > > * good and well-written documentation > (literate Haskell helps a lot) > * novel ideas to use functional programming > * elegance > * showing how functional programming can ease tasks that > are difficult to achieve in an imperative style > > Maybe we should create a Page on haskell.org (which I would do if I > had write-access) mirroring the pages [2,3]? > > Kind regards, > Michael > > [1] http://c2.com/cgi/wiki/Wiki?ReadGreatPrograms > [2] http://c2.com/cgi/wiki/Wiki?GreatProgramsToRead > [3] http://c2.com/cgi/wiki/Wiki?ProgramsToRead > > > -- > Dipl.-Inf. Michael C. Lesniak > University of Kassel > Programming Languages / Methodologies Research Group > Department of Computer Science and Electrical Engineering > > Wilhelmsh?her Allee 73 > 34121 Kassel > > Phone: +49-(0)561-804-6269 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mlesniak at uni-kassel.de Tue Dec 1 11:01:38 2009 From: mlesniak at uni-kassel.de (Michael Lesniak) Date: Tue Dec 1 10:36:23 2009 Subject: [Haskell-cafe] Great Programs to Read? In-Reply-To: <008074D7-AECB-4AD5-B1F1-549D18B17CD7@gmail.com> References: <5f8b37690911300422i4f8787aaj96c9152b73bdd239@mail.gmail.com> <008074D7-AECB-4AD5-B1F1-549D18B17CD7@gmail.com> Message-ID: <5f8b37690912010801p2b106e7etcc4e969692c841a9@mail.gmail.com> Hello, thanks for all the advices; will have enough to read for the next weeks and months! :-) - Michael -- Dipl.-Inf. Michael C. Lesniak University of Kassel Programming Languages / Methodologies Research Group Department of Computer Science and Electrical Engineering Wilhelmsh?her Allee 73 34121 Kassel Phone: +49-(0)561-804-6269 From dave at zednenem.com Tue Dec 1 11:09:29 2009 From: dave at zednenem.com (David Menendez) Date: Tue Dec 1 10:44:12 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> Message-ID: <49a77b7a0912010809y61482cf0xc5a6cbd5a9c7bee0@mail.gmail.com> On Tue, Dec 1, 2009 at 5:29 AM, Heinrich Apfelmus wrote: > Duncan Coutts wrote: >> On Mon, 2009-11-30 at 06:08 +0000, Malcolm Wallace wrote: >>> However, if you really want to terminate the stream at >>> the first error, and to reflect this in the type, then I guess you can >>> define your own list type: >>> >>> data ListThenError e a = Cons a (ListThenError e a) >>> ? ? ? ? ? ? ? ? ? ? ? ? | Error e >>> >>> Of course this has the disadvantage that then your consumer must >>> change to use this type too. >> >> I've been using this list type quite a lot recently. It's in the 'tar' >> package for example. It comes with variants of the standard functions >> foldl, foldr, unfoldr that take into account the error possibility. >> >> At some point we should probably make a package to standardise and >> document this lazy error handling idiom. > > I propose to (trivially) generalize this type to "list with an end" > > ? data ListEnd a b = Cons a (ListEnd a b) > ? ? ? ? ? ? ? ? ? ?| End b > > because it may have other uses than just lazy error handling. This is almost a composition of a non-determism monad transformer with an exception monad. Specifically, "LogicT (Either e) a" is (almost) isomorphic with data NX e a = Cons a (NX e a) | Nil | Error e reflect :: NX e a -> LogicT (Either e) a reflect (Cons a r) = return a `mplus` reflect r reflect Nil = mzero reflect (Error e) = lift (Left e) reify :: LogicT (Either e) a -> NX e a reify m = j $ runLogicT m (\a -> Right . Cons a . j) (Right Nil) where j = either Error id -- Dave Menendez From tittoassini at gmail.com Tue Dec 1 11:42:13 2009 From: tittoassini at gmail.com (Pasqualino "Titto" Assini) Date: Tue Dec 1 11:17:01 2009 Subject: [Haskell-cafe] KiCS (Curry to Haskell interpreter) problem Message-ID: <2d34474e0912010842k542109baocebedcf1baa3ba07@mail.gmail.com> Hi, I am playing around with KiCS and I have a strange problem, when I evaluate a goal the variable bindings are not displayed, I see only the value of the expression. The same expression evaluated in pakcs (another curry interpreter) displays the bindings correctly. Is this a known bug? I would have contacted the author but his email in not in the haskell cabal file. Incidentally, is anyone else using KiCS ? Any comments/remarks ? Best, titto From leepike at gmail.com Tue Dec 1 11:43:00 2009 From: leepike at gmail.com (Lee Pike) Date: Tue Dec 1 11:18:21 2009 Subject: [Haskell-cafe] Fwd: Timing and Atom References: <8038987B-24DB-48EC-868D-BA50CB79313C@gmail.com> Message-ID: [Tom -- resending my reply---I forgot to post to the list.] Neil, could you provide a reference (more on the practical side than the theory side) for the Stochastic Process Algebras you mention? And is there an embedding in Haskell? :) Lee Begin forwarded message: From: Lee Pike Date: November 30, 2009 10:14:33 PM PST To: Tom Hawkins Subject: Re: Timing and Atom Tom, Thanks a lot for the detailed reply! > If you need greater timing resolution than what is provided by the > main loop, then I think the only option is to reference a hardware > counter. Right, of course. Use a hardware counter if you're not using a RTOS. That was the quick answer I wasn't considering. :) > I never considered running Atom generated functions in an asynchronous > loop until you posted your "Atomic Fibonacci Server" example Yeah, I always think it's fun to use synchronous languages asynchronously. Usually people think of trying to implement synchrony from asynchronous languages. > But there is a wide field of applications where this approach would > work just > fine -- not having to worry about meeting a hard loop time would > certainly simplify the design. I think it's a trade-off, right? You don't worry as much about time, but you have to worry about doing synchronization using handshakes or similar protocols. I know folks who make fault-tolerant systems generally prefer synchronized systems since asynchrony gets really hard once you start considering the possibility of random faults (See, for example, or _Real-Time Systems_ by Hermann Kopetz). > Could some form of static analysis be applied to provide the timing > guarantees? Of the asynchronous system (e.g., the "Fib. server")? In something like that, it should function under any possible schedule because of the handshakes (I should model-check it to prove that). Did I misunderstand your point? Thanks again for answering my question! Lee From rodrigo.bonifacio at uol.com.br Tue Dec 1 13:00:57 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Tue Dec 1 12:35:47 2009 Subject: [Haskell-cafe] Existencial Types Message-ID: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091201/fa5184da/attachment.html From iavor.diatchki at gmail.com Tue Dec 1 13:06:14 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Dec 1 12:41:07 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: Clutterhs 0.1 In-Reply-To: <1259637160.2281.1095.camel@stacy> References: <1259468280.21437.151.camel@wanda> <20091129080918.662a91fd@gaura-nitai.no-ip.org> <1259510041.4111.10.camel@wanda> <20091130092241.74a0b23c@gaura-nitai.no-ip.org> <1259637160.2281.1095.camel@stacy> Message-ID: <5ab17e790912011006q39ed2b18o5ce879f8f5a24f00@mail.gmail.com> Hi, I work with Trevor on the other Clutter binding. We did exchange a few messages with Matt, but we were not sure how to combine the two libraries because our approaches to writing the binding were a bit different. In general, I don't think that having two similar libraries is a huge problem. I tend to do this kind of hacking for fun, and I really do not enjoy the competition that is being encouraged when we try to select "the one true library" (e.g., with efforts such as the Haskell platform). Let a thousand flowers bloom, I say :-) -Iavor On Mon, Nov 30, 2009 at 7:12 PM, Matt Arsenault wrote: > On Mon, 2009-11-30 at 09:22 +0100, Gour wrote: > >> Do you have some public repo for the project's code? > > I thought I mentioned this somewhere, but I've been using this git repo: > > http://jayne.hortont.com/git/cgit.cgi/clutterhs.git/ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dave at zednenem.com Tue Dec 1 13:21:56 2009 From: dave at zednenem.com (David Menendez) Date: Tue Dec 1 12:56:41 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> Message-ID: <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> On Tue, Dec 1, 2009 at 1:00 PM, rodrigo.bonifacio wrote: > Dear all, I wrote the following? types: > >> class Transformation t where >>? (<+>) :: t -> SPLModel? -> InstanceModel -> InstanceModel > >> data Configuration = forall t . Transformation t => Configuration >> (FeatureExpression, [t]) >> type ConfigurationKnowledge = [Configuration] > > > > I tried to write a function that retrieves the list of transformations of a > configuration. Bellow a code snip of such a function. > >> transformations ck fc = concat [snd c | (Configuration c) <- ck, eval fc >> (fst c)] > > However, compiling this I got: > > --- > Inferred type is less polymorphic than expected > Quantified type variable `t' escapes > When checking an existential match that binds > c :: (FeatureModel.Types.FeatureExpression, [t]) > The pattern(s) have type(s): Configuration > The body has type: [t] > In a stmt of a list comprehension: (Configuration c) <- ck > In the first argument of `concat', namely > `[snd c | (Configuration c) <- ck, eval fc (fst c)]' > > --- > > > > How can I fix this problem? The problem is that transformations is creating a heterogenous list, i.e., there is no guarantee that the contents of the list all have the same type. You can get around this by declaring a type representing any transformation, data SomeTransformation = forall t. Transformation t => ST t and having transformation return a list of those. However, if Transformation really only has one member function, you'd be better off eliminating the existential types entirely. e.g., data Configuration = Configuration FeatureExpression (SPLModel -> InstanceModel -> InstanceModel) -- Dave Menendez From gour at gour-nitai.com Tue Dec 1 14:02:41 2009 From: gour at gour-nitai.com (Gour) Date: Tue Dec 1 13:37:56 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: Clutterhs 0.1 References: <1259468280.21437.151.camel@wanda> <20091129080918.662a91fd@gaura-nitai.no-ip.org> <1259510041.4111.10.camel@wanda> <20091130092241.74a0b23c@gaura-nitai.no-ip.org> <1259637160.2281.1095.camel@stacy> <5ab17e790912011006q39ed2b18o5ce879f8f5a24f00@mail.gmail.com> Message-ID: <20091201200241.55a2ef3c@gaura-nitai.no-ip.org> On Tue, 1 Dec 2009 10:06:14 -0800 >>>>>> "Iavor" == Iavor Diatchki wrote: Iavor> I work with Trevor on the other Clutter binding. We did Iavor> exchange a few messages with Matt, but we were not sure how to Iavor> combine the two libraries because our approaches to writing the Iavor> binding were a bit different. OK. Iavor> In general, I don't think that having two similar libraries is a Iavor> huge problem. I tend to do this kind of hacking for fun, and I Iavor> really do not enjoy the competition that is being encouraged Iavor> when we try to select "the one true library" (e.g., with efforts Iavor> such as the Haskell platform). Let a thousand flowers bloom, I Iavor> say :-) I do not object of having choice - that's why I like Linux, but, otoh, prefer to have one fully-baked lib than several half-baked solutions which was/is problem with some Haskell packages. btw, are you interested in binding nbtk/mx toolkit for Moblin which is based on Clutter? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091201/ccdcc915/signature.bin From qdunkan at gmail.com Tue Dec 1 14:21:27 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Dec 1 13:56:11 2009 Subject: [Haskell-cafe] lazy logging (was: Are there standard idioms for lazy, pure error handling?) Message-ID: <2518b95d0912011121x5056255eue3792c9fb7aee33a@mail.gmail.com> This is only peripherally related, but I also have a lot of list functions that can possibly be an error, but usually processing can continue. So they tend to return [Either Error Result]. I have another function thus: -- A foldr version is not lazy enough and overflows the stack. partition_either [] = ([], []) partition_either (x:xs) = let (ls, rs) = partition_either xs in case x of Left l -> (l:ls, rs) Right r -> (ls, r:rs) I was a little surprised I couldn't find this in the standard library... or maybe it is? Anyway, the trick is logging the errors while incrementally processing the non-errors. Logging them first forces the whole thing. Mixing the logging in with the processing forces the processing to be in IO and is not as nice as having it separate. If the next processing step is also pure, the errors must be propagated. 'map (fmap f)' should do it, as long as the errors are all the same type. It's still not ideal because the logs happen in a bunch at the end, and are still taking up memory meanwhile. The only thing I can think of is the dreaded lazy IO... plain unsafePerformIO wouldn't work because nothing is forcing it. It would be sort of an output version of getContents, but it would have to have some magic to know when a thunk has been evaluated without forcing it. But hey, the debugger does it! And the RTS already happily logs things in the middle of pure computation, so this would just be giving programmers access to it... so it's not *so* crazy :) From daniel.is.fischer at web.de Tue Dec 1 15:00:13 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 14:36:31 2009 Subject: [Haskell-cafe] lazy logging (was: Are there standard idioms for lazy, pure error handling?) In-Reply-To: <2518b95d0912011121x5056255eue3792c9fb7aee33a@mail.gmail.com> References: <2518b95d0912011121x5056255eue3792c9fb7aee33a@mail.gmail.com> Message-ID: <200912012100.13949.daniel.is.fischer@web.de> Am Dienstag 01 Dezember 2009 20:21:27 schrieb Evan Laforge: > This is only peripherally related, but I also have a lot of list > functions that can possibly be an error, but usually processing can > continue. So they tend to return [Either Error Result]. I have > another function thus: > > -- A foldr version is not lazy enough and overflows the stack. try foldr (\e ~(ls,rs) -> case e of { Left l -> (l:ls,rs); Right r -> (ls,r:rs) }) ([],[]) with the lazy pattern, it should be lazy enough. > partition_either [] = ([], []) > partition_either (x:xs) = > let (ls, rs) = partition_either xs > in case x of > Left l -> (l:ls, rs) > Right r -> (ls, r:rs) > > I was a little surprised I couldn't find this in the standard > library... or maybe it is? Data.Either.partitionEithers Data.List.partition isLeft isLeft (Left _) = True isLeft _ = False From daniel.is.fischer at web.de Tue Dec 1 15:26:45 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 15:02:58 2009 Subject: [Haskell-cafe] lazy logging (was: Are there standard idioms for lazy, pure error handling?) In-Reply-To: <200912012100.13949.daniel.is.fischer@web.de> References: <2518b95d0912011121x5056255eue3792c9fb7aee33a@mail.gmail.com> <200912012100.13949.daniel.is.fischer@web.de> Message-ID: <200912012126.45665.daniel.is.fischer@web.de> Am Dienstag 01 Dezember 2009 21:00:13 schrieb Daniel Fischer: > Am Dienstag 01 Dezember 2009 20:21:27 schrieb Evan Laforge: > > This is only peripherally related, but I also have a lot of list > > functions that can possibly be an error, but usually processing can > > continue. So they tend to return [Either Error Result]. I have > > another function thus: > > > > -- A foldr version is not lazy enough and overflows the stack. > > try > > foldr (\e ~(ls,rs) -> case e of { Left l -> (l:ls,rs); Right r -> (ls,r:rs) > }) ([],[]) > > with the lazy pattern, it should be lazy enough. Yup. Tested now. > > > partition_either [] = ([], []) > > partition_either (x:xs) = > > let (ls, rs) = partition_either xs > > in case x of > > Left l -> (l:ls, rs) > > Right r -> (ls, r:rs) > > > > I was a little surprised I couldn't find this in the standard > > library... or maybe it is? > > Data.Either.partitionEithers And that's not lazy enough, either. Ticket: http://hackage.haskell.org/trac/ghc/ticket/3709 > > Data.List.partition isLeft > > isLeft (Left _) = True > isLeft _ = False Not quite the same. From Tom.Schrijvers at cs.kuleuven.be Tue Dec 1 16:38:14 2009 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Tue Dec 1 16:13:13 2009 Subject: [Haskell-cafe] university courses on type families/GADTs? Message-ID: Hello Haskell Cafe, I was wondering whether there are any universities that teach about Haskell type families or GADTs? Thanks, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From lrpalmer at gmail.com Tue Dec 1 16:39:17 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Dec 1 16:14:02 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> Message-ID: <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> On Tue, Dec 1, 2009 at 11:21 AM, David Menendez wrote: > On Tue, Dec 1, 2009 at 1:00 PM, rodrigo.bonifacio > wrote: >> Dear all, I wrote the following? types: >> >>> class Transformation t where >>>? (<+>) :: t -> SPLModel? -> InstanceModel -> InstanceModel >> >>> data Configuration = forall t . Transformation t => Configuration >>> (FeatureExpression, [t]) >>> type ConfigurationKnowledge = [Configuration] I would suggest doing away with the class in a case like this. data Transformation = Transformation { (<+>) :: SPLModel -> InstanceModel -> InstanceModel } data Configuration = Configuration FeatureExpression [Transformation] I suspect that it was OO heritage that led you to want a class here? Forget that! :-) Luke From seanmcl at gmail.com Tue Dec 1 17:11:42 2009 From: seanmcl at gmail.com (Sean McLaughlin) Date: Tue Dec 1 16:46:46 2009 Subject: [Haskell-cafe] module export question Message-ID: <6579f8680912011411v43b82b30ofd4dabe864dde3b4@mail.gmail.com> Say I have the following module: ---------------------------------------- module A ( T(T) , t , val ) where data T = T { t :: Int } val :: T val = T 7 ---------------------------------------- When I use A with the following imports, I don't expect this to work, but it does: import qualified A import A(T(..)) main = putStrLn $ show $ t A.val The problem is that I explicitly didn't export 't' as an element of T (by not writing T(..)). Am I just misunderstanding how exports work? I couldn't figure out what the correct behavior should be by looking at the 98 report. Sean From lrpalmer at gmail.com Tue Dec 1 17:18:44 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Dec 1 16:53:28 2009 Subject: [Haskell-cafe] module export question In-Reply-To: <6579f8680912011411v43b82b30ofd4dabe864dde3b4@mail.gmail.com> References: <6579f8680912011411v43b82b30ofd4dabe864dde3b4@mail.gmail.com> Message-ID: <7ca3f0160912011418h2616ab00ie1645ba16b670aac@mail.gmail.com> On Tue, Dec 1, 2009 at 3:11 PM, Sean McLaughlin wrote: > Say I have the following module: > > ---------------------------------------- > module A > ?( T(T) > ?, t > ?, val > ?) > where > > data T = T { t :: Int } > > val :: T > val = T 7 > ---------------------------------------- > > > When I use A with the following imports, I don't expect this to work, > but it does: > > import qualified A > import A(T(..)) > > main = putStrLn $ show $ t A.val > > The problem is that I explicitly didn't export 't' as an element of T > (by not writing T(..)). > Am I just misunderstanding how exports work? ?I couldn't figure out > what the correct > behavior should be by looking at the 98 report. Oh interesting. What a crazy corner case. I also feel like your program shouldn't be valid. Maybe it's a bug? From rmm-haskell at z.odi.ac Tue Dec 1 17:26:22 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Tue Dec 1 17:01:15 2009 Subject: [Haskell-cafe] module export question In-Reply-To: <7ca3f0160912011418h2616ab00ie1645ba16b670aac@mail.gmail.com> References: <6579f8680912011411v43b82b30ofd4dabe864dde3b4@mail.gmail.com> <7ca3f0160912011418h2616ab00ie1645ba16b670aac@mail.gmail.com> Message-ID: It looks like it is specified and the intended behavior: From the report, section 5.2: An algebraic datatype T declared by a data or newtype declaration may be named in one of three ways: The form T names the type but not the constructors or field names. The ability to export a type without its constructors allows the construction of abstract datatypes (see Section 5.8). The form T(c1,...,cn), names the type and some or all of its constructors and field names. The abbreviated form T(..) names the type and all its constructors and field names that are currently in scope (whether qualified or not). And then later similarly for imports from 5.3.1: Exactly which entities are to be imported can be specified in one of the following three ways: The imported entities can be specified explicitly by listing them in parentheses. Items in the list have the same form as those in export lists, except qualifiers are not permitted and the `module modid' entity is not permitted. When the(..) form of import is used for a type or class, the (..) refers to all of the constructors, methods, or field names exported from the module. The list must name only entities exported by the imported module. The list may be empty, in which case nothing except the instances is imported. -Ross On Dec 1, 2009, at 5:18 PM, Luke Palmer wrote: > On Tue, Dec 1, 2009 at 3:11 PM, Sean McLaughlin > wrote: >> Say I have the following module: >> >> ---------------------------------------- >> module A >> ( T(T) >> , t >> , val >> ) >> where >> >> data T = T { t :: Int } >> >> val :: T >> val = T 7 >> ---------------------------------------- >> >> >> When I use A with the following imports, I don't expect this to work, >> but it does: >> >> import qualified A >> import A(T(..)) >> >> main = putStrLn $ show $ t A.val >> >> The problem is that I explicitly didn't export 't' as an element of T >> (by not writing T(..)). >> Am I just misunderstanding how exports work? I couldn't figure out >> what the correct >> behavior should be by looking at the 98 report. > > Oh interesting. What a crazy corner case. I also feel like your > program shouldn't be valid. Maybe it's a bug? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091201/f34cb3bf/attachment.html From tzz at lifelogs.com Tue Dec 1 17:31:10 2009 From: tzz at lifelogs.com (Ted Zlatanov) Date: Tue Dec 1 17:06:10 2009 Subject: [Haskell-cafe] Re: inversion lists References: <26690.208.57.251.240.1258318451.squirrel@mail.alumni.caltech.edu> <4B048DA3.2060501@henning-thielemann.de> <87bpiz6x1n.fsf@lifelogs.com> <200911190454.13312.daniel.is.fischer@web.de> <87pr7c7uk6.fsf@lifelogs.com> Message-ID: <87bpiil429.fsf@lifelogs.com> On Fri, 20 Nov 2009 15:30:49 -0600 Ted Zlatanov wrote: TZ> A nice property of inversion lists is that inverting them simply TZ> requires removing or adding the minimum possible value at the beginning TZ> of the list. A membership test requires traversal but since the list is TZ> sorted we know when to stop if it doesn't exist. Set union and TZ> difference are pretty tricky but at least can stop early if one of two TZ> sets is finite. As I learn more Haskell I'll try implementing these TZ> step by step. Is there any interest in making this an actual module or TZ> is it not very useful in the context of Haskell? OK, here's my current state. The first two functions are not mine, of course (the original invlist' was called h, that's all). invlist_negate just appends 0 or removes it. I think the first condition (on an empty list) is not necessary. Should I keep it for clarity? For invlist_member I basically pass the current state down into the recursion chain on invlist_member'. The function will end early if it can, or it will scan all the way down the list in the worst case (when the goal value is greater than the last interval marker). I think I could do it with a foldl but I wasn't able to figure it out. Any suggestions are welcome. I can definitely reimplement the invlist function similarly to invlist_member, by passing an exclusion state boolean down, which will make the code longer. I'm not sure if it will be bad for performance. I think it will be better because I'll be able to do it lazily as opposed to the foldr below which needs a finite list. Can I do it with a direct foldl instead? I need to look at it carefully but maybe someone has a suggestion. I plan to do set operations after I get the basics right :) This should really have been in comp.lang.haskell.beginner. Sorry for the elementary stuff, I'm keeping the thread in c.l.h.cafe only to avoid double postings at this point. Thanks Ted invlist' :: Num a => a -> [a] -> [a] invlist' x (y:ys) | x+1 == y = x:ys invlist' x zs = x:(x+1):zs invlist = foldr invlist' [] invlist_negate [] = [0] invlist_negate (0:xs) = xs invlist_negate xs = 0:xs invlist_member _ [] = False -- bootstrap membership test with a False exclusion state (an inversion list begins with the first included value) invlist_member goal (x:xs) = invlist_member' goal False (x:xs) invlist_member' goal exclude (x:xs) = if goal < x then exclude else invlist_member' goal (not exclude) xs -- flip the exclusion state of the list invlist_member' _ exclude _ = exclude -- if we can't match one more element, return the current exclusion state From ross at soi.city.ac.uk Tue Dec 1 17:34:31 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Dec 1 17:09:20 2009 Subject: [Haskell-cafe] module export question In-Reply-To: <6579f8680912011411v43b82b30ofd4dabe864dde3b4@mail.gmail.com> References: <6579f8680912011411v43b82b30ofd4dabe864dde3b4@mail.gmail.com> Message-ID: <20091201223431.GA26650@soi.city.ac.uk> On Tue, Dec 01, 2009 at 05:11:42PM -0500, Sean McLaughlin wrote: > The problem is that I explicitly didn't export 't' as an element of T > (by not writing T(..)). > Am I just misunderstanding how exports work? I couldn't figure out > what the correct behavior should be by looking at the 98 report. Exports (and imports) merely enumerate names, not their relationships, so the original export is equivalent to T(T, t) or T(..). From jeremy at goop.org Tue Dec 1 17:34:46 2009 From: jeremy at goop.org (Jeremy Fitzhardinge) Date: Tue Dec 1 17:09:40 2009 Subject: [Haskell-cafe] Trying to sort out multiparameter type classes and their instances Message-ID: <4B159A06.4020404@goop.org> I'm playing around with some types to represent a game board (like Go, Chess, Scrabble, etc). I'm using a type class to represent the basic Board interface, so I can change the implementation freely: class Board b pos piece where -- Update board with piece played at pos play :: b pos piece -> pos -> piece -> b pos piece -- Query pos to get piece (Nothing if off board) at :: b pos piece -> pos -> Maybe piece -- Empty board empty :: b pos piece and a Position on the board is represented thus: class Position p where up :: p -> p down :: p -> p left :: p -> p right :: p -> p With a concrete implementation using a tuple: instance (Enum c,Enum r) => Position (c,r) where up = second pred down = second succ left = first pred right = first succ My initial Board is a function: position -> Maybe piece, but I'm having a hard time writing the instance for it. My first attempt is: instance Board (pos -> Maybe piece) pos piece where empty = \_ -> Nothing at = ($) play b pos piece = move where move pos' | pos' == pos = Just piece | otherwise = b pos' but ghci complains: board.hs:34:15: Kind mis-match Expected kind `* -> * -> *', but `pos -> Maybe piece' has kind `*' In the instance declaration for `Board (pos -> Maybe piece) pos piece' Playing around with parentheses on the instance line got various similar messages, but I couldn't get anything to work. What am I missing here? One thing that strikes me is that "Board (pos -> Maybe piece) pos piece" has a lot of redundancy, and I'm wondering if I'm defining the Board type class wrong in the first place. Given that the "b" type parameter necessarily defines the position and pieces, I tried using dependent types: class Board b | b -> pos, b -> piece where ... but this complains "Not in scope: type variable `pos'/`piece'", so I tried sprinkling some existential types around as well: class (forall pos piece. b pos piece) => Board b | b -> pos, b -> piece where ... (with and without the dependent types) but this just complains "malformed class assertion". As you can probably tell, I'm just thrashing around trying things without really understanding what's going on here, so I'm hoping someone can give me some useful pointers. J From lemming at henning-thielemann.de Tue Dec 1 17:52:49 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Dec 1 17:27:37 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: NoSlow - Microbenchmarks for array libraries In-Reply-To: References: Message-ID: On Fri, 27 Nov 2009, Henning Thielemann wrote: > On Fri, 27 Nov 2009, Roman Leshchinskiy wrote: > >> You can get more information (including the ugly tables) from my blog >> >> http://unlines.wordpress.com/2009/11/27/noslow > > Btw. storablevector supports 'zip' using > http://hackage.haskell.org/package/storable-tuple > but you may also use 'zipWith' with an atomar result type for testing. However, I have noticed that the instances in storable-tuple are not quite efficient. They are implemented with storable-record, which is elegant, but apparently too hard to compile efficiently for GHC. Storable-record computes the offsets for members of a record automatically according to their aligment constraints. But GHC seems not to realize, that the offsets are constants. From daniel.is.fischer at web.de Tue Dec 1 18:12:44 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 17:48:57 2009 Subject: [Haskell-cafe] Trying to sort out multiparameter type classes and their instances In-Reply-To: <4B159A06.4020404@goop.org> References: <4B159A06.4020404@goop.org> Message-ID: <200912020012.44889.daniel.is.fischer@web.de> Am Dienstag 01 Dezember 2009 23:34:46 schrieb Jeremy Fitzhardinge: > I'm playing around with some types to represent a game board (like Go, > Chess, Scrabble, etc). > > I'm using a type class to represent the basic Board interface, so I can > change the implementation freely: > > class Board b pos piece where > -- Update board with piece played at pos > play :: b pos piece -> pos -> piece -> b pos piece So the parameter b of the class is a type constructor taking two types and constructing a type from those. IOW, it's a type constructor of kind (* -> * -> *), like (->) or Either. (* is the kind of types [Int, Char, Either Bool (), Double -> Rational -> Int, ...] > -- Query pos to get piece (Nothing if off board) > at :: b pos piece -> pos -> Maybe piece > -- Empty board > empty :: b pos piece > > and a Position on the board is represented thus: > > class Position p where > up :: p -> p > down :: p -> p > left :: p -> p > right :: p -> p > > With a concrete implementation using a tuple: > > instance (Enum c,Enum r) => Position (c,r) where > up = second pred > down = second succ > left = first pred > right = first succ > > > My initial Board is a function: position -> Maybe piece, but I'm having > a hard time writing the instance for it. My first attempt is: > > instance Board (pos -> Maybe piece) pos piece where > empty = \_ -> Nothing > at = ($) > play b pos piece = move > where move pos' | pos' == pos = Just piece > > | otherwise = b pos' > > but ghci complains: > board.hs:34:15: > Kind mis-match > Expected kind `* -> * -> *', but `pos -> Maybe piece' has kind `*' > In the instance declaration for `Board (pos > -> Maybe piece) pos piece' > Yes, as said above. (pos -> Maybe piece) is a *type*, but the type class expects a type constructor of kind (* -> * ->*) here. > > Playing around with parentheses on the instance line got various similar > messages, but I couldn't get anything to work. > > What am I missing here? > > One thing that strikes me is that "Board (pos -> Maybe piece) pos piece" > has a lot of redundancy, and I'm wondering if I'm defining the Board > type class wrong in the first place. > > Given that the "b" type parameter necessarily defines the position and > pieces, I tried using dependent types: > > class Board b | b -> pos, b -> piece where ... Method 1: The class above, with a modified instance. newtype Brd pos piec = Brd { mpiece :: pos -> Maybe piece } instance (Eq pos) => Board Brd pos piece where play b pos piece = Brd $ \p -> if p == pos then Just piece else mpiece b pos ... Perhaps not truly satisfying. Method 2: Multiparameter type class with functional dependencies and suitable kinds class Board b pos piece | b -> pos, b -> piece where play :: b -> pos -> piece -> b at :: b -> pos -> Maybe piece empty :: b instance (Eq pos) => Board (pos -> Maybe piece) pos piece where play b pos piece = \p -> if p == pos then Just piece else b p at = id empty = const Nothing requires {-# LANGUAGE FlexibleInstances #-} Not necessarily ideal either. Method 3: Associated type families {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module Board where class Board b where type Pos b :: * type Piece b :: * play :: b -> Pos b -> Piece b -> b at :: b -> Pos b -> Maybe (Piece b) empty :: b instance (Eq pos) => Board (pos -> Maybe piece) where type Pos (pos -> Maybe piece) = pos type Piece (pos -> Maybe piece) = piece play b pos piece = \p -> if p == pos then Just piece else b p at b p = b p empty _ = Nothing I would try that first. Choose your pick. From sjoerd at w3future.com Tue Dec 1 18:14:58 2009 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Tue Dec 1 17:49:45 2009 Subject: [Haskell-cafe] Re: inversion lists In-Reply-To: <87bpiil429.fsf@lifelogs.com> References: <26690.208.57.251.240.1258318451.squirrel@mail.alumni.caltech.edu> <4B048DA3.2060501@henning-thielemann.de> <87bpiz6x1n.fsf@lifelogs.com> <200911190454.13312.daniel.is.fischer@web.de> <87pr7c7uk6.fsf@lifelogs.com> <87bpiil429.fsf@lifelogs.com> Message-ID: <23727FE6-D6A7-4107-A256-58B4B0BD4FAF@w3future.com> Hi Ted, Some tips: > invlist_negate [] = [0] > invlist_negate (0:xs) = xs > invlist_negate xs = 0:xs You are doing this for generic Num instances, so 0 probably isn't the lower bound. Haskell has another type class for this: Bounded. Then you can use minBound instead of 0. Also the first line is just a special case of the last one. invlist_negate :: (Bounded a, Num a) => [a] -> [a] invlist_negate (minBound : xs) = xs invlist_negate xs = minBound : xs Try doing invlist_member together with a function invlist_notMember (just like there is notElem for lists), I think that would clean things up a bit. Keep on going, there's lots of fun ahead! greetings, Sjoerd -- Sjoerd Visscher sjoerd@w3future.com From rodrigo.bonifacio at uol.com.br Tue Dec 1 18:21:32 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Tue Dec 1 17:56:29 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> Message-ID: <4b15a4fc38367_453e4f293e856a@weasel6.tmail> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091201/0cf54aed/attachment.html From pumpkingod at gmail.com Tue Dec 1 18:24:51 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Tue Dec 1 17:59:36 2009 Subject: [Haskell-cafe] Re: inversion lists In-Reply-To: <23727FE6-D6A7-4107-A256-58B4B0BD4FAF@w3future.com> References: <26690.208.57.251.240.1258318451.squirrel@mail.alumni.caltech.edu> <4B048DA3.2060501@henning-thielemann.de> <87bpiz6x1n.fsf@lifelogs.com> <200911190454.13312.daniel.is.fischer@web.de> <87pr7c7uk6.fsf@lifelogs.com> <87bpiil429.fsf@lifelogs.com> <23727FE6-D6A7-4107-A256-58B4B0BD4FAF@w3future.com> Message-ID: You probably don't want that minBound in the pattern, but rather as a comparison in a guard. Dan On Tue, Dec 1, 2009 at 6:14 PM, Sjoerd Visscher wrote: > Hi Ted, > > Some tips: >> invlist_negate [] = [0] >> invlist_negate (0:xs) = xs >> invlist_negate xs = 0:xs > > You are doing this for generic Num instances, so 0 probably isn't the lower bound. Haskell has another type class for this: Bounded. Then you can use minBound instead of 0. Also the first line is just a special case of the last one. > > invlist_negate :: (Bounded a, Num a) => [a] -> [a] > invlist_negate (minBound : xs) = xs > invlist_negate xs = minBound : xs > > Try doing invlist_member together with a function invlist_notMember (just like there is notElem for lists), I think that would clean things up a bit. > > Keep on going, there's lots of fun ahead! > > greetings, > Sjoerd > > -- > Sjoerd Visscher > sjoerd@w3future.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From daniel.is.fischer at web.de Tue Dec 1 19:12:23 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 18:48:48 2009 Subject: [Haskell-cafe] Re: inversion lists In-Reply-To: <87bpiil429.fsf@lifelogs.com> References: <26690.208.57.251.240.1258318451.squirrel@mail.alumni.caltech.edu> <87pr7c7uk6.fsf@lifelogs.com> <87bpiil429.fsf@lifelogs.com> Message-ID: <200912020112.23886.daniel.is.fischer@web.de> Am Dienstag 01 Dezember 2009 23:31:10 schrieb Ted Zlatanov: > On Fri, 20 Nov 2009 15:30:49 -0600 Ted Zlatanov wrote: > > TZ> A nice property of inversion lists is that inverting them simply > TZ> requires removing or adding the minimum possible value at the beginning > TZ> of the list. A membership test requires traversal but since the list > is TZ> sorted we know when to stop if it doesn't exist. Set union and TZ> > difference are pretty tricky but at least can stop early if one of two TZ> > sets is finite. As I learn more Haskell I'll try implementing these TZ> > step by step. Is there any interest in making this an actual module or TZ> > is it not very useful in the context of Haskell? > > OK, here's my current state. The first two functions are not mine, of > course (the original invlist' was called h, that's all). > > invlist_negate just appends 0 or removes it. I think the first > condition (on an empty list) is not necessary. Should I keep it for > clarity? I don't think it's necessary. As Sjoerd mentioned, the use of 0 is problematic. > > For invlist_member I basically pass the current state down into the > recursion chain on invlist_member'. The function will end early if it > can, or it will scan all the way down the list in the worst case (when > the goal value is greater than the last interval marker). I think I > could do it with a foldl but I wasn't able to figure it out. > > Any suggestions are welcome. I can definitely reimplement the invlist > function similarly to invlist_member, by passing an exclusion state > boolean down, which will make the code longer. I'm not sure if it will > be bad for performance. I think it will be better because I'll be able > to do it lazily as opposed to the foldr below which needs a finite list. No, quite the opposite. foldr is wonderful for lazy list processing. I just need to make my function a wee bit lazier: Prelude> let h x zs = x:case zs of { (y:ys) | x+1 == y -> ys; _ -> (x+1):zs; } Prelude> let invlist xs = foldr h [] xs Prelude> invlist [1,2,3,7,8,12,13,14,20] [1,4,7,9,12,15,20,21] Prelude> take 10 $ invlist [2,5 .. ] [2,3,5,6,8,9,11,12,14,15] Prelude> take 10 $ invlist [2,4 .. ] [2,3,4,5,6,7,8,9,10,11] Prelude> take 10 $ invlist [2 .. ] [2^CInterrupted. Prelude> take 10 $ invlist [2 :: Data.Int.Int16 .. ] [2,-32768] -- That's a problem here Hadn't thought about infinite (or even long) lists when I wrote it. > Can I do it with a direct foldl instead? No, foldl cannot produce anything before the whole list has been traversed, so it can't deal with infinite lists at all. > I need to look at it > carefully but maybe someone has a suggestion. > > I plan to do set operations after I get the basics right :) > > This should really have been in comp.lang.haskell.beginner. Sorry for > the elementary stuff, I'm keeping the thread in c.l.h.cafe only to avoid > double postings at this point. > > Thanks > Ted > > invlist' :: Num a => a -> [a] -> [a] > invlist' x (y:ys) > > | x+1 == y = x:ys > > invlist' x zs = x:(x+1):zs invlist' :: Integral a => a -> [a] -> [a] invlist' x zs = x:ws where ws = case zs of (y:ys) | x+1 == y -> ys _ -> (x+1):zs -- we could use Num here, but for an implementation of sets via inversion lists, -- Integral is the appropriate setting. Perhaps even better use Integral and Bounded invlist' :: (Integral a, Bounded a) => a -> [a] -> [a] invlist' x _ | x == maxBound = [x] invlist' x zs = x:ws where ws = case zs of (y:ys) | x+1 == y -> ys _ -> (x+1):zs Now: Prelude> invlist [2 :: Data.Int.Int8 .. ] [2] :D > Don't forget a type signature here. Otherwise you'll get bitten by the monomorphism restriction. invlist :: (Integral a, Bounded a) => [a] -> [a] > invlist = foldr invlist' [] > Problem. That is only sensible if we only consider sets of nonnegative numbers. For Integral and Bounded, invlist_negate (x:xs) | x == minBound = xs invlist_negate xs = minBound:xs > invlist_negate [] = [0] > invlist_negate (0:xs) = xs > invlist_negate xs = 0:xs > > invlist_member _ [] = False > > -- bootstrap membership test with a False exclusion state (an inversion > list begins with the first included value) invlist_member goal (x:xs) = > invlist_member' goal False (x:xs) > > invlist_member' goal exclude (x:xs) = > if goal < x then > exclude > else > invlist_member' goal (not exclude) xs -- flip the exclusion state > of the list > > invlist_member' _ exclude _ = exclude -- if we can't match one more > element, return the current exclusion state invlist_member :: (Integral a, Bounded a) => a -> [a] -> Bool invlist_member goal = foldr (\n b -> if goal < n then False else not b) False *maybe* I'll think about unions, intersections and other set operations as foldr's. From iavor.diatchki at gmail.com Tue Dec 1 19:40:24 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Dec 1 19:15:10 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: Clutterhs 0.1 In-Reply-To: <20091201200241.55a2ef3c@gaura-nitai.no-ip.org> References: <1259468280.21437.151.camel@wanda> <20091129080918.662a91fd@gaura-nitai.no-ip.org> <1259510041.4111.10.camel@wanda> <20091130092241.74a0b23c@gaura-nitai.no-ip.org> <1259637160.2281.1095.camel@stacy> <5ab17e790912011006q39ed2b18o5ce879f8f5a24f00@mail.gmail.com> <20091201200241.55a2ef3c@gaura-nitai.no-ip.org> Message-ID: <5ab17e790912011640x26131e17t828fe35c6606edc@mail.gmail.com> Hi On Tue, Dec 1, 2009 at 11:02 AM, Gour wrote: > Iavor> In general, I don't think that having two similar libraries is a > Iavor> huge problem. ?I tend to do this kind of hacking for fun, and I > Iavor> really do not enjoy the competition that is being encouraged > Iavor> when we try to select "the one true library" (e.g., with efforts > Iavor> such as the Haskell platform). ?Let a thousand flowers bloom, I > Iavor> say :-) > > I do not object of having choice - that's why I like Linux, but, otoh, > prefer to have one fully-baked lib than several half-baked solutions > which was/is problem with some Haskell packages. We are baking ;) > btw, are you interested in binding nbtk/mx toolkit for Moblin which is > based on Clutter? I am not that familiar with it, but it might be interesting to have some Clutter based widgets for GUIs. -Iavor From jeremy at goop.org Tue Dec 1 19:43:04 2009 From: jeremy at goop.org (Jeremy Fitzhardinge) Date: Tue Dec 1 19:17:53 2009 Subject: [Haskell-cafe] Trying to sort out multiparameter type classes and their instances In-Reply-To: <200912020012.44889.daniel.is.fischer@web.de> References: <4B159A06.4020404@goop.org> <200912020012.44889.daniel.is.fischer@web.de> Message-ID: <4B15B818.4040207@goop.org> On 12/01/09 15:12, Daniel Fischer wrote: > Am Dienstag 01 Dezember 2009 23:34:46 schrieb Jeremy Fitzhardinge: > >> I'm playing around with some types to represent a game board (like Go, >> Chess, Scrabble, etc). >> >> I'm using a type class to represent the basic Board interface, so I can >> change the implementation freely: >> >> class Board b pos piece where >> -- Update board with piece played at pos >> play :: b pos piece -> pos -> piece -> b pos piece >> > So the parameter b of the class is a type constructor taking two types and constructing a > type from those. > Yep. > IOW, it's a type constructor of kind (* -> * -> *), like (->) or Either. > (* is the kind of types [Int, Char, Either Bool (), Double -> Rational -> Int, ...] > > [...] > >> but ghci complains: >> board.hs:34:15: >> Kind mis-match >> Expected kind `* -> * -> *', but `pos -> Maybe piece' has kind `*' >> In the instance declaration for `Board (pos >> -> Maybe piece) pos piece' >> >> > Yes, as said above. > (pos -> Maybe piece) is a *type*, but the type class expects a type constructor of kind > (* -> * ->*) here. > I thought "(pos -> Maybe piece) pos piece" would provide the 3 type arguments to Board. Oh, I see my mistake. I was seeing "b pos piece" as type parameters for Board, but actually Board is just taking a single parameter of kind * -> * -> *. > Method 2: Multiparameter type class with functional dependencies and suitable kinds > > class Board b pos piece | b -> pos, b -> piece where > play :: b -> pos -> piece -> b > at :: b -> pos -> Maybe piece > empty :: b > > instance (Eq pos) => Board (pos -> Maybe piece) pos piece where > play b pos piece = \p -> if p == pos then Just piece else b p > at = id > empty = const Nothing > > requires {-# LANGUAGE FlexibleInstances #-} > > Not necessarily ideal either. > OK, but that's pretty much precisely what I was aiming for. I'm not sure I understand what the difference between play :: b pos piece -> pos -> piece -> b pos piece and play :: b -> pos -> piece -> b is. Does adding type params to b here change its kind? > Method 3: Associated type families > > {-# LANGUAGE TypeFamilies, FlexibleInstances #-} > module Board where > > class Board b where > type Pos b :: * > type Piece b :: * > play :: b -> Pos b -> Piece b -> b > at :: b -> Pos b -> Maybe (Piece b) > empty :: b > > instance (Eq pos) => Board (pos -> Maybe piece) where > type Pos (pos -> Maybe piece) = pos > type Piece (pos -> Maybe piece) = piece > play b pos piece = \p -> if p == pos then Just piece else b p > at b p = b p > empty _ = Nothing > > I would try that first. > OK, there's some new stuff there I'm going to have to digest... Thanks very much, J From ryani.spam at gmail.com Tue Dec 1 19:43:13 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Dec 1 19:18:00 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <4b15a4fc38367_453e4f293e856a@weasel6.tmail> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> <4b15a4fc38367_453e4f293e856a@weasel6.tmail> Message-ID: <2f9b2d30912011643l4cc719e5l2fddf8cb4f2e2218@mail.gmail.com> newtype Transformation = Transformation { (<+>) :: SPLModel -> InstanceModel -> InstanceModel } data SelectScenarios = SelectScenarios { scIds :: [Id] } scenarioTransform scenario = Transformation $ \spl inst -> something testScenario = SelectScenarios [] test = scenarioTransform testScenario <+> undefined Don't use typeclasses unless you really need to. Higher-order functions are usually what you want. -- ryan On Tue, Dec 1, 2009 at 3:21 PM, rodrigo.bonifacio wrote: > Thanks Luke. > > In fact I, will have different implementations of the Transformation type. > Something like: > > data SelectScenarios = SelectScenarios { > > scIds :: [Id] > > } > > > > And then I should be able to make SelectScenarios a kind of Transformation. > So I think that I really need a class. What do you think about it? > > instance Transformation SelectScenario where > > (<+>)? .... > > > > Regards, > > Rodrigo. > > > > > > > > > > > > Em 01/12/2009 19:39, Luke Palmer < lrpalmer@gmail.com > escreveu: > > On Tue, Dec 1, 2009 at 11:21 AM, David Menendez wrote: >> On Tue, Dec 1, 2009 at 1:00 PM, rodrigo.bonifacio >> wrote: >>> Dear all, I wrote the following? types: >>> >>>> class Transformation t where >>>>? (<+>) :: t -> SPLModel? -> InstanceModel -> InstanceModel >>> >>>> data Configuration = forall t . Transformation t => Configuration >>>> (FeatureExpression, [t]) >>>> type ConfigurationKnowledge = [Configuration] > > I would suggest doing away with the class in a case like this. > > data Transformation = Transformation { > (<+>) :: SPLModel -> InstanceModel -> InstanceModel > } > > data Configuration = Configuration FeatureExpression [Transformation] > > I suspect that it was OO heritage that l ed you to want a class here? > Forget that! :-) > > Luke > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lrpalmer at gmail.com Tue Dec 1 19:44:25 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Dec 1 19:19:08 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <4b15a4fc38367_453e4f293e856a@weasel6.tmail> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> <4b15a4fc38367_453e4f293e856a@weasel6.tmail> Message-ID: <7ca3f0160912011644k4badf367s96fb02f47ed49ae4@mail.gmail.com> On Tue, Dec 1, 2009 at 4:21 PM, rodrigo.bonifacio wrote: > Thanks Luke. > > In fact I, will have different implementations of the Transformation type. > Something like: > > data SelectScenarios = SelectScenarios { > > scIds :: [Id] > > } What is this different type buying you? You can never "downcast" to it later. > And then I should be able to make SelectScenarios a kind of Transformation. > So I think that I really need a class. What do you think about it? > > instance Transformation SelectScenario where > > (<+>)? .... So instead of making a type and an instance, just implement it directly as a Transformation: selectScenario :: [Id] -> Transformation selectScenario ids = Transformation { (<+>) = {- whatever implementation you gave for (<+>) above, using ids -} } If the only purpose of SelectScenario (your type) is to be used polymorphically as a Transformation, then this approach is isomorphic -- i.e. anything you can do with the existential type trick you can do with this approach. If SelectScecario is used for other purposes, then give an explicit cast function toTransformation :: SelectScenario -> Transformation toTransformation (SelectScenario ids) = Transformation { (<+>) = {- implementation of (<+>) just as if it were a class method -} } Existential types only buy you power when the quantified variable appears more than once on the right hand side, for example: forall a. Num a => (a,a). But even those can usually be factored out into more direct representations (I seem to recall Oleg has a proof that they always can, actually). Luke From mpm at alumni.caltech.edu Tue Dec 1 20:01:29 2009 From: mpm at alumni.caltech.edu (Michael P Mossey) Date: Tue Dec 1 19:36:39 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track Message-ID: <4B15BC69.1020101@alumni.caltech.edu> Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way. I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong. To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy. In this one example, in a OO way of thinking, I have data called AssignedNumbers that assigns integers to unique strings and keeps track of the used integers and next available integer (the choice of available integer could follow a number of conventions so I wanted to hide that in an ADT.) So it has an associated function: getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) What getNumber does is: - check if the string already has a number assigned to it. If so, return that number. - if not, pick the next available number. - in all cases, return the possibly changed state of AssignedNumbers Then in a larger data structure, it contains fields of type AssignedNumbers. Like data MusicStuff = MusicStuff { oscillatorNumbers :: AssignedNumbers , tableNumbers :: AssignedNumbers , ... } I'm using MusicStuff in a State monad, so I might write a function like doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) doSomeMusicStuff aString1 aString2 = do ms <- get (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) (t1,newTabNums) = getNumber aString2 (tableNumbers ms) put ms { oscillatorNumbers = newOscNums , tableNumbers = newTabNums } return (o1,t1) For what it does, this is extremely verbose and filled with distracting visual content. And this is just a very simple example---my real problem is several times more state-ful. Is there a better way? Note that in Python it would be a method def doMusicStuff( self, s1, s2 ) : return (self.oscillatorNumbers.next(s1), self.oscillatorNumbers.next(s2)) From anandc at mcmaster.ca Tue Dec 1 20:10:08 2009 From: anandc at mcmaster.ca (Christopher Anand) Date: Tue Dec 1 19:45:15 2009 Subject: [Haskell-cafe] university courses on type families/GADTs? In-Reply-To: References: Message-ID: I think these topics have been covered in http://www.cas.mcmaster.ca/~kahl/FP/2009/ Christopher On Tue, 1 Dec 2009 22:38:14 +0100 (CET) Tom Schrijvers wrote: > Hello Haskell Cafe, > > I was wondering whether there are any universities that teach about > Haskell type families or GADTs? > > Thanks, > > Tom > > -- > Tom Schrijvers > > Department of Computer Science > K.U. Leuven > Celestijnenlaan 200A > B-3001 Heverlee > Belgium > > tel: +32 16 327544 > e-mail: tom.schrijvers@cs.kuleuven.be > url: http://www.cs.kuleuven.be/~toms/ > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From caseyh at istar.ca Tue Dec 1 20:22:56 2009 From: caseyh at istar.ca (Casey Hawthorne) Date: Tue Dec 1 19:57:47 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15BC69.1020101@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: Please check out Paul Hudak's page. http://cs-www.cs.yale.edu/homes/hudak-paul/ On Tue, 01 Dec 2009 17:01:29 -0800, you wrote: >Perhaps someone could either (1) help me do what I'm trying to do, or (2) show >me a better way. > >I have a problem that is very state-ful and I keep thinking of it as OO, which >is driving me crazy. Haskell is several times harder to use than Python in this >instance, probably because I'm doing it wrong. > >To give you a larger context, this problem is essentially compiling a >description of music (my own) into a kind of music-machine-language (CSound). >CSound is relatively untidy. > >In this one example, in a OO way of thinking, I have data called AssignedNumbers >that assigns integers to unique strings and keeps track of the used integers and >next available integer (the choice of available integer could follow a number of >conventions so I wanted to hide that in an ADT.) So it has an associated function: > >getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) > >What getNumber does is: > > - check if the string already has a number assigned to it. If so, return that >number. > > - if not, pick the next available number. > > - in all cases, return the possibly changed state of AssignedNumbers > >Then in a larger data structure, it contains fields of type AssignedNumbers. Like > >data MusicStuff = MusicStuff > { oscillatorNumbers :: AssignedNumbers > , tableNumbers :: AssignedNumbers > , ... } > >I'm using MusicStuff in a State monad, so I might write a function like > >doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) >doSomeMusicStuff aString1 aString2 = do > ms <- get > (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) > (t1,newTabNums) = getNumber aString2 (tableNumbers ms) > put ms { oscillatorNumbers = newOscNums > , tableNumbers = newTabNums } > return (o1,t1) > >For what it does, this is extremely verbose and filled with distracting visual >content. And this is just a very simple example---my real problem is several >times more state-ful. Is there a better way? > >Note that in Python it would be a method > >def doMusicStuff( self, s1, s2 ) : > return (self.oscillatorNumbers.next(s1), self.oscillatorNumbers.next(s2)) > > > > > > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Casey From daniel.is.fischer at web.de Tue Dec 1 20:38:33 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 20:15:23 2009 Subject: [Haskell-cafe] Trying to sort out multiparameter type classes =?utf-8?q?and=09their?= instances In-Reply-To: <4B15B818.4040207@goop.org> References: <4B159A06.4020404@goop.org> <200912020012.44889.daniel.is.fischer@web.de> <4B15B818.4040207@goop.org> Message-ID: <200912020238.33474.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 01:43:04 schrieb Jeremy Fitzhardinge: > On 12/01/09 15:12, Daniel Fischer wrote: > > Am Dienstag 01 Dezember 2009 23:34:46 schrieb Jeremy Fitzhardinge: > >> I'm playing around with some types to represent a game board (like Go, > >> Chess, Scrabble, etc). > >> > >> I'm using a type class to represent the basic Board interface, so I can > >> change the implementation freely: > >> > >> class Board b pos piece where > >> -- Update board with piece played at pos > >> play :: b pos piece -> pos -> piece -> b pos piece > > > > So the parameter b of the class is a type constructor taking two types > > and constructing a type from those. > > Yep. > > > IOW, it's a type constructor of kind (* -> * -> *), like (->) or Either. > > (* is the kind of types [Int, Char, Either Bool (), Double -> Rational -> > > Int, ...] > > > > [...] > > > >> but ghci complains: > >> board.hs:34:15: > >> Kind mis-match > >> Expected kind `* -> * -> *', but `pos -> Maybe piece' has kind `*' > >> In the instance declaration for `Board (pos > >> -> Maybe piece) pos piece' > > > > Yes, as said above. > > (pos -> Maybe piece) is a *type*, but the type class expects a type > > constructor of kind (* -> * ->*) here. > > I thought "(pos -> Maybe piece) pos piece" would provide the 3 type > arguments to Board. > > Oh, I see my mistake. I was seeing "b pos piece" as type parameters for > Board, but actually Board is just taking a single parameter of kind * -> > * -> *. No. class Board b pos piece where -- Update board with piece played at pos play :: b pos piece -> pos -> piece -> b pos piece the class Board takes three parameters: b, pos and piece. The (first) argument of play is the type (kind *) b pos piece Thus b is a type constructor taking two arguments. Since the arguments it takes, pos and piece, appear as the types of the second and third argument of play, these two must be plain types (kind *). Thus b :: * -> * -> * But in your instance declaration, in the position of b, you pass (pos -> Maybe piece), which is a type (kind *) and not a binary type constructor as required by the class declaration. If Haskell had type-level lambdas, what you would have needed to pass there is (/\ t1 t2. (t1 -> Maybe t2)) (or, if Haskell had type-constructor composition: ((. Maybe) . (->)) ) However, Haskell has neither type-level lambdas nor type-constructor composition, so you can't. You can only emulate that by using newtypes, hence Method 1 in my reply. > > > Method 2: Multiparameter type class with functional dependencies and > > suitable kinds > > > > class Board b pos piece | b -> pos, b -> piece where > > play :: b -> pos -> piece -> b > > at :: b -> pos -> Maybe piece > > empty :: b > > > > instance (Eq pos) => Board (pos -> Maybe piece) pos piece where > > play b pos piece = \p -> if p == pos then Just piece else b p > > at = id > > empty = const Nothing > > > > requires {-# LANGUAGE FlexibleInstances #-} > > > > Not necessarily ideal either. > > OK, but that's pretty much precisely what I was aiming for. I'm not > sure I understand what the difference between > > play :: b pos piece -> pos -> piece -> b pos piece > > and > > play :: b -> pos -> piece -> b > > is. Does adding type params to b here change its kind? That's not quite correctly expressed, but basically, yes, that's it. Any type expression that may legally appear to the left or right of '->' in a type signature has kind *. A type expression that takes parameters has a different kind, if it takes one plain type to produce a plain type, it has kind (* -> *), examples: [], Maybe. If it takes two plain types to produce a plain type, it has kind (* -> * -> *), examples: Either, (->). A type expression may also take type expressions which are not plain types to produce a plain type, for example StateT. That takes 1) the state type s (kind *) 2) the transforming (or transformed, I'm not sure about the terminology) Monad m (kind * -> *) 3) the result type a (kind *) to produce the plain type StateT s m a (kind *), hence StateT :: * -> (* -> *) -> * -> *. So with the signature play :: b -> pos -> piece -> b, b must be a plain type (elementary, like Int, Bool; or a fully applied type constructor of arity > 0, like [()], Maybe Char, Either Int Bool, ((Int,Int) -> Maybe String) or StateT [Int] Maybe Bool), that is, a type expression of kind *. With the signature play :: b pos piece -> pos -> piece -> b pos piece, b must be a type expression of arity 2, taking two plain types as arguments, that is, a type constructor of kind (* -> * -> *), like Either, State, (->) or a partially applied type constructor of higher arity like ((,,,) Int (Char ->Bool)) [the quadruple constructor (,,,) of kind (* -> * -> * -> * -> *) applied to two types, leaving two slots open]. > > > Method 3: Associated type families > > > > {-# LANGUAGE TypeFamilies, FlexibleInstances #-} > > module Board where > > > > class Board b where > > type Pos b :: * > > type Piece b :: * > > play :: b -> Pos b -> Piece b -> b > > at :: b -> Pos b -> Maybe (Piece b) > > empty :: b > > > > instance (Eq pos) => Board (pos -> Maybe piece) where > > type Pos (pos -> Maybe piece) = pos > > type Piece (pos -> Maybe piece) = piece > > play b pos piece = \p -> if p == pos then Just piece else b p > > at b p = b p > > empty _ = Nothing > > > > I would try that first. > > OK, there's some new stuff there I'm going to have to digest... It's very becoming. Type families have several advantages over functional dependencies. > > Thanks very much, > J From mpm at alumni.caltech.edu Tue Dec 1 20:55:00 2009 From: mpm at alumni.caltech.edu (Michael Mossey) Date: Tue Dec 1 20:30:01 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: <4B15C8F4.4020506@alumni.caltech.edu> Thanks for the reply. Was there something specific you were referring to, or just the idea that he wrote Haskore? Haskore is not very closely related to what I'm trying to do. I believe he has a CSound back end for Haskore, but it is in a rough state and not closely related to what I'm trying to do. Most computer music packages have a fairly well-defined idea of a musical event, and events usually get translated one-to-one into another language. I have a quite messy problem which is describable as a big state machine, at least in the way I think of it. An input "event" can trigger a cascade of changes to the state. Channel numbers must be assigned and tracked, table numbers as well, decisions about whether to create a new table or re-use an old one, global variables and commands added and/or modified, etc. So I am hoping for a comment from that perspective. Thanks, Mike Casey Hawthorne wrote: > Please check out Paul Hudak's page. > > http://cs-www.cs.yale.edu/homes/hudak-paul/ > From robgreayer at gmail.com Tue Dec 1 21:01:15 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Tue Dec 1 20:36:00 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15BC69.1020101@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: <4ec472cb0912011801x200bfb8cxa199cf79b177b3af@mail.gmail.com> On Tue, Dec 1, 2009 at 8:01 PM, Michael P Mossey wrote: > Perhaps someone could either (1) help me do what I'm trying to do, or (2) > show me a better way. > > I have a problem that is very state-ful and I keep thinking of it as OO, > which is driving me crazy. Haskell is several times harder to use than > Python in this instance, probably because I'm doing it wrong. > > To give you a larger context, this problem is essentially compiling a > description of music (my own) into a kind of music-machine-language > (CSound). CSound is relatively untidy. > > In this one example, in a OO way of thinking, I have data called > AssignedNumbers that assigns integers to unique strings and keeps track of > the used integers and next available integer (the choice of available > integer could follow a number of conventions so I wanted to hide that in an > ADT.) So it has an associated function: > > getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) > > What getNumber does is: > > - check if the string already has a number assigned to it. If so, return > that number. > > - if not, pick the next available number. > > - in all cases, return the possibly changed state of AssignedNumbers > > Then in a larger data structure, it contains fields of type > AssignedNumbers. Like > > data MusicStuff = MusicStuff > { oscillatorNumbers :: AssignedNumbers > , tableNumbers :: AssignedNumbers > , ... } > > I'm using MusicStuff in a State monad, so I might write a function like > > doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) > doSomeMusicStuff aString1 aString2 = do > ms <- get > (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) > (t1,newTabNums) = getNumber aString2 (tableNumbers ms) > put ms { oscillatorNumbers = newOscNums > , tableNumbers = newTabNums } > return (o1,t1) > > For what it does, this is extremely verbose and filled with distracting > visual content. And this is just a very simple example---my real problem is > several times more state-ful. Is there a better way? > As a quick observation, you might consider changing getNumber to be something like: nextNumber :: String -> NumberGroup -> State MusicStuff Int where NumberGroup is something like data NumberGroup = OscNums | TabNums |... nextNumber updates the appropriate set of numbers in MusicStuff and returns the number. doSomeMusicStuff then becomes: doSomeMusicStuff aString1 aString2 = (,) `liftM` nextNumber OscNums `ap` nextNumber TabNums or better yet (applicatively) doSomeMusicStuff aString1 aString2 = (,) <$> nextNumber OscNums <*> nextNumber TabNums -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091201/a62ec2fa/attachment.html From robgreayer at gmail.com Tue Dec 1 21:03:05 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Tue Dec 1 20:37:51 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4ec472cb0912011801x200bfb8cxa199cf79b177b3af@mail.gmail.com> References: <4B15BC69.1020101@alumni.caltech.edu> <4ec472cb0912011801x200bfb8cxa199cf79b177b3af@mail.gmail.com> Message-ID: <4ec472cb0912011803v3adb0e08ma54ce7f36006cc9d@mail.gmail.com> On Tue, Dec 1, 2009 at 9:01 PM, Robert Greayer wrote: > > > On Tue, Dec 1, 2009 at 8:01 PM, Michael P Mossey wrote: > >> Perhaps someone could either (1) help me do what I'm trying to do, or (2) >> show me a better way. >> >> I have a problem that is very state-ful and I keep thinking of it as OO, >> which is driving me crazy. Haskell is several times harder to use than >> Python in this instance, probably because I'm doing it wrong. >> >> To give you a larger context, this problem is essentially compiling a >> description of music (my own) into a kind of music-machine-language >> (CSound). CSound is relatively untidy. >> >> In this one example, in a OO way of thinking, I have data called >> AssignedNumbers that assigns integers to unique strings and keeps track of >> the used integers and next available integer (the choice of available >> integer could follow a number of conventions so I wanted to hide that in an >> ADT.) So it has an associated function: >> >> getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) >> >> What getNumber does is: >> >> - check if the string already has a number assigned to it. If so, return >> that number. >> >> - if not, pick the next available number. >> >> - in all cases, return the possibly changed state of AssignedNumbers >> >> Then in a larger data structure, it contains fields of type >> AssignedNumbers. Like >> >> data MusicStuff = MusicStuff >> { oscillatorNumbers :: AssignedNumbers >> , tableNumbers :: AssignedNumbers >> , ... } >> >> I'm using MusicStuff in a State monad, so I might write a function like >> >> doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) >> doSomeMusicStuff aString1 aString2 = do >> ms <- get >> (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) >> (t1,newTabNums) = getNumber aString2 (tableNumbers ms) >> put ms { oscillatorNumbers = newOscNums >> , tableNumbers = newTabNums } >> return (o1,t1) >> >> For what it does, this is extremely verbose and filled with distracting >> visual content. And this is just a very simple example---my real problem is >> several times more state-ful. Is there a better way? >> > > As a quick observation, you might consider changing getNumber to be > something like: > > nextNumber :: String -> NumberGroup -> State MusicStuff Int > > where NumberGroup is something like > > data NumberGroup = OscNums | TabNums |... > > nextNumber updates the appropriate set of numbers in MusicStuff and returns > the number. doSomeMusicStuff then becomes: > > doSomeMusicStuff aString1 aString2 = (,) `liftM` nextNumber OscNums `ap` > nextNumber TabNums > > or better yet (applicatively) > > doSomeMusicStuff aString1 aString2 = (,) <$> nextNumber OscNums <*> > nextNumber TabNums > > Oops, that's: doSomeMusicStuff aString1 aString2 = (,) `liftM` nextNumber aString1 OscNums `ap` nextNumber aString2 TabNums or: doSomeMusicStuff aString1 aString2 = (,) <$> nextNumber aString1 OscNums <*> nextNumber aString2 TabNums -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091201/17e003aa/attachment.html From daniel.is.fischer at web.de Tue Dec 1 21:03:23 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 20:39:35 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15BC69.1020101@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: <200912020303.23958.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 02:01:29 schrieb Michael P Mossey: > Perhaps someone could either (1) help me do what I'm trying to do, or (2) > show me a better way. > > I have a problem that is very state-ful and I keep thinking of it as OO, > which is driving me crazy. Haskell is several times harder to use than > Python in this instance, probably because I'm doing it wrong. If you want to do something very stateful, it is a bit cumbersome in Haskell. Perhaps it is the wrong approach and you can do it with much less state. Or perhaps, this is possible, too, it is not a task for which Haskell is well suited. Or perhaps you're really doing it wrong because of lack of experience. > > To give you a larger context, this problem is essentially compiling a > description of music (my own) into a kind of music-machine-language > (CSound). CSound is relatively untidy. > > In this one example, in a OO way of thinking, I have data called > AssignedNumbers that assigns integers to unique strings and keeps track of > the used integers and next available integer (the choice of available > integer could follow a number of conventions so I wanted to hide that in an > ADT.) So it has an associated function: > > getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) Yeah, that screams State Monad. > > What getNumber does is: > > - check if the string already has a number assigned to it. If so, return > that number. > > - if not, pick the next available number. > > - in all cases, return the possibly changed state of AssignedNumbers > > Then in a larger data structure, it contains fields of type > AssignedNumbers. Like > > data MusicStuff = MusicStuff > { oscillatorNumbers :: AssignedNumbers > , tableNumbers :: AssignedNumbers > , ... } > > I'm using MusicStuff in a State monad, so I might write a function like > > doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) > doSomeMusicStuff aString1 aString2 = do > ms <- get > (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) > (t1,newTabNums) = getNumber aString2 (tableNumbers ms) > put ms { oscillatorNumbers = newOscNums > , tableNumbers = newTabNums } > return (o1,t1) > > For what it does, this is extremely verbose and filled with distracting > visual content. And this is just a very simple example---my real problem is > several times more state-ful. Is there a better way? If you're doing that in many places, factor out the methods getOscillatorNumber :: String -> State MusicStuff Int getOscillatorNumber str = do ms <- get let on = oscilatorNumbers ms (o1,newOn) = getNumber str on put (ms{ oscillatorNumbers = newOn }) return o1 same for tableNumbers etc. Then doSomeMusicStuff aString1 aString2 = do o <- getOscillatorNumber aString1 t <- getTableNumber aString2 return (o,t) and the verbosity is moved to one place. That isn't worthwhile for seldomly used stuff, of course. > > Note that in Python it would be a method > > def doMusicStuff( self, s1, s2 ) : > return (self.oscillatorNumbers.next(s1), > self.oscillatorNumbers.next(s2)) > Yeah, mutability gives brevity here. From mpm at alumni.caltech.edu Tue Dec 1 21:28:04 2009 From: mpm at alumni.caltech.edu (Michael Mossey) Date: Tue Dec 1 21:03:08 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <200912020303.23958.daniel.is.fischer@web.de> References: <4B15BC69.1020101@alumni.caltech.edu> <200912020303.23958.daniel.is.fischer@web.de> Message-ID: <4B15D0B4.6070900@alumni.caltech.edu> Daniel Fischer wrote: >> getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) > > Yeah, that screams State Monad. > Hi, thanks for all the advice. I was hoping my AssignedNumbers "class" would be useful with many data structures. In other words I would have data State1 = State1 { a :: AssignedNumbers, b :: AssignedNumbers, ... } data State2 = State2 { c :: AssignedNumbers, d :: AssignedNumbers, ... } func1 :: State State1 Int func1 = do ... something using a and b ... func2 :: State State2 Int func2 = do ... something using c and d ... So I thought maybe I could defined a function like nextNumber :: MonadState s m => (s -> AssignedNumbers) -> (AssignedNumbers -> s) -> m Int nextNumber retreive putBack = ... and have it be useful in both "State State1 a" and "State State2 a" monads, but defining the retrieve and putBack functions isn't pretty. I will try to grok Robert's reply also. Maybe he has something addressing this. Mike From daniel.is.fischer at web.de Tue Dec 1 21:55:07 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 1 21:31:20 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15D0B4.6070900@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> <200912020303.23958.daniel.is.fischer@web.de> <4B15D0B4.6070900@alumni.caltech.edu> Message-ID: <200912020355.07973.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 03:28:04 schrieb Michael Mossey: > Daniel Fischer wrote: > >> getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers) > > > > Yeah, that screams State Monad. > > Hi, thanks for all the advice. > > I was hoping my AssignedNumbers "class" would be useful with many data > structures. In other words I would have > > data State1 = State1 { a :: AssignedNumbers, b :: AssignedNumbers, ... } > data State2 = State2 { c :: AssignedNumbers, d :: AssignedNumbers, ... } > > func1 :: State State1 Int > func1 = do > ... something using a and b ... > > func2 :: State State2 Int > func2 = do > ... something using c and d ... > > So I thought maybe I could defined a function like > > nextNumber :: MonadState s m => (s -> AssignedNumbers) -> (AssignedNumbers > -> s) -> m Int > nextNumber retreive putBack = ... > > and have it be useful in both "State State1 a" and "State State2 a" monads, > but defining the retrieve and putBack functions isn't pretty. > > I will try to grok Robert's reply also. Maybe he has something addressing > this. Definitely. data AssignType = Oscillator | Table | Thingamajig deriving (Eq, Ord, Ix) data MusicState = MS { assignedNumbers :: Array AssignType AssignedNumbers , other stuff } deriving (Everything you need) fetchNumber :: String -> AssignType -> State MusicState Int fetchNumber str ty = do an <- gets ((! ty) . assignedNumbers) let (i,newAn) = getNumber str an modify (\ms -> ms{ assignedNumbers = assignedNumbers ms // [(ty,newAn)] }) return i doSomeMusicStuff aString1 aString2 = do o <- fetchNumber aString1 Oscillator t <- fetchNumber aString2 Table return (o,t) > > Mike From chak at cse.unsw.edu.au Tue Dec 1 22:22:05 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Dec 1 21:57:02 2009 Subject: [Haskell-cafe] university courses on type families/GADTs? In-Reply-To: References: Message-ID: Tom Schrijvers wrote, > I was wondering whether there are any universities that teach about Haskell type families or GADTs? I do in my course "Language-based Software Safety" (both TFs and GADTs). It's an advanced, research-oriented course for 4th year undergraduate and for postgraduate students. (It wasn't offered last year and this year, but will be again offered next year.) Manuel From jeremy at goop.org Tue Dec 1 22:38:28 2009 From: jeremy at goop.org (Jeremy Fitzhardinge) Date: Tue Dec 1 22:13:15 2009 Subject: [Haskell-cafe] Trying to sort out multiparameter type classes and their instances In-Reply-To: <200912020238.33474.daniel.is.fischer@web.de> References: <4B159A06.4020404@goop.org> <200912020012.44889.daniel.is.fischer@web.de> <4B15B818.4040207@goop.org> <200912020238.33474.daniel.is.fischer@web.de> Message-ID: <4B15E134.8020808@goop.org> On 12/01/09 17:38, Daniel Fischer wrote: > Am Mittwoch 02 Dezember 2009 01:43:04 schrieb Jeremy Fitzhardinge: > >> On 12/01/09 15:12, Daniel Fischer wrote: >> >>> Am Dienstag 01 Dezember 2009 23:34:46 schrieb Jeremy Fitzhardinge: >>> >>>> I'm playing around with some types to represent a game board (like Go, >>>> Chess, Scrabble, etc). >>>> >>>> I'm using a type class to represent the basic Board interface, so I can >>>> change the implementation freely: >>>> >>>> class Board b pos piece where >>>> -- Update board with piece played at pos >>>> play :: b pos piece -> pos -> piece -> b pos piece >>>> >>> So the parameter b of the class is a type constructor taking two types >>> and constructing a type from those. >>> >> Yep. >> >> >>> IOW, it's a type constructor of kind (* -> * -> *), like (->) or Either. >>> (* is the kind of types [Int, Char, Either Bool (), Double -> Rational -> >>> Int, ...] >>> >>> [...] >>> >>> >>>> but ghci complains: >>>> board.hs:34:15: >>>> Kind mis-match >>>> Expected kind `* -> * -> *', but `pos -> Maybe piece' has kind `*' >>>> In the instance declaration for `Board (pos >>>> -> Maybe piece) pos piece' >>>> >>> Yes, as said above. >>> (pos -> Maybe piece) is a *type*, but the type class expects a type >>> constructor of kind (* -> * ->*) here. >>> >> I thought "(pos -> Maybe piece) pos piece" would provide the 3 type >> arguments to Board. >> >> Oh, I see my mistake. I was seeing "b pos piece" as type parameters for >> Board, but actually Board is just taking a single parameter of kind * -> >> * -> *. >> > No. > > class Board b pos piece where > -- Update board with piece played at pos > play :: b pos piece -> pos -> piece -> b pos piece > > the class Board takes three parameters: b, pos and piece. > > The (first) argument of play is the type (kind *) > > b pos piece > > Thus b is a type constructor taking two arguments. Since the arguments it takes, pos and > piece, appear as the types of the second and third argument of play, these two must be > plain types (kind *). > > Thus > > b :: * -> * -> * > > But in your instance declaration, in the position of b, you pass > > (pos -> Maybe piece), which is a type (kind *) and not a binary type constructor as > required by the class declaration. > If Haskell had type-level lambdas, what you would have needed to pass there is > > (/\ t1 t2. (t1 -> Maybe t2)) > > (or, if Haskell had type-constructor composition: ((. Maybe) . (->)) ) > > However, Haskell has neither type-level lambdas nor type-constructor composition, so you > can't. > You can only emulate that by using newtypes, hence Method 1 in my reply. > > >> >>> Method 2: Multiparameter type class with functional dependencies and >>> suitable kinds >>> >>> class Board b pos piece | b -> pos, b -> piece where >>> play :: b -> pos -> piece -> b >>> at :: b -> pos -> Maybe piece >>> empty :: b >>> >>> instance (Eq pos) => Board (pos -> Maybe piece) pos piece where >>> play b pos piece = \p -> if p == pos then Just piece else b p >>> at = id >>> empty = const Nothing >>> >>> requires {-# LANGUAGE FlexibleInstances #-} >>> >>> Not necessarily ideal either. >>> >> OK, but that's pretty much precisely what I was aiming for. I'm not >> sure I understand what the difference between >> >> play :: b pos piece -> pos -> piece -> b pos piece >> >> and >> >> play :: b -> pos -> piece -> b >> >> is. Does adding type params to b here change its kind? >> > That's not quite correctly expressed, but basically, yes, that's it. > What would be the correct way to express it? > With the signature > > play :: b pos piece -> pos -> piece -> b pos piece, > > b must be a type expression of arity 2, taking two plain types as arguments, that is, a > type constructor of kind (* -> * -> *), like Either, State, (->) or a partially applied > type constructor of higher arity like ((,,,) Int (Char ->Bool)) [the quadruple constructor > (,,,) of kind (* -> * -> * -> * -> *) applied to two types, leaving two slots open]. > OK, I think I understand now. It helps explain my questions about the types of "first" and "second", which I always use on tuples, but their types are much more general. >>> Method 3: Associated type families >>> >>> {-# LANGUAGE TypeFamilies, FlexibleInstances #-} >>> module Board where >>> >>> class Board b where >>> type Pos b :: * >>> type Piece b :: * >>> play :: b -> Pos b -> Piece b -> b >>> at :: b -> Pos b -> Maybe (Piece b) >>> empty :: b >>> >>> instance (Eq pos) => Board (pos -> Maybe piece) where >>> type Pos (pos -> Maybe piece) = pos >>> type Piece (pos -> Maybe piece) = piece >>> play b pos piece = \p -> if p == pos then Just piece else b p >>> at b p = b p >>> empty _ = Nothing >>> >>> I would try that first. >>> >> OK, there's some new stuff there I'm going to have to digest... >> > It's very becoming. Type families have several advantages over functional dependencies. > Could you go into more detail about the advantages? Thanks, J From stefan at cs.uu.nl Wed Dec 2 01:20:10 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Dec 2 02:09:45 2009 Subject: [Haskell-cafe] university courses on type families/GADTs? In-Reply-To: References: Message-ID: <34F94F2F-03CF-4EBC-9D22-C960CE809B6B@cs.uu.nl> Tom, > I was wondering whether there are any universities that teach about > Haskell type families or GADTs? I'm quite sure at least GADTs are covered in INFOMAFP, the graduate course on Advanced Functional Programming at UU: http://www.cs.uu.nl/docs/vakken/afp Cheers, Stefan From warrensomebody at gmail.com Wed Dec 2 02:40:11 2009 From: warrensomebody at gmail.com (Warren Harris) Date: Wed Dec 2 02:15:00 2009 Subject: [Haskell-cafe] buildExpressionParser prefix recursion Message-ID: I was wondering why Parsec's buildExpressionParser doesn't allow prefix expressions to be handled recursively, e.g. given a prefix "!" operation, it seems that "!!a" could parse without requiring parentheses ("!(!a)"). Is there an easy way to extend it? (I have a rich expression grammar I'd like to parse which includes several prefix forms, and it would be a shame to have to abandon buildExpressionParser since it is so concise and convenient.) Thanks, Warren From bbr at informatik.uni-kiel.de Wed Dec 2 03:43:11 2009 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Dec 2 03:17:57 2009 Subject: [Haskell-cafe] KiCS (Curry to Haskell interpreter) problem Message-ID: > I am playing around with KiCS and I have a strange problem, when I > evaluate a goal the variable bindings are not displayed, I see only > the value of the expression. The idea is, that you decide yourself which bindings you want to see. For example, you write (let x free in (not x,x)) to get (True,False) More? (False,True) More? No more solutions > I would have contacted the author but his email in not in the haskell > cabal file. Thanks for the hint. I have added my mail now and will do another update in a few weeks. Meanwhile, anyone interested in the system can contact me directly under "bbr at informatik.uni-kiel.de" Thanks for your interest in kics! Bernd From dev at mobileink.com Wed Dec 2 06:23:37 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Wed Dec 2 05:58:21 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15BC69.1020101@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: <75cc17ac0912020323s455c8ddexba01e350f852d051@mail.gmail.com> On Tue, Dec 1, 2009 at 7:01 PM, Michael P Mossey wrote: > Perhaps someone could either (1) help me do what I'm trying to do, or (2) > show me a better way. >> > In this one example, in a OO way of thinking, I have data called > AssignedNumbers that assigns integers to unique strings and keeps track of > the used integers and next available integer (the choice of available > integer could follow a number of conventions so I wanted to hide that in an > ADT.) So it has an associated function: > What do the numbers and strings mean? Can you use an algebraic type instead of strings? Do particular numbers have meaning or are they just serial numbers? Can you compute some sort of checksum for the strings rather than rely on an external list of numbers? If you must have a list of numbers, can you embed it in a specialized string type, so that numbers get assigned as a side-effect of string construction? In other words, would it help to think more in terms of specific types rather than generic numbers and strings? -G From dev at mobileink.com Wed Dec 2 06:30:24 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Wed Dec 2 06:05:12 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15C8F4.4020506@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> <4B15C8F4.4020506@alumni.caltech.edu> Message-ID: <75cc17ac0912020330r6e7fe27cs659922948de3c428@mail.gmail.com> On Tue, Dec 1, 2009 at 7:55 PM, Michael Mossey wrote: > Thanks for the reply. Was there something specific you were referring to, or Maybe http://plucky.cs.yale.edu/cs431/reading.htm Chapter 9 "An Algebra of Music." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091202/73c3d9da/attachment.html From stephen.tetley at gmail.com Wed Dec 2 07:58:17 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Wed Dec 2 07:33:01 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15C8F4.4020506@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> <4B15C8F4.4020506@alumni.caltech.edu> Message-ID: <5fdc56d70912020458k6542d692t114c760d013b483d@mail.gmail.com> Hi Mike There used to be some slides available commenting on Haskore's CSound interface. But they seem to have vanished (I have a copy rendered to pdf when they were available). Like all slide presentations there's a lot of reading between the lines to get a good picture after the fact: http://www.nepls.org/Events/16/abstracts.html#hudak http://plucky.cs.yale.edu/cs431/HasSoundNEPLS-10-05.ppt -- vanished Maybe you're doomed to frustration though trying to implement your system in "Haskell". For the argument I'm about to make, I'd say a working programming language has two things - syntax, semantics and libraries and a repertory of prior art. Stateful programming clearly has some syntax burden in Haskell, stateful monadic programming has some benefit of 'stratification' - you have precise control of 'what state is where'. It's a matter of taste whether you like Python's flexibility or Haskell's, erm, 'locality' (precision?). As for the second half of what you get from a programming language, your system description frames what you want to do with an emphasis on dynamic aspects. This seems a good way off from the prior art in Haskell. For instance there are Haskell synthesizers - George Giorgidze's yampa-synth and Jerzy Karczmarczuk's Clarion (actually in Clean, but near enough). Here you build signal processing modules - unit generators, of course - Yampasynth uses arrows to do this Clarion uses infinite streams. With both you would build a synthesizer statically from unit generators and somehow run it to produce sounds[1]. There is also the prior art of embedded hardware description languages, Lava, Hydra, Wired, Gordon Pace's HeDLa, soon Kansas Lava. One could view constructing synthesizers from unit generators as usefully analogous to constructing circuits - and certainly if you are 'compiling' to another system to do do the real work (in your case CSound) the papers on Wired, HeDLa, and Kansas Lava have useful insights on 'offshoring' compilation. But again these systems have strong bearing in the 'static description' of a circuit rather than its dynamical operation. If neither of those 'genres' is close to what you really want to do then the Haskell prior art is running a bit thin. You could look at dataflow - the dynamic PD / Max systems are often describe as a dataflow systems. There are some outposts in Haskell of dataflow programming - Gordon Pace has an embedding of Lustre available from his homepage and there has been work on dataflow programming via comonads. There is also reactive programming, but musical examples are thin on the ground (nonexistent?) so it might be a long haul to come up with something. Best wishes Stephen [1] This seems a bit of a paraphrase of Yampasynth - which I think allows you to define a synthesizer statically in code, but then play it interactively. 2009/12/2 Michael Mossey : > Thanks for the reply. Was there something specific you were referring to, or > just the idea that he wrote Haskore? Haskore is not very closely related to > what I'm trying to do. From duncan at well-typed.com Wed Dec 2 08:04:21 2009 From: duncan at well-typed.com (Duncan Coutts) Date: Wed Dec 2 07:39:05 2009 Subject: [Haskell-cafe] Building network package on Windows In-Reply-To: <5ab17e790906062143h3968488bg577cdbe0de796bd9@mail.gmail.com> References: <5ab17e790906062143h3968488bg577cdbe0de796bd9@mail.gmail.com> Message-ID: <1259759061.4896.97476.camel@localhost> On Sat, 2009-06-06 at 21:43 -0700, Iavor Diatchki wrote: > Hi, > I have been trying to build the package "network" from hackage > (version 2.2.1.3) on Windows Vista, and I could really use some help. > Unfortunately, if I try to use my package to build an > executable application I get a linker error, reporting a missing > symbol during linking: > C:\Users\diatchki\AppData\Roaming\cabal\network-2.2.1.3\ghc-6.10.3/libHSnetwork-2.2.1.3.a(Socket.o):fake:(.text+0xb014): > undefined reference to `getnameinfo' > collect2: ld returned 1 exit status I saw some other people run into this today. > Now, "getnameinfo" is present in the header files, and it is also > defined in the library ws2_32.a which is being passed to GHC so I am > not sure what is going on. Any ideas? > Searching the web suggests that the problem may be somehow related to > the standard calling conventions but I don't really understand. Right. The getnameinfo in ws2_32.a uses the stdcall calling convention. The actual linker symbol for it is "_getnameinfo@28". If it used the ccall convention then it's linker symbol name would be "_getnameinfo". The FFI decl for getnameinfo uses ccall. So that's why we get the error. The current version uses a C wrapper for this function (for unrelated reasons) and this has the side effect that the C compiler picks up the correct calling convention from the C header files. We would be able to catch errors like this if we had a tool that would check the Haskell FFI decls match the C headers. Of course c2hs already does this, but only for generating correct FFI decls in the first place. It cannot be used in a mode where it checks existing code. That might be a useful extension though since very few projects seem to use c2hs to generate correct imports in the first place. It also does not currently check stdcall vs ccall calling convention but it could fairly easily be extended to do so (since it parses those attributes). -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From matthias.goergens at googlemail.com Wed Dec 2 08:16:02 2009 From: matthias.goergens at googlemail.com (=?ISO-8859-1?Q?Matthias_G=F6rgens?=) Date: Wed Dec 2 07:51:06 2009 Subject: [Haskell-cafe] Ord k => Data.Set.Set k -> (k->v) -> Data.Map.Map k v Message-ID: I feel that Data.Set and Data.Map should be working together more closely. For example you can already get the keyset of a Map, but the `other way' is not built-in. I mean a function with a signature like Ord k => Data.Set.Set k -> (k->v) -> Data.Map.Map k v You can implement it in O(n): > assoc :: (a->b) -> [a] -> [(a,b)] > assoc f = map (\x -> (x, f x)) > mapToMap :: Ord k => (k -> v) -> Data.Set.Set k -> Data.Map.Map k v > mapToMap f = Data.Map.fromAscList . assoc f . Data.Set.toAscList The name assoc alludes to the assoc-lists of Lisp. From Christian.Maeder at dfki.de Wed Dec 2 08:49:21 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Dec 2 08:24:05 2009 Subject: [Haskell-cafe] computing lists of pairs Message-ID: <4B167061.10007@dfki.de> Wizards, I've the following small piece of code \begin{code} pairs :: [a] -> [b] -> [[(a, b)]] pairs l1 = map (zip l1) . takeKFromN l1 takeKFromN :: [b] -> [a] -> [[a]] takeKFromN s l = case s of [] -> [[]] _ : r -> [ a : b | a <- l, b <- takeKFromN r l] \end{code} I have a predicate: p :: (a, b) -> Bool and I want to keep only those results of pairs which fulfill "all p". I do so currently by "filter (all p) (pairs l1 l2)", but I want to generate the beginning of this pair lists more efficiently, because the result list of pairs may become very large, soon: length (pairs l1 l2) == length l2 ^ length l1 Any ideas (or other hints) to improve the code? "pairs" computes all different mappings from all elements of l1 to some elements of l2. "takeKFromN" computes all possible sequences of length l1 with elements from l2. I somehow want to integrate the predicate into the generation. Cheers Christian From simonpj at microsoft.com Wed Dec 2 09:45:49 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Dec 2 09:19:17 2009 Subject: [Haskell-cafe] Type synonym family inside type class In-Reply-To: <4B0FAB41.9070603@van.steenbergen.nl> References: <4B0FAB41.9070603@van.steenbergen.nl> Message-ID: <59543203684B2244980D7E4057D5FBC1085050FA@DB3EX14MBXC310.europe.corp.microsoft.com> I agree this is wrong. I've created a Trac bug report http://hackage.haskell.org/trac/ghc/ticket/3714 Thanks for pointing it out Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- | bounces@haskell.org] On Behalf Of Martijn van Steenbergen | Sent: 27 November 2009 10:35 | To: Haskell Cafe | Subject: [Haskell-cafe] Type synonym family inside type class | | Hello, | | I have a type family and a type class: | | > type family ErrorAlg (f :: (* -> *) -> * -> *) e ix :: * | | > class MkErrorAlg f where | > mkErrorAlg :: ErrorAlg f e a -> f (K0 a) ix -> Either e a | | Instances for these two really go hand in hand, so I thought I would | move the type family into the type class. However, this causes GHC to | complain about the type variables that are bound on the LHS of the type | synonym: | | > Not in scope: type variable `e' | > Not in scope: type variable `ix' | | In function types, using new type variables (i.e. type variables not | bound by the type class header) implicitly means universal | quantification over these variables. Why is this disallowed in type | families inside type classes? | | Thanks, | | Martijn. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From tzz at lifelogs.com Wed Dec 2 09:55:22 2009 From: tzz at lifelogs.com (Ted Zlatanov) Date: Wed Dec 2 09:34:57 2009 Subject: [Haskell-cafe] Re: inversion lists References: <26690.208.57.251.240.1258318451.squirrel@mail.alumni.caltech.edu> <87pr7c7uk6.fsf@lifelogs.com> <87bpiil429.fsf@lifelogs.com> <200912020112.23886.daniel.is.fischer@web.de> Message-ID: <871vjdl92d.fsf@lifelogs.com> On Wed, 2 Dec 2009 01:12:23 +0100 Daniel Fischer wrote: DF> No, quite the opposite. foldr is wonderful for lazy list processing. DF> I just need to make my function a wee bit lazier: ... DF> No, foldl cannot produce anything before the whole list has been traversed, so it can't DF> deal with infinite lists at all. Got it. I simply had reversed the two functions mentally and thought foldl was the lazy one. I'll follow up on the rest separately. Ted From daniel.is.fischer at web.de Wed Dec 2 10:27:14 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 2 10:03:32 2009 Subject: [Haskell-cafe] computing lists of pairs In-Reply-To: <4B167061.10007@dfki.de> References: <4B167061.10007@dfki.de> Message-ID: <200912021627.15986.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 14:49:21 schrieb Christian Maeder: > Wizards, > > I've the following small piece of code > > \begin{code} > pairs :: [a] -> [b] -> [[(a, b)]] > pairs l1 = map (zip l1) . takeKFromN l1 > > takeKFromN :: [b] -> [a] -> [[a]] > takeKFromN s l = case s of > [] -> [[]] > _ : r -> [ a : b | a <- l, b <- takeKFromN r l] > \end{code} > > I have a predicate: > p :: (a, b) -> Bool > > and I want to keep only those results of pairs which fulfill > "all p". takeKFromNWithP :: (a -> b -> Bool) -> [a] -> [b] -> [[b]] takeKFromNWithP p s l = case s of (h:t) -> [x:ys | x <- filter (p h) l, ys <- takeKFromNWithP p t l] [] -> [[]] filteredPairs :: (a -> b -> Bool) -> [a] -> [b] -> [[(a,b)]] filteredPairs p l1 = map (zip l1) . takeKFromNWithP l1 or, in one go: funkyName :: (a -> b -> Bool) -> [a] -> [b] -> [[(a,b)]] funkyName p s l = case s of (h:t) -> [(h,a):ys | a <- filter (p h) l, ys <- funkyName p t l] [] -> [[]] > > I do so currently by "filter (all p) (pairs l1 l2)", but I want to > generate the beginning of this pair lists more efficiently, because the > result list of pairs may become very large, soon: > > length (pairs l1 l2) == length l2 ^ length l1 > > Any ideas (or other hints) to improve the code? > > "pairs" computes all different mappings from all elements of l1 to some > elements of l2. "takeKFromN" computes all possible sequences of length > l1 with elements from l2. > > I somehow want to integrate the predicate into the generation. > > Cheers Christian > From mpm at alumni.caltech.edu Wed Dec 2 10:32:20 2009 From: mpm at alumni.caltech.edu (Michael Mossey) Date: Wed Dec 2 10:07:19 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <5fdc56d70912020458k6542d692t114c760d013b483d@mail.gmail.com> References: <4B15BC69.1020101@alumni.caltech.edu> <4B15C8F4.4020506@alumni.caltech.edu> <5fdc56d70912020458k6542d692t114c760d013b483d@mail.gmail.com> Message-ID: <4B168884.8010500@alumni.caltech.edu> Stephen Tetley wrote: > Hi Mike > > There used to be some slides available commenting on Haskore's CSound > interface. But they seem to have vanished (I have a copy rendered to > pdf when they were available). Like all slide presentations there's a > lot of reading between the lines to get a good picture after the fact: > > > http://www.nepls.org/Events/16/abstracts.html#hudak > http://plucky.cs.yale.edu/cs431/HasSoundNEPLS-10-05.ppt -- vanished > This looks like a great resource. Maybe Dr. Hudak can get me a copy. He clearly has the experience to implement a CSound "compiler" as gracefully as anyone could. > Maybe you're doomed to frustration though trying to implement your > system in "Haskell". For the argument I'm about to make, I'd say a > working programming language has two things - syntax, semantics and > libraries and a repertory of prior art. Stateful programming clearly > has some syntax burden in Haskell, stateful monadic programming has > some benefit of 'stratification' - you have precise control of 'what > state is where'. It's a matter of taste whether you like Python's > flexibility or Haskell's, erm, 'locality' (precision?). > > As for the second half of what you get from a programming language, > your system description frames what you want to do with an emphasis on > dynamic aspects. This seems a good way off from the prior art in > Haskell. For instance there are Haskell synthesizers - George > Giorgidze's yampa-synth and Jerzy Karczmarczuk's Clarion (actually in > Clean, but near enough). Here you build signal processing modules - > unit generators, of course - Yampasynth uses arrows to do this Clarion > uses infinite streams. With both you would build a synthesizer > statically from unit generators and somehow run it to produce > sounds[1]. > > There is also the prior art of embedded hardware description > languages, Lava, Hydra, Wired, Gordon Pace's HeDLa, soon Kansas Lava. > One could view constructing synthesizers from unit generators as > usefully analogous to constructing circuits - and certainly if you are > 'compiling' to another system to do do the real work (in your case > CSound) the papers on Wired, HeDLa, and Kansas Lava have useful > insights on 'offshoring' compilation. But again these systems have > strong bearing in the 'static description' of a circuit rather than > its dynamical operation. > Thanks for this detailed review. I will investigate these things. My system sits halfway between a low-level signal processor language like CSound and a high-level music description language like Hudak's Haskore. My work as a composer will be done at the highest level possible, which means thinking in terms of "notes"---things that go "boo" at a certain time, place, frequency, amplitude, timbre, etc. But I want to express things beyond, say, MIDI, like indicating that a group of notes should be played legato---which doesn't mean "play them individually with no separation of notes" but actually means "modify the csound instrument's behavior at the time of note connections." So in one small breath I can say, "Make this legato" and at the low level the elves are scurrying around like mad, rearranging code, changing out instruments, merging notes, etc. I also have a bad case of "Not Invented Here Syndrome"---seriously, I want to use this system to do experimental composition, by which I mean any crazy idea I dream up can be implemented by adding to or modifying my system, which gives me a preference to write it myself. > If neither of those 'genres' is close to what you really want to do > then the Haskell prior art is running a bit thin. You could look at > dataflow - the dynamic PD / Max systems are often describe as a > dataflow systems. There are some outposts in Haskell of dataflow > programming - Gordon Pace has an embedding of Lustre available from > his homepage and there has been work on dataflow programming via > comonads. There is also reactive programming, but musical examples are > thin on the ground > (nonexistent?) so it might be a long haul to come up with something. But this all sounds great to study. Thanks, Mike From mpm at alumni.caltech.edu Wed Dec 2 10:35:36 2009 From: mpm at alumni.caltech.edu (Michael Mossey) Date: Wed Dec 2 10:10:23 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <75cc17ac0912020330r6e7fe27cs659922948de3c428@mail.gmail.com> References: <4B15BC69.1020101@alumni.caltech.edu> <4B15C8F4.4020506@alumni.caltech.edu> <75cc17ac0912020330r6e7fe27cs659922948de3c428@mail.gmail.com> Message-ID: <4B168948.2090405@alumni.caltech.edu> Hi Gregg, Yes, I've read his book School of Expression and I'll have to check up on this draft. His ideas are very useful at the level of composing music, where an algebraic representation is natural and flies free and high. It's when that representation grinds against an old quaint system like CSound that things get ugly. However, I have a new idea. Stay tuned. -Mike Gregg Reynolds wrote: > On Tue, Dec 1, 2009 at 7:55 PM, Michael Mossey > wrote: > > Thanks for the reply. Was there something specific you were referring > to, or > > Maybe http://plucky.cs.yale.edu/cs431/reading.htm Chapter 9 "An Algebra > of Music." > From daniel.is.fischer at web.de Wed Dec 2 10:51:33 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 2 10:27:57 2009 Subject: [Haskell-cafe] computing lists of pairs In-Reply-To: <200912021627.15986.daniel.is.fischer@web.de> References: <4B167061.10007@dfki.de> <200912021627.15986.daniel.is.fischer@web.de> Message-ID: <200912021651.36533.daniel.is.fischer@web.de> Or: fpairs p s l = sequence [[(a,b) | b <- filter (p a) l] | a <- s] From mpm at alumni.caltech.edu Wed Dec 2 10:55:01 2009 From: mpm at alumni.caltech.edu (Michael Mossey) Date: Wed Dec 2 10:29:49 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15BC69.1020101@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: <4B168DD5.1010406@alumni.caltech.edu> Michael P Mossey wrote: > Perhaps someone could either (1) help me do what I'm trying to do, or > (2) show me a better way. > > I have a problem that is very state-ful and I keep thinking of it as OO, > which is driving me crazy. Haskell is several times harder to use than > Python in this instance, probably because I'm doing it wrong. > Stop the presses! I had an idea to make this more functional in style. Do it through multiple passes. The idea is that we've got a list of musical events as input ("Node" is a term some algorithmic composers use, so I will use type Node.) In fact we could have other types of input data too, so I might need the algebraic type data InputType = Node ... | CSoundSource ... etc. Then we make a pass through the nodes using map concat to produce a bunch of Output data. data Output = OIStatement ... | OInstrName InstrName -- represents an instrument name -- (ultimately we need a number, but -- won't know that # during first -- pass) | OInstrNum Int -- when we compute an instrument -- number, this will replace the above | OMixer MixerName ... we have a function processInput: processInput :: InputType -> [Output] This expresses the idea that a single input may result in the generation of several pieces of output data. The first pass is just a concat map firstPass :: [InputType] -> [Output] firstPass = concatMap processInput In translating an InputType datum, we look at it "in isolation"---here it sits in front of us in the stream, and we haven't maintained a lot of state---and we translate it to some intermediate Output form, making all specific calculations or substitutions possible at that given time and context. Then further passes are needed, many of which are folds. For example, to assign the instrument number I have some kind of NumberDatabase, but now my dealings with it are limited to a single fold. assignNumbers :: [Output] -> NumberDatabase assignNumbers outputList = foldl g newNumberDatabase outputList where g outputDatum numberDb = case outputDatum of OInstrName n -> ... ah! unassigned name! update db _ -> numberDb -- just return unchanged All the rest of the processing can be done via filters, folds, and maps. Does this seem more functional in style? Thanks, Mike From Christian.Maeder at dfki.de Wed Dec 2 11:10:02 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Dec 2 10:44:45 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <200912021651.36533.daniel.is.fischer@web.de> References: <4B167061.10007@dfki.de> <200912021627.15986.daniel.is.fischer@web.de> <200912021651.36533.daniel.is.fischer@web.de> Message-ID: <4B16915A.2050208@dfki.de> Thanks a lot, works as expected and is super short! Cheers Christian Daniel Fischer schrieb: > > Or: > > fpairs p s l = sequence [[(a,b) | b <- filter (p a) l] | a <- s] From daniel.is.fischer at web.de Wed Dec 2 11:35:34 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 2 11:11:52 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <4B16915A.2050208@dfki.de> References: <4B167061.10007@dfki.de> <200912021651.36533.daniel.is.fischer@web.de> <4B16915A.2050208@dfki.de> Message-ID: <200912021735.36264.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 17:10:02 schrieb Christian Maeder: > Thanks a lot, works as expected and is super short! You're welcome. However, according to a couple of tests, the "funkyName" version is somewhat faster and allocates less. > > Cheers Christian > > Daniel Fischer schrieb: > > Or: > > > > fpairs p s l = sequence [[(a,b) | b <- filter (p a) l] | a <- s] From daniel.is.fischer at web.de Wed Dec 2 11:47:58 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 2 11:24:09 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B168DD5.1010406@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> <4B168DD5.1010406@alumni.caltech.edu> Message-ID: <200912021747.59111.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 16:55:01 schrieb Michael Mossey: > Does this seem more functional in style? Much more :) From Christian.Maeder at dfki.de Wed Dec 2 12:54:51 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Dec 2 12:29:34 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <200912021735.36264.daniel.is.fischer@web.de> References: <4B167061.10007@dfki.de> <200912021651.36533.daniel.is.fischer@web.de> <4B16915A.2050208@dfki.de> <200912021735.36264.daniel.is.fischer@web.de> Message-ID: <4B16A9EB.6090903@dfki.de> Daniel Fischer schrieb: > However, according to a couple of tests, the "funkyName" version is somewhat faster and > allocates less. My timing tests showed that your fpairs version is fastest. (first argument "True" selects filteredPairs, "False" funkyName) My initial version "myf" is almost unusable. C. (code attached) maeder@leibniz:~/haskell/examples> ghc --make -O2 FilteredPairs.hs [1 of 1] Compiling Main ( FilteredPairs.hs, FilteredPairs.o ) Linking FilteredPairs ... maeder@leibniz:~/haskell/examples> time ./FilteredPairs True EQ 5000 5000 real 0m0.567s user 0m0.536s sys 0m0.020s maeder@leibniz:~/haskell/examples> time ./FilteredPairs False EQ 5000 5000 real 0m0.819s user 0m0.796s sys 0m0.012s -------------- next part -------------- A non-text attachment was scrubbed... Name: FilteredPairs.hs Type: text/x-haskell Size: 1086 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091202/a7f58e9a/FilteredPairs.bin From ryani.spam at gmail.com Wed Dec 2 13:44:39 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Dec 2 13:19:20 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <7ca3f0160912011644k4badf367s96fb02f47ed49ae4@mail.gmail.com> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> <4b15a4fc38367_453e4f293e856a@weasel6.tmail> <7ca3f0160912011644k4badf367s96fb02f47ed49ae4@mail.gmail.com> Message-ID: <2f9b2d30912021044k7aff4d11nc1a0261ca457a646@mail.gmail.com> On Tue, Dec 1, 2009 at 4:44 PM, Luke Palmer wrote: > Existential types only buy you power when the quantified variable > appears more than once on the right hand side, for example: ?forall a. > Num a => (a,a). ?But even those can usually be factored out into more > direct representations (I seem to recall Oleg has a proof that they > always can, actually). You are probably right that there is an encoding that doesn't use existentials, but I've found they can be very useful in a few situations, such as: data Step s a = Done | Yield s a | Skip s data Stream a = forall s. Stream s (s -> Step s a) Here the type of the stream state is encapsulated and not accessible to the outside world, but it can still get some values of that type via the result of the Step function. data Expr a where ... App :: Expr (a -> b) -> Expr a -> Expr b Here we quantify over the type of the argument "a"; we just know that we have an expression of that type and an expression of the function type it wants. -- ryan From daniel.is.fischer at web.de Wed Dec 2 14:55:14 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 2 14:33:20 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <4B16A9EB.6090903@dfki.de> References: <4B167061.10007@dfki.de> <200912021735.36264.daniel.is.fischer@web.de> <4B16A9EB.6090903@dfki.de> Message-ID: <200912022055.16082.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 18:54:51 schrieb Christian Maeder: > Daniel Fischer schrieb: > > However, according to a couple of tests, the "funkyName" version is > > somewhat faster and allocates less. > > My timing tests showed that your fpairs version is fastest. > (first argument "True" selects filteredPairs, "False" funkyName) I can confirm that for your test; still funkyName allocates less: ./FilteredPairs True EQ 5000 +RTS -sstderr 5000 1,810,136 bytes allocated in the heap 1,160,412 bytes copied during GC 517,964 bytes maximum residency (1 sample(s)) 16,932 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 2 collections, 0 parallel, 0.01s, 0.01s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.44s ( 0.44s elapsed) GC time 0.01s ( 0.01s elapsed) ./FilteredPairs False EQ 5000 +RTS -sstderr 5000 1,432,328 bytes allocated in the heap 974,252 bytes copied during GC 441,064 bytes maximum residency (1 sample(s)) 27,608 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 2 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.84s ( 0.84s elapsed) GC time 0.01s ( 0.01s elapsed) ./FilteredPairs True GT 5000 +RTS -sstderr 5000 10,961,984 bytes allocated in the heap 12,164,420 bytes copied during GC 3,046,920 bytes maximum residency (4 sample(s)) 25,836 bytes maximum slop 7 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 16 collections, 0 parallel, 0.04s, 0.04s elapsed Generation 1: 4 collections, 0 parallel, 0.03s, 0.04s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.23s ( 0.24s elapsed) GC time 0.08s ( 0.09s elapsed) ./FilteredPairs False GT 5000 +RTS -sstderr 5000 5,246,036 bytes allocated in the heap 5,185,808 bytes copied during GC 1,699,744 bytes maximum residency (2 sample(s)) 27,612 bytes maximum slop 4 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 8 collections, 0 parallel, 0.02s, 0.02s elapsed Generation 1: 2 collections, 0 parallel, 0.02s, 0.01s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.44s ( 0.45s elapsed) GC time 0.04s ( 0.03s elapsed) > > My initial version "myf" is almost unusable. > > C. > > (code attached) > > maeder@leibniz:~/haskell/examples> ghc --make -O2 FilteredPairs.hs > [1 of 1] Compiling Main ( FilteredPairs.hs, FilteredPairs.o ) > Linking FilteredPairs ... > maeder@leibniz:~/haskell/examples> time ./FilteredPairs True EQ 5000 > 5000 > > real 0m0.567s > user 0m0.536s > sys 0m0.020s > maeder@leibniz:~/haskell/examples> time ./FilteredPairs False EQ 5000 > 5000 > > real 0m0.819s > user 0m0.796s > sys 0m0.012s But with a different test, funkyName is considerably faster: ./pairs 1 8 20 +RTS -sstderr -A150M 5529600 899,189,488 bytes allocated in the heap 72,912,040 bytes copied during GC 28,074,964 bytes maximum residency (2 sample(s)) 465,800 bytes maximum slop 200 MB total memory in use (2 MB lost due to fragmentation) Generation 0: 4 collections, 0 parallel, 0.17s, 0.21s elapsed Generation 1: 2 collections, 0 parallel, 0.36s, 0.39s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.72s ( 0.95s elapsed) GC time 0.52s ( 0.60s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.25s ( 1.56s elapsed) %GC time 41.9% (38.8% elapsed) Alloc rate 1,235,074,051 bytes per MUT second Productivity 57.8% of total user, 46.5% of total elapsed ./pairs 2 8 20 +RTS -sstderr -A150M 5529600 651,866,696 bytes allocated in the heap 76,108,204 bytes copied during GC 28,075,464 bytes maximum residency (2 sample(s)) 465,248 bytes maximum slop 200 MB total memory in use (2 MB lost due to fragmentation) Generation 0: 3 collections, 0 parallel, 0.18s, 0.20s elapsed Generation 1: 2 collections, 0 parallel, 0.38s, 0.41s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.61s ( 0.77s elapsed) GC time 0.56s ( 0.61s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.17s ( 1.38s elapsed) %GC time 47.6% (44.0% elapsed) Alloc rate 1,065,075,527 bytes per MUT second Productivity 52.1% of total user, 44.0% of total elapsed ./pairs 3 8 20 +RTS -sstderr -A150M 5529600 516,244,640 bytes allocated in the heap 84,175,532 bytes copied during GC 28,074,916 bytes maximum residency (2 sample(s)) 465,940 bytes maximum slop 200 MB total memory in use (2 MB lost due to fragmentation) Generation 0: 2 collections, 0 parallel, 0.16s, 0.17s elapsed Generation 1: 2 collections, 0 parallel, 0.38s, 0.41s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.42s ( 0.60s elapsed) GC time 0.53s ( 0.58s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.95s ( 1.18s elapsed) %GC time 56.1% (49.0% elapsed) Alloc rate 1,240,892,153 bytes per MUT second Productivity 43.9% of total user, 35.1% of total elapsed ./pairs 4 8 20 +RTS -sstderr -A150M 5529600 271,711,724 bytes allocated in the heap 28,059,740 bytes copied during GC 28,075,488 bytes maximum residency (1 sample(s)) 461,344 bytes maximum slop 172 MB total memory in use (1 MB lost due to fragmentation) Generation 0: 1 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.18s, 0.21s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.24s ( 0.41s elapsed) GC time 0.18s ( 0.21s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.43s ( 0.62s elapsed) %GC time 43.0% (33.3% elapsed) Alloc rate 1,113,504,186 bytes per MUT second Productivity 57.0% of total user, 39.1% of total elapsed Which one is faster depends on what you do, it seems. -------------- next part -------------- A non-text attachment was scrubbed... Name: pairs.hs Type: text/x-haskell Size: 1758 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091202/697a4e52/pairs.bin From aditya87 at gmail.com Wed Dec 2 16:36:07 2009 From: aditya87 at gmail.com (Aditya M) Date: Wed Dec 2 16:10:48 2009 Subject: [Haskell-cafe] Beginner's speed problem Message-ID: Hi, I am trying to solve this problem: https://www.spoj.pl/problems/LASTDIG/ It is very simple. Given a and b, return the last digit of a^b. b could be large, so I used logarithmic exponentiation and wrote/submitted the code below for this problem: ---------------------------------------------------------------------- lastdigit :: Int -> Int -> Int -> Int lastdigit 0 0 _ = 1 lastdigit a b c | even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c | b == 1 = (a*c) `rem` 10 | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c) doit :: [Char] -> Int doit line = lastdigit (read $ head $ words line) (read $ last $ words line) 1 main = do n <- getLine inputs <- sequence $ take (read n) $ repeat getLine let slist = map doit inputs mapM_ (putStrLn.show) slist ------------------------------------------------------------------- As n in main is at most 30, I thought this would easily run in 1 second, but I get a time limit exceeded error on the site. Can someone tell me where my code is taking too much time? Thanks in advance! -- Aditya Manthramurthy From dons at galois.com Wed Dec 2 16:44:01 2009 From: dons at galois.com (Don Stewart) Date: Wed Dec 2 16:18:43 2009 Subject: [Haskell-cafe] Beginner's speed problem In-Reply-To: References: Message-ID: <20091202214401.GL12545@whirlpool.galois.com> aditya87: > Hi, > > I am trying to solve this problem: https://www.spoj.pl/problems/LASTDIG/ > It is very simple. Given a and b, return the last digit of a^b. b > could be large, so I used logarithmic exponentiation and > wrote/submitted the code below for this problem: > > > ---------------------------------------------------------------------- > lastdigit :: Int -> Int -> Int -> Int > lastdigit 0 0 _ = 1 > lastdigit a b c | even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c > | b == 1 = (a*c) `rem` 10 > | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c) > > doit :: [Char] -> Int > doit line = lastdigit (read $ head $ words line) (read $ last $ words line) 1 > > main = do > n <- getLine > inputs <- sequence $ take (read n) $ repeat getLine > let slist = map doit inputs > mapM_ (putStrLn.show) slist > ------------------------------------------------------------------- I notice an unnec. lazy 'c' argument to lastdigit, {-# LANGUAGE BangPatterns #-} lastdigit :: Int -> Int -> Int -> Int lastdigit 0 0 _ = 1 lastdigit a b !c | even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c | b == 1 = (a*c) `rem` 10 | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c) doit :: [Char] -> Int doit line = lastdigit (read $ head $ words line) (read $ last $ words line) 1 main = do n <- getLine inputs <- sequence $ take (read n) $ repeat getLine let slist = map doit inputs mapM_ (putStrLn.show) slist Would generate better code for lastdigit. From mail at joachim-breitner.de Wed Dec 2 17:03:52 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed Dec 2 16:38:37 2009 Subject: [Haskell-cafe] instance Binary UTCTime (Was: Oprhan instances) In-Reply-To: <1259541001.4896.82681.camel@localhost> References: <6d2443150911141020o1d50f40by6530d0f4305c1ffb@mail.gmail.com> <200911190329.39888.daniel.is.fischer@web.de> <1259261051.3456.62.camel@localhost> <200911262032.12007.daniel.is.fischer@web.de> <1259267273.24650.6.camel@localhost> <694519c50911261247n1e5b5b78l3b485a4db23de524@mail.gmail.com> <49a77b7a0911261340r4f530d18o613066ef289c1fc3@mail.gmail.com> <1259501875.4896.79996.camel@localhost> <49a77b7a0911291342kc992aeat575e5c71e61afd6b@mail.gmail.com> <1259541001.4896.82681.camel@localhost> Message-ID: <1259791432.3091.65.camel@localhost> Hi, Am Montag, den 30.11.2009, 00:30 +0000 schrieb Duncan Coutts: > I should also note that distros will not look kindly on solutions that > require N * M separate packages. with my Debian-Developer hat on I can very much support this statement. Which is why I?m so interested in a proper solution to the instance-Providing-problem. And which is why I?m trying to revive the thread now :-) Would it be techically possible and feasible to write instance that do not actually cause a dependency on the package that defines the class resp. the data type? From a distributor point of view, I could live quite well with a setup like this: * When the package providing class Foo is compiled, instances for all interesting data types in the distribution are defined. This means a lot of build-dependencies, but they are not too bad (although annoying). * The generated package does (somehow) not depend on all these data packages. Of course, any part of the code that uses these data types, especially the class instances, are only usable when the corresponding package is also installed. I guess this would need compiler support, to not choke on code that uses unknown data types. * Packages needing an instance Foo Bar would just depend on the packges providing foo and bar, and the instance will be available and functional. This idea works symmetric: The instances could also be defined in the data type package, with no hard dependency on the package providing the class definition. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091202/f3e38f94/attachment.bin From daniel.is.fischer at web.de Wed Dec 2 17:15:55 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 2 16:52:19 2009 Subject: [Haskell-cafe] Beginner's speed problem In-Reply-To: <20091202214401.GL12545@whirlpool.galois.com> References: <20091202214401.GL12545@whirlpool.galois.com> Message-ID: <200912022315.58224.daniel.is.fischer@web.de> Am Mittwoch 02 Dezember 2009 22:44:01 schrieb Don Stewart: > aditya87: > > Hi, > > > > I am trying to solve this problem: https://www.spoj.pl/problems/LASTDIG/ > > It is very simple. Given a and b, return the last digit of a^b. b > > could be large, so I used logarithmic exponentiation and Just to mention it, you can do something much much faster for this problem. Something in the microsecond range (if IO is fast enough, millisecond otherwise). > > wrote/submitted the code below for this problem: > > > > > > ---------------------------------------------------------------------- > > lastdigit :: Int -> Int -> Int -> Int > > lastdigit 0 0 _ = 1 > > lastdigit a b c | even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c > > > > | b == 1 = (a*c) `rem` 10 > > | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) > > | (a*c) > > > > doit :: [Char] -> Int > > doit line = lastdigit (read $ head $ words line) (read $ last $ words > > line) 1 > > > > main = do > > n <- getLine > > inputs <- sequence $ take (read n) $ repeat getLine > > let slist = map doit inputs > > mapM_ (putStrLn.show) slist > > ------------------------------------------------------------------- > > I notice an unnec. lazy 'c' argument to lastdigit, Though for <= 30 inputs and exponents < 2^31, the laziness shouldn't do too much harm, I think. Shouldn't push it over one second, now they've at last replaced 6.6.1. > > > {-# LANGUAGE BangPatterns #-} > > lastdigit :: Int -> Int -> Int -> Int > lastdigit 0 0 _ = 1 > lastdigit a b !c | even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` > 2) c > > | b == 1 = (a*c) `rem` 10 However, | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c) is problematic. The (a*c), to be exact. The exponent may be close to 2^31, so up to 30 bits may be set. You then have a multiplication of up to 30 factors, the first is (< 20), the others (< 10), but it may easily overflow Int range, and then the last digit need not be correct. You need ((a*c) `rem` 10) there. > > doit :: [Char] -> Int > doit line = lastdigit (read $ head $ words line) (read $ last $ words > line) 1 > > main = do > n <- getLine > inputs <- sequence $ take (read n) $ repeat getLine > let slist = map doit inputs > mapM_ (putStrLn.show) slist I'd prefer main = do lns <- fmap lines getContents mapM_ (print . doit) $ tail lns or main = fmap lines getContents >>= mapM_ (print . doit) . tail > > Would generate better code for lastdigit. From andrewcoppin at btinternet.com Wed Dec 2 17:26:12 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Dec 2 17:00:51 2009 Subject: [Haskell-cafe] Finding HP Message-ID: <4B16E984.7070504@btinternet.com> Today I was setting up a my new, and I wanted to put Haskell on it. Rather than download GHC itself, I decided to install the Haskell Platform instead, just to see what it's like. Much to my surprise, I couldn't actually find any reference to its existence anywhere from the haskell.org home page, and I eventually had to run a search to find it. Subsequently, I realise [as somebody will no doubt point out] that the link is actually there, on the front page, right next to GHC, Hugs, et al. My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the "Implementations" page, and maybe the GHC homepage? Just a suggestion... From dons at galois.com Wed Dec 2 17:29:00 2009 From: dons at galois.com (Don Stewart) Date: Wed Dec 2 17:03:43 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <4B16E984.7070504@btinternet.com> References: <4B16E984.7070504@btinternet.com> Message-ID: <20091202222900.GO12545@whirlpool.galois.com> andrewcoppin: > Today I was setting up a my new, and I wanted to put Haskell on it. > Rather than download GHC itself, I decided to install the Haskell > Platform instead, just to see what it's like. > > Much to my surprise, I couldn't actually find any reference to its > existence anywhere from the haskell.org home page, and I eventually had > to run a search to find it. It is listed right on the front page, twice. It is the first link on the page: [Download Haskell] As well as: "[The Haskell Platform] has been released." Are you sure this isn't user error? -- Don From gcross at phys.washington.edu Wed Dec 2 17:44:57 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Wed Dec 2 17:19:46 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <4B16E984.7070504@btinternet.com> References: <4B16E984.7070504@btinternet.com> Message-ID: On Dec 2, 2009, at 2:26 PM, Andrew Coppin wrote: > Subsequently, I realise [as somebody will no doubt point out] that the link is actually there, on the front page, right next to GHC, Hugs, et al. On Dec 2, 2009, at 2:29 PM, Don Stewart wrote: > It is listed right on the front page, twice. Whoa, Andrew, you really can predict the future!!! Any stock market tips? On a more serious note, "Download Haskell" /= "Download Haskell Platform", so if I were glancing down the sidebar looking for a link to download the "Haskell Platform" then the first link wouldn't have registered for me. And putting a "X has been released link!" in the news does not count as a prominent download link. Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: On Dec 2, 2009, at 2:26 PM, Andrew Coppin wrote: > My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the "Implementations" page, and maybe the GHC homepage? Just a suggestion... ... then in my own humble opinion, snapping back with "Are you sure this isn't user error?" is not a particularly nice response. - Greg From martijn at van.steenbergen.nl Wed Dec 2 19:16:16 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Wed Dec 2 18:51:01 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping Message-ID: <4B170350.2070504@van.steenbergen.nl> So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? Thanks, Martijn. From tonymorris at gmail.com Wed Dec 2 19:19:52 2009 From: tonymorris at gmail.com (Tony Morris) Date: Wed Dec 2 18:54:32 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <4B170350.2070504@van.steenbergen.nl> References: <4B170350.2070504@van.steenbergen.nl> Message-ID: <4B170428.204@gmail.com> Isn't that the point of type-classes? Martijn van Steenbergen wrote: > So here's a totally wild idea Sjoerd and I came up with. > > What if newtypes were unwrapped implicitly? > > What advantages and disadvantages would it have? > In what cases would this lead to ambiguous code? > > Thanks, > > Martijn. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Tony Morris http://tmorris.net/ From holgersiegel74 at yahoo.de Wed Dec 2 19:25:37 2009 From: holgersiegel74 at yahoo.de (Holger Siegel) Date: Wed Dec 2 19:00:21 2009 Subject: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping] Message-ID: <1259799937.5053.14.camel@cornfed> Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: > So here's a totally wild idea Sjoerd and I came up with. > > What if newtypes were unwrapped implicitly? > > What advantages and disadvantages would it have? > In what cases would this lead to ambiguous code? 1) instance Monoid a => Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b => Monoid (a -> b) From sjoerd at w3future.com Wed Dec 2 19:40:02 2009 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Wed Dec 2 19:14:48 2009 Subject: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping] In-Reply-To: <1259799937.5053.14.camel@cornfed> References: <1259799937.5053.14.camel@cornfed> Message-ID: <7D26677F-E463-433C-98D7-A438F33E5319@w3future.com> The idea is that there's just enough unwrapping such that you don't need to use getDual and appEndo. On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: > Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van > Steenbergen: >> So here's a totally wild idea Sjoerd and I came up with. >> >> What if newtypes were unwrapped implicitly? >> >> What advantages and disadvantages would it have? >> In what cases would this lead to ambiguous code? > > 1) > instance Monoid a => Monoid (Dual a) > > 2) > instance Monoid (Endo a) > instance Monoid b => Monoid (a -> b) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjoerd@w3future.com From wren at freegeek.org Wed Dec 2 19:43:48 2009 From: wren at freegeek.org (wren ng thornton) Date: Wed Dec 2 19:18:30 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: <1259671018-sup-4320@peray> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <1259671018-sup-4320@peray> Message-ID: <4B1709C4.7060707@freegeek.org> Nicolas Pouillard wrote: > Excerpts from Heinrich Apfelmus's message of Tue Dec 01 11:29:24 +0100 2009: >> I propose to (trivially) generalize this type to "list with an end" >> >> data ListEnd a b = Cons a (ListEnd a b) >> | End b >> >> because it may have other uses than just lazy error handling. For >> mnemonic value, we could call it a "train": >> >> data Train a b = Wagon a (Train a b) >> | Loco b >> >> [...] > > This proposition looks quite nice and gently subsume the ListThenError > type. > > type ListThenError e a = Train a (Maybe e) > > Anyone to put this on Hackage? I rather like it too. The mnemonic version sounds a lot nicer than "ListEnd", though I'd probably call the constructors Cabin and Caboose. The nice thing about the generalization is that even though (Train a b) is very similar to ([a],b) it's not exactly isomorphic. There are differences in the strictness of generating them and I've often wanted something like Train. Wherever this ends up, it'd be pretty easy to do train-fusion in order to reduce the cost over using lists. If noone else wants to take it, I could probably find a few tuits to get it done. Though it looks like John Millikin already has failable-list up on Hackage, which differs only in also having a Nil to end with (which interferes with certain fusions, but not the major ones). -- Live well, ~wren From gcross at phys.washington.edu Wed Dec 2 19:42:55 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Wed Dec 2 19:20:34 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <4B170350.2070504@van.steenbergen.nl> References: <4B170350.2070504@van.steenbergen.nl> Message-ID: <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> Out of curiosity, why would one want a "newtype" that were unwrapped implicitly, rather than just using "type"? Personally, whenever I use a newtype it is precisely because I *want* the compiler not to implicitly turn it into something else in order to protect myself. Cheers, Greg On Dec 2, 2009, at 4:16 PM, Martijn van Steenbergen wrote: > So here's a totally wild idea Sjoerd and I came up with. > > What if newtypes were unwrapped implicitly? > > What advantages and disadvantages would it have? > In what cases would this lead to ambiguous code? > > Thanks, > > Martijn. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From garious at gmail.com Wed Dec 2 20:08:03 2009 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Dec 2 19:43:05 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> References: <4B170350.2070504@van.steenbergen.nl> <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> Message-ID: <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> Gregory Crosswhite wrote: > Out of curiosity, why would one want a "newtype" that were unwrapped implicitly, rather than just using "type"? One reason might be because you only switched from 'type' to 'newtype' so that you could write more refined Arbitrary instances for your QuickCheck tests. -Greg From lrpalmer at gmail.com Wed Dec 2 20:22:07 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Dec 2 19:56:48 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> References: <4B170350.2070504@van.steenbergen.nl> <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> Message-ID: <7ca3f0160912021722x4211008dg6ca77009f321edf7@mail.gmail.com> On Wed, Dec 2, 2009 at 6:08 PM, Greg Fitzgerald wrote: > Gregory Crosswhite wrote: >> Out of curiosity, why would one want a "newtype" that were unwrapped implicitly, rather than just using "type"? > > One reason might be because you only switched from 'type' to 'newtype' > so that you could write more refined Arbitrary instances for your > QuickCheck tests. Maybe that is an indication that we should use a checker combinator library instead of typeclasses for automated testing. Less convenient, more adaptable. Luke From gcross at phys.washington.edu Wed Dec 2 20:32:09 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Wed Dec 2 20:10:51 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> References: <4B170350.2070504@van.steenbergen.nl> <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> Message-ID: <13C675B1-481E-423F-A7C3-C884D2E56F17@phys.washington.edu> Ah, that's a really good point. It seems then that there is a use for implicitly unwrapped newtypes, but perhaps only when you never really wanted to use a newtype to begin with but had to in order to use a different instance declaration for the same type. That suggests that the feature we'd really like is a way to declare that we want a type in a context to act as if it had a different instance declaration for a given typeclass, without having to go through newtype. Cheers, Greg On Dec 2, 2009, at 5:08 PM, Greg Fitzgerald wrote: > Gregory Crosswhite wrote: >> Out of curiosity, why would one want a "newtype" that were unwrapped implicitly, rather than just using "type"? > > One reason might be because you only switched from 'type' to 'newtype' > so that you could write more refined Arbitrary instances for your > QuickCheck tests. > > -Greg From rwbarton at math.harvard.edu Wed Dec 2 21:29:29 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Wed Dec 2 21:04:10 2009 Subject: [Haskell-cafe] instance Binary UTCTime (Was: Oprhan instances) In-Reply-To: <1259791432.3091.65.camel@localhost> References: <200911190329.39888.daniel.is.fischer@web.de> <1259261051.3456.62.camel@localhost> <200911262032.12007.daniel.is.fischer@web.de> <1259267273.24650.6.camel@localhost> <694519c50911261247n1e5b5b78l3b485a4db23de524@mail.gmail.com> <49a77b7a0911261340r4f530d18o613066ef289c1fc3@mail.gmail.com> <1259501875.4896.79996.camel@localhost> <49a77b7a0911291342kc992aeat575e5c71e61afd6b@mail.gmail.com> <1259541001.4896.82681.camel@localhost> <1259791432.3091.65.camel@localhost> Message-ID: <20091203022929.GA3316@rwbarton.mit.edu> On Wed, Dec 02, 2009 at 11:03:52PM +0100, Joachim Breitner wrote: > Hi, > > Am Montag, den 30.11.2009, 00:30 +0000 schrieb Duncan Coutts: > > I should also note that distros will not look kindly on solutions that > > require N * M separate packages. > > with my Debian-Developer hat on I can very much support this statement. > Which is why I?m so interested in a proper solution to the > instance-Providing-problem. And which is why I?m trying to revive the > thread now :-) > > Would it be techically possible and feasible to write instance that do > not actually cause a dependency on the package that defines the class > resp. the data type? It is technically possible, using Template Haskell, by exporting a TH value representing the instance, which can be constructed without importing the module where the class is defined, and leaving it to the importer (which has that module imported as well) to splice in the class declaration. ----- file A.hs module A where class Foo a where foo :: Int -> a ----- file B.hs {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH -- do not import A newtype Bar = Bar Int deriving Show -- the TH equivalent of "instance Foo Bar where foo = Bar" instanceFooBar :: Q [Dec] instanceFooBar = return [InstanceD [] (AppT (ConT $ mkName "A.Foo") (ConT $ mkName "B.Bar")) [ValD (VarP $ mkName "foo") (NormalB (ConE $ mkName "B.Bar")) []]] ----- file C.hs {-# LANGUAGE TemplateHaskell #-} import A import B $(instanceFooBar) main = print (foo 3 :: Bar) ----- Needless to say it would be preferable not to write instances directly as TH syntax trees! Unfortunately (for our purposes) the definition "instanceFooBar = [d| instance A.Foo Bar where foo = Bar |]" is rejected by the compiler unless A is imported in B (it complains that A.Foo and foo are not in scope). I suppose one could create a class B.Foo with the same definition as A.Foo, write a quoted instance referring to A.Foo, and use some generic programming to replace all occurrences of B.Foo with A.Foo. Of course, module B still sort of depends on module A in the sense that if the definition of A.Foo changes, importers of B will no longer be able to use instanceFooBar until B is updated. On the other hand B could export TH descriptions of multiple instance corresponding to different versions of A.Foo, relying on the importer to select the one which matches its selected version of A. Regards, Reid Barton From garious at gmail.com Wed Dec 2 21:40:08 2009 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Dec 2 21:15:08 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <13C675B1-481E-423F-A7C3-C884D2E56F17@phys.washington.edu> References: <4B170350.2070504@van.steenbergen.nl> <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> <13C675B1-481E-423F-A7C3-C884D2E56F17@phys.washington.edu> Message-ID: <1f3dc80d0912021840m6734a07by2bcd3ffaecbd63ce@mail.gmail.com> > That suggests that the feature we'd really like is a way > to declare that we want a type in a context to act as if it > had a different instance declaration for a given typeclass, > without having to go through newtype. I'd want implicit type coercion from subtypes, so that you wouldn't need an infinite hierarchy of nested typeclasses to implement the following for all integers: data One = One -- Somehow tell GHC that One is a subset of Integer (without implementing Num) oneToInteger :: One -> Integer oneToInteger One = 1 One + One == (2 :: Integer) Seems like something Agda could handle. -Greg From byorgey at seas.upenn.edu Wed Dec 2 22:10:11 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Dec 2 21:44:52 2009 Subject: [Haskell-cafe] Second Call for Copy: Monad.Reader Issue 15 Message-ID: <20091203031010.GA31664@seas.upenn.edu> It's not too late to write something for Issue 15 of the Monad.Reader! Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The submission deadline for Issue 15 is **Friday, January 8, 2010** The Monad.Reader ~~~~~~~~~~~~~~~~ The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki-page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~~~~~~~~~~~~~~~~~ Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. I am also happy to provide feedback on draft versions before the submission deadline. Please submit articles for the next issue to me by e-mail (byorgey at cis.upenn.edu). Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll sort something out. From DekuDekuplex at Yahoo.com Thu Dec 3 00:05:33 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Dec 2 23:40:33 2009 Subject: [Haskell-cafe] universal binary version of Haskell Platform? Message-ID: <34heh5557a7pdou2jokj05ia77dlc2e7kb@4ax.com> Recently, in changing my work schedule to work mainly from home, I switched from mainly using a work Wintel machine running Windows XP Professional, Service Pack 3, to mainly using my home PowerPC G4 PowerBook Macintosh, currently upgraded to Mac OS X 10.5.8 Leopard. However, to my surprise, there does not seem to be a version of the Haskell Platform that runs natively on my current OS. Does anybody know where to find a universal binary version of the Haskell Platform, or at least of GHC 6.10.4? Otherwise, I'm stuck without a native version. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From gcross at phys.washington.edu Thu Dec 3 00:46:27 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 3 00:21:19 2009 Subject: [Haskell-cafe] Haddock Secrets? Message-ID: Hey everyone, Is there some secret to getting Haddock to work with literate Haskell sources that I am missing? For example, when I download Takusen and type cabal configure cabal haddock It produces HTML files complete with a table of contents, but with all of the documentation stripped out. Oddly, I know that it is *possible* to process the literate sources into documentation because it appears on Hackage! I am doing this on OSX Snow Leopard with GHC 6.10.4 and Haddock 2.5. Thanks, Greg From aditya87 at gmail.com Thu Dec 3 00:52:01 2009 From: aditya87 at gmail.com (Aditya M) Date: Thu Dec 3 00:26:41 2009 Subject: [Haskell-cafe] Beginner's speed problem In-Reply-To: <200912022315.58224.daniel.is.fischer@web.de> References: <20091202214401.GL12545@whirlpool.galois.com> <200912022315.58224.daniel.is.fischer@web.de> Message-ID: Hello Thanks for all the help! I only have a couple of questions. On Thu, Dec 3, 2009 at 03:45, Daniel Fischer wrote: > Am Mittwoch 02 Dezember 2009 22:44:01 schrieb Don Stewart: >> aditya87: >> > Hi, >> > >> > I am trying to solve this problem: https://www.spoj.pl/problems/LASTDIG/ >> > It is very simple. Given a and b, return the last digit of a^b. b >> > could be large, so I used logarithmic exponentiation and > > Just to mention it, you can do something much much faster for this problem. > Something in the microsecond range (if IO is fast enough, millisecond otherwise). > I guess you mean that we can find the cycle that the last digits follow while multiplying repeatedly by a, and then use that. I'll try that next in Haskell! >> ? ? {-# LANGUAGE BangPatterns #-} >> >> ? ? lastdigit :: Int -> Int -> Int -> Int >> ? ? lastdigit 0 0 _ ?= 1 >> ? ? lastdigit a b !c | even b ? ?= lastdigit ( (a*a) `rem` 10 ) (b `quot` >> 2) c >> >> ? ? ? ? ? ? ? ? ? ? ?| b == 1 ? ?= (a*c) `rem` 10 > > However, > > ? | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c) This bang pattern (!c) is giving me pattern match errors. Is its only effect evaluating c instead of plain substitution? -- Aditya Manthramurthy From gcross at phys.washington.edu Thu Dec 3 00:58:35 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 3 00:34:40 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <1f3dc80d0912021840m6734a07by2bcd3ffaecbd63ce@mail.gmail.com> References: <4B170350.2070504@van.steenbergen.nl> <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> <13C675B1-481E-423F-A7C3-C884D2E56F17@phys.washington.edu> <1f3dc80d0912021840m6734a07by2bcd3ffaecbd63ce@mail.gmail.com> Message-ID: <8446E77D-5E6C-40C7-8838-56C984946E52@phys.washington.edu> But it seems to me like the whole point of using "newtype" is because you *don't* want your new type to be used everywhere that the old type can be used; otherwise you would just use "type" to create an alias. The only convincing exception I have heard to this (as you helpfully explained to me) is that one might be forced to use newtype to make a piece of code use a different instance declaration for a type. In particular, I am not sure what you are getting at with your example, since one :: Integer one = 1 works just as well. Why did you want to define a new type? Cheers, Greg On Dec 2, 2009, at 6:40 PM, Greg Fitzgerald wrote: >> That suggests that the feature we'd really like is a way >> to declare that we want a type in a context to act as if it >> had a different instance declaration for a given typeclass, >> without having to go through newtype. > > I'd want implicit type coercion from subtypes, so that you wouldn't > need an infinite hierarchy of nested typeclasses to implement the > following for all integers: > > data One = One > > -- Somehow tell GHC that One is a subset of Integer (without > implementing Num) > oneToInteger :: One -> Integer > oneToInteger One = 1 > > One + One == (2 :: Integer) > > Seems like something Agda could handle. > > -Greg From batterseapower at hotmail.com Thu Dec 3 02:40:13 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Dec 3 02:14:53 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <8446E77D-5E6C-40C7-8838-56C984946E52@phys.washington.edu> References: <4B170350.2070504@van.steenbergen.nl> <476F1018-B281-43D4-B535-78E47359C4A0@phys.washington.edu> <1f3dc80d0912021708q76d5a57fg466fad16331708c9@mail.gmail.com> <13C675B1-481E-423F-A7C3-C884D2E56F17@phys.washington.edu> <1f3dc80d0912021840m6734a07by2bcd3ffaecbd63ce@mail.gmail.com> <8446E77D-5E6C-40C7-8838-56C984946E52@phys.washington.edu> Message-ID: <9d4d38820912022340x51bbe4f6hf453b62b4b1ae1a6@mail.gmail.com> 2009/12/3 Gregory Crosswhite : > But it seems to me like the whole point of using "newtype" is because you *don't* want your new type to be used everywhere that the old type can be used; ?otherwise you would just use "type" to create an alias. ?The only convincing exception I have heard to this (as you helpfully explained to me) is that one might be forced to use newtype to make a piece of code use a different instance declaration for a type. You might also be forced to use a newtype because you need to use it recursively - i.e. you need an alternative to equirecursive types. I hit this quite often when building datatype using fixpoints-of-a-functor and regularly wish for the ability to write: type Fix f = f (Fix f) Cheers, Max From tomahawkins at gmail.com Thu Dec 3 03:02:19 2009 From: tomahawkins at gmail.com (Tom Hawkins) Date: Thu Dec 3 02:36:59 2009 Subject: [Haskell-cafe] Re: [Haskell] Interesting experiences of test automation in Haskell? Automation of Software Test 2010 In-Reply-To: <727FFF824663494EBF5DF9E7E2B25764@HALL> References: <727FFF824663494EBF5DF9E7E2B25764@HALL> Message-ID: <594c1e830912030002x7458cc16tc75bc668fcd5140@mail.gmail.com> On Fri, Nov 27, 2009 at 9:30 PM, John Hughes wrote: > This is a "heads up" about a workshop on test automation that I just joined > the programme committee of. Automation of Software Test will be co-located > with ICSE in Cape Town in May--the workshop home page is?here: > > http://www.cs.allegheny.edu/ast2010/ > > Tools like QuickCheck, SmallCheck and HUnit fit the call for papers > perfectly. So if you're doing some interesting automated testing in Haskell, > why not submit a paper about it, and show a new audience what the Haskell > community is up to? Both research papers and case studies are welcome, and > the latter can even be in the form of a presentation of up to 15 slides--so > there's no excuse for not putting something together! Recently we added a unit testing framework to Atom: a haskell DSL for hard realtime embedded applications. The framework hooks into Atom's assertion and functional coverage statements and provides some basic randomization utilities for automatic test generation. We've used this framework to test the embedded software of Eaton's parallel hydraulic hybrid application (HLA). One nice feature we've incorporated for our application is in the event of an assertion violation, simulation data is formated such that we can use the same analysis and debug tools that we use for real vehicle telemetry. I don't think we can make it to Cape Town, but I'll see if one of us can write up a case study. (Shruti, Tejas, Jake, any interest?) Here's an example test log from Language.Atom.Unit: pass: processTest1 cycles = 1000 pass: dualProcessTest cycles = 1000 pass: processNoDeactivationGuard cycles = 1000 pass: processNoActivationGuard cycles = 1000 pass: processDuelingProcesses cycles = 1000 pass: arbiterTest1 cycles = 1000 pass: arbiterTest2 cycles = 1000 pass: arbiterTest3 cycles = 1000 pass: arbiterTest8 cycles = 1000 pass: arbiterTest10 cycles = 1000 pass: absDisengagementTest cycles = 35000 pass: cruiseControlDisengagementTest cycles = 35000 pass: engineSpeedDisengagementTest cycles = 35000 pass: pumpSpeedDisengagementTest cycles = 35000 pass: ignitionDisengagementTest cycles = 35000 pass: selectedGearDisengagementTest cycles = 35000 pass: currentGearDisengagementTest cycles = 35000 pass: modeDisengagementTest cycles = 35000 pass: commissioningProcessDisengagementTest cycles = 35000 pass: canEEC1DisengagementTest cycles = 35000 pass: canEEC2DisengagementTest cycles = 35000 pass: canETC1DisengagementTest cycles = 35000 pass: canETC2DisengagementTest cycles = 35000 pass: canEBCDisengagementTest cycles = 35000 pass: canECCDisengagementTest cycles = 35000 pass: driverisolationFaultDisengagementTest cycles = 35000 pass: drivermodeDrainFaultDisengagementTest cycles = 35000 pass: drivermodeFillFaultDisengagementTest cycles = 35000 pass: drivermainBypassFaultDisengagementTest cycles = 35000 pass: driverchargeBypassFaultDisengagementTest cycles = 35000 pass: driverclutch1FaultDisengagementTest cycles = 35000 pass: driverclutch2FaultDisengagementTest cycles = 35000 pass: driverclutch3FaultDisengagementTest cycles = 35000 pass: driverpumpFaultDisengagementTest cycles = 35000 pass: drivermotorFaultDisengagementTest cycles = 35000 pass: coolerFanOnOffTest cycles = 40000 pass: stateTransitionTest cycles = 75000 pass: swashCmdInBootstrapTest cycles = 40000 pass: brakePressureAboveRangeAndTxSpeedDisengagementTest cycles = 35000 pass: brakePressureAboveRangeDisengagementTest cycles = 35000 pass: accumulatorPressureBelowRangeDisengagementTest cycles = 35000 pass: accumulatorPressureAboveRangeDisengagementTest cycles = 35000 pass: sawsh1BelowRangeDisengagementTest cycles = 35000 pass: swash1AboveRangeDisengagementTest cycles = 35000 pass: swash2BelowRangeDisengagementTest cycles = 35000 pass: swash2AboveRangeDisengagementTest cycles = 35000 pass: swashDiffOnBoundaryDisengagementTest cycles = 35000 pass: swashDiffAboveRangeDisengagementTest cycles = 35000 pass: pumpCaseOilTempCAboveRangeDisengagementTest cycles = 35000 pass: pumpCaseOilTempCBelowRangeDisengagementTest cycles = 35000 pass: pumpCaseOilTempCBoundaryDisengagementTest cycles = 35000 pass: reservoirOilTempCAboveRangeDisengagementTest cycles = 35000 pass: reservoirOilTempCBelowRangeDisengagementTest cycles = 35000 pass: reservoirOilTempCBoundaryDisengagementTest cycles = 35000 pass: tempSensorMiscompareAboveRangeDisengagementTest cycles = 35000 pass: tempSensorMiscompareBoundaryDisengagementTest cycles = 35000 pass: reservoirOilTempCTooExtremeDisengagementTest cycles = 35000 pass: reservoirOilTempCTooExtremeBoundaryDisengagementTest cycles = 35000 pass: reservoirOilLevelGalLDisengagementTest cycles = 35000 pass: reservoirOilLevelGalHDisengagementTest cycles = 35000 pass: pumpSpeedAboveRangeLDisengagementTest cycles = 35000 pass: pumpSpeedAboveRangeHDisengagementTest cycles = 35000 pass: accumOverPressureBoundaryDisengagementTest cycles = 35000 pass: accumOverPressureAboveRangeDisengagementTest cycles = 35000 pass: filterPressureBelowRangeDisengagementTest cycles = 35000 pass: filterPressureAboveRangeDisengagementTest cycles = 35000 pass: 5VSupplyBelowRangeDisengagementTest cycles = 35000 pass: 5VSupplyAboveRangeDisengagementTest cycles = 35000 pass: 12VSupplyBelowRangeDisengagementTest cycles = 35000 pass: 12VSupplyAboveRangeDisengagementTest cycles = 35000 pass: stuckEngagedDisengagementTest cycles = 35000 pass: stuckOilLevelDisengagementTest cycles = 35000 pass: clutchdisengagementFaultTest cycles = 40000 pass: clutchSensorMiscompareFault cycles = 40000 pass: clutchSensorMiscompareFaultAbovePumpSpeedandabsRangeTest cycles = 40000 pass: clutchSensorMiscompareFaultAbovePumpSpeedandBelowabsRangeTest cycles = 40000 pass: clutchSensorMiscompareFaultBoundaryTest cycles = 40000 pass: clutchSensorMiscompareFaultAboveRangeTest cycles = 40000 pass: unexpectedDisengagementTest cycles = 40000 pass: failedEngagementAttemptsTest cycles = 40000 pass: fanOffTest cycles = 30000 pass: evuTest cycles = 30000 pass: swashCalTest cycles = 40000 pass: seedKey32Test1 cycles = 100 pass: seedKey32Test2 cycles = 100 pass: seedKey32Test3 cycles = 100 pass: seedKey32Test4 cycles = 100 pass: seedKey32Test5 cycles = 100 pass: seedKey32Test6 cycles = 100 pass: seedKey32Test7 cycles = 100 Total Passing Tests : 90 / 90 Total Simulation Cycles : 2650700 Total Function Coverage : 102 / 102 GREEN LIGHT > > So how about it? It would be great to see some Haskell papers at the > workshop! Deadline 20 January. > > John Hughes > > PS Check out the ICSE web site for information on the location: > http://www.sbs.co.za/ICSE2010/ > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > From vandijk.roel at gmail.com Thu Dec 3 03:37:48 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Dec 3 03:12:28 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: References: <4B16E984.7070504@btinternet.com> Message-ID: On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite wrote: > On a more serious note, "Download Haskell" /= "Download Haskell Platform", so if I were glancing down the sidebar looking for a link to download the "Haskell Platform" then the first link wouldn't have registered for me. ?And putting a "X has been released link!" in the news does not count as a prominent download link. If I wanted to know something *about* the *Haskell Platform* I would click the link The Haskell Platform under the section About. So it is actually mentioned 3 times on the front page. What could be improved are the 2 download links: "Download Haskell" and "Download GHC". It would perhaps be better to have one nice big "Download" button that takes you to a separate download page. > Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: > ... then in my own humble opinion, snapping back with "Are you sure this isn't user error?" is not a particularly nice response. E-mail isn't the best medium to convey emotion. I read Dons reply as "Are you sure this is a problem with the front page and not a slight oversight on your part?" Regards, Roel van Dijk From tonymorris at gmail.com Thu Dec 3 03:51:49 2009 From: tonymorris at gmail.com (Tony Morris) Date: Thu Dec 3 03:26:29 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: References: <4B16E984.7070504@btinternet.com> Message-ID: <4B177C25.8070001@gmail.com> > Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: > > On Dec 2, 2009, at 2:26 PM, Andrew Coppin wrote: > > >> My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the "Implementations" page, and maybe the GHC homepage? Just a suggestion... >> > > ... then in my own humble opinion, snapping back with "Are you sure this isn't user error?" is not a particularly nice response. > > When someone asks a question after being offered feedback designed to improve a page, and does so in a very non-threatening way: > Are you sure this isn't user error? ... then in my own humble opinion, snapping back with "\"Are you sure this isn't a user error?\" is not a particularly nice response" is not a particularly nice response. -- Tony Morris http://tmorris.net/ From noteed at gmail.com Thu Dec 3 03:57:21 2009 From: noteed at gmail.com (minh thu) Date: Thu Dec 3 03:32:20 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <4B177C25.8070001@gmail.com> References: <4B16E984.7070504@btinternet.com> <4B177C25.8070001@gmail.com> Message-ID: <40a414c20912030057y1bd95869x108c782a7ee98170@mail.gmail.com> 2009/12/3 Tony Morris : > >> Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: >> >> On Dec 2, 2009, at 2:26 PM, Andrew Coppin wrote: >> >> >>> My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the "Implementations" page, and maybe the GHC homepage? Just a suggestion... >>> >> >> ... then in my own humble opinion, snapping back with "Are you sure this isn't user error?" is not a particularly nice response. >> >> > When someone asks a question after being offered feedback designed to > improve a page, and does so in a very non-threatening way: > >> Are you sure this isn't user error? > > ... then in my own humble opinion, snapping back with "\"Are you sure > this isn't a user error?\" is not a particularly nice response" is not a > particularly nice response. HumbleOpinion> putStrLn response *** Exception: stack overflow Cheers, Thu From Alistair.Bayley at invesco.com Thu Dec 3 04:17:29 2009 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Thu Dec 3 03:52:13 2009 Subject: [Haskell-cafe] Haddock Secrets? In-Reply-To: References: Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9110264D5@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of > Gregory Crosswhite > > Is there some secret to getting Haddock to work with literate > Haskell sources that I am missing? > > For example, when I download Takusen and type > > cabal configure > cabal haddock > > It produces HTML files complete with a table of contents, but > with all of the documentation stripped out. Oddly, I know > that it is *possible* to process the literate sources into > documentation because it appears on Hackage! You need a recent version of cabal i.e. >= 1.6.0.3. I don't think the haddock version matters much (cabal can handle haddock-1 and haddock-2, I think). The problem is that haddock does not retain literate comments i.e. the .lhs preprocessor is run before haddock parses the file, and literate comments are stripped. This has been fixed in cabal by having cabal preprocess the .lhs file itself, with a special preprocessor that retains literate comments. The resulting .hs file is passed to haddock, and voil?. Before cabal solved the problem, I used to run a similar custom preprocessor over the Takusen source tree, and then invoke haddock manually to create the html docs. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From gcross at phys.washington.edu Thu Dec 3 04:28:46 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 3 04:04:06 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: References: <4B16E984.7070504@btinternet.com> Message-ID: > If I wanted to know something *about* the *Haskell Platform* I would > click the link The Haskell Platform under the section About. So it is > actually mentioned 3 times on the front page. What could be improved > are the 2 download links: "Download Haskell" and "Download GHC". It > would perhaps be better to have one nice big "Download" button that > takes you to a separate download page. Good thinking! >> Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: >> ... then in my own humble opinion, snapping back with "Are you sure this isn't user error?" is not a particularly nice response. > > E-mail isn't the best medium to convey emotion. I read Dons reply as > "Are you sure this is a problem with the front page and not a slight > oversight on your part?" Fair enough, and I will be the first person to admit that my own response was not the nicest way that I could have --- wait, hold on... darn you Tony Morris, you beat me to it! Fine, in that case I will be the *second* person to admit that my own response was not the nicest way that I could have counter-responded. I maintain, though, that when someone describes an experience they had using something in which they got confused, and offers constructive feedback on how things might be improved so that others could be less confused in the future, then it is much better to reply to the person's suggestions and whether they are good or bad ideas, rather than to describe why it was unreasonable for the person to have been confused, since the latter kind of response will just turn the person off from offering potentially helpful suggestions in the future. Cheers, Greg From JohnDEarle at cox.net Thu Dec 3 04:49:52 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 3 04:24:48 2009 Subject: [Haskell-cafe] On the Meaning of Haskell 8 Message-ID: <01DFE4B5A09B4FFB9F3463654034D443@JohnPC> This is a continuation of what I wrote on the Haskell Prime mailing list which accounts for why this is the eighth in the series. These are lecture notes and if anyone has not already noticed from the Haskell Prime mailing list. I am giving a lecture. Type aliases allow you to extend the type system beyond the capabilities of the language. For example, natural numbers are not part of the type system, but you can say that a number has the natural number type by using a type alias. Ensuring that a number is indeed a natural number is your problem. The compiler will only ensure that it is at least an integer. There are a variety of instances where type aliases are useful. A prominent application in computer programming languages is to establish a form verses function relationship. Types in functional languages are formal types and not functional types ironically. A common example of this is to define an address type alias where you declare it as a string. Yes, it is a string formally, but it does not function as such. Its semantics are more specific and so it is not merely a string. How it behaves in context will differ and be more specific than a string. To quote Dune, "There is a place terrifying to us, women, that we cannot go." The compiler cannot go there, but it can verify that it is at least a string. The form verses function distinction is especially useful when unifying against a tuple. Functional types can in large measure supplant labels. When you know its functional type you will usually know enough to know what it is referring to. When all you know is its formal type it can be touch and go. It is possible as the programmer to develop a set of rules beyond those that ensure that the address type is a string that for the benefit of the programmer describe where it is grammatically correct for variables of the address type may appear to which the compiler is wholly ignorant. When defining tuple types, type aliases were intended to replace labels. The result is more compact. The down side is that to access members unification must be employed. In the C language type aliases can be created using either the C preprocessor or the typedef construct. Consequently, this notion of type alias does not apply exclusively to functional languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/fbd76439/attachment.html From mail at joachim-breitner.de Thu Dec 3 05:07:51 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Dec 3 04:42:31 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <4B170350.2070504@van.steenbergen.nl> References: <4B170350.2070504@van.steenbergen.nl> Message-ID: <1259834871.3407.5.camel@localhost> Hi, Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: > So here's a totally wild idea Sjoerd and I came up with. > > What if newtypes were unwrapped implicitly? > > What advantages and disadvantages would it have? > In what cases would this lead to ambiguous code? not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: ?Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.? Instead I find my self writing manually code like myfoo :: (Blubb -> MyFoo) -> MyFoo -> MyFoo -> MyFoo myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) I guess TH could probably do this. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/92f05b6e/attachment.bin From sjoerd at w3future.com Thu Dec 3 05:25:36 2009 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Thu Dec 3 05:00:20 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <1259834871.3407.5.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: Hmm, as long as you provide a type signature, Haskell could do implicit wrapping as well. If I'm not mistaken, the compiler should be able to figure out what to do in this case: > myfoo :: (Blubb -> MyFoo) -> MyFoo -> MyFoo -> MyFoo > myfoo = foo Sjoerd On Dec 3, 2009, at 11:07 AM, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van > Steenbergen: >> So here's a totally wild idea Sjoerd and I came up with. >> >> What if newtypes were unwrapped implicitly? >> >> What advantages and disadvantages would it have? >> In what cases would this lead to ambiguous code? > > not sure if this is what you are thinking at, but everytime I wrap a > type Foo in a newtype MyFoo to define my own instances (or just for more > expressiveness code), I wish I had a way to tell the compiler: > ?Please define function myfoo to be the same as foo, with all occurences > of Foo in its type signature replaced by MyFoo.? > > Instead I find my self writing manually code like > > myfoo :: (Blubb -> MyFoo) -> MyFoo -> MyFoo -> MyFoo > myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) > > I guess TH could probably do this. > > Greetings, > Joachim > > > -- > Joachim "nomeata" Breitner > mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C > JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ > Debian Developer: nomeata@debian.org > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjoerd@w3future.com From mail at joachim-breitner.de Thu Dec 3 05:31:50 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Dec 3 05:06:33 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: <1259836310.3407.6.camel@localhost> Hi, Am Donnerstag, den 03.12.2009, 11:25 +0100 schrieb Sjoerd Visscher: > Hmm, as long as you provide a type signature, Haskell could do implicit wrapping as well. > > If I'm not mistaken, the compiler should be able to figure out what to do in this case: > > myfoo :: (Blubb -> MyFoo) -> MyFoo -> MyFoo -> MyFoo > > myfoo = foo Maybe it should, but it does not: $ cat test.hs data Foo = Foo newtype MyFoo = MyFoo { unMyFoo :: Foo } foo :: Foo -> (() -> Foo) -> Foo foo Foo f = Foo myfoo :: MyFoo -> (() -> MyFoo) -> MyFoo myfoo = foo $ runhaskell test.hs test.hs:9:8: Couldn't match expected type `MyFoo' against inferred type `Foo' In the expression: foo In the definition of `myfoo': myfoo = foo Greetings, JOachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/e4d5ce04/attachment-0001.bin From JohnDEarle at cox.net Thu Dec 3 05:45:55 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 3 05:20:50 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping Message-ID: I am uncertain if what any of you seek makes sense. The type checker is concerned with establishing a principle type and that is what is being reported, the principle type. The compiler as I pointed out in "On the Meaning of Haskell 8" by design has not a clue as to the significance your type alias has. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/9aec892f/attachment.html From holgersiegel74 at yahoo.de Thu Dec 3 05:47:07 2009 From: holgersiegel74 at yahoo.de (Holger Siegel) Date: Thu Dec 3 05:21:47 2009 Subject: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping] In-Reply-To: <7D26677F-E463-433C-98D7-A438F33E5319@w3future.com> References: <1259799937.5053.14.camel@cornfed> <7D26677F-E463-433C-98D7-A438F33E5319@w3future.com> Message-ID: <1259837227.2756.8.camel@cornfed> Am Donnerstag, den 03.12.2009, 01:40 +0100 schrieb Sjoerd Visscher: > The idea is that there's just enough unwrapping such that you don't > need to use getDual and appEndo. Yes, but what does Dual [1] `mappend Dual [2] mean then? Should it use the Monoid instance of Dual and return Dual [2, 1] ? Should it unwrap the lists beforehand and re-wrap them afterwards and return Dual [1, 2] ? Should it unwrap the resulting list afterwards and return [1, 2] or even [2,1] ? That's not obvious to me. > On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: > > > Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van > > Steenbergen: > >> So here's a totally wild idea Sjoerd and I came up with. > >> > >> What if newtypes were unwrapped implicitly? > >> > >> What advantages and disadvantages would it have? > >> In what cases would this lead to ambiguous code? > > > > 1) > > instance Monoid a => Monoid (Dual a) > > > > 2) > > instance Monoid (Endo a) > > instance Monoid b => Monoid (a -> b) > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- > Sjoerd Visscher > sjoerd@w3future.com > > > From duncan.coutts at googlemail.com Thu Dec 3 05:52:35 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu Dec 3 05:27:20 2009 Subject: [Haskell-cafe] universal binary version of Haskell Platform? In-Reply-To: <34heh5557a7pdou2jokj05ia77dlc2e7kb@4ax.com> References: <34heh5557a7pdou2jokj05ia77dlc2e7kb@4ax.com> Message-ID: <1259837555.4896.102798.camel@localhost> On Thu, 2009-12-03 at 14:05 +0900, Benjamin L.Russell wrote: > Recently, in changing my work schedule to work mainly from home, I > switched from mainly using a work Wintel machine running Windows XP > Professional, Service Pack 3, to mainly using my home PowerPC G4 > PowerBook Macintosh, currently upgraded to Mac OS X 10.5.8 Leopard. > > However, to my surprise, there does not seem to be a version of the > Haskell Platform that runs natively on my current OS. > > Does anybody know where to find a universal binary version of the > Haskell Platform, or at least of GHC 6.10.4? Otherwise, I'm stuck > without a native version. There no binary platform installer for OSX PPC. You'll have to grab ghc-6.10.4 for PPC from the ghc download page and then install the platform from the generic source tarball. If you'd like to help us next time to make a platform binary for PPC then that'd be great. I don't think we have the setup to make universal binaries but it should be possible to make a PPC build if we have a volunteer. Duncan From sjoerd at w3future.com Thu Dec 3 05:54:58 2009 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Thu Dec 3 05:29:40 2009 Subject: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping] In-Reply-To: <1259837227.2756.8.camel@cornfed> References: <1259799937.5053.14.camel@cornfed> <7D26677F-E463-433C-98D7-A438F33E5319@w3future.com> <1259837227.2756.8.camel@cornfed> Message-ID: <3667985D-F29E-4287-8C65-A66089E2E177@w3future.com> In the case of Dual [1] `mappend` Dual [2] there's no need to do any unwrapping. There is if you say: l :: [Int] l = Dual [1] `mappend` Dual [2] The way I think this could work is that when the type checker detects a type error, it will first try to resolve it by newtype unwrapping (or wrapping even). Sjoerd On Dec 3, 2009, at 11:47 AM, Holger Siegel wrote: > Am Donnerstag, den 03.12.2009, 01:40 +0100 schrieb Sjoerd Visscher: >> The idea is that there's just enough unwrapping such that you don't >> need to use getDual and appEndo. > > Yes, but what does > > Dual [1] `mappend Dual [2] > > mean then? Should it use the Monoid instance of Dual and return > > Dual [2, 1] > > ? Should it unwrap the lists beforehand and re-wrap them afterwards and > return > > Dual [1, 2] > > ? Should it unwrap the resulting list afterwards and return [1, 2] or > even [2,1] ? > > That's not obvious to me. > > >> On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: >> >>> Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van >>> Steenbergen: >>>> So here's a totally wild idea Sjoerd and I came up with. >>>> >>>> What if newtypes were unwrapped implicitly? >>>> >>>> What advantages and disadvantages would it have? >>>> In what cases would this lead to ambiguous code? >>> >>> 1) >>> instance Monoid a => Monoid (Dual a) >>> >>> 2) >>> instance Monoid (Endo a) >>> instance Monoid b => Monoid (a -> b) >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -- >> Sjoerd Visscher >> sjoerd@w3future.com >> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjoerd@w3future.com From duncan.coutts at googlemail.com Thu Dec 3 05:55:34 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu Dec 3 05:30:17 2009 Subject: [Haskell-cafe] instance Binary UTCTime (Was: Oprhan instances) In-Reply-To: <1259791432.3091.65.camel@localhost> References: <6d2443150911141020o1d50f40by6530d0f4305c1ffb@mail.gmail.com> <200911190329.39888.daniel.is.fischer@web.de> <1259261051.3456.62.camel@localhost> <200911262032.12007.daniel.is.fischer@web.de> <1259267273.24650.6.camel@localhost> <694519c50911261247n1e5b5b78l3b485a4db23de524@mail.gmail.com> <49a77b7a0911261340r4f530d18o613066ef289c1fc3@mail.gmail.com> <1259501875.4896.79996.camel@localhost> <49a77b7a0911291342kc992aeat575e5c71e61afd6b@mail.gmail.com> <1259541001.4896.82681.camel@localhost> <1259791432.3091.65.camel@localhost> Message-ID: <1259837734.4896.102816.camel@localhost> On Wed, 2009-12-02 at 23:03 +0100, Joachim Breitner wrote: > Would it be techically possible and feasible to write instance that do > not actually cause a dependency on the package that defines the class > resp. the data type? From a distributor point of view, I could live > quite well with a setup like this: > * When the package providing class Foo is compiled, instances for all > interesting data types in the distribution are defined. This means a lot > of build-dependencies, but they are not too bad (although annoying). > * The generated package does (somehow) not depend on all these data > packages. Of course, any part of the code that uses these data types, > especially the class instances, are only usable when the corresponding > package is also installed. I guess this would need compiler support, to > not choke on code that uses unknown data types. > * Packages needing an instance Foo Bar would just depend on the packges > providing foo and bar, and the instance will be available and > functional. > > This idea works symmetric: The instances could also be defined in the > data type package, with no hard dependency on the package providing the > class definition. Aye, I've thought about a model like this before. I think it's worth considering and working out if it'd be technically feasible. Duncan From nccb2 at kent.ac.uk Thu Dec 3 06:03:44 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Thu Dec 3 05:40:22 2009 Subject: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping] In-Reply-To: <3667985D-F29E-4287-8C65-A66089E2E177@w3future.com> References: <1259799937.5053.14.camel@cornfed> <7D26677F-E463-433C-98D7-A438F33E5319@w3future.com> <1259837227.2756.8.camel@cornfed> <3667985D-F29E-4287-8C65-A66089E2E177@w3future.com> Message-ID: <4B179B10.9020304@kent.ac.uk> Sjoerd Visscher wrote: > In the case of Dual [1] `mappend` Dual [2] there's no need to do any unwrapping. There is if you say: > l :: [Int] > l = Dual [1] `mappend` Dual [2] > > The way I think this could work is that when the type checker detects a type error, it will first try to resolve it by newtype unwrapping (or wrapping even). > So if I have: l :: Dual [Int] l = [1] `mappend` [2] It will wrap after the mappend, rather than before? But: l :: Dual [Int] l = Dual [1] `mappend` [2] Would wrap the RHS in Dual? Does this version unwrap the LHS: l :: [Int] l = Dual [1] `mappend` [2] And finally, what about: l :: [Int] l = Dual [1] `mappend` Endo [2] Automatic wrapping and unwrapping, like automatic coercions, look like an opportunity for surprising behaviour. OTOH, perhaps some sort of deriving mechanism would be good. To revisit someone's previous suggestion, perhaps you could allow functions in the deriving clause, so that if you have: f :: Foo -> Foo -> Foo newtype MyFoo = MyFoo {getFoo :: Foo} deriving (f as g) will generate: g :: MyFoo -> MyFoo -> MyFoo g x y = Foo (f (getFoo x) (getFoo y)) I think it's not something worth adding (too subtle), but I thought I'd throw it in as a possibility. Neil. From bugfact at gmail.com Thu Dec 3 06:09:12 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Dec 3 05:43:54 2009 Subject: [Haskell-cafe] I miss OO In-Reply-To: <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> References: <4B0D98DE.4070507@alumni.caltech.edu> <75cc17ac0911260207u446561c1r75de76ee9397955f@mail.gmail.com> <5fdc56d70911260444v1f619d3dx486a053215343d1f@mail.gmail.com> <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> Message-ID: Nice. It would be fantastic to have a little practical real-world challenge (like building a simple music system, or a simple multi-channel sound mixer), and work this out in an imperative language, an object-oriented language, a functional language, and maybe other languages too, like logic languages or constraint languages (does the latter exist?) When OO is about constructing a "machine" and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? Also Luke Palmer talked a couple of times about "co-algebraic" approaches, but not being a computer scientist, I never really understood what that meant ("just reverse all the arrows"?) On Thu, Nov 26, 2009 at 3:49 PM, Gregg Reynolds wrote: > On Thu, Nov 26, 2009 at 6:44 AM, Stephen Tetley > wrote: >> 2009/11/26 Gregg Reynolds : >> >>> Modeling musical stuff could provide an excellent illustration of the >>> difference between OO and the Haskell way; it's the difference between >>> metaphysical engineering and constructive mathematics. >> >> >> Hmm, Stephen Travis Pope's SmOKe - a design that has been the basis of >> various state-of-the-art Smalltalk music systems - seems pretty >> concrete to me rather than metaphysical. >> >> http://heaveneverywhere.com/stp/PostScript/icmc.94.mode.pdf >> > > Looks interesting, but what I was trying to get at - ``metaphysical > engineering'' just popped into my head and sounded kinda cool so I > went with it - is that these are two radically different ways of > thinking about what we're doing when we write programs. > > For example, Pope talks about music in terms of properties, but then > says "[t]hese properties may be music-specific _objects_ (such as > pitches or spatial positions)..." (emphasis added). ?This is standard > OO-speak; there's nothing wrong with it, the point is just that the > domain of interest is viewed as a collection of ``objects'' and their > behaviors, where ``object'' is the word we use for lack of a better > term to refer to things that exist - hence metaphysics. ?Are there > _really_ any objects involved, especially where properties are > concerned? ?Not for me, though others may differ. ?In any case, the > overall picture is that programs are combinations of such objects, so > the program is viewed as the description of a kind of machine - hence > engineering. ?In order to describe music, the programmer describes a > machine. > > By contrast, a ``purely functional'' approach (I prefer ``algebraic'' > as more accurate or at least more revealing) might construe such > properties in terms of ?types and operations on values of the types, > which capture the notion of property directly without implicating > objects in any way. ?A music library would be viewed in terms of a > language (algebra), with customized names for domain-specific types > and operations, that the programmer can use to describe music instead > of describing a machine that produces music. ?Which makes the > programmer a litterateur rather than a constructor of machines, among > other things. > > Cheers, > > Gregg > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From greenrd at greenrd.org Wed Dec 2 00:27:46 2009 From: greenrd at greenrd.org (Robin Green) Date: Thu Dec 3 05:47:32 2009 Subject: [Haskell-cafe] Patches and forks for GHC 6.12 Message-ID: Some packages will need modifications to build or work with GHC 6.12 (in some cases, just modifications to the .cabal file). I've created this wiki page to track work people have done on that which hasn't yet been included into official packages or repositories: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 Please add any ones you know of (or just email me and I'll add them for you). -- Robin From matthew.pocock at ncl.ac.uk Thu Dec 3 06:13:09 2009 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Thu Dec 3 05:47:49 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <1259834871.3407.5.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: Perhaps what you are looking for is a more powerful "defining" semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo Matthew > not sure if this is what you are thinking at, but everytime I wrap a > type Foo in a newtype MyFoo to define my own instances (or just for more > expressiveness code), I wish I had a way to tell the compiler: > ?Please define function myfoo to be the same as foo, with all occurences > of Foo in its type signature replaced by MyFoo.? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/45136fc6/attachment.html From matthew.pocock at ncl.ac.uk Thu Dec 3 06:15:08 2009 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Thu Dec 3 05:49:54 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: Of course, I meand 'deriving', not 'defining' /me embarsed 2009/12/3 Matthew Pocock > Perhaps what you are looking for is a more powerful "defining" semantics? > > newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has > are delegated through from MyFoo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/35e2b7c9/attachment.html From mail at joachim-breitner.de Thu Dec 3 06:28:55 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Dec 3 06:03:34 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: <1259839735.6800.1.camel@localhost> Hi, Am Donnerstag, den 03.12.2009, 11:13 +0000 schrieb Matthew Pocock: > Perhaps what you are looking for is a more powerful "defining" > semantics? > > newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo > has are delegated through from MyFoo it goes into the right direction, but I?d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/4c828604/attachment.bin From ketil at malde.org Thu Dec 3 06:34:05 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Dec 3 06:08:46 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <1259670159.4896.91431.camel@localhost> (Duncan Coutts's message of "Tue, 01 Dec 2009 12:22:39 +0000") References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> Message-ID: <871vjcuw9e.fsf@malde.org> Duncan Coutts writes: >> [1] http://hackage.haskell.org/package/failable-list > Nice. I agree this is needed (or rather, would be nice to standardise). Although I don't care for the cutesy naming suggested in the 'Train' datatype, failable-list could be made more general. Why is there a specific constructor 'Done', instead of just allowing the user to select a value of type 'e' (using 'Maybe b' if nothing else works)? Perhaps we could also consider an infix notation, like: data TerminatedList a e = Then a (TerminatedList a e) | Finally e (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` "success!". Of course, you might prefer symbols instead.) -k -- If I haven't seen further, it is by standing in the footprints of giants From malcolm.wallace at cs.york.ac.uk Thu Dec 3 06:45:09 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Dec 3 06:21:24 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <871vjcuw9e.fsf@malde.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> Message-ID: <2E9CFDD9-5A11-4382-8754-FCEB7675ED81@cs.york.ac.uk> > data TerminatedList a e = Then a (TerminatedList a e) > | Finally e Nice. > (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` "success!". Errm, you mean: 4 `Then` 5 `Then` 1 `Then` Finally "success!" Regards, Malcolm From tomahawkins at gmail.com Thu Dec 3 06:52:05 2009 From: tomahawkins at gmail.com (Tom Hawkins) Date: Thu Dec 3 06:26:45 2009 Subject: [Haskell-cafe] ANN: atom-0.1.3 Message-ID: <594c1e830912030352sfe4714ag10a582e3f1bd416d@mail.gmail.com> This release of Atom slightly changes the semantics of assertions and coverage. Assertion and coverage are now checked between the execution of every rule, instead of only when the rules containing assertions are fired. They are still subject to parental guard conditions, but not period or phase constraints. This means... period 20 $ atom "checkSomeStuff" $ do cond ok assert "A" a assert "B" b cover "C" c ... A, B, and C are checked all the time "ok" is true, not just every 20th cycle. Checking between every rule execution obviously impacts simulation time, but the increased testing rigor is worth it. I also added 'linear' to Common, which does linear interpolation and extrapolation on a line given two points. (I found I was replicating this function everywhere for sensor calibrations, control limits, etc.) http://hackage.haskell.org/package/atom From nccb2 at kent.ac.uk Thu Dec 3 06:53:01 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Thu Dec 3 06:29:38 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: <4B1709C4.7060707@freegeek.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <1259671018-sup-4320@peray> <4B1709C4.7060707@freegeek.org> Message-ID: <4B17A69D.5010603@kent.ac.uk> wren ng thornton wrote: > Nicolas Pouillard wrote: >> Excerpts from Heinrich Apfelmus's message of Tue Dec 01 11:29:24 >> +0100 2009: >>> For mnemonic value, we could call it a "train": >>> >>> data Train a b = Wagon a (Train a b) >>> | Loco b >> > > I rather like it too. The mnemonic version sounds a lot nicer than > "ListEnd", though I'd probably call the constructors Cabin and Caboose. I suspect the Train name runs into cultural differences. Cabin and Caboose are not names I know in relation to trains, and even Wagon and Loco don't immediately convey to me which one is which. I think a more obvious Cons/Terminator naming scheme is best. Neil. From echant+haskell at maretmanu.org Thu Dec 3 07:03:02 2009 From: echant+haskell at maretmanu.org (Emmanuel CHANTREAU) Date: Thu Dec 3 06:37:32 2009 Subject: [Haskell-cafe] Optimization with Strings ? Message-ID: <20091203130302.6a67ad99@brouillard.aima.fr> Hello In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? (Sorry for my english, I'm french) thank you -- Emmanuel Chantr?au From dav.vire+haskell at gmail.com Thu Dec 3 07:20:31 2009 From: dav.vire+haskell at gmail.com (David Virebayre) Date: Thu Dec 3 06:55:11 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203130302.6a67ad99@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> Message-ID: <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> On Thu, Dec 3, 2009 at 1:03 PM, Emmanuel CHANTREAU wrote: > In my futur program, it use a lot of binary trees with strings (words) > as leaf. There is just arround 1000 words and they will appear a lot of > times. The program will possibly consume a lot of process and memory > (it is a mathematics proover). > I began this program in C++ but haskell has a prety good speed and > memory footprint and is easier. But I don't know if it worth to do this > optimization: having a dictionary to translate string words in Int. > The answer depends on the automatic optimizations in GHC, because GHC > could compare quickely two strings if it is the same object, so it > depends if program generated by GHC have a dictionary (tree) of strings > internaly. Someone knows this ? It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) => Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False So you will have to code your own optimisation. David. P.S. In French if you didn't understand: Ca ne marche pas comme ?a. Les chaines de caract?res ne sont que des listes de caract?res. La comparaison sur les listes est faite r?cursivement, caract?re par caract?re, il suffit pour s'en assurer de regarder au source : Donc il vaut mieux que tu impl?mente ton propre dictionnaire. From bulat.ziganshin at gmail.com Thu Dec 3 07:32:48 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Dec 3 07:13:02 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203130302.6a67ad99@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> Message-ID: <1246934596.20091203153248@gmail.com> Hello Emmanuel, Thursday, December 3, 2009, 3:03:02 PM, you wrote: > memory footprint and is easier. But I don't know if it worth to do this > optimization: having a dictionary to translate string words in Int. GHC compiler already has this optimization. unfortunately it's not in the code it generates but in compiler itself (GHC is written in Haskell and compiled by itself). so it is definitely worth an implementation if you handle lots of strings as compiler does -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lrpalmer at gmail.com Thu Dec 3 07:41:34 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Dec 3 07:16:15 2009 Subject: [Haskell-cafe] I miss OO In-Reply-To: References: <4B0D98DE.4070507@alumni.caltech.edu> <75cc17ac0911260207u446561c1r75de76ee9397955f@mail.gmail.com> <5fdc56d70911260444v1f619d3dx486a053215343d1f@mail.gmail.com> <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> Message-ID: <7ca3f0160912030441q3b99696fk779106924d7526de@mail.gmail.com> On Thu, Dec 3, 2009 at 4:09 AM, Peter Verswyvelen wrote: > Also Luke Palmer talked a couple of times about "co-algebraic" > approaches, but not being a computer scientist, I never really > understood what that meant ("just reverse all the arrows"?) Disclaimer: I am not a category theorist. I think my intuition matches the terminology pretty well, but I would like to see someone who knows what they are talking about elaborate or correct me. The way I use the term, a coalgebraic data type is still very much functional in nature. Here's how I see it: An initial algebra focuses on the constructors. You see: data Nat = Zero | Succ !Nat Notice Zero :: Nat, Succ :: Nat -> Nat. We say that Nat is the smallest data type that supports both of those constructrs (because of Haskell's laziness, if I hadn't put the ! there, it wouldn't be the least). When you want to construct one, you use one of the constructors (because it is by def. just large enough to have those) When you want to destruct one, i.e. write a function f :: Nat -> A for some A, you say "well it had to have been made with Zero or Succ", so you pattern match on Zero and pattern match on Succ. A final coalgebra focuses on the projections. You might see: data Conat = Conat { proj :: Either () Conat } So proj :: Conat -> Either () Conat. But we can't say that it's the smallest data type that supports that projection, because that is a very small data type (it always projects to ()). Rather it is the *largest* data type that still supports that projection. When you want to destruct one, you just use one of the projection, because it is by def. still small enough to always have them. When you want to construct one, it is enough to specify the values for each of the projections, because the data type is large enough to hold any (well-defined) projection you can think of. See the dualities? The difference between Nat and Conat is that Conat has one additional element, fix (Conat . Right). Technically all the lazy data types are final coalgebras (just stated with focus on the constructors), because they have these infinite elements, but it is convenient to pretend that they don't sometimes. But go to any of the popular total dependently-typed languages and there are some differences (one of those differences being that none of them get final coalgebras right[1]). Luke [1] Conor McBride. Let's see how things unfold. http://strictlypositive.org/ObsCoin.pdf From duncan.coutts at googlemail.com Thu Dec 3 08:00:01 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu Dec 3 07:46:27 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <871vjcuw9e.fsf@malde.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> Message-ID: <1259845201.4896.103489.camel@localhost> On Thu, 2009-12-03 at 12:34 +0100, Ketil Malde wrote: > Duncan Coutts writes: > > >> [1] http://hackage.haskell.org/package/failable-list > > > Nice. > > I agree this is needed (or rather, would be nice to standardise). > > Although I don't care for the cutesy naming suggested in the 'Train' > datatype, failable-list could be made more general. Why is there a > specific constructor 'Done', instead of just allowing the user to select > a value of type 'e' (using 'Maybe b' if nothing else works)? > > Perhaps we could also consider an infix notation, like: > > data TerminatedList a e = Then a (TerminatedList a e) > | Finally e > > (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` "success!". Of > course, you might prefer symbols instead.) I agree the naming could do with some work and it's worth trying a few variants to see what seems nicest. I've got an open mind on the suggestion to amalgamate the two ways the list could end. I'm not especially in favour of generalising for the sake of generalising, especially if it looses the connection to the notion of annotating your "ordinary" data structure with extra errors. If I effectively always have to use an Either for the final value then perhaps it does not buy anything and just makes the folds uglier (since it might loose the connection with the ordinary fold). But it could make even that use case simpler so it's worth looking at in a few examples (eg the tar package). Note that another similar use case is lazy progress reporting. In cabal-install's dependency solver I've used: -- | A type to represent the unfolding of an expensive long running -- calculation that may fail. We may get intermediate steps before the -- final result which may be used to indicate progress and/or logging -- messages. -- data Progress step fail done = Step step (Progress step fail done) | Fail fail | Done done It's a difference in emphasis but I think it may also have a different Monad instance since we consider Progress to be a single value, not a list. It's like the Either error monad but with extra writer style logging. Duncan From conor at strictlypositive.org Thu Dec 3 08:34:21 2009 From: conor at strictlypositive.org (Conor McBride) Date: Thu Dec 3 08:10:55 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <4B170350.2070504@van.steenbergen.nl> References: <4B170350.2070504@van.steenbergen.nl> Message-ID: Hi Martijn On 3 Dec 2009, at 00:16, Martijn van Steenbergen wrote: > So here's a totally wild idea Sjoerd and I came up with. > > What if newtypes were unwrapped implicitly? Subtyping. > What advantages and disadvantages would it have? The typechecker being psychic; the fact that it isn't. It's very easy to add forms of subtyping and make a mess of type and instance inference. > In what cases would this lead to ambiguous code? If f :: x -> ZipList y we get traverse f :: t x -> [t y] but it is not clear whether to attach the unpacking to f or to the result, and that will determine the idiom in which the traversal occurs. And that's before you start mixing the sugar of newtypes with the fertiliser of GADTs... But even if it's dangerous to unpack newtypes silently, it's rather nice to do it systematically, via a type class. Here are old posts of mine which mention this and then show off a bit. http://www.mail-archive.com/haskell-cafe@haskell.org/msg37213.html http://www.haskell.org/pipermail/libraries/2008-January/008917.html These days, how about class Newtype n where type Unpack n pack :: Unpack n -> n unpack :: n -> Unpack n and related machinery? Cheers Conor From JohnDEarle at cox.net Thu Dec 3 08:57:02 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 3 08:31:58 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping Message-ID: There is another point that needs to be made. A type signature isn't actually a type specification. It is a type assertion and a type specification in the event that the compiler needs your help. Most of the time the compiler can care less what you think and does not require your assistance. In languages like C you get to call the shots. In languages such as Haskell you don't get that opportunity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/8d52da7a/attachment.html From matthias.goergens at googlemail.com Thu Dec 3 09:03:21 2009 From: matthias.goergens at googlemail.com (=?ISO-8859-1?Q?Matthias_G=F6rgens?=) Date: Thu Dec 3 08:38:21 2009 Subject: [Haskell-cafe] Card games In-Reply-To: References: <20091107105451.GA7384@kira.casa> <20091107140753.GB23128@kira.casa> Message-ID: Hi Tom, Did you make any progress on your Dominion quest? I guess you could start by modeling `Big Money' and add the other cards (and interaction) from there. Also I guess there is a common baseline of things that are inherent in a lot of card games --- mechanics that cards support: Shuffling, having two sides, hiding one of two sides, picking a random card from a subset (or at least one where you can only see one side), placing cards in constellations on a table (with one side up). I guess with a bit of type system trickery you can even make sure that strategies don't look at the sides of the cards they are not supposed to look at --- without having to do any other information hiding like only providing access by getter functions. Matthias. From lemming at henning-thielemann.de Thu Dec 3 09:33:37 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Dec 3 09:05:17 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15BC69.1020101@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> Message-ID: <4B17CC41.5050509@henning-thielemann.de> Michael P Mossey schrieb: > Perhaps someone could either (1) help me do what I'm trying to do, or > (2) show me a better way. > > I have a problem that is very state-ful and I keep thinking of it as OO, > which is driving me crazy. Haskell is several times harder to use than > Python in this instance, probably because I'm doing it wrong. > > To give you a larger context, this problem is essentially compiling a > description of music (my own) into a kind of music-machine-language > (CSound). CSound is relatively untidy. There are currently two public interfaces to CSound: http://hackage.haskell.org/packages/archive/haskore/0.1/doc/html/Haskore-Interface-CSound.html http://hackage.haskell.org/package/hCsound You may also want to use SuperCollider: http://hackage.haskell.org/package/hsc3 From ketil at malde.org Thu Dec 3 09:35:51 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Dec 3 09:10:32 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <2E9CFDD9-5A11-4382-8754-FCEB7675ED81@cs.york.ac.uk> (Malcolm Wallace's message of "Thu, 3 Dec 2009 11:45:09 +0000") References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <2E9CFDD9-5A11-4382-8754-FCEB7675ED81@cs.york.ac.uk> Message-ID: <87my20t9a0.fsf@malde.org> Malcolm Wallace writes: > Errm, you mean: 4 `Then` 5 `Then` 1 `Then` Finally "success!" Yes, sorry, and thanks. I guess I should learn to check with ghci before posting... How about this for a nicer syntax? infixr 8 :+ infixr 8 +: data TList a e = a :+ (TList a e) | Return e deriving Show x +: y = x :+ (Return y) *Main> 2 :+ 4 +: "success" 2 :+ (4 :+ Return "success") I like the generic terminal value, it allows things like: *Main> let count = go 0 where go i (x:xs) = x :+ go (i+1) xs; go i [] = Return i *Main> :t count count :: [t] -> TList t Integer *Main> count [1..5] 1 :+ (2 :+ (3 :+ (4 :+ (5 :+ Return 5)))) (But perhaps these things can be done more elegantly using State or similar?) -k -- If I haven't seen further, it is by standing in the footprints of giants From lemming at henning-thielemann.de Thu Dec 3 09:37:35 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Dec 3 09:12:15 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <5fdc56d70912020458k6542d692t114c760d013b483d@mail.gmail.com> References: <4B15BC69.1020101@alumni.caltech.edu> <4B15C8F4.4020506@alumni.caltech.edu> <5fdc56d70912020458k6542d692t114c760d013b483d@mail.gmail.com> Message-ID: On Wed, 2 Dec 2009, Stephen Tetley wrote: > As for the second half of what you get from a programming language, > your system description frames what you want to do with an emphasis on > dynamic aspects. This seems a good way off from the prior art in > Haskell. For instance there are Haskell synthesizers - George > Giorgidze's yampa-synth and Jerzy Karczmarczuk's Clarion (actually in > Clean, but near enough). Here you build signal processing modules - > unit generators, of course - Yampasynth uses arrows to do this Clarion > uses infinite streams. With both you would build a synthesizer > statically from unit generators and somehow run it to produce > sounds[1]. Shameless advertisement here: http://hackage.haskell.org/package/synthesizer-core http://www.youtube.com/watch?v=KA6DE9jlpSY From echant+haskell at maretmanu.org Thu Dec 3 10:23:56 2009 From: echant+haskell at maretmanu.org (Emmanuel CHANTREAU) Date: Thu Dec 3 09:58:17 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> Message-ID: <20091203162356.32431136@brouillard.aima.fr> Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre a ?crit : > It doesn't work this way : Strings are just lists of Chars. Comparison > is made recursively, Char by Char. You can have a look at the source > to make sure : > > instance (Eq a) => Eq [a] where > [] == [] = True > (x:xs) == (y:ys) = x == y && xs == ys > _xs == _ys = False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that "forall x; List x => x==x". GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. Bulat says that this optimization is not done, so I will do it by my hands (ho my poor lazy hands). -- Emmanuel Chantr?au From vandijk.roel at gmail.com Thu Dec 3 10:30:39 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Dec 3 10:05:20 2009 Subject: [Haskell-cafe] happstack homepage Message-ID: I noticed that happstack.com and tutorial.happstack.com are both equal to patch-tag.com. Google's cache has the original pages. Is this the result of some misconfiguration or something else? I want to play with happstack and this is a slight inconvenience. On the other hand, all happstack packages build without problems so I'll build the tutorial locally and work from there. Regards, Roel From nccb2 at kent.ac.uk Thu Dec 3 10:31:56 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Thu Dec 3 10:05:43 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203162356.32431136@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> <20091203162356.32431136@brouillard.aima.fr> Message-ID: <4B17D9EC.3010808@kent.ac.uk> Emmanuel CHANTREAU wrote: > Le Thu, 3 Dec 2009 13:20:31 +0100, > David Virebayre a ?crit : > > >> It doesn't work this way : Strings are just lists of Chars. Comparison >> is made recursively, Char by Char. You can have a look at the source >> to make sure : >> >> instance (Eq a) => Eq [a] where >> [] == [] = True >> (x:xs) == (y:ys) = x == y && xs == ys >> _xs == _ys = False >> > > Hello > > Thank you David and Bulat for your answers. > > I don't see the proof you see. Because GHC could store two sames > objects juste once and by the definition of == on lists it could deduce > that "forall x; List x => x==x". GHC have all informations to do this > optimization job, because haskell functions definitions are mathematics > definitions. > Besides any other reasons, Haskell has the error function, and infinite lists. Consider: p :: String p = error "Haha!" q :: String q = repeat 'a' pEqualsP :: Bool pEqualsP = p == p qEqualsQ :: Bool qEqualsQ = q == q By your rule, pEqualsP and qEqualsQ should be True. In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate. Since Strings can contain such errors and infinite lists, you can't know for certain that an object equals itself without checking its entire length, which is what the original definition for equals did anyway. There may be strict data structures for which your optimisation might be applicable, though. Neil. From echant+haskell at maretmanu.org Thu Dec 3 10:32:15 2009 From: echant+haskell at maretmanu.org (Emmanuel CHANTREAU) Date: Thu Dec 3 10:06:41 2009 Subject: [Haskell-cafe] GHC magic optimization ? Message-ID: <20091203163215.48a8f21b@brouillard.aima.fr> Hello One thing is magic for me: how GHC can know what function results to remember and what results can be forgotten ? Is it just a stupid buffer algorithm or is there some mathematics truths behind this ? I'm very happy about Haskell, it's so great to put some smart ideas in a computer. thanks -- Emmanuel Chantr?au From holgersiegel74 at yahoo.de Thu Dec 3 10:34:09 2009 From: holgersiegel74 at yahoo.de (Holger Siegel) Date: Thu Dec 3 10:08:49 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203162356.32431136@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> <20091203162356.32431136@brouillard.aima.fr> Message-ID: <1259854449.2756.18.camel@cornfed> Am Donnerstag, den 03.12.2009, 16:23 +0100 schrieb Emmanuel CHANTREAU: > Le Thu, 3 Dec 2009 13:20:31 +0100, > David Virebayre a ?crit : > > > It doesn't work this way : Strings are just lists of Chars. Comparison > > is made recursively, Char by Char. You can have a look at the source > > to make sure : > > > > instance (Eq a) => Eq [a] where > > [] == [] = True > > (x:xs) == (y:ys) = x == y && xs == ys > > _xs == _ys = False > > Hello > > Thank you David and Bulat for your answers. > > I don't see the proof you see. Because GHC could store two sames > objects juste once and by the definition of == on lists it could deduce > that "forall x; List x => x==x". GHC have all informations to do this > optimization job, because haskell functions definitions are mathematics > definitions. This does not always hold, because the equivalence known from mathematics differs from Haskell's strict equality when it comes to infinite or undefined values. Consider let x = repeat () in x == x and let x = error "oops" in x == x In both cases your optimized program would return True, although the value is undefined (bottom). From lemming at henning-thielemann.de Thu Dec 3 10:40:32 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Dec 3 10:15:35 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <20091203163215.48a8f21b@brouillard.aima.fr> References: <20091203163215.48a8f21b@brouillard.aima.fr> Message-ID: On Thu, 3 Dec 2009, Emmanuel CHANTREAU wrote: > Hello > > One thing is magic for me: how GHC can know what function results to > remember and what results can be forgotten ? > > Is it just a stupid buffer algorithm or is there some mathematics > truths behind this ? Although it is not required by the Haskell 98 report, the 'let' expression usually stores variable values (sharing) and top-level constants are also stored. I wonder how much of currently existing Haskell code would still work, if this would be changed, since this behavior is essential for memory usage and speed. If you want to cache function results, see: http://www.haskell.org/haskellwiki/Memoization From ekirpichov at gmail.com Thu Dec 3 10:53:06 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Dec 3 10:27:47 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <20091203163215.48a8f21b@brouillard.aima.fr> References: <20091203163215.48a8f21b@brouillard.aima.fr> Message-ID: <5e0214850912030753r5aa99b2ake4d5fb1ed46ec22c@mail.gmail.com> Hi. There is actually no magic at all going on. Haskell has a reasonably well-defined evaluation model; you can approximate it, at least not taking IO into account, with lazy graph reduction (look that up on google). Probably that is the "mathematical truth" you're looking for. Actually, if Haskell had any magic, it would be bad, because magic can't be reliable (if you can't describe it, you can't rely on it) and your magically-efficient program would suddenly and unexplainably break at random changes in the source or in the compiler version. I remember being slightly shocked when I discovered that even in Prolog no magic is going on and it has a well-defined evaluation model, too (before that, when I only heard of Prolog but hadn't read anything serious about it, I thought that it is a bunch of unthinkable theorem proving wizardry). 2009/12/3 Emmanuel CHANTREAU : > Hello > > One thing is magic for me: how GHC can know what function results to > remember and what results can be forgotten ? > > Is it just a stupid buffer algorithm or is there some mathematics > truths behind this ? > > I'm very happy about Haskell, it's so great to put some smart ideas in > a computer. > > thanks > > -- > Emmanuel Chantr?au > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru From miguelimo38 at yandex.ru Thu Dec 3 10:58:33 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Dec 3 10:34:35 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <20091203163215.48a8f21b@brouillard.aima.fr> References: <20091203163215.48a8f21b@brouillard.aima.fr> Message-ID: <4B17E029.5070404@yandex.ru> Does this really mean that you want to know how the garbage collector works? Emmanuel CHANTREAU wrote: > Hello > > One thing is magic for me: how GHC can know what function results to > remember and what results can be forgotten ? > > Is it just a stupid buffer algorithm or is there some mathematics > truths behind this ? > > I'm very happy about Haskell, it's so great to put some smart ideas in > a computer. > > thanks > From bulat.ziganshin at gmail.com Thu Dec 3 11:18:28 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Dec 3 10:53:24 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203162356.32431136@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> <20091203162356.32431136@brouillard.aima.fr> Message-ID: <1343507511.20091203191828@gmail.com> Hello Emmanuel, Thursday, December 3, 2009, 6:23:56 PM, you wrote: > that "forall x; List x => x==x". GHC have all informations to do this > optimization job, because haskell functions definitions are mathematics > definitions. GHC doesn't make ALL possible optimizations, isn't it obvious? ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From JohnDEarle at cox.net Thu Dec 3 11:25:07 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 3 11:00:03 2009 Subject: [Haskell-cafe] Optimization with Strings ? Message-ID: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> Dear Emmanuel Chantr?au, You may want to look into Objective CAML http://caml.inria.fr/ which is a French product as you can see from the Internet address. It is likely better suited to the task than Haskell and has a reputation for speed. For those who prefer object oriented programming it has facilities for that which may ease your transition from C++. The Microsoft F# language is based on Objective CAML. Haskell has a problem with its type system and is not rigorous. Haskell is not a suitable language for proof assistants and so I would advise you to stay clear of Haskell. Standard ML was engineered with the needs of proof assistants in mind and so you may want to look into Standard ML, but you should be very happy with Objective CAML. It has an excellent reputation. The Coq proof assistant which is another French product is based on Objective CAML. If you do decide that Haskell is the way, it will help ease your transition to Haskell. There is nothing that says you can't keep your fingers in several pies at once. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/84d8e408/attachment.html From daniel.is.fischer at web.de Thu Dec 3 11:32:08 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Dec 3 11:08:18 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <4B17D9EC.3010808@kent.ac.uk> References: <20091203130302.6a67ad99@brouillard.aima.fr> <20091203162356.32431136@brouillard.aima.fr> <4B17D9EC.3010808@kent.ac.uk> Message-ID: <200912031732.08396.daniel.is.fischer@web.de> Am Donnerstag 03 Dezember 2009 16:31:56 schrieb Neil Brown: > Emmanuel CHANTREAU wrote: > > Le Thu, 3 Dec 2009 13:20:31 +0100, > > > > David Virebayre a ?crit : > >> It doesn't work this way : Strings are just lists of Chars. Comparison > >> is made recursively, Char by Char. You can have a look at the source > >> to make sure : > >> > >> instance (Eq a) => Eq [a] where > >> [] == [] = True > >> (x:xs) == (y:ys) = x == y && xs == ys > >> _xs == _ys = False > > > > Hello > > > > Thank you David and Bulat for your answers. > > > > I don't see the proof you see. Because GHC could store two sames > > objects juste once and by the definition of == on lists it could deduce > > that "forall x; List x => x==x". GHC have all informations to do this > > optimization job, because haskell functions definitions are mathematics > > definitions. > > Besides any other reasons, Haskell has the error function, and infinite > lists. Consider: > > p :: String > p = error "Haha!" > > q :: String > q = repeat 'a' > > pEqualsP :: Bool > pEqualsP = p == p > > qEqualsQ :: Bool > qEqualsQ = q == q > > By your rule, pEqualsP and qEqualsQ should be True. In fact, the > correct answer is that pEqualsP should produce an error and qEqualsQ > should never terminate. Since Strings can contain such errors and > infinite lists, you can't know for certain that an object equals itself > without checking its entire length, which is what the original > definition for equals did anyway. There may be strict data structures > for which your optimisation might be applicable, though. > > Neil. However, GHC offers a *really unsafe* function that allows to quickly check whether two values refer to the same heap-object. But it won't help Emmanuel, because any indirection causes it to say no and "let x = expression in x == x" should never appear in code anyway. From dons at galois.com Thu Dec 3 11:39:46 2009 From: dons at galois.com (Don Stewart) Date: Thu Dec 3 11:14:30 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> Message-ID: <20091203163946.GA17116@whirlpool.galois.com> JohnDEarle: > You may want to look into Objective CAML http://caml.inria.fr/ which is a > French product as you can see from the Internet address. It is likely better > suited to the task than Haskell and has a reputation for speed. For those who > prefer object oriented programming it has facilities for that which may ease > your transition from C++. The Microsoft F# language is based on Objective CAML. > > Haskell has a problem with its type system and is not rigorous. Haskell is not > a suitable language for proof assistants and so I would advise you to stay > clear of Haskell. Standard ML was engineered with the needs of proof assistants > in mind and so you may want to look into Standard ML, but you should be very > happy with Objective CAML. It has an excellent reputation. The Coq proof > assistant which is another French product is based on Objective CAML. Ok, that is serious trolling. There are several proof assistants written in Haskell: http://hackage.haskell.org/package/Agda http://hackage.haskell.org/package/ivor http://www.e-pig.org/ http://wiki.di.uminho.pt/wiki/bin/view/PURe/Camila http://www.cwi.nl/~jve/demo/ http://www.haskell.org/dumatel/ http://www.cs.chalmers.se/~koen/folkung/ http://taz.cs.wcupa.edu/~dmead/code/prover/ http://www.math.chalmers.se/~koen/paradox/ http://proofgeneral.inf.ed.ac.uk/Kit http://www.haskell.org/yarrow/ and the guarantees of purity the type system provides are extremely useful for verification purposes. Please, before posting like this to the Haskell community, inform yourself more of what the Haskell community has produced. -- Don From dons at galois.com Thu Dec 3 11:43:29 2009 From: dons at galois.com (Don Stewart) Date: Thu Dec 3 11:18:10 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: References: <4B16E984.7070504@btinternet.com> Message-ID: <20091203164329.GC17116@whirlpool.galois.com> vandijk.roel: > On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite > wrote: > > On a more serious note, "Download Haskell" /= "Download Haskell Platform", so if I were glancing down the sidebar looking for a link to download the "Haskell Platform" then the first link wouldn't have registered for me. ?And putting a "X has been released link!" in the news does not count as a prominent download link. > > If I wanted to know something *about* the *Haskell Platform* I would > click the link The Haskell Platform under the section About. So it is > actually mentioned 3 times on the front page. What could be improved > are the 2 download links: "Download Haskell" and "Download GHC". It > would perhaps be better to have one nice big "Download" button that > takes you to a separate download page. Having a single download link that only points to the Haskell Platform would be a bit of a policy shift. Is the community ready to accept that users looking for "Haskell" should be given the HP binaries? If so, I can change it to have a single "Download" button. Though it might be preferable to do that after the next release (the first non-beta release). -- Don From jfredett at gmail.com Thu Dec 3 11:46:37 2009 From: jfredett at gmail.com (Joe Fredette) Date: Thu Dec 3 11:21:20 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <20091203164329.GC17116@whirlpool.galois.com> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> Message-ID: <2F6EB3B8-4885-4CD8-8857-7A11CB0A2258@gmail.com> I think it makes sense, the HP is supposed to set up the entire environment needed for typical haskell development (at least, that is my understanding). As such, what's the point in making downloading haskell mean downloading a single _peice_ of haskell (GHC) only to have to download _everything else anyway_ (cabal-et-al, various "standard" libraries, etc). Perhaps we could put it to some kind of community vote. /Joe On Dec 3, 2009, at 11:43 AM, Don Stewart wrote: > vandijk.roel: >> On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite >> wrote: >>> On a more serious note, "Download Haskell" /= "Download Haskell >>> Platform", so if I were glancing down the sidebar looking for a >>> link to download the "Haskell Platform" then the first link >>> wouldn't have registered for me. And putting a "X has been >>> released link!" in the news does not count as a prominent download >>> link. >> >> If I wanted to know something *about* the *Haskell Platform* I would >> click the link The Haskell Platform under the section About. So it is >> actually mentioned 3 times on the front page. What could be improved >> are the 2 download links: "Download Haskell" and "Download GHC". It >> would perhaps be better to have one nice big "Download" button that >> takes you to a separate download page. > > Having a single download link that only points to the Haskell Platform > would be a bit of a policy shift. Is the community ready to accept > that > users looking for "Haskell" should be given the HP binaries? > > If so, I can change it to have a single "Download" button. Though it > might be preferable to do that after the next release (the first > non-beta release). > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vanenkj at gmail.com Thu Dec 3 11:51:18 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu Dec 3 11:25:58 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <2F6EB3B8-4885-4CD8-8857-7A11CB0A2258@gmail.com> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> <2F6EB3B8-4885-4CD8-8857-7A11CB0A2258@gmail.com> Message-ID: I'm all for making HP the default as long as we find a way to make some of the larger packages (I'm thinking gtk2hs) either ship with HP in Windows or install correctly with HP. On Thu, Dec 3, 2009 at 11:46 AM, Joe Fredette wrote: > I think it makes sense, the HP is supposed to set up the entire environment > needed for typical haskell development (at least, that is my understanding). > As such, what's the point in making downloading haskell mean downloading a > single _peice_ of haskell (GHC) only to have to download _everything else > anyway_ (cabal-et-al, various "standard" libraries, etc). > > Perhaps we could put it to some kind of community vote. > > /Joe > > > On Dec 3, 2009, at 11:43 AM, Don Stewart wrote: > > vandijk.roel: >> >>> On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite >>> wrote: >>> >>>> On a more serious note, "Download Haskell" /= "Download Haskell >>>> Platform", so if I were glancing down the sidebar looking for a link to >>>> download the "Haskell Platform" then the first link wouldn't have registered >>>> for me. And putting a "X has been released link!" in the news does not >>>> count as a prominent download link. >>>> >>> >>> If I wanted to know something *about* the *Haskell Platform* I would >>> click the link The Haskell Platform under the section About. So it is >>> actually mentioned 3 times on the front page. What could be improved >>> are the 2 download links: "Download Haskell" and "Download GHC". It >>> would perhaps be better to have one nice big "Download" button that >>> takes you to a separate download page. >>> >> >> Having a single download link that only points to the Haskell Platform >> would be a bit of a policy shift. Is the community ready to accept that >> users looking for "Haskell" should be given the HP binaries? >> >> If so, I can change it to have a single "Download" button. Though it >> might be preferable to do that after the next release (the first >> non-beta release). >> >> -- Don >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/503a84ef/attachment.html From JohnDEarle at cox.net Thu Dec 3 12:09:09 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 3 11:44:06 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <20091203163946.GA17116@whirlpool.galois.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> Message-ID: <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> See "[Haskell-cafe] Optimization with Strings ?" for background. Don Stewart wrote, "the guarantees of purity the type system provides are extremely useful for verification purposes". My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. I am already well aware of the numbers. They do not impress me. I have written on this already. I have given Haskell the benefit of the doubt and said, What's wrong with being uncompromising? There is something wrong with it, if it has taken you off the path of truth. This is not uncompromising. This is something else. It is called fanaticism and this is the opinion that I have come to after due consideration. If you are going to argue your case, be constructive. Tell me how the type system is not flawed and how the Haskell language is rigorous. What proof do you have of this? Explain to me how Haskell has been merely uncompromising in its pursuit of perfection and did not manage to step over the threshold into fanaticism. Please remain on topic and on point. From vanenkj at gmail.com Thu Dec 3 12:13:29 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu Dec 3 11:48:08 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> Message-ID: The burden of proof is on you to demonstrate that it _is_. On Thu, Dec 3, 2009 at 12:09 PM, John D. Earle wrote: > See "[Haskell-cafe] Optimization with Strings ?" for background. > > Don Stewart wrote, "the guarantees of purity the type system provides are > extremely > useful for verification purposes". My response to this is in theory. This > is what caught my attention initially, but the language lacks polish and > does not appear to be going in a direction where it shows signs where it > will self-correct. It may even be beyond repair. I care about others and I > don't want people to be misled. > > I am already well aware of the numbers. They do not impress me. I have > written on this already. I have given Haskell the benefit of the doubt and > said, What's wrong with being uncompromising? There is something wrong with > it, if it has taken you off the path of truth. This is not uncompromising. > This is something else. It is called fanaticism and this is the opinion that > I have come to after due consideration. > > If you are going to argue your case, be constructive. Tell me how the type > system is not flawed and how the Haskell language is rigorous. What proof do > you have of this? Explain to me how Haskell has been merely uncompromising > in its pursuit of perfection and did not manage to step over the threshold > into fanaticism. Please remain on topic and on point. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/35ceaa0c/attachment.html From vanenkj at gmail.com Thu Dec 3 12:13:44 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu Dec 3 11:48:24 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> Message-ID: *flawed, that is On Thu, Dec 3, 2009 at 12:13 PM, John Van Enk wrote: > The burden of proof is on you to demonstrate that it _is_. > > On Thu, Dec 3, 2009 at 12:09 PM, John D. Earle wrote: > >> See "[Haskell-cafe] Optimization with Strings ?" for background. >> >> Don Stewart wrote, "the guarantees of purity the type system provides are >> extremely >> useful for verification purposes". My response to this is in theory. This >> is what caught my attention initially, but the language lacks polish and >> does not appear to be going in a direction where it shows signs where it >> will self-correct. It may even be beyond repair. I care about others and I >> don't want people to be misled. >> >> I am already well aware of the numbers. They do not impress me. I have >> written on this already. I have given Haskell the benefit of the doubt and >> said, What's wrong with being uncompromising? There is something wrong with >> it, if it has taken you off the path of truth. This is not uncompromising. >> This is something else. It is called fanaticism and this is the opinion that >> I have come to after due consideration. >> >> If you are going to argue your case, be constructive. Tell me how the type >> system is not flawed and how the Haskell language is rigorous. What proof do >> you have of this? Explain to me how Haskell has been merely uncompromising >> in its pursuit of perfection and did not manage to step over the threshold >> into fanaticism. Please remain on topic and on point. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/2b62eb38/attachment.html From JohnDEarle at cox.net Thu Dec 3 12:31:49 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 3 12:06:46 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? Message-ID: <6BEDFDD3DCDF4FEE899B565412253364@JohnPC> It will be better for all of you to figure it out for yourselves and gain more experience about what is out there. Haskell isn't the world. Haskell would be the cutting edge if it didn't have competition. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/83ba288f/attachment.html From miguelimo38 at yandex.ru Thu Dec 3 12:33:00 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Dec 3 12:07:41 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> Message-ID: <525FCBB0-F80B-4EB7-A803-123729BA226F@yandex.ru> On 3 Dec 2009, at 20:09, John D. Earle wrote: > See "[Haskell-cafe] Optimization with Strings ?" for background. Somehow all your posts to the "Optimization..." thread were classified as spam by my e-mail client. Seems like it's developing self-awareness. > If you are going to argue your case, be constructive. Tell me how > the type system is not flawed and how the Haskell language is > rigorous. What proof do you have of this? Explain to me how Haskell > has been merely uncompromising in its pursuit of perfection and did > not manage to step over the threshold into fanaticism. Please remain > on topic and on point. Happily. But it takes two to make a conversation. Why don't YOU start first? From alec at thened.net Thu Dec 3 12:32:53 2009 From: alec at thened.net (Alec Berryman) Date: Thu Dec 3 12:08:19 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203130302.6a67ad99@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> Message-ID: <20091203173253.GA4022@thened.net> Emmanuel CHANTREAU on 2009-12-03 13:03:02 +0100: > In my futur program, it use a lot of binary trees with strings (words) > as leaf. There is just arround 1000 words and they will appear a lot of > times. The program will possibly consume a lot of process and memory > (it is a mathematics proover). > > I began this program in C++ but haskell has a prety good speed and > memory footprint and is easier. But I don't know if it worth to do this > optimization: having a dictionary to translate string words in Int. > > The answer depends on the automatic optimizations in GHC, because GHC > could compare quickely two strings if it is the same object, so it > depends if program generated by GHC have a dictionary (tree) of strings > internaly. Someone knows this ? I don't know of a library to intern strings, but it's not too hard to implement. I couldn't find the code I wrote to do this, but I looked around a bit and this is about what I remember doing: http://www.haskell.org/pipermail/haskell-cafe/2005-June/010335.html For the application I was using, interning strings did provide a significant reduction in memory, but for whatever reason didn't help with speed. From miguelimo38 at yandex.ru Thu Dec 3 12:34:58 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Dec 3 12:09:37 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <6BEDFDD3DCDF4FEE899B565412253364@JohnPC> References: <6BEDFDD3DCDF4FEE899B565412253364@JohnPC> Message-ID: OK, that was certainly constructive. Sorry, don't need a self- appointed messiah here. On 3 Dec 2009, at 20:31, John D. Earle wrote: > It will be better for all of you to figure it out for yourselves and > gain more experience about what is out there. Haskell isn't the > world. Haskell would be the cutting edge if it didn't have > competition. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jwlato at gmail.com Thu Dec 3 12:45:10 2009 From: jwlato at gmail.com (John Lato) Date: Thu Dec 3 12:19:49 2009 Subject: [Haskell-cafe] Re: seems like I'm on the wrong track Message-ID: <9979e72e0912030945q788027e4l18632d00af947945@mail.gmail.com> > From: Henning Thielemann > > Michael P Mossey schrieb: >> Perhaps someone could either (1) help me do what I'm trying to do, or >> (2) show me a better way. >> >> I have a problem that is very state-ful and I keep thinking of it as OO, >> which is driving me crazy. Haskell is several times harder to use than >> Python in this instance, probably because I'm doing it wrong. >> >> To give you a larger context, this problem is essentially compiling a >> description of music (my own) into a kind of music-machine-language >> (CSound). CSound is relatively untidy. > > There are currently two public interfaces to CSound: > > http://hackage.haskell.org/packages/archive/haskore/0.1/doc/html/Haskore-Interface-CSound.html > > http://hackage.haskell.org/package/hCsound > Incidentally, these two packages serve very different purposes. hCsound is an interface to the Csound runtime API, while the Haskore interface is an EDSL front-end to Csound's own input format. There is very little overlap in functionality between the two. The Haskore interface is much closer to what Michael wants to do, but as he's commented already, it is a bit dated. hCsound is unlikely to be of much use for compiling a secondary language to csound code. John From rodrigo.bonifacio at uol.com.br Thu Dec 3 12:45:48 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Thu Dec 3 12:20:32 2009 Subject: [Haskell-cafe] Existencial Types In-Reply-To: <4b17ee7ac9fe4_6e231060f3f0167@weasel3.tmail> References: <4b1559d95a4fb_14260a13f0413@weasel17.tmail> <49a77b7a0912011021w6c2e4667y9c52e35ec18d452c@mail.gmail.com> <7ca3f0160912011339m41d58305ia0bbedbb0b932eb5@mail.gmail.com> <4b15a4fc38367_453e4f293e856a@weasel6.tmail> <7ca3f0160912011644k4badf367s96fb02f47ed49ae4@mail.gmail.com> <4b17ee7ac9fe4_6e231060f3f0167@weasel3.tmail> Message-ID: <4b17f94ce8c1_75a71060f3f016c@weasel3.tmail> Dear Luke, thanks for your answers.... > If SelectScecario is used for other purposes, then give an explicit > cast function Sure, as I mentioned, we have different transformations and it would be worth to filter a list of transformations by a particular type or even apply the list of transformations in a particular order considering their type. > toTransformation :: SelectScenario -> Transformation > toTransformation (SelectScenario ids) = Transformation { > (<+>) = {- implementation of (<+>) just as if it were a class method -} > } I understand your idea, but I will have to implement several variations of "toTransformation", one for each kind of transformation. Moreover, I couldn't realize how is possible to define a function that could be applied to different transformations without using type classes--- I have to restrict the types of argument of such a function. Moreover, I couldn't figure out what are the benefits of your solution. Please, if possible, could you elaborate that a bit more, in order that I could understand why your design is better (I mean, more legible, reusable or concise)? Thanks in advance, Rodrigo. Em 01/12/2009 22:44, Luke Palmer < lrpalmer@gmail.com > escreveu: On Tue, Dec 1, 2009 at 4:21 PM, rodrigo.bonifacio wrote: > Thanks Luke. > > In fact I, will have different implementations of the Transformation type. > Something like: > > data SelectScenarios = SelectScenarios { > > scIds :: [Id] > > } What is this different type buying you? You can never "downcast" to it later. > And then I should be able to make SelectScenarios a kind of Transformation. > So I think that I really need a class. What do you think about it? > > instance Transformation SelectScenario where > > (<+>)? .... So instead of making a type and an instance, just implement it directly as a Transformation: selectScenario :: [Id] -> Transformation selectScenario ids = Transformation { (<+>) = {- whatever implementation you gave for (<+>) above, using ids -} } If the only purpose of SelectScenario (your type) is to be used polymorphically as a Transformation, then this approach is isomorphic -- i.e. anything you can do with the existential type trick you can do with this approach. If SelectScecario is used for other purposes, then give an explicit cast function toTransformation :: SelectScenario -> Transformation toTransformation (SelectScenario ids) = Transformation { (<+>) = {- implementation of (<+>) just as if it were a class method -} } Existential types only buy you power when the quantified variable appears more than once on the right hand side, for example: forall a. Num a => (a,a). But even those can usually be factored out into more direct representations (I seem to recall Oleg has a proof that they always can, actually). Luke From dave at zednenem.com Thu Dec 3 12:51:10 2009 From: dave at zednenem.com (David Menendez) Date: Thu Dec 3 12:25:52 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203173253.GA4022@thened.net> References: <20091203130302.6a67ad99@brouillard.aima.fr> <20091203173253.GA4022@thened.net> Message-ID: <49a77b7a0912030951j1941ae09r61b4b224e9dbb000@mail.gmail.com> On Thu, Dec 3, 2009 at 12:32 PM, Alec Berryman wrote: > Emmanuel CHANTREAU on 2009-12-03 13:03:02 +0100: > >> In my futur program, it use a lot of binary trees with strings (words) >> as leaf. There is just arround 1000 words and they will appear a lot of >> times. The program will possibly consume a lot of process and memory >> (it is a mathematics proover). >> >> I began this program in C++ but haskell has a prety good speed and >> memory footprint and is easier. But I don't know if it worth to do this >> optimization: having a dictionary to translate string words in Int. >> >> The answer depends on the automatic optimizations in GHC, because GHC >> could compare quickely two strings if it is the same object, so it >> depends if program generated by GHC have a dictionary (tree) of strings >> internaly. Someone knows this ? > > I don't know of a library to intern strings, but it's not too hard to > implement. ?I couldn't find the code I wrote to do this, but I looked > around a bit and this is about what I remember doing: > > http://www.haskell.org/pipermail/haskell-cafe/2005-June/010335.html > > For the application I was using, interning strings did provide a > significant reduction in memory, but for whatever reason didn't help > with speed. I'd use a trie. Edison provides Data.Edison.Assoc.TernaryTrie, and there are a few other trie packages at hackage. -- Dave Menendez From dave at zednenem.com Thu Dec 3 13:03:38 2009 From: dave at zednenem.com (David Menendez) Date: Thu Dec 3 12:38:17 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <1259839735.6800.1.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> <1259839735.6800.1.camel@localhost> Message-ID: <49a77b7a0912031003kd08f07asaf267603f0b83ab5@mail.gmail.com> On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 03.12.2009, 11:13 +0000 schrieb Matthew Pocock: >> Perhaps what you are looking for is a more powerful "defining" >> semantics? >> >> newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo >> has are delegated through from MyFoo > > it goes into the right direction, but I?d also like to have this also > capeable to derive single functions (giving them a new name), and not > only class instances. Something like the restricted type synonym extension in Hugs? -- Dave Menendez From stefan at cs.uu.nl Thu Dec 3 13:14:40 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Dec 3 12:49:21 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> Message-ID: <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> John, Miguel (and others), >> Don Stewart wrote, "the guarantees of purity the type system >> provides are extremely >> useful for verification purposes". My response to this is in >> theory. This is what caught my attention initially, but the >> language lacks polish and does not appear to be going in a >> direction where it shows signs where it will self-correct. It may >> even be beyond repair. I care about others and I don't want people >> to be misled. [...] > The burden of proof is on you to demonstrate that it _is_. I admit it's tempting, but wouldn't you agree that, especially in this case, it's better not to feed the troll? Cheers, Stefan From lennart at augustsson.net Thu Dec 3 13:21:12 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Dec 3 12:55:53 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> Message-ID: Thank you Sir for giving me a good laugh! On Thu, Dec 3, 2009 at 5:25 PM, John D. Earle wrote: > Dear Emmanuel Chantr?au, > > You may want to look into Objective CAML http://caml.inria.fr/ which is a > French product as you can see from the Internet address. It is likely better > suited to the task than Haskell and has a reputation for speed. For those > who prefer object oriented programming it has facilities for that which may > ease your transition from C++. The Microsoft F# language is based on > Objective CAML. > > Haskell has a problem with its type system and is not rigorous. Haskell is > not a suitable language for proof assistants and so I would advise you to > stay clear of Haskell. Standard ML was engineered with the needs of proof > assistants in mind and so you may want to look into Standard ML, but you > should be very happy with Objective CAML. It has an excellent reputation. > The Coq proof assistant which is another French product is based on > Objective CAML. > > If you do decide that Haskell is the way, it will help ease your transition > to Haskell. There is nothing that says you can't keep your fingers in > several pies at once. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From yairchu at gmail.com Thu Dec 3 13:22:16 2009 From: yairchu at gmail.com (yairchu@gmail.com) Date: Thu Dec 3 12:56:55 2009 Subject: [Haskell-cafe] Re: Implicit newtype unwrapping In-Reply-To: <1259834871.3407.5.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: > I guess TH could probably do this. I think this does what you wish for: http://hackage.haskell.org/packages/archive/peakachu/0.2/doc/html/Data-Newtype.html Example: > $(mkWithNewtypeFuncs [2] ''ZipList) > withZipList2 (<*>) [(+3), (*3)] [6, 7] [9, 21] > $(mkInNewtypeFuncs [2] ''ZipList) > getZipList $ inZipList2 (++) (ZipList "hello ") (ZipList "world") > "hello world" in some future this won't be in this unrelated "peakachu" package, and be incorporated into Neil M's derive. but for now this is where you can find it. cheers, Yair On Dec 3, 12:07?pm, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van > Steenbergen: > > > So here's a totally wild idea Sjoerd and I came up with. > > > What if newtypes were unwrapped implicitly? > > > What advantages and disadvantages would it have? > > In what cases would this lead to ambiguous code? > > not sure if this is what you are thinking at, but everytime I wrap a > type Foo in a newtype MyFoo to define my own instances (or just for more > expressiveness code), I wish I had a way to tell the compiler: > ?Please define function myfoo to be the same as foo, with all occurences > of Foo in its type signature replaced by MyFoo.? > > Instead I find my self writing manually code like > > myfoo :: (Blubb -> MyFoo) -> MyFoo -> MyFoo -> MyFoo > myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) > > I guess TH could probably do this. > > Greetings, > Joachim > > -- > Joachim "nomeata" Breitner > ? mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C > ? JID: nome...@joachim-breitner.de |http://www.joachim-breitner.de/ > ? Debian Developer: nome...@debian.org > > ?signature.asc > < 1KViewDownload > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe From korpios at korpios.com Thu Dec 3 13:23:24 2009 From: korpios at korpios.com (Tom Tobin) Date: Thu Dec 3 12:58:04 2009 Subject: [Haskell-cafe] Card games In-Reply-To: References: <20091107105451.GA7384@kira.casa> <20091107140753.GB23128@kira.casa> Message-ID: 2009/12/3 Matthias G?rgens : > Hi Tom, > > Did you make any progress on your Dominion quest? ?I guess you could > start by modeling `Big Money' and add the other cards (and > interaction) from there. No, I'm still trying to tune a "partitionM" function I wrote. (I'm still a beginner.) ^_^ I'd like to write a Dominion library or some more generic superset at some point, though. From agocorona at gmail.com Thu Dec 3 14:13:34 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu Dec 3 13:48:15 2009 Subject: Fwd: [Haskell-cafe] Optimization with Strings ? In-Reply-To: References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> Message-ID: Use makeStableName from System.Mem.StableName StableName`s are just for checking pointer equality. Instead of checking for equality of the strings, check for pointer equality of their stableNames a dirty way: pointerEq x y= unsafePerformIO $ do px <- makeStableName x py <- makeStableName y return x == y pEq x y | pointerEq x y == True = True | otherwise = x == y 2009/12/3 David Virebayre > On Thu, Dec 3, 2009 at 1:03 PM, Emmanuel CHANTREAU > > wrote: > > > In my futur program, it use a lot of binary trees with strings (words) > > as leaf. There is just arround 1000 words and they will appear a lot of > > times. The program will possibly consume a lot of process and memory > > (it is a mathematics proover). > > > I began this program in C++ but haskell has a prety good speed and > > memory footprint and is easier. But I don't know if it worth to do this > > optimization: having a dictionary to translate string words in Int. > > > The answer depends on the automatic optimizations in GHC, because GHC > > could compare quickely two strings if it is the same object, so it > > depends if program generated by GHC have a dictionary (tree) of strings > > internaly. Someone knows this ? > > It doesn't work this way : Strings are just lists of Chars. Comparison > is made recursively, Char by Char. You can have a look at the source > to make sure : > > instance (Eq a) => Eq [a] where > [] == [] = True > (x:xs) == (y:ys) = x == y && xs == ys > _xs == _ys = False > > So you will have to code your own optimisation. > > David. > > P.S. In French if you didn't understand: > > Ca ne marche pas comme ?a. > Les chaines de caract?res ne sont que des listes de caract?res. > La comparaison sur les listes est faite r?cursivement, caract?re par > caract?re, il suffit pour s'en assurer de regarder au source : > Donc il vaut mieux que tu impl?mente ton propre dictionnaire. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/49eec714/attachment.html From gcross at phys.washington.edu Thu Dec 3 14:13:20 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 3 13:48:31 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203130302.6a67ad99@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> Message-ID: You might want to check out the "stringtable-atom" and "bytestring-trie" packages; these are the packages to which I turn when I want to see if I can speed up my code by using a different data structure to map String's to values. Cheers, Greg On Dec 3, 2009, at 4:03 AM, Emmanuel CHANTREAU wrote: > Hello > > In my futur program, it use a lot of binary trees with strings (words) > as leaf. There is just arround 1000 words and they will appear a lot of > times. The program will possibly consume a lot of process and memory > (it is a mathematics proover). > > I began this program in C++ but haskell has a prety good speed and > memory footprint and is easier. But I don't know if it worth to do this > optimization: having a dictionary to translate string words in Int. > > The answer depends on the automatic optimizations in GHC, because GHC > could compare quickely two strings if it is the same object, so it > depends if program generated by GHC have a dictionary (tree) of strings > internaly. Someone knows this ? > > (Sorry for my english, I'm french) > > thank you > > -- > Emmanuel Chantr?au > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From agocorona at gmail.com Thu Dec 3 14:21:14 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu Dec 3 13:55:54 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <4B17D9EC.3010808@kent.ac.uk> References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> <20091203162356.32431136@brouillard.aima.fr> <4B17D9EC.3010808@kent.ac.uk> Message-ID: " In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate" ????? should? or you want to say "actually do that so the optimization does is not done"? The correct amswer is not the sould you mention, but True (IMHO). So the optimization can be done anyway. 2009/12/3 Neil Brown > Emmanuel CHANTREAU wrote: > >> Le Thu, 3 Dec 2009 13:20:31 +0100, >> David Virebayre > >> a ?crit : >> >> >> >>> It doesn't work this way : Strings are just lists of Chars. Comparison >>> is made recursively, Char by Char. You can have a look at the source >>> to make sure : >>> >>> instance (Eq a) => Eq [a] where >>> [] == [] = True >>> (x:xs) == (y:ys) = x == y && xs == ys >>> _xs == _ys = False >>> >>> >> >> Hello >> >> Thank you David and Bulat for your answers. >> >> I don't see the proof you see. Because GHC could store two sames >> objects juste once and by the definition of == on lists it could deduce >> that "forall x; List x => x==x". GHC have all informations to do this >> optimization job, because haskell functions definitions are mathematics >> definitions. >> >> > Besides any other reasons, Haskell has the error function, and infinite > lists. Consider: > > p :: String > p = error "Haha!" > > q :: String > q = repeat 'a' > > pEqualsP :: Bool > pEqualsP = p == p > > qEqualsQ :: Bool > qEqualsQ = q == q > > By your rule, pEqualsP and qEqualsQ should be True. In fact, the correct > answer is that pEqualsP should produce an error and qEqualsQ should never > terminate. Since Strings can contain such errors and infinite lists, you > can't know for certain that an object equals itself without checking its > entire length, which is what the original definition for equals did anyway. > There may be strict data structures for which your optimisation might be > applicable, though. > > Neil. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/ff1ec2a4/attachment.html From daniel.is.fischer at web.de Thu Dec 3 14:37:06 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Dec 3 14:14:24 2009 Subject: [Haskell-cafe] Card games In-Reply-To: References: <20091107105451.GA7384@kira.casa> Message-ID: <200912032037.06686.daniel.is.fischer@web.de> Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: > 2009/12/3 Matthias G?rgens : > > Hi Tom, > > > > Did you make any progress on your Dominion quest? ?I guess you could > > start by modeling `Big Money' and add the other cards (and > > interaction) from there. > > No, I'm still trying to tune a "partitionM" function I wrote. Maybe we can help? > (I'm still a beginner.) ^_^ I'd like to write a Dominion library or some > more generic superset at some point, though. From jfredett at gmail.com Thu Dec 3 14:40:58 2009 From: jfredett at gmail.com (Joe Fredette) Date: Thu Dec 3 14:15:41 2009 Subject: [Haskell-cafe] Card games In-Reply-To: <200912032037.06686.daniel.is.fischer@web.de> References: <20091107105451.GA7384@kira.casa> <200912032037.06686.daniel.is.fischer@web.de> Message-ID: <98733687-EC48-428A-A96D-DAB4CAE7612C@gmail.com> Yah! We like helping! On Dec 3, 2009, at 2:37 PM, Daniel Fischer wrote: > Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: >> 2009/12/3 Matthias G?rgens : >>> Hi Tom, >>> >>> Did you make any progress on your Dominion quest? I guess you could >>> start by modeling `Big Money' and add the other cards (and >>> interaction) from there. >> >> No, I'm still trying to tune a "partitionM" function I wrote. > > Maybe we can help? > >> (I'm still a beginner.) ^_^ I'd like to write a Dominion library >> or some >> more generic superset at some point, though. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From garious at gmail.com Thu Dec 3 14:52:37 2009 From: garious at gmail.com (Greg Fitzgerald) Date: Thu Dec 3 14:27:35 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: References: <4B170350.2070504@van.steenbergen.nl> Message-ID: <1f3dc80d0912031152u3c0ba55akb9c3fb72a0b96929@mail.gmail.com> On Thu, Dec 3, 2009 at 5:34 AM, Conor McBride wrote: > http://www.haskell.org/pipermail/libraries/2008-January/008917.html On Tue, Jan 15, 2008 at 3:31 PM, Conor McBride wrote: > Haskell's classes are the best damn rhythm section in > the industry: you hum it, they play it. On Fri, Dec 10, 2004 at 2:21 AM, Conor McBride wrote: > If you're willing to make the types distinguish the idioms you're using, > as in choice-lists and vector-lists, then a lot of routine operations wither > to a huddle of combinators sitting under a type signature which actually does > most of the work. Instance inference is like having a great rhythm section: > you hum it, they play it. Very eloquent Conor. Can we get this guy quoted in HWN? I think he's earned it. :-) On Thu, Dec 3, 2009 at 5:34 AM, Conor McBride wrote: > class Newtype n where > type Unpack n > pack :: Unpack n -> n > unpack :: n -> Unpack n Nice. Would the code below be a good way to deal with subtyping? It'd be convenient to have some way to go from a 64-bit Double to a 32-bit Float and be informed when a Double can't be represented precisely by a Float, but to have the option to move forward with the minor loss of precision. class Subset n where type Superset n demote :: Superset n -> Either n n promote :: n -> Superset n squeeze :: Subset n => Superset n -> n squeeze = either id id . demote In action: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13554#a13554 Thanks, Greg From daniel.is.fischer at web.de Thu Dec 3 14:54:22 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Dec 3 14:30:30 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> Message-ID: <200912032054.22413.daniel.is.fischer@web.de> Am Donnerstag 03 Dezember 2009 19:14:40 schrieb Stefan Holdermans: > John, Miguel (and others), > > >> Don Stewart wrote, "the guarantees of purity the type system > >> provides are extremely > >> useful for verification purposes". My response to this is in > >> theory. This is what caught my attention initially, but the > >> language lacks polish and does not appear to be going in a > >> direction where it shows signs where it will self-correct. It may > >> even be beyond repair. I care about others and I don't want people > >> to be misled. [...] > > > > The burden of proof is on you to demonstrate that it _is_. > > I admit it's tempting, but wouldn't you agree that, especially in this > case, it's better not to feed the troll? To feed, or not to feed: that is the question: Whether 'tis nobler in the mind to suffer The quips and ramblings of outrageous trolling, Or to take arms against a sea of nonsense, And by opposing end them? > > Cheers, > > Stefan From miguelimo38 at yandex.ru Thu Dec 3 14:58:10 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Dec 3 14:32:49 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <200912032054.22413.daniel.is.fischer@web.de> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <200912032054.22413.daniel.is.fischer@web.de> Message-ID: Brilliant. Just brilliant. On 3 Dec 2009, at 22:54, Daniel Fischer wrote: > Am Donnerstag 03 Dezember 2009 19:14:40 schrieb Stefan Holdermans: >> John, Miguel (and others), >> >>>> Don Stewart wrote, "the guarantees of purity the type system >>>> provides are extremely >>>> useful for verification purposes". My response to this is in >>>> theory. This is what caught my attention initially, but the >>>> language lacks polish and does not appear to be going in a >>>> direction where it shows signs where it will self-correct. It may >>>> even be beyond repair. I care about others and I don't want people >>>> to be misled. [...] >>> >>> The burden of proof is on you to demonstrate that it _is_. >> >> I admit it's tempting, but wouldn't you agree that, especially in >> this >> case, it's better not to feed the troll? > > To feed, or not to feed: that is the question: > Whether 'tis nobler in the mind to suffer > The quips and ramblings of outrageous trolling, > Or to take arms against a sea of nonsense, > And by opposing end them? > >> >> Cheers, >> >> Stefan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jfredett at gmail.com Thu Dec 3 15:01:04 2009 From: jfredett at gmail.com (Joe Fredette) Date: Thu Dec 3 14:35:44 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <200912032054.22413.daniel.is.fischer@web.de> Message-ID: I think you meant to say: Now is the winter of our discontent with this troll made glorious summer by this son of Fischer. So long as we bastardize the bard, we best bastardize him fully! :) /Joe On Dec 3, 2009, at 2:58 PM, Miguel Mitrofanov wrote: > Brilliant. Just brilliant. > > On 3 Dec 2009, at 22:54, Daniel Fischer wrote: > >> Am Donnerstag 03 Dezember 2009 19:14:40 schrieb Stefan Holdermans: >>> John, Miguel (and others), >>> >>>>> Don Stewart wrote, "the guarantees of purity the type system >>>>> provides are extremely >>>>> useful for verification purposes". My response to this is in >>>>> theory. This is what caught my attention initially, but the >>>>> language lacks polish and does not appear to be going in a >>>>> direction where it shows signs where it will self-correct. It may >>>>> even be beyond repair. I care about others and I don't want people >>>>> to be misled. [...] >>>> >>>> The burden of proof is on you to demonstrate that it _is_. >>> >>> I admit it's tempting, but wouldn't you agree that, especially in >>> this >>> case, it's better not to feed the troll? >> >> To feed, or not to feed: that is the question: >> Whether 'tis nobler in the mind to suffer >> The quips and ramblings of outrageous trolling, >> Or to take arms against a sea of nonsense, >> And by opposing end them? >> >>> >>> Cheers, >>> >>> Stefan >> >> >> _______________________________________________ >> 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 From korpios at korpios.com Thu Dec 3 15:24:11 2009 From: korpios at korpios.com (Tom Tobin) Date: Thu Dec 3 14:58:51 2009 Subject: [Haskell-cafe] Card games In-Reply-To: <200912032037.06686.daniel.is.fischer@web.de> References: <20091107105451.GA7384@kira.casa> <200912032037.06686.daniel.is.fischer@web.de> Message-ID: On Thu, Dec 3, 2009 at 1:37 PM, Daniel Fischer wrote: > Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: >> No, I'm still trying to tune a "partitionM" function I wrote. > > Maybe we can help? Sure; should I post it to haskell-beginners? From daniel.is.fischer at web.de Thu Dec 3 15:29:34 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Dec 3 15:05:40 2009 Subject: [Haskell-cafe] Card games In-Reply-To: References: <20091107105451.GA7384@kira.casa> <200912032037.06686.daniel.is.fischer@web.de> Message-ID: <200912032129.34334.daniel.is.fischer@web.de> Am Donnerstag 03 Dezember 2009 21:24:11 schrieb Tom Tobin: > On Thu, Dec 3, 2009 at 1:37 PM, Daniel Fischer wrote: > > Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: > >> No, I'm still trying to tune a "partitionM" function I wrote. > > > > Maybe we can help? > > Sure; should I post it to haskell-beginners? Here, there, most of us are subscribed to both lists. From korpios at korpios.com Thu Dec 3 15:34:43 2009 From: korpios at korpios.com (Tom Tobin) Date: Thu Dec 3 15:09:22 2009 Subject: [Haskell-cafe] Card games In-Reply-To: <200912032129.34334.daniel.is.fischer@web.de> References: <20091107105451.GA7384@kira.casa> <200912032037.06686.daniel.is.fischer@web.de> <200912032129.34334.daniel.is.fischer@web.de> Message-ID: On Thu, Dec 3, 2009 at 2:29 PM, Daniel Fischer wrote: > Am Donnerstag 03 Dezember 2009 21:24:11 schrieb Tom Tobin: >> On Thu, Dec 3, 2009 at 1:37 PM, Daniel Fischer wrote: >> > Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: >> >> No, I'm still trying to tune a "partitionM" function I wrote. >> > >> > Maybe we can help? >> >> Sure; should I post it to haskell-beginners? > > Here, there, most of us are subscribed to both lists. I posted it to the beginners list, subject "partitionM". From ketil at malde.org Thu Dec 3 16:32:31 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Dec 3 16:07:09 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <200912032054.22413.daniel.is.fischer@web.de> (Daniel Fischer's message of "Thu, 3 Dec 2009 20:54:22 +0100") References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <200912032054.22413.daniel.is.fischer@web.de> Message-ID: <87k4x3rbf4.fsf@malde.org> Daniel Fischer writes: > To feed, or not to feed: that is the question: Out, out, brief troll! This is certainly a thread that's full of sound and fury, but (or so I'm afraid) signifying nothing. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From mail at joachim-breitner.de Thu Dec 3 16:34:12 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Dec 3 16:08:54 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <49a77b7a0912031003kd08f07asaf267603f0b83ab5@mail.gmail.com> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> <1259839735.6800.1.camel@localhost> <49a77b7a0912031003kd08f07asaf267603f0b83ab5@mail.gmail.com> Message-ID: <1259876052.3105.5.camel@localhost> Hi, Am Donnerstag, den 03.12.2009, 13:03 -0500 schrieb David Menendez: > On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner > wrote: > > Am Donnerstag, den 03.12.2009, 11:13 +0000 schrieb Matthew Pocock: > >> Perhaps what you are looking for is a more powerful "defining" > >> semantics? > >> > >> newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo > >> has are delegated through from MyFoo > > > > it goes into the right direction, but I?d also like to have this also > > capeable to derive single functions (giving them a new name), and not > > only class instances. > > Something like the restricted type synonym extension in Hugs? > > yes, this is very close to what I?d hope for. Last minor (but really minor) wish: I don?t think it would hurt to allow the use of this feature independent of the definition of the newtype: I could have a newtype Foo = Foo Int somewhere, possibly in a different module, and write something like myFoo :: Foo -> (Foo,Foo) resolving Foo myFoo a = (a,a+a) (syntax and wording very ad hoc and not thought through). But yes, I think I?d be happy to have hugs? extension here at hand sometimes. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/13893b2b/attachment.bin From dave at zednenem.com Thu Dec 3 16:35:14 2009 From: dave at zednenem.com (David Menendez) Date: Thu Dec 3 16:09:58 2009 Subject: [Haskell-cafe] Implicit newtype unwrapping In-Reply-To: <4B170350.2070504@van.steenbergen.nl> References: <4B170350.2070504@van.steenbergen.nl> Message-ID: <49a77b7a0912031335m1be7a34emb0d7f97351f2ca11@mail.gmail.com> On Wed, Dec 2, 2009 at 7:16 PM, Martijn van Steenbergen wrote: > So here's a totally wild idea Sjoerd and I came up with. > > What if newtypes were unwrapped implicitly? As several have suggested, this creates ambiguity. But it might be handy to have a way to declare a scope in which the newtype is transparent. E.g., newtype N = N T f :: T -> T -> T f = ... open N in -- in this block, N is treated as a synonym for T g :: N -> N -> N g = f This is similar to the restricted type synonyms feature in Hugs, and I think it's straightforward to encode in GHC's System FC. >From my perspective, the primary advantage to a feature like this is that it avoids the need to convert [N] to [T], which under the current system effectively requires mapping an identity function over the entire list. But that also exposes the danger of this idea, where GADTs and type families are involved. data G where A :: G N B :: G T a :: G N -> N a ~A = N -- should never fail, because A is the only (non-bottom) value of type G N. Now, what stops me from writing something like this? open N in ... a B ... (See the discussion at for how this problem crops up with generalized newtype deriving.) -- Dave Menendez From mail at joachim-breitner.de Thu Dec 3 16:39:24 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Dec 3 16:14:07 2009 Subject: [Haskell-cafe] Re: Implicit newtype unwrapping In-Reply-To: References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> Message-ID: <1259876364.3105.8.camel@localhost> Hi, Am Donnerstag, den 03.12.2009, 10:22 -0800 schrieb yairchu@gmail.com: > > I guess TH could probably do this. > > I think this does what you wish for: > http://hackage.haskell.org/packages/archive/peakachu/0.2/doc/html/Data-Newtype.html > > Example: > > $(mkWithNewtypeFuncs [2] ''ZipList) > > withZipList2 (<*>) [(+3), (*3)] [6, 7] > [9, 21] > > $(mkInNewtypeFuncs [2] ''ZipList) > > getZipList $ inZipList2 (++) (ZipList "hello ") (ZipList "world") > > "hello world" > > in some future this won't be in this unrelated "peakachu" package, and > be incorporated into Neil M's derive. > but for now this is where you can find it. Nice, and close. It seems it does not handle the datatype in arbitrary positions in the type (as in Foo -> ( a -> Either Foo ())) -> (Foo, ())). But thanks for the pointer. Maybe I should give it a shot. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/37b93693/attachment.bin From gcross at phys.washington.edu Thu Dec 3 16:50:06 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 3 16:25:59 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message Message-ID: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> If there is one thing that we really don't have enough of in Haskell, it is *ways to handle errors*! Thus, I am pleased to announce the release of the "error-message" package to help in filling this, erm, gap. This philosophy behind this package is that it is often better to find out all of the errors that have occured in a computation and report them simultaneously, rather than aborting as soon as the first error is encountered. Towards this end, this package supplies a type of /combinable error messages/ (ErrorMessage in the Data.ErrorMessage module) so that all of the errors from subcomputations can be gathered and presented together. The following provides an example of how these can be used: ================================================== sqrtWithError :: Float -> Either ErrorMessage Float sqrtWithError x | x < 0 = leftErrorMessageText ("Error computing the square root of " ++ (show x) ++ ":") "Square roots cannot be taken of negative numbers." | otherwise = Right (sqrt x) sumWithError :: Either ErrorMessage Float -> Either ErrorMessage Float -> Either ErrorMessage Float sumWithError (Left error1) (Left error2) = Left (error1 `mappend` error2) sumWithError (Left error) _ = Left error sumWithError _ (Left error) = Left error sumWithError (Right value1) (Right value2) = Right (value1 + value2) showSumOrErrorOf :: Float -> Float -> String showSumOrErrorOf x y = case sumWithError (sqrtWithError x) (sqrtWithError y) of Right value -> "The value is " ++ show value Left error -> show . formatErrorMessage $ error ================================================== The result of @showSumOrErrorOf (-1) (-2)@ is the string, Error computing the square root of -1: Square roots cannot be taken of negative numbers. Error computing the square root of -2: Square roots cannot be taken of negative numbers. whereas the result of @showSumOrErrorOf (-1) (-1)@ is the string, Error computing the square root of -1: Square roots cannot be taken of negative numbers. Note how the error message only appears once; this is because the process of combining the error messages automatically eliminates all identical headings under the assumption that they came from the same original computation, as was the case here. Currently, the definition of @sumWithError@ is largely boilerplate. Happily, the Haskell community has done a lot of work to identify patterns such as these and to write libraries that allow us to express them concisely. In particular, a standard trick when working with errors like this is to express the calculation as a 'Monad', such as by using the following definition: ================================================== sumWithError_2 argument1 argument2 = do value1 <- argument1 value2 <- argument2 return (value1 + value2) ================================================== Or, even more concisely: ================================================== sumWithError_3 = liftM2 (+) ================================================== Unfortunately though, neither of these definitions have the same semantics as the original @sumWithError@, as using both we get the following error message for @showSumOrErrorOf (-1) (-2)@: ================================================== Error computing the square root of -1: Square roots cannot be taken of negative numbers. ================================================== That is, we have lost the second of the two error messages. The reason for this is that 'Monad'-style error processing expresses the computation as a sequence, and gives up as soon as it sees any error. In this case of @sumWithError@, however, the evaluation of the second argument can proceed even if there was an error in the first argument. Thus, rather than using a 'Monad' pattern, we use an 'Applicative' pattern: ================================================== sumWithError_4 = liftA2 (+) ================================================== Now both error messages are displayed. Anyway, I hope that someone other than myself finds this pattern to be helpful. :-) Cheers, Greg From gcross at phys.washington.edu Thu Dec 3 17:01:57 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 3 16:38:36 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling Message-ID: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> Hey everyone, When I uploaded my new package, "error-message", I also went ahead and created a new category: "Error Handling". I did this because there are a number of packages related to this issue, so it might be helpful to have them presented together in one place. Thus, if you have or are in the process of writing a package related to this, please consider adding it to this category sometime so that my package doesn't get lonely. :-) Cheers, Greg From alexey.skladnoy at gmail.com Thu Dec 3 17:41:25 2009 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Thu Dec 3 17:16:04 2009 Subject: [Haskell-cafe] Data.Binary and error handling In-Reply-To: <838F1A91-9CE7-481A-B7C5-764DF594F52A@glyphic.com> References: <8425cc0e0911270300w4b5565b9sacef82f19d57cdb1@mail.gmail.com> <221b53ab0911270731s6ea07756kb9c03a0c3b1b9cbc@mail.gmail.com> <838F1A91-9CE7-481A-B7C5-764DF594F52A@glyphic.com> Message-ID: <8425cc0e0912031441m15f8eb1fxb31460603b1e547d@mail.gmail.com> On Fri, Nov 27, 2009 at 10:36 PM, Mark Lentczner wrote: > I'm in the same quandary: > > Data.Binary from the binary package has no error handling > Data.Serialize from the cereal package uses only strict ByteString > > I was going to add error handling to Binary as a weekend project (it isn't that hard), but when I contacted the developers of binary, I was pointed at cereal. But as my project can parse multi-megabyte objects off the wire, I really want lazy ByteString support. > > I understand from the cereal creators that lazy ByteStrings are not in the future of cereal, since they got a big speed boost by going to strict ByteStrings only. > > I understand that Bryan O'Sullivan might have done work on adding errors to Binary... Bryan? If that's available, can we get it? If not, shall I do the work to add error handling? It's a long weekend... I've got time! > As an experiment I ported error handling from cereal to binary. It does work, passes all tests shipped with binary. Perfomance became worse. According to benchmarks shipped with binary I observed ~25% perfomance drop. However when I ported my program I have 40% speedup. I think it's because I removed code which work around lack error handling and replaced with error handling in Get monad As for strictess concerns. Patch doesn't seem to change strictess from current state. At least my program which uses very big inputs works without any changes. Comments and suggestions are welcome -------------- next part -------------- A non-text attachment was scrubbed... Name: binary-errors.patch Type: text/x-patch Size: 4524 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/9085a836/binary-errors.bin From malcolm.wallace at cs.york.ac.uk Thu Dec 3 17:46:13 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Dec 3 17:21:26 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <20091203164329.GC17116@whirlpool.galois.com> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> Message-ID: <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> >> It would perhaps be better to have one nice big "Download" button >> that >> takes you to a separate download page. > > Having a single download link that only points to the Haskell Platform > would be a bit of a policy shift. ... but that was *not* what was suggested. The suggestion was to have a single Download button, leading to a *page* of suitably described links, allowing the user to choose whether they only wanted the basics (a choice of compiler/interpreter + cabal), or the whole Platform, or something else. It would be the ideal place to explain what cabal is and how to use hackage to get more libraries than are contained in the platform. It would perhaps reduce the clutter on the front page that some people complained of (although I don't personally think it cluttered). Regards, Malcolm From dons at galois.com Thu Dec 3 17:48:35 2009 From: dons at galois.com (Don Stewart) Date: Thu Dec 3 17:23:24 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> Message-ID: <20091203224835.GW17556@whirlpool.galois.com> malcolm.wallace: > The suggestion was to have a single Download button, leading to a *page* > of suitably described links, allowing the user to choose whether they > only wanted the basics (a choice of compiler/interpreter + cabal), or the > whole Platform, or something else. It would be the ideal place to > explain what cabal is and how to use hackage to get more libraries than > are contained in the platform. It would perhaps reduce the clutter on > the front page that some people complained of (although I don't > personally think it cluttered). Sounds great! Can someone prepare such a page, please. The wiki should be directly editable. -- Don From jeremy at n-heptane.com Thu Dec 3 17:50:33 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Dec 3 17:25:16 2009 Subject: [Haskell-cafe] SYB <> very, very mysteriously Message-ID: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> I have the following program which loops under GHC 6.10.4: http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=13561#a13561 {-# LANGUAGE DeriveDataTypeable, FlexibleInstances, MultiParamTypeClasses, UndecidableInstances #-} module Main where import qualified Data.Data as Data import Data.Typeable (Typeable) import Happstack.Data.Default import Data.Generics.SYB.WithClass.Basics import Data.Generics.SYB.WithClass.Instances () data Proposition = Proposition Expression deriving (Show, Data.Data, Typeable) data Expression = Conjunction (Maybe Expression) deriving (Show, Data.Data, Typeable) -- instance (Sat (ctx [Expression]), Sat (ctx Expression), Sat (ctx Proposition)) => Data ctx Proposition where instance Data DefaultD Proposition where gunfold _ k z c = case constrIndex c of 1 -> k (z Proposition) instance Default Proposition constrExpr :: Constr constrExpr = mkConstr dataTypeExpr "Conjuction" [] Prefix dataTypeExpr :: DataType dataTypeExpr = mkDataType "Expression" [constrExpr] instance ( Data ctx [Expression] , Sat (ctx Expression) , Sat (ctx (Maybe Expression))) => Data ctx Expression where {- instance Data DefaultD Expression where -} gunfold _ k z c = case constrIndex c of 1 -> k (z Conjunction) dataTypeOf _ _ = dataTypeExpr instance Default Expression e :: Expression e = defaultValueD dict main = print e I wish to explain the *many* ways in which it is mysterious. If you load the program into GHCi and evaluate 'e' it will hang. If you compile the program and run it, it will output <>. This behavior seems annoying, but not very weird. But, here is where it gets fun: 1. if you load the program into GHCi and eval 'e' it will hang. But, if you load the program and type, '(defaultValueD dict) :: Expression' at the prompt, it works fine! 2. if you remove the (Data DefaultD Proposition) instance, it works fine. (Even though Expression does not refer to Proposition in any way) 3. if you simply change the definition of 'gunfold' in the 'Data ctx Proposition' instance to, error "foo". The application works fine. That's right, if you change the body of a function that isn't even being called, evaluating 'e' starts working. (Even though Expression does not refer to Proposition in any way. And even though that gunfold instance is never actually called). 4. if you change the constraint on, Data ctx Expression, from (Data ctx [Expression]) to (Data ctx Expression) it works fine. (Or remove it all together). 5. if you change 'instance (Data DefaultD Proposition) where' to the line above it which is commented out, it works fine. 6. if you change the type of Proposition to, data Proposition = Proposition (Expression, Expression), then it works fine. So far I have only tested this in GHC 6.10.4. Any idea what is going on here? I can't imagine how changing the body of functions that aren't being called would fix things... - jeremy From jeremy at n-heptane.com Thu Dec 3 17:55:45 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Dec 3 17:30:24 2009 Subject: [Haskell-cafe] happstack homepage In-Reply-To: References: Message-ID: <27CCF54C-11FF-474B-BF2E-9EE969960D87@n-heptane.com> Hello, See this thread, http://groups.google.com/group/happs/browse_thread/thread/6e4d6af0109cc649 - jeremy On Dec 3, 2009, at 9:30 AM, Roel van Dijk wrote: > I noticed that happstack.com and tutorial.happstack.com are both equal > to patch-tag.com. Google's cache has the original pages. Is this the > result of some misconfiguration or something else? > > I want to play with happstack and this is a slight inconvenience. On > the other hand, all happstack packages build without problems so I'll > build the tutorial locally and work from there. > > Regards, > Roel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From stefan at cs.uu.nl Thu Dec 3 18:02:55 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Dec 3 17:37:34 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <200912032054.22413.daniel.is.fischer@web.de> Message-ID: <3A548875-2CAC-4BCE-9E3D-3DC6F3052967@cs.uu.nl> >> To feed, or not to feed: that is the question: >> Whether 'tis nobler in the mind to suffer >> The quips and ramblings of outrageous trolling, >> Or to take arms against a sea of nonsense, >> And by opposing end them? > Brilliant. Just brilliant. +1 Cheers, Stefan From stefan at cs.uu.nl Thu Dec 3 18:08:23 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Dec 3 17:43:02 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <200912032054.22413.daniel.is.fischer@web.de> Message-ID: <7843DD55-5E7A-4B07-A559-C232C8D06196@cs.uu.nl> > So long as we bastardize the bard, we best bastardize him fully! :) If only we could claim: Though this be madness, yet there is method in 't. Cheers, Stefan From marlowsd at gmail.com Thu Dec 3 18:30:05 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 3 18:04:56 2009 Subject: [Haskell-cafe] Wikipedia article Message-ID: <4B1849FD.2000706@gmail.com> As noted before, the Wikipedia article for Haskell is a disorganised mess. http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 earlier this year, dons suggested reorganising it and posted a template on the Haskell wiki: http://haskell.org/haskellwiki/WikipediaArticleDesign I've made a start on a new version of the page: http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 I've kept most of the existing information, but reorganised it more or less according to Don's template, and I filled out the overview section. Also I fixed numerous things, but the page still has a long way to go Does anyone mind if I spam the existing Haskell article with this new one, or do people think we should continue editing the sandbox version until it's in better shape? Cheers, Simon From dons at galois.com Thu Dec 3 18:36:22 2009 From: dons at galois.com (Don Stewart) Date: Thu Dec 3 18:11:03 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <4B1849FD.2000706@gmail.com> References: <4B1849FD.2000706@gmail.com> Message-ID: <20091203233622.GB17556@whirlpool.galois.com> marlowsd: > As noted before, the Wikipedia article for Haskell is a disorganised mess. > > http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 > > earlier this year, dons suggested reorganising it and posted a template > on the Haskell wiki: > > http://haskell.org/haskellwiki/WikipediaArticleDesign > > I've made a start on a new version of the page: > > http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 > > I've kept most of the existing information, but reorganised it more or > less according to Don's template, and I filled out the overview section. > Also I fixed numerous things, but the page still has a long way to go > > Does anyone mind if I spam the existing Haskell article with this new > one, or do people think we should continue editing the sandbox version > until it's in better shape? Maybe we should make the switch, and move the old page into some historical section. That's more likely to ensure the page gets filled out... Gwern, other wikipedians, thoughts? -- Don From mail at joachim-breitner.de Thu Dec 3 19:00:03 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Dec 3 18:34:50 2009 Subject: [Haskell-cafe] Re: Implicit newtype unwrapping In-Reply-To: <1259876364.3105.8.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> <1259876364.3105.8.camel@localhost> Message-ID: <1259884803.3105.21.camel@localhost> Hi, Am Donnerstag, den 03.12.2009, 22:39 +0100 schrieb Joachim Breitner: > Nice, and close. It seems it does not handle the datatype in arbitrary > positions in the type (as in Foo -> ( a -> Either Foo ())) -> (Foo, > ())). But thanks for the pointer. Maybe I should give it a shot. I started to write a module. My (incomplete!) code looks like this: ===================================================== {-# LANGUAGE PatternGuards #-} module OpenNewtype (openNewType) where import Debug.Trace import Language.Haskell.TH import Data.Monoid import qualified Data.Map as M openNewtype typeName declsQ = do info <- reify typeName decls <- declsQ tmpName1 <- newName "x" tmpName2 <- newName "x" -- Check if the given type is really a simple newtype case info of TyConI (NewtypeD _ _ _ (NormalC constr [(NotStrict,ConT realType)]) _) -> let types = getTypeMap decls in return $ map (go constr tmpName2 tmpName2 realType types) decls _ -> error $ "openNewType can only handle siple newtype defined types\nArgument was: " ++ pprint info where go constr tmpName1 tmpName2 realType types d = case d of (ValD (VarP name) _ _) -> FunD name [Clause [] (NormalB (wrap name types)) [d]] (FunD name _) -> FunD name [Clause [] (NormalB (wrap name types)) [d]] _ -> d where wrap name types | Just t <- M.lookup name types = wrapCo (VarE name) t | otherwise = (VarE name) wrapCo exp (ConT t) | t == typeName = inject exp | otherwise = exp wrapCo exp (ForallT _ _ t) = wrapCo exp t wrapCo exp (VarT _) = exp wrapCo exp (TupleT _) = exp wrapCo exp (ArrowT) = exp wrapCo exp (ListT) = exp wrapCo exp (AppT (AppT ArrowT t1) t2) = LamE [VarP tmpName1] (wrapCo (AppE exp (wrapCon (VarE tmpName1) t1)) t2) wrapCon exp (ConT t) | t == typeName = unwrap exp | otherwise = exp wrapCon exp (ForallT _ _ t) = wrapCo exp t wrapCon exp (VarT _) = exp wrapCon exp (TupleT _) = exp wrapCon exp (ArrowT) = exp wrapCon exp (ListT) = exp wrapCon exp (AppT (AppT ArrowT t1) t2) = LamE [VarP tmpName1] (wrapCon (AppE exp (wrapCo (VarE tmpName1) t1)) t2) inject :: Exp -> Exp inject e = AppE (ConE constr) e unwrap :: Exp -> Exp unwrap e = LetE [ValD (ConP constr [VarP tmpName2]) (NormalB e) []] (VarE tmpName2) getTypeMap :: [Dec] -> M.Map Name Type getTypeMap = mconcat . map go where go (SigD name t) = M.singleton name t go _ = mempty ===================================================== And the intended usage would be ===================================================== {-# LANGUAGE TemplateHaskell #-} import OpenNewtype newtype Foo = Foo Int deriving Show $(openNewtype ''Foo [d| nullFoo :: Foo nullFoo = 0 {- toFoo :: Int -> Foo toFoo = id fromFoo :: Foo -> Int fromFoo = id -} succFoo :: Foo -> Foo succFoo = succ addFoo :: Foo -> Foo -> Foo addFoo a b = a + b |] ) main = do print (succFoo (Foo 1)) ===================================================== And indeed, it works for null, succFoo, addFoo. The generated code looks like this, for example for succfoo: succFoo :: Main.Foo -> Main.Foo succFoo = \ x[a28u] -> Main.Foo (succFoo (let Main.Foo x[a28v] = x[a28u] in x[a28v])) where succFoo = GHC.Enum.succ But when I uncommented the definition of toFoo and fromfoo, I got: Demo.hs:11:9: Couldn't match expected type `Foo' against inferred type `Int' In the expression: id In the definition of `toFoo': toFoo = id In the second argument of `openNewtype', namely `[d| nullFoo :: Foo nullFoo = 0 toFoo :: Int -> Foo toFoo = id .... |]' And just now, after writing half the code, I find out that $( fun [d|...|] ) runs the type checker on the declarations before passing them to fun, which of course kills my whole approach here, as only having the declarations pass through openNewType will make them type check. Is there any way to pass declarations to a TH function so that their names are resolved, but their type is not checked (or, alternatively, type errors are ignored). If not, what would be a sane work-around? Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/440099e2/attachment.bin From wren at freegeek.org Thu Dec 3 19:49:32 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Dec 3 19:18:49 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <1259845201.4896.103489.camel@localhost> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <1259845201.4896.103489.camel@localhost> Message-ID: <4B185C9C.6040706@freegeek.org> Duncan Coutts wrote: > I've got an open mind on the suggestion to amalgamate the two ways the > list could end. I'm not especially in favour of generalising for the > sake of generalising, especially if it looses the connection to the > notion of annotating your "ordinary" data structure with extra errors. > If I effectively always have to use an Either for the final value then > perhaps it does not buy anything and just makes the folds uglier (since > it might loose the connection with the ordinary fold). But it could make > even that use case simpler so it's worth looking at in a few examples > (eg the tar package). These days I view folds as automatically defined by the data type, so I don't see any reason (on those grounds) to want to compare it to lists' foldr as opposed to any other arbitrary catamorphism. One reason to prefer a single basis is that it simplifies the ability to do concatenation and the associated fusion. It still only has one termination point (unlike trees) so it's still possible to do augment fusion. But because there are two bases, concatenation needs to look like this: concat2 :: T a b -> (b -> T a b) -> T a b -> T a b Whereas for the version with no Nil, it's just: concat1 :: T a b -> (b -> T a b) -> T a b As for the usage, we'd be comparing these two: concat2 foo handler bar concat1 foo (maybe bar handler) One of the nice things about not having a Nil is that it lets you easily be polymorphic over things ending in () ---a normal list---, (Maybe a) ---a fallible list---, (Either a b) ---your progress type---, etc. Whereas the version that has both Nil and End forces us into the (Maybe a) scenario. A side effect of this is that the (Either a b) option isn't available because we can only construct t=Mx.(x*t)+(1+a+b) not t=Mx.(x*t)+(a+b). -- Live well, ~wren From daniel.is.fischer at web.de Thu Dec 3 19:55:05 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Dec 3 19:31:12 2009 Subject: [Haskell-cafe] Beginner's speed problem In-Reply-To: References: <200912022315.58224.daniel.is.fischer@web.de> Message-ID: <200912040155.05766.daniel.is.fischer@web.de> Am Donnerstag 03 Dezember 2009 06:52:01 schrieb Aditya M: > Hello > > Thanks for all the help! > > I only have a couple of questions. > > On Thu, Dec 3, 2009 at 03:45, Daniel Fischer wrote: > > Am Mittwoch 02 Dezember 2009 22:44:01 schrieb Don Stewart: > >> aditya87: > >> > Hi, > >> > > >> > I am trying to solve this problem: > >> > https://www.spoj.pl/problems/LASTDIG/ It is very simple. Given a and > >> > b, return the last digit of a^b. b could be large, so I used > >> > logarithmic exponentiation and > > > > Just to mention it, you can do something much much faster for this > > problem. Something in the microsecond range (if IO is fast enough, > > millisecond otherwise). > > I guess you mean that we can find the cycle that the last digits > follow while multiplying repeatedly by a, and then use that. Yes. Except there's not much finding to be done, you can pretty much write it down immediately. But I underestimated the slowness of String IO, so it's not gaining you terribly much unless you resort to ByteString IO. As an indication, for files containing 20.9 million, 2.85 million, 25942 (a,b) pairs respectively: ByteString + shortcut: 4.6 seconds, 0.66 seconds, 0.00 seconds ByteString + modular exponentiation: 49.2 seconds, 6.74 seconds, 0.06 seconds String + shortcut: 262 seconds, 35.04 seconds, 0.33 seconds String + modular exponentiation: 303 seconds, 40.73 seconds, 0.38 seconds (Note: I have tweaked the String IO, using main = fmap lines getContents >>= putStr . unlines . (map doit) . tail and modified doit (returns a String now, is a little stricter, calls words line only once; also read - for the base, I use (digitToInt . last), it's much faster than read) 1. With "replicateM n getLine" or "sequence $ take n $ repeat getLine", the entire input must be read in before processing can start. Firstly that's slower and secondly it needs a lot of memory - more than I have, for the larger files. 2. (putStr . unlines) is faster than mapM_ putStrLn. It could be tweaked more, but that wouldn't gain nearly as much as switching to ByteString.) So with String IO, in either method the overwhelming part of the time is used for IO (and read), in comparison, the algorithmic difference pales. With ByteString IO, the algorithmic difference stands out. > > I'll try that next in Haskell! > > >> ? ? {-# LANGUAGE BangPatterns #-} > >> > >> ? ? lastdigit :: Int -> Int -> Int -> Int > >> ? ? lastdigit 0 0 _ ?= 1 > >> ? ? lastdigit a b !c | even b ? ?= lastdigit ( (a*a) `rem` 10 ) (b > >> `quot` 2) c > >> > >> ? ? ? ? ? ? ? ? ? ? ?| b == 1 ? ?= (a*c) `rem` 10 > > > > However, > > > > ? | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c) > > This bang pattern (!c) is giving me pattern match errors. ??? without the LANGUAGE pragma, it would give a parse error, so you can't have forgotten that. But in lastdigit :: Int -> Int -> Int -> Int lastdigit 0 0 _ ?= 1 lastdigit a b !c | even b ? ?= lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c | b == 1 ? ?= (a*c) `rem` 10 | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) ((a*c) `rem` 10) there is simply no possibility for a pattern match error (other than having one argument bottom). I'm flabbergasted. > Is its only effect evaluating c instead of plain substitution? Yes, it keeps c evaluated instead of building a thunk. You can get pretty much the same effect by having lastdigit :: Int -> Int -> Int -> Int lastdigit 0 0 _ ?= 1 lastdigit a b c | even b ? ?= lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c | b == 1 ? ?= (a*c) `rem` 10 | otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) $! ((a*c) `rem` 10) using strict application on the last argument when it is modified. From matthias.goergens at googlemail.com Thu Dec 3 20:00:47 2009 From: matthias.goergens at googlemail.com (=?ISO-8859-1?Q?Matthias_G=F6rgens?=) Date: Thu Dec 3 19:35:45 2009 Subject: [Haskell-cafe] I miss OO In-Reply-To: References: <4B0D98DE.4070507@alumni.caltech.edu> <75cc17ac0911260207u446561c1r75de76ee9397955f@mail.gmail.com> <5fdc56d70911260444v1f619d3dx486a053215343d1f@mail.gmail.com> <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> Message-ID: > It would be fantastic to have a little practical real-world challenge > (like building a simple music system, or a simple multi-channel sound > mixer), and work this out in an imperative language, an > object-oriented language, a functional language, and maybe other > languages too, like logic languages or constraint languages (does the > latter exist?) There are some constraint languages. But I do not know whether they are general purpose (or even Turing complete). I have used ZIMPL, which is a language for specifying mixed integer linear optimization problems (which is somewhat related to constraint programming). Though it would not be useful for a music system. From wren at freegeek.org Thu Dec 3 20:06:39 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Dec 3 19:36:01 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <49a77b7a0912030951j1941ae09r61b4b224e9dbb000@mail.gmail.com> References: <20091203130302.6a67ad99@brouillard.aima.fr> <20091203173253.GA4022@thened.net> <49a77b7a0912030951j1941ae09r61b4b224e9dbb000@mail.gmail.com> Message-ID: <4B18609F.8070107@freegeek.org> David Menendez wrote: > Alec Berryman wrote: >> I don't know of a library to intern strings, but it's not too hard to >> implement. I couldn't find the code I wrote to do this, but I looked >> around a bit and this is about what I remember doing: >> >> http://www.haskell.org/pipermail/haskell-cafe/2005-June/010335.html >> >> For the application I was using, interning strings did provide a >> significant reduction in memory, but for whatever reason didn't help >> with speed. > > I'd use a trie. Edison provides Data.Edison.Assoc.TernaryTrie, and > there are a few other trie packages at hackage. One of those: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie also uses ByteStrings instead of Strings. This will further reduce your memory footprint and will improve performance (because of cache consistency, less pointer chasing, and using C's fast string comparison function). I've been meaning to write a ByteString interning library on top of it, but haven't found the time just yet. -- Live well, ~wren From lrpalmer at gmail.com Thu Dec 3 20:03:21 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Dec 3 19:37:59 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: References: <20091203130302.6a67ad99@brouillard.aima.fr> <4c88418c0912030420t1b81a525x2fd16c50732ec1ba@mail.gmail.com> <20091203162356.32431136@brouillard.aima.fr> <4B17D9EC.3010808@kent.ac.uk> Message-ID: <7ca3f0160912031703y5a2df39ei57d67e01cfc3556f@mail.gmail.com> On Thu, Dec 3, 2009 at 12:21 PM, Alberto G. Corona wrote: > " In fact, the correct answer is that pEqualsP should produce an error and > qEqualsQ should never terminate" > > ????? > should? or you want to say "actually do that so the optimization does is not > done"? > The correct amswer is not the sould you mention, but True (IMHO). So the > optimization can be done anyway. No, the correct answer is actually _|_. Returning True would violate referential transparency: p = [1..] Now suppose p == p returned True. Then we can substitute any name for its value, by ref trans. So p == [1..] should also return True. This is reasonable. However, it is possible to prove (outside Haskell, but still rigoroously in terms of its semantics) that [1..] = fix (\xs -> 1 : map (+1) xs). So p == fix (1 : map (+1) xs) should also return True. This is getting unreasonable. Such an expectation would seem to require (==) to do a comprehensive proof search. Luke > 2009/12/3 Neil Brown >> >> Emmanuel CHANTREAU wrote: >>> >>> Le Thu, 3 Dec 2009 13:20:31 +0100, >>> David Virebayre a ?crit : >>> >>> >>>> >>>> It doesn't work this way : Strings are just lists of Chars. Comparison >>>> is made recursively, Char by Char. You can have a look at the source >>>> to make sure : >>>> >>>> instance (Eq a) => Eq [a] where >>>> ? ?[] ? ? == [] ? ? = True >>>> ? ?(x:xs) == (y:ys) = x == y && xs == ys >>>> ? ?_xs ? ?== _ys ? ?= False >>>> >>> >>> Hello >>> >>> Thank you David and Bulat for your answers. >>> >>> I don't see the proof you see. Because GHC could store two sames >>> objects juste once and by the definition of == on lists it could deduce >>> that "forall x; List x => x==x". GHC have all informations to do this >>> optimization job, because haskell functions definitions are mathematics >>> definitions. >>> >> >> Besides any other reasons, Haskell has the error function, and infinite >> lists. ?Consider: >> >> p :: String >> p = error "Haha!" >> >> q :: String >> q = repeat 'a' >> >> pEqualsP :: Bool >> pEqualsP = p == p >> >> qEqualsQ :: Bool >> qEqualsQ = q == q >> >> By your rule, pEqualsP and qEqualsQ should be True. ?In fact, the correct >> answer is that pEqualsP should produce an error and qEqualsQ should never >> terminate. ?Since Strings can contain such errors and infinite lists, you >> can't know for certain that an object equals itself without checking its >> entire length, which is what the original definition for equals did anyway. >> ?There may be strict data structures for which your optimisation might be >> applicable, though. >> >> Neil. >> _______________________________________________ >> 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 > > From matthias.goergens at googlemail.com Thu Dec 3 20:03:17 2009 From: matthias.goergens at googlemail.com (=?ISO-8859-1?Q?Matthias_G=F6rgens?=) Date: Thu Dec 3 19:38:18 2009 Subject: [Haskell-cafe] I miss OO In-Reply-To: References: <4B0D98DE.4070507@alumni.caltech.edu> <75cc17ac0911260207u446561c1r75de76ee9397955f@mail.gmail.com> <5fdc56d70911260444v1f619d3dx486a053215343d1f@mail.gmail.com> <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> Message-ID: > When OO is about constructing a "machine" and talking about objects, > and FP is about making little algebraic languages, what would C or > Pascal be like? In these languages, you don't think about objects, but > you don't think about an algebra either? It's been a very long time > since I worked with these languages, but as far as I recall, I started > thinking about data structures and procedures operating on these data > structures, which sounds a look like making ADTs and > functions/operations on these... So this sounds odd, because it would > mean that C and Pascal are in a sense closer to FP than OO is? You are working with state all the time in C and Pascal. Perhaps a C with a garbage collector would be closer to FP, because you could construct new structures all the time without worrying about memory leaks. From gwern0 at gmail.com Thu Dec 3 20:30:54 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Dec 3 20:05:34 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <20091203233622.GB17556@whirlpool.galois.com> References: <4B1849FD.2000706@gmail.com> <20091203233622.GB17556@whirlpool.galois.com> Message-ID: On Thu, Dec 3, 2009 at 6:36 PM, Don Stewart wrote: > marlowsd: >> As noted before, the Wikipedia article for Haskell is a disorganised mess. >> >> http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 >> >> earlier this year, dons suggested reorganising it and posted a template >> on the Haskell wiki: >> >> http://haskell.org/haskellwiki/WikipediaArticleDesign >> >> I've made a start on a new version of the page: >> >> http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 >> >> I've kept most of the existing information, but reorganised it more or >> less according to Don's template, and I filled out the overview section. >> ?Also I fixed numerous things, but the page still has a long way to go >> >> Does anyone mind if I spam the existing Haskell article with this new >> one, or do people think we should continue editing the sandbox version >> until it's in better shape? > > Maybe we should make the switch, and move the old page into some > historical section. That's more likely to ensure the page gets filled > out... > > Gwern, other wikipedians, thoughts? > > -- Don The changes look fine to me, although I'm a little surprised at all the {{fact}} tags. (Some of them look very easy to fix, like why typeclasses were introduced in the first place.) There's no need to do any page moving or anything; the new version can just be pasted in. The main concern is maintaining a complete & correct copyright history, and if Simon made all the edits modifying the original text, and he also makes the big update, then there's no issue: the holder of the copyright will appear aright in the history with all his changes. -- gwern From allbery at ece.cmu.edu Thu Dec 3 20:41:45 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Dec 3 20:16:52 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <20091203164329.GC17116@whirlpool.galois.com> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> Message-ID: <93B63BE6-A10F-4FF6-99E9-0129918549D5@ece.cmu.edu> On Dec 3, 2009, at 11:43 , Don Stewart wrote: > vandijk.roel: >> On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite >> wrote: >>> On a more serious note, "Download Haskell" /= "Download Haskell >>> Platform", so if I were glancing down the sidebar looking for a >>> link to download the "Haskell Platform" then the first link >>> wouldn't have registered for me. And putting a "X has been >>> released link!" in the news does not count as a prominent download >>> link. >> >> If I wanted to know something *about* the *Haskell Platform* I would >> click the link The Haskell Platform under the section About. So it is >> actually mentioned 3 times on the front page. What could be improved >> are the 2 download links: "Download Haskell" and "Download GHC". It >> would perhaps be better to have one nice big "Download" button that >> takes you to a separate download page. > > Having a single download link that only points to the Haskell Platform > would be a bit of a policy shift. Is the community ready to accept > that > users looking for "Haskell" should be given the HP binaries? But that isn't the suggestion; I see nowhere a statement that the separate download page needs to only have the Haskell Platform. In fact, I suspect it would be good for the download page to provide both and suggest in user-friendly terms which one to download (which I suspect is still GHC for now, until the HP settles down a bit). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/428e0068/PGP.bin From echant+haskell at maretmanu.org Thu Dec 3 20:48:14 2009 From: echant+haskell at maretmanu.org (Emmanuel CHANTREAU) Date: Thu Dec 3 20:22:33 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <4B17E029.5070404@yandex.ru> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> Message-ID: <20091204024814.08f1824e@brouillard.aima.fr> Hello First, thank you for all answers. Le Thu, 03 Dec 2009 18:58:33 +0300, Miguel Mitrofanov a ?crit : > Does this really mean that you want to know how the garbage collector > works? Well, I try to understand your question... I will take an example: f x y= x+y The program ask the user to enter two numbers and print the sum. If the user enter "1 2" "f 1 2=3" is stored and a gargage collector is used to remove this dandling expression later ? If the user enter again "1 2", ghc search in dandling results to try to find the result without computing it again ? For Eugene: I use "magic" to mean beautiful and difficult to understand. I believe in magic: I believe everything can be understood with time. -- Emmanuel Chantr?au From allbery at ece.cmu.edu Thu Dec 3 21:22:12 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Dec 3 20:57:03 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> Message-ID: On Dec 3, 2009, at 13:14 , Stefan Holdermans wrote: > John, Miguel (and others), > >>> Don Stewart wrote, "the guarantees of purity the type system >>> provides are extremely >>> useful for verification purposes". My response to this is in >>> theory. This is what caught my attention initially, but the >>> language lacks polish and does not appear to be going in a >>> direction where it shows signs where it will self-correct. It may >>> even be beyond repair. I care about others and I don't want people >>> to be misled. [...] > >> The burden of proof is on you to demonstrate that it _is_. > > I admit it's tempting, but wouldn't you agree that, especially in > this case, it's better not to feed the troll? This "troll" was, apparently, invited by one of the Simons onto the Haskell' list, then asked to move his spiels here. That said, I have to say that, based on his output so far, I have trouble interpreting his "path of truth" as one of mathematical rigor; in the context of his "On the Meaning of Haskell" screeds, it sounds more like some kind of religious "truth". I.e. the "fanatic" arrow's pointing the wrong way, as far as I can tell. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/56c3b741/PGP.bin From allbery at ece.cmu.edu Thu Dec 3 21:27:09 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Dec 3 21:01:49 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> Message-ID: On Dec 3, 2009, at 21:22 , Brandon S. Allbery KF8NH wrote: > Haskell" screeds, it sounds more like some kind of religious > "truth". I.e. the "fanatic" arrow's pointing the wrong way, as far > as I can tell. I also have trouble understanding how a programming language can be a fanatic. Or how you give that statement any mathematical rigor. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/21fbaf9e/PGP.bin From miran.lipovaca at gmail.com Thu Dec 3 21:30:00 2009 From: miran.lipovaca at gmail.com (=?ISO-8859-2?Q?Miran_Lipova=E8a?=) Date: Thu Dec 3 21:04:52 2009 Subject: [Haskell-cafe] Monomorphic local let bindings and GHCi Message-ID: <4B187428.2080308@gmail.com> Hi! There have been proposals to abandon generalisation for local let bindings because they make specifying and implementing the type system very complicated when extensions like multi parameter type classes, type functions and GADTs are taken into consideration. I agree with what the paper says in general, I'm just interested/concerned as to how abandoning local let generealisation would affect GHCi. While we rarely rely on the polymorphism of functions defined in local let bindings, I think a lot of programmers rely on the polymorphism of functions that they define with let in GHCi. I have a feeling that GHCi would be a lot less useful if it didn't allow us to define functions that are polymorphic in it. Also, what would the behavior be anyway? If we did > let f x = x in GHCi and then inspected the type of f, what would GHCi report? Would it use defaulting and give us () -> ()? Or would it display a polymorphic type a -> a and then change that type to something monomorphic once we use f with some value? What if we defined several functions like this that called each other? So I think that if local let generalisation is abandoned, let bindings in GHCi would somehow have to be modified to remain polymorphic. Any thoughts? From allbery at ece.cmu.edu Thu Dec 3 21:33:15 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Dec 3 21:07:55 2009 Subject: [Haskell-cafe] I miss OO In-Reply-To: References: <4B0D98DE.4070507@alumni.caltech.edu> <75cc17ac0911260207u446561c1r75de76ee9397955f@mail.gmail.com> <5fdc56d70911260444v1f619d3dx486a053215343d1f@mail.gmail.com> <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> Message-ID: <7B5F773A-DDA0-484D-962F-D68B6845CE60@ece.cmu.edu> On Dec 3, 2009, at 20:03 , Matthias G?rgens wrote: >> When OO is about constructing a "machine" and talking about objects, >> and FP is about making little algebraic languages, what would C or >> Pascal be like? In these languages, you don't think about objects, >> but >> you don't think about an algebra either? It's been a very long time >> since I worked with these languages, but as far as I recall, I >> started >> thinking about data structures and procedures operating on these data >> structures, which sounds a look like making ADTs and >> functions/operations on these... So this sounds odd, because it would >> mean that C and Pascal are in a sense closer to FP than OO is? > > You are working with state all the time in C and Pascal. Perhaps a C > with a garbage collector would be closer to FP, because you could > construct new structures all the time without worrying about memory > leaks. A Boehm GC library for C has been around for years. Nevertheless, I wouldn't call C-with-Boehm "functional programming". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/2036aba5/PGP.bin From aslatter at gmail.com Thu Dec 3 22:10:31 2009 From: aslatter at gmail.com (Antoine Latter) Date: Thu Dec 3 21:45:10 2009 Subject: [Haskell-cafe] Re: Implicit newtype unwrapping In-Reply-To: <1259884803.3105.21.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> <1259876364.3105.8.camel@localhost> <1259884803.3105.21.camel@localhost> Message-ID: <694519c50912031910seca57ffw60bd8684f2ed44e0@mail.gmail.com> On Thu, Dec 3, 2009 at 6:00 PM, Joachim Breitner wrote: > > But when I uncommented the definition of toFoo and fromfoo, I got: > > Demo.hs:11:9: > ? ?Couldn't match expected type `Foo' against inferred type `Int' > ? ?In the expression: id > ? ?In the definition of `toFoo': toFoo = id > ? ?In the second argument of `openNewtype', namely > ? ? ? ?`[d| nullFoo :: Foo > ? ? ? ? ? ? nullFoo = 0 > ? ? ? ? ? ? toFoo :: Int -> Foo > ? ? ? ? ? ? toFoo = id > ? ? ? ? ? ? .... |]' > > And just now, after writing half the code, I find out that $( fun > [d|...|] ) runs the type checker on the declarations before passing them > to fun, which of course kills my whole approach here, as only having the > declarations pass through openNewType will make them type check. > > Is there any way to pass declarations to a TH function so that their > names are resolved, but their type is not checked (or, alternatively, > type errors are ignored). > > If not, what would be a sane work-around? > You could switch over to using a quasi-quoter. I think there's one on hackage for parsing haskell declarations you might be able to start with: http://hackage.haskell.org/package/haskell-src-meta More on GHC quasi-quotations: http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation Antoine From conal at conal.net Thu Dec 3 22:27:25 2009 From: conal at conal.net (Conal Elliott) Date: Thu Dec 3 22:02:23 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? Message-ID: I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/2d1e0c0c/attachment.html From greg at gregorycollins.net Thu Dec 3 22:55:18 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Thu Dec 3 22:29:56 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: (Conal Elliott's message of "Thu, 3 Dec 2009 19:27:25 -0800") References: Message-ID: <87aaxzcs0p.fsf@gregorycollins.net> Conal Elliott writes: > I'd like to make some FRPish toys that keep files updated to have > functional relationships with other files.? hinotify looks like just > the sort of underlying magic I could use for efficient implementation > on linux.? Is there any support for mac os x?? Could support be either > added to hinotify or maybe inotify and a mac-friendly library be > abstracted into a common Haskell interface?? I'm fine with an > imperative interface, since I can abstract into a functional library, > which I guess would be a sort of persistent simplified FRP. On Mac & BSD you have to use kqueue, and on Windows it's ReadDirectoryChangesW. A platform-agnostic Haskell library for detecting filesystem change notifications is something that I would really appreciate! G -- Gregory Collins From qdunkan at gmail.com Thu Dec 3 23:32:46 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Thu Dec 3 23:07:23 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <20091204024814.08f1824e@brouillard.aima.fr> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> Message-ID: <2518b95d0912032032p2e306912xb165819191d46b5@mail.gmail.com> > I will take an example: > > f x y= x+y > > The program ask the user to enter two numbers and print the sum. If the > user enter "1 2" "f 1 2=3" is stored and a gargage collector is used to > remove this dandling expression later ? > If the user enter again "1 2", ghc search in dandling results to > try to find the result without computing it again ? If you do 'let x = f 1 2' then 'x' will be computed once it's demanded, and at that point the thunk will be overwritten with a number. Further references just return the number. But when 'x' is out of scope it gets GCed. So it depends if you keep 'x' in scope, just like strict languages. The interesting thing is CAFs, which at the top level will never be out of scope and hence live forever. However, it's my vague understanding that due to optimizations, a non-global looking CAF can wind up at the top level. For example, given these: expensive arg = trace "exp" arg f args key = Map.lookup key fm where fm = Map.fromList (expensive args) main = let g = f [('a', 1), ('b', 2)] in print (g 'a', g 'c') g args = (v, args) where v = expensive 42 main = print (g 12, g 90) 'trace' implies that expensive is only called once in both cases, but I have to pass -O2, otherwise it gets called twice. That implies inner definitions with no free variables are only promoted (I believe it's called "let floating"?) with -O2. I think the 'f' example is impressive. The GHC optimizer is pretty neat! http://www.haskell.org/haskellwiki/Constant_applicative_form From aslatter at gmail.com Thu Dec 3 23:33:06 2009 From: aslatter at gmail.com (Antoine Latter) Date: Thu Dec 3 23:07:43 2009 Subject: [Haskell-cafe] Re: Implicit newtype unwrapping In-Reply-To: <694519c50912031910seca57ffw60bd8684f2ed44e0@mail.gmail.com> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> <1259876364.3105.8.camel@localhost> <1259884803.3105.21.camel@localhost> <694519c50912031910seca57ffw60bd8684f2ed44e0@mail.gmail.com> Message-ID: <694519c50912032033r3e43c400x792c5029a6d3f8d@mail.gmail.com> On Thu, Dec 3, 2009 at 9:10 PM, Antoine Latter wrote: > On Thu, Dec 3, 2009 at 6:00 PM, Joachim Breitner > wrote: >> >> But when I uncommented the definition of toFoo and fromfoo, I got: >> >> Demo.hs:11:9: >> ? ?Couldn't match expected type `Foo' against inferred type `Int' >> ? ?In the expression: id >> ? ?In the definition of `toFoo': toFoo = id >> ? ?In the second argument of `openNewtype', namely >> ? ? ? ?`[d| nullFoo :: Foo >> ? ? ? ? ? ? nullFoo = 0 >> ? ? ? ? ? ? toFoo :: Int -> Foo >> ? ? ? ? ? ? toFoo = id >> ? ? ? ? ? ? .... |]' >> >> And just now, after writing half the code, I find out that $( fun >> [d|...|] ) runs the type checker on the declarations before passing them >> to fun, which of course kills my whole approach here, as only having the >> declarations pass through openNewType will make them type check. >> >> Is there any way to pass declarations to a TH function so that their >> names are resolved, but their type is not checked (or, alternatively, >> type errors are ignored). >> >> If not, what would be a sane work-around? >> > > You could switch over to using a quasi-quoter. I think there's one on > hackage for parsing haskell declarations you might be able to start > with: > > http://hackage.haskell.org/package/haskell-src-meta > > More on GHC quasi-quotations: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation > So I gave it a try: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13575 But it doesn't work, and I don't understand TH enough to figure out why. I'm guessing that the TH code can't associate the parsed type name with the passed-in type name, so we don't know to do the proper unwrapping/wrapping. Antoine From allbery at ece.cmu.edu Fri Dec 4 00:01:10 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Dec 3 23:35:50 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> Message-ID: <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> > 2009/12/03 Brandon S. Allbery KF8NH : >> This "troll" was, apparently, invited by one of the Simons >> onto the Haskell' list, then asked to move his spiels here. I am informed that the "invitation" I was referring to was actually about his being invited *out*, not in, so his origin is still a mystery and "troll" is likely appropriate. (I can't say he's demonstrated much of a mathematical basis for his trollery; only a propensity for pompous declarations, and deflection when challenged on them. Put up or shut up, troll.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/626fef0d/PGP.bin From dan at unencrypted.org Fri Dec 4 00:19:57 2009 From: dan at unencrypted.org (Dan Colish) Date: Thu Dec 3 23:54:56 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> Message-ID: <7c21e7d30912032119h4051ca74kc0ac1458d774539e@mail.gmail.com> On Thu, Dec 3, 2009 at 9:01 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > 2009/12/03 Brandon S. Allbery KF8NH : >> >> This "troll" was, apparently, invited by one of the Simons >>> onto the Haskell' list, then asked to move his spiels here. >>> >> > > I am informed that the "invitation" I was referring to was actually about > his being invited *out*, not in, so his origin is still a mystery and > "troll" is likely appropriate. (I can't say he's demonstrated much of a > mathematical basis for his trollery; only a propensity for pompous > declarations, and deflection when challenged on them. Put up or shut up, > troll.) > > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > I'd just like to point out or reiterate the odd rise in trolling and the recent announcements of haskell-2010... I'm not sure what you can do about that, but if people wish you ill, they'll come out of the woodwork when you're at your best. -- --Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091203/77b0c7ac/attachment-0001.html From miguelimo38 at yandex.ru Fri Dec 4 00:58:04 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Dec 4 00:32:42 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <20091204024814.08f1824e@brouillard.aima.fr> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> Message-ID: > I will take an example: > > f x y= x+y > > The program ask the user to enter two numbers and print the sum. If > the > user enter "1 2" "f 1 2=3" is stored and a gargage collector is used > to > remove this dandling expression later ? It's not stored in any way. > If the user enter again "1 2", ghc search in dandling results to > try to find the result without computing it again ? No, it wouldn't. It would calculate it another time. From qdunkan at gmail.com Fri Dec 4 01:36:04 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Fri Dec 4 01:10:41 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <7c21e7d30912032119h4051ca74kc0ac1458d774539e@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <7c21e7d30912032119h4051ca74kc0ac1458d774539e@mail.gmail.com> Message-ID: <2518b95d0912032236s32d6ad5arb6838a71a63177c4@mail.gmail.com> > I'd just like to point out or reiterate the odd rise in trolling and the > recent announcements of haskell-2010... Just wait until haskell-2012 is announced with nonexistential aka eschatological types spelled "notany a. World". It evaluates to a new form of bottom that blackholes the entire world... From jfredett at gmail.com Fri Dec 4 01:38:39 2009 From: jfredett at gmail.com (Joe Fredette) Date: Fri Dec 4 01:13:19 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <2518b95d0912032236s32d6ad5arb6838a71a63177c4@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <7c21e7d30912032119h4051ca74kc0ac1458d774539e@mail.gmail.com> <2518b95d0912032236s32d6ad5arb6838a71a63177c4@mail.gmail.com> Message-ID: <2ED3F390-48F1-4AE7-B5BC-23882F11C3D7@gmail.com> The Mayan's Set 'em up, Haskellers knock them down... On Dec 4, 2009, at 1:36 AM, Evan Laforge wrote: >> I'd just like to point out or reiterate the odd rise in trolling >> and the >> recent announcements of haskell-2010... > > Just wait until haskell-2012 is announced with nonexistential aka > eschatological types spelled "notany a. World". > > It evaluates to a new form of bottom that blackholes the entire > world... > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From functionallyharmonious at yahoo.com Fri Dec 4 02:13:58 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 01:48:36 2009 Subject: [Haskell-cafe] Greetings! 2D Graphics? Message-ID: <868304.88343.qm@web113112.mail.gq1.yahoo.com> Greetings, my name is M. This is my first time posting to a mailing list so forgive me if I've done something wrong. I just finished "Real World Haskell" and am currently working through "School of Expression". I am new to Haskell but I already love it. My question is this...? I am interested in doing graphics work in Haskell, but I am lost trying to pick a library. I've been designing engineering apps in Java for 6 years and I'll admit I've been coddled by its standard library, lol. I am looking for something very lightweight with the basic capabilities of Java's Graphics2D class (antialias, composite, clipping, transformation, simple drawing primitives, gradients). I want something simple and "lightweight" because my interest is to play with building higher level abstractions myself. I use XP and Ubuntu so I'd prefer not to use the Graphics-Win32 library used by "School of Expression" if there is a platform independent library. I've read through http://www.haskell.org/haskellwiki/Applications_and_libraries/Graphics and the pertinent libraries seem to be Haven, HGL or Cairo via Gtk2Hs right? Which is the most popular/active and appropriate for a beginner to start working with? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/4201e269/attachment.html From ekirpichov at gmail.com Fri Dec 4 02:33:22 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Fri Dec 4 02:08:00 2009 Subject: [Haskell-cafe] Greetings! 2D Graphics? In-Reply-To: <868304.88343.qm@web113112.mail.gq1.yahoo.com> References: <868304.88343.qm@web113112.mail.gq1.yahoo.com> Message-ID: <5e0214850912032333lad8db16g4fd7674cb5872c7b@mail.gmail.com> 2009/12/4 M Xyz > Greetings, my name is M. This is my first time posting to a mailing list so > forgive me if I've done something wrong. I just finished "Real World > Haskell" and am currently working through "School of Expression". I am new > to Haskell but I already love it. My question is this... > > I am interested in doing graphics work in Haskell, but I am lost trying to > pick a library. I've been designing engineering apps in Java for 6 years and > I'll admit I've been coddled by its standard library, lol. I am looking for > something very lightweight with the basic capabilities of Java's Graphics2D > class (antialias, composite, clipping, transformation, simple drawing > primitives, gradients). I want something simple and "lightweight" because my > interest is to play with building higher level abstractions myself. > > I use XP and Ubuntu so I'd prefer not to use the Graphics-Win32 library > used by "School of Expression" if there is a platform independent library. > I've read through > http://www.haskell.org/haskellwiki/Applications_and_libraries/Graphics and > the pertinent libraries seem to be Haven, HGL or Cairo via Gtk2Hs right? > Which is the most popular/active and appropriate for a beginner to start > working with? > > I wrote http://hackage.haskell.org/package/timeplot and somewhat extended http://hackage.haskell.org/package/Chart for that. Chart is based on Cairo and I found it (Cairo) very easy and intuitive to use, yet quite powerful and performant. However, it is not a combinator library although you can make one based on it, if that's what you're looking for. There are quite a few graphics libraries based on Cairo on hackage, which means I'm not alone :) > Thank you! > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Eugene Kirpichov Web IR developer, market.yandex.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/85c5294e/attachment.html From lrpalmer at gmail.com Fri Dec 4 03:07:56 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 4 02:42:33 2009 Subject: [Haskell-cafe] Greetings! 2D Graphics? In-Reply-To: <868304.88343.qm@web113112.mail.gq1.yahoo.com> References: <868304.88343.qm@web113112.mail.gq1.yahoo.com> Message-ID: <7ca3f0160912040007p251808f3oc353d0bef511899c@mail.gmail.com> On Fri, Dec 4, 2009 at 12:13 AM, M Xyz wrote: > Greetings, my name is M. This is my first time posting to a mailing list so > forgive me if I've done something wrong. I just finished "Real World > Haskell" and am currently working through "School of Expression". I am new > to Haskell but I already love it. My question is this... > > I am interested in doing graphics work in Haskell, but I am lost trying to > pick a library. I've been designing engineering apps in Java for 6 years and > I'll admit I've been coddled by its standard library, lol. I am looking for > something very lightweight with the basic capabilities of Java's Graphics2D > class (antialias, composite, clipping, transformation, simple drawing > primitives, gradients). I want something simple and "lightweight" because my > interest is to play with building higher level abstractions myself. > > I use XP and Ubuntu so I'd prefer not to use the Graphics-Win32 library > used by "School of Expression" if there is a platform independent library. > I've read through > http://www.haskell.org/haskellwiki/Applications_and_libraries/Graphics and > the pertinent libraries seem to be Haven, HGL or Cairo via Gtk2Hs right? > Which is the most popular/active and appropriate for a beginner to start > working with? > I admit author's bias, but I suggest graphics-drawingcombinators. It is a 2D drawing library based on OpenGL with a pure interface (no IO, except to finally render your drawing), and supports all the stuff you want except clipping. It uses the SDL bindings, which I have heard are not easy to install on windows, but go smooth as a baby's bottom on ubuntu. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/596e67cf/attachment.html From dagit at codersbase.com Fri Dec 4 03:13:27 2009 From: dagit at codersbase.com (Jason Dagit) Date: Fri Dec 4 02:48:07 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> Message-ID: On Thu, Dec 3, 2009 at 8:25 AM, John D. Earle wrote: > Haskell has a problem with its type system and is not rigorous. Haskell is > not a suitable language for proof assistants and so I would advise you to > stay clear of Haskell. Standard ML was engineered with the needs of proof > assistants in mind and so you may want to look into Standard ML, but you > should be very happy with Objective CAML. It has an excellent reputation. > The Coq proof assistant which is another French product is based on > Objective CAML. > If I understand you correctly, SML was engineered with the needs of a proof assistant in mind, but OCaml is a very different language. And it seems you are pushing F#/OCaml not SML. Do F# and OCaml have full formal semantics for their type systems that have been verified? Or are they "merely" based on Hindley-Milner type systems? If it is the latter, then could you help me understand why Haskell is so much worse? If it's the former could you please point me to the appropriate research so I can educate myself? If the objection is primarily String performance based then I would recommend that you take a look at ByteString or uvector. Please help me understand the holes in Haskell's type system. Have you published some research on the flaws of Haskell's design? If Haskell is unsound I'd certainly like to know where and why so that I can improve my programs. Please help. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/cf7d49cf/attachment.html From simonpj at microsoft.com Fri Dec 4 03:18:49 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Dec 4 02:53:29 2009 Subject: [Haskell-cafe] Monomorphic local let bindings and GHCi In-Reply-To: <4B187428.2080308@gmail.com> References: <4B187428.2080308@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1085063F2@DB3EX14MBXC310.europe.corp.microsoft.com> | So I think that if local let generalisation is abandoned, let bindings in GHCi | would somehow have to be modified to remain polymorphic. I agree. They are like top-level bindings in a Haskell module, and should be generalised. They don't suffer from the problems of generalising nested bindings. Simon From vandijk.roel at gmail.com Fri Dec 4 03:38:46 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Fri Dec 4 03:13:23 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> Message-ID: > The suggestion was to have a single Download button, leading to a *page* of > suitably described links, allowing the user to choose whether they only > wanted the basics (a choice of compiler/interpreter + cabal), or the whole > Platform, or something else. ?It would be the ideal place to explain what > cabal is and how to use hackage to get more libraries than are contained in > the platform. ?It would perhaps reduce the clutter on the front page that > some people complained of (although I don't personally think it cluttered). Thank you. That was exactly what I meant. Now we need to make a prototype of that page. From vandijk.roel at gmail.com Fri Dec 4 03:51:03 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Fri Dec 4 03:25:42 2009 Subject: [Haskell-cafe] happstack homepage In-Reply-To: <27CCF54C-11FF-474B-BF2E-9EE969960D87@n-heptane.com> References: <27CCF54C-11FF-474B-BF2E-9EE969960D87@n-heptane.com> Message-ID: 2009/12/3 Jeremy Shaw : > See this thread, > http://groups.google.com/group/happs/browse_thread/thread/6e4d6af0109cc649 Ah, thank you. I somehow missed that. From ketil at malde.org Fri Dec 4 03:51:03 2009 From: ketil at malde.org (Ketil Malde) Date: Fri Dec 4 03:25:44 2009 Subject: [Haskell-cafe] Re: [Haskell] Second Call for Copy: Monad.Reader Issue 15 In-Reply-To: <20091203031010.GA31664@seas.upenn.edu> (Brent Yorgey's message of "Wed, 2 Dec 2009 22:10:11 -0500") References: <20091203031010.GA31664@seas.upenn.edu> Message-ID: <87638nnmvc.fsf@malde.org> Brent Yorgey writes: > It's not too late to write something for Issue 15 of the Monad.Reader! > Whether you're an established academic or have only just started > learning Haskell, if you have something to say, please consider > writing an article for The Monad.Reader! One thing that'd make a *very* useful contribution, would be reviews comparing different libraries that overlap in scope. We have a large selection of libraries now, but it's hard for users to know which ones provide industry-grade usability, and which ones are merely proofs of concept. So, if you're wondering what library to use for some particular purpose, why not try a set of them and mail the results to Brent? GtkHs vs wxWidgets vs ..., diagram vs graphics-drawingcombinators vs Chart vs..., database libraries, XML parsing libraries, and so on and so on. -k -- If I haven't seen further, it is by standing in the footprints of giants From colinpauladams at googlemail.com Fri Dec 4 03:57:05 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Fri Dec 4 03:31:42 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> Message-ID: <1afdeaec0912040057l49d27085t1124cd6a3328b646@mail.gmail.com> > Please help me understand the holes in Haskell's type system. Not really wanting to support the troll, but ... unsafePerformIO? Can't it be removed? -- Colin Adams Preston, Lancashire, ENGLAND From semanticphilosopher at googlemail.com Fri Dec 4 04:10:36 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Fri Dec 4 03:45:16 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <1afdeaec0912040057l49d27085t1124cd6a3328b646@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <1afdeaec0912040057l49d27085t1124cd6a3328b646@mail.gmail.com> Message-ID: <2E528463-5D5B-47A5-93A8-425EDFD3BA46@gmail.com> Or maybe it should be renamed proofObligationsOnUseNeedToBeSupliedBySuitablyQualifiedIndividualPerformIO which is what it really is - unsafe in the wrong hands Nei On 4 Dec 2009, at 08:57, Colin Adams wrote: >> Please help me understand the holes in Haskell's type system. > > Not really wanting to support the troll, but ... > > unsafePerformIO? > > Can't it be removed? > -- > Colin Adams > Preston, > Lancashire, > ENGLAND > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From colinpauladams at googlemail.com Fri Dec 4 04:16:21 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Fri Dec 4 03:50:58 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <2E528463-5D5B-47A5-93A8-425EDFD3BA46@gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <1afdeaec0912040057l49d27085t1124cd6a3328b646@mail.gmail.com> <2E528463-5D5B-47A5-93A8-425EDFD3BA46@gmail.com> Message-ID: <1afdeaec0912040116v79adfae9p9440149c81ae1a4c@mail.gmail.com> But the type system doesn't insist on such a proof - so is it not a hole? 2009/12/4 Neil Davies : > Or maybe it should be renamed > > ?proofObligationsOnUseNeedToBeSupliedBySuitablyQualifiedIndividualPerformIO > > which is what it really is - unsafe in the wrong hands > > Nei > > On 4 Dec 2009, at 08:57, Colin Adams wrote: > >>> Please help me understand the holes in Haskell's type system. >> >> Not really wanting to support the troll, but ... >> >> unsafePerformIO? >> >> Can't it be removed? >> -- >> Colin Adams >> Preston, >> Lancashire, >> ENGLAND >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Colin Adams Preston, Lancashire, ENGLAND From marlowsd at gmail.com Fri Dec 4 04:21:29 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Dec 4 03:56:36 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: References: <4B1849FD.2000706@gmail.com> <20091203233622.GB17556@whirlpool.galois.com> Message-ID: <4B18D499.4070401@gmail.com> On 04/12/2009 01:30, Gwern Branwen wrote: > The changes look fine to me, although I'm a little surprised at all > the {{fact}} tags. (Some of them look very easy to fix, like why > typeclasses were introduced in the first place.) Yes, they're just placeholders to fill in later. (I'm new to wikipedia, should they be {{citation needed}} or something?) > There's no need to do any page moving or anything; the new version can > just be pasted in. The main concern is maintaining a complete& > correct copyright history, and if Simon made all the edits modifying > the original text, and he also makes the big update, then there's no > issue: the holder of the copyright will appear aright in the history > with all his changes. Ok, done! http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 edit away. I'll try to have a go at the Parallelism/Concurrency section when I have time. Cheers, Simon From semanticphilosopher at googlemail.com Fri Dec 4 04:25:00 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Fri Dec 4 03:59:39 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <1afdeaec0912040116v79adfae9p9440149c81ae1a4c@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <1afdeaec0912040057l49d27085t1124cd6a3328b646@mail.gmail.com> <2E528463-5D5B-47A5-93A8-425EDFD3BA46@gmail.com> <1afdeaec0912040116v79adfae9p9440149c81ae1a4c@mail.gmail.com> Message-ID: <5BAF2694-3520-4673-912A-61EDB1EE053B@gmail.com> Ah but the type system is the proof - it doesn't permit you to construct things that are 'unsafe' - the whole way the language (and its implementation) is constructed is to do that for you. The issue is that, very occasionally, you the programmer (usually for reasons of performance - runtime or code lines) want something slightly out of the ordinary. This is the escape mechanism. To quote the late, great DNA - it is all about rigidly defined areas of doubt and uncertainty - one of the arts of programming is to push all the nasty doubt and uncertainty into a small corner where you can beat it to death with a large dose of logic, proof and (occasional) handwaving... Now before you start talking about 'surely the type system should be complete' - I refer you to http://en.wikipedia.org/wiki/G?del%27s_incompleteness_theorem Take comfort in that, I do, it means that us humans still have a role....... Neil On 4 Dec 2009, at 09:16, Colin Adams wrote: > But the type system doesn't insist on such a proof - so is it not a > hole? > > 2009/12/4 Neil Davies : >> Or maybe it should be renamed >> >> >> proofObligationsOnUseNeedToBeSupliedBySuitablyQualifiedIndividualPerformIO >> >> which is what it really is - unsafe in the wrong hands >> >> Nei >> >> On 4 Dec 2009, at 08:57, Colin Adams wrote: >> >>>> Please help me understand the holes in Haskell's type system. >>> >>> Not really wanting to support the troll, but ... >>> >>> unsafePerformIO? >>> >>> Can't it be removed? >>> -- >>> Colin Adams >>> Preston, >>> Lancashire, >>> ENGLAND >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > > -- > Colin Adams > Preston, > Lancashire, > ENGLAND From simonpj at microsoft.com Fri Dec 4 04:34:51 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Dec 4 04:09:32 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> Message-ID: <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> Friends One of the absolutely best things about the Haskell community is that it is almost invariably respectful and usually friendly. People often remark on this when they join the community. Beginner questions are greeted with polite and helpful replies. Category theory and elementary type errors show up in successive messages. Etc. But thread is an exception. If you think someone is talking nonsense, I think the best policy is to ignore it or reply privately (not to the list); then the thread dies. I find derogatory discussion of a particular person quite discouraging. It is likely to be unjust, and it encourages more of the same. It's like littering your own house. Respect, guys, please. Simon | >> This "troll" was, apparently, invited by one of the Simons | >> onto the Haskell' list, then asked to move his spiels here. | | I am informed that the "invitation" I was referring to was actually | about his being invited *out*, not in, so his origin is still a | mystery and "troll" is likely appropriate. (I can't say he's | demonstrated much of a mathematical basis for his trollery; only a | propensity for pompous declarations, and deflection when challenged on | them. Put up or shut up, troll.) From dav.vire+haskell at gmail.com Fri Dec 4 04:37:17 2009 From: dav.vire+haskell at gmail.com (David Virebayre) Date: Fri Dec 4 04:11:54 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <4c88418c0912040137g6725a8e6yb20efa4a8aff5e73@mail.gmail.com> On Fri, Dec 4, 2009 at 10:34 AM, Simon Peyton-Jones wrote: > Friends Amen ! From nccb2 at kent.ac.uk Fri Dec 4 05:36:09 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Fri Dec 4 05:09:53 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <20091204024814.08f1824e@brouillard.aima.fr> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> Message-ID: <4B18E619.8020502@kent.ac.uk> Emmanuel CHANTREAU wrote: > I will take an example: > > f x y= x+y > > The program ask the user to enter two numbers and print the sum. If the > user enter "1 2" "f 1 2=3" is stored and a gargage collector is used to > remove this dandling expression later ? > If the user enter again "1 2", ghc search in dandling results to > try to find the result without computing it again ? > Hi, I think what you're asking is how Haskell knows at run-time for which expressions it can re-use the results. The answer is: it doesn't, it works it out at compile-time. So if you have: f x y = x + y And at some point in your program you call f 1 2, and later on from a totally separate function you call f 1 2, the function will be evaluated twice (assuming 1 and 2 weren't known constants at compile-time). But let's say you have: g x y = f x y * f x y Now the compiler (i.e. at compile-time) can do some magic. It can spot the common expression and know the result of f x y must be the same both times, so it can convert to: g x y = let z = f x y in z * z Now, the Haskell run-time will evaluate f x y once, store the result in z, and use it twice. That's how it can use commonalities in your code and avoid multiple evaluations of the same function call, which I *think* was your question. Thanks, Neil. From mail at joachim-breitner.de Fri Dec 4 05:39:34 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Dec 4 05:14:13 2009 Subject: [Haskell-cafe] Re: Implicit newtype unwrapping In-Reply-To: <1259884803.3105.21.camel@localhost> References: <4B170350.2070504@van.steenbergen.nl> <1259834871.3407.5.camel@localhost> <1259876364.3105.8.camel@localhost> <1259884803.3105.21.camel@localhost> Message-ID: <1259923174.3070.9.camel@localhost> Hi, Am Freitag, den 04.12.2009, 01:00 +0100 schrieb Joachim Breitner: > And just now, after writing half the code, I find out that $( fun > [d|...|] ) runs the type checker on the declarations before passing them > to fun, which of course kills my whole approach here, as only having the > declarations pass through openNewType will make them type check. > > Is there any way to pass declarations to a TH function so that their > names are resolved, but their type is not checked (or, alternatively, > type errors are ignored). > > If not, what would be a sane work-around? I found one. openNewType now expects a type synonym declaration as the very first declaration. It will then replace the type synonym by the given type name in every type signature (which is simple, thanks to Data.Generics), and change the function definition to wrap and unwarp the types as needed. So the following actually works now: $(openNewtype ''Foo [d| type Foo' = Int nullFoo :: Foo' nullFoo = 0 toFoo :: Int -> Foo' toFoo = id fromFoo :: Foo' -> Int fromFoo = id succFoo :: Foo' -> Foo' succFoo = succ addFoo :: Foo' -> Foo' -> Foo' addFoo a b = a + b |] ) Given this OpenNewType module: ==================================== {-# LANGUAGE PatternGuards #-} module OpenNewtype where import Debug.Trace import Language.Haskell.TH import Data.Monoid import qualified Data.Map as M import Data.Generics.Schemes import Data.Generics.Aliases openNewtype newTypeName declsQ = do info <- reify newTypeName (taDecl:decls) <- declsQ tmpName1 <- newName "x" tmpName2 <- newName "x" -- Check if the given type is really a simple newtype typeAlias <- case taDecl of TySynD typeAlias [] concreteType -- Could check concrete Type against newtype -> return typeAlias _ -> error $ "openNewType needs a type synosym declaration as the first declaration\nFirst declaration was: " ++ pprint taDecl case info of TyConI (NewtypeD _ _ _ (NormalC constr [(NotStrict,ConT _)]) _) -> let types = getTypeMap decls in return $ map (go constr tmpName1 tmpName2 typeAlias types) decls _ -> error $ "openNewType can only handle siple newtype defined types\nArgument was: " ++ pprint info where go constr tmpName1 tmpName2 typeAlias types d = case d of (ValD (VarP name) _ _) -> FunD name [Clause [] (NormalB (wrap name types)) [d]] (FunD name _) -> FunD name [Clause [] (NormalB (wrap name types)) [d]] (SigD _ _) -> everywhere (mkT (\tn -> if tn == typeAlias then newTypeName else tn)) d _ -> d where wrap name types | Just t <- M.lookup name types = wrapCo (VarE name) t | otherwise = (VarE name) -- Short-Circuit if type to be replaced does not occur wrapCo exp t | not (doesTypeNameOccur typeAlias t) = exp wrapCo exp (ConT t) = inject exp wrapCo exp (ForallT _ _ t) = wrapCo exp t wrapCo exp (VarT _) = exp wrapCo exp (TupleT _) = exp wrapCo exp (ArrowT) = exp wrapCo exp (ListT) = exp wrapCo exp (AppT (AppT ArrowT t1) t2) = LamE [VarP tmpName1] (wrapCo (AppE exp (wrapCon (VarE tmpName1) t1)) t2) -- Short-Circuit if type to be replaced does not occur wrapCon exp t | not (doesTypeNameOccur typeAlias t) = exp wrapCon exp (ConT t) = unwrap exp wrapCon exp (ForallT _ _ t) = wrapCo exp t wrapCon exp (VarT _) = exp wrapCon exp (TupleT _) = exp wrapCon exp (ArrowT) = exp wrapCon exp (ListT) = exp wrapCon exp (AppT (AppT ArrowT t1) t2) = LamE [VarP tmpName1] (wrapCon (AppE exp (wrapCo (VarE tmpName1) t1)) t2) inject :: Exp -> Exp inject e = AppE (ConE constr) e unwrap :: Exp -> Exp unwrap e = LetE [ValD (ConP constr [VarP tmpName2]) (NormalB e) []] (VarE tmpName2) getTypeMap :: [Dec] -> M.Map Name Type getTypeMap = mconcat . map go where go (SigD name t) = M.singleton name t go _ = mempty doesTypeNameOccur tn t = gcount (mkQ False (== tn)) t > 0 ==================================== It is missing the functionality to handle occurrences of Foo' in tuples or lists, and of course it will be hard to handle occurrences of Foo' in arbitrary data types (Maybe, Data.Map, user defined data types). One could use "fmap" in these cases and hope that the data type actually is a Functor (or a Cofunctor in some cases? how to tell?), but this approach will probably never work for all cases. One could just use unsafeCoerce, after checking that Foo' and Foo really refer to the same type (one as a type synonym and one as a newtype). Would that work? It would at least break if somewhere in the modified code a type class method is called, where the instances for Foo and Int differ. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/68500f0d/attachment.bin From lrpalmer at gmail.com Fri Dec 4 05:43:27 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 4 05:18:03 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <4B18E619.8020502@kent.ac.uk> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> Message-ID: <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> On Fri, Dec 4, 2009 at 3:36 AM, Neil Brown wrote: > But let's say you have: > > g x y = f x y * f x y > > Now the compiler (i.e. at compile-time) can do some magic. ?It can spot the > common expression and know the result of f x y must be the same both times, > so it can convert to: > > g x y = let z = f x y in z * z GHC does *not* do this by default, quite intentionally, even when optimizations are enabled. The reason is because it can cause major changes in the space complexity of a program. Eg. x = sum [1..10^6] + product [1..10^6] x' = let l = [1..10^6] in sum l + product l x runs in constant space, but x' keeps the whole list in memory. The CSE here has actually wasted both time and space, since it is harder to save [1..10^6] than to recompute it! (Memory vs. arithmetic ops) So GHC leaves it to the user to specify sharing. If you want an expression shared, let bind it and reuse. Luke From mail at joachim-breitner.de Fri Dec 4 05:43:28 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Dec 4 05:18:09 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <4B18E619.8020502@kent.ac.uk> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> Message-ID: <1259923408.3070.12.camel@localhost> Hi, Am Freitag, den 04.12.2009, 10:36 +0000 schrieb Neil Brown: > But let's say you have: > > g x y = f x y * f x y > > Now the compiler (i.e. at compile-time) can do some magic. It can > spot the common expression and know the result of f x y must be the > same both times, so it can convert to: > > g x y = let z = f x y in z * z > > Now, the Haskell run-time will evaluate f x y once, store the result > in z, and use it twice. That's how it can use commonalities in your > code and avoid multiple evaluations of the same function call, which I > *think* was your question. Note that although the compiler _could_ do this transformation, it does not actually do it because of some unwanted subtleties: http://www.haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F (I was a bit disappointed when I found out about this, after first hearing how much great optimization a haskell compiler _could_ do, but that?s reality.) Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/5a395e09/attachment.bin From martijn at van.steenbergen.nl Fri Dec 4 05:53:38 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Fri Dec 4 05:28:16 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <20091203164329.GC17116@whirlpool.galois.com> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> Message-ID: <4B18EA32.1000603@van.steenbergen.nl> Don Stewart wrote: > vandijk.roel: >> On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite >> wrote: >>> On a more serious note, "Download Haskell" /= "Download Haskell Platform", so if I were glancing down the sidebar looking for a link to download the "Haskell Platform" then the first link wouldn't have registered for me. And putting a "X has been released link!" in the news does not count as a prominent download link. >> If I wanted to know something *about* the *Haskell Platform* I would >> click the link The Haskell Platform under the section About. So it is >> actually mentioned 3 times on the front page. What could be improved >> are the 2 download links: "Download Haskell" and "Download GHC". It >> would perhaps be better to have one nice big "Download" button that >> takes you to a separate download page. > > Having a single download link that only points to the Haskell Platform > would be a bit of a policy shift. Is the community ready to accept that > users looking for "Haskell" should be given the HP binaries? Although as others pointed out this wasn't the suggestion, I do think that it is a good idea to eventually have a single big download button ? la firefox.com: Haskell Platform OS-specific (based on best effort guess) button linking directly to download, with less prominent options to download for other OS'es, or other implementations. Groetjes, Martijn. From apfelmus at quantentunnel.de Fri Dec 4 06:01:42 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Dec 4 05:36:48 2009 Subject: [Haskell-cafe] Re: Optimization with Strings ? In-Reply-To: <20091203130302.6a67ad99@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> Message-ID: Emmanuel CHANTREAU wrote: > In my futur program, it use a lot of binary trees with strings (words) > as leaf. There is just arround 1000 words and they will appear a lot of > times. The program will possibly consume a lot of process and memory > (it is a mathematics proover). If your strings are indeed leaves, then chances are that you share them a lot and there's nothing much to worry about. For instance, the following complete binary tree data Tree a = Leaf a | Branch (Tree a) (Tree a) example a = tree 100 where tree 0 = Leaf a tree n = let t = tree (n-1) in Branch t t uses only linear space and the argument a is stored exactly once. I'm not sure whether this answers your question, though, also because it depends on what exactly you want. I suggest writing a tiny prototype of your idea and asking on the mailing list again when there are any performance problems. Also, knowing Haskell's evaluation model helps a lot http://en.wikibooks.org/wiki/Haskell/Graph_reduction Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From leather at cs.uu.nl Fri Dec 4 06:18:13 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Dec 4 05:53:11 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <4B1849FD.2000706@gmail.com> References: <4B1849FD.2000706@gmail.com> Message-ID: <3c6288ab0912040318m1b608581q7d18caff103931c2@mail.gmail.com> On Fri, Dec 4, 2009 at 00:30, Simon Marlow wrote: > As noted before, the Wikipedia article for Haskell is a disorganised mess. > > http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 > I'm confused. When I'm logged in to Wikipedia, I see a page that is vastly different from when I'm not logged in. I haven't played with Wikipedia in a long time, so perhaps there is some reason for this, of which I am not aware. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/a2f64b04/attachment-0001.html From marlowsd at gmail.com Fri Dec 4 06:20:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Dec 4 05:55:37 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <3c6288ab0912040318m1b608581q7d18caff103931c2@mail.gmail.com> References: <4B1849FD.2000706@gmail.com> <3c6288ab0912040318m1b608581q7d18caff103931c2@mail.gmail.com> Message-ID: <4B18F080.7010603@gmail.com> On 04/12/2009 11:18, Sean Leather wrote: > > On Fri, Dec 4, 2009 at 00:30, Simon Marlow wrote: > > As noted before, the Wikipedia article for Haskell is a disorganised > mess. > > http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 > > > I'm confused. When I'm logged in to Wikipedia, I see a page that is > vastly different from when I'm not logged in. I haven't played with > Wikipedia in a long time, so perhaps there is some reason for this, of > which I am not aware. Doesn't do that for me. Strange. Cheers, Simon From noteed at gmail.com Fri Dec 4 06:24:44 2009 From: noteed at gmail.com (minh thu) Date: Fri Dec 4 05:59:41 2009 Subject: [Haskell-cafe] language-dot usage Message-ID: <40a414c20912040324p730b2d52w4a052b1c6102b6b6@mail.gmail.com> Hi, I'm using the language-dot package to generate some .dot file. I'm wondering how to make edges. I was expecting to generate something like 1 -> {2 ; 3} but get in fact 1 -> 2 -> 3 I used the (pseudo) statements [NodeStatement $ NodeID 1, EdgeStatement [NodeId 2, NodeId 3]] What is the proper way to do that ? Thanks, Thu From leather at cs.uu.nl Fri Dec 4 06:28:08 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Dec 4 06:03:06 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <4B18F080.7010603@gmail.com> References: <4B1849FD.2000706@gmail.com> <3c6288ab0912040318m1b608581q7d18caff103931c2@mail.gmail.com> <4B18F080.7010603@gmail.com> Message-ID: <3c6288ab0912040328r64b14809vae018a85003f7079@mail.gmail.com> On Fri, Dec 4, 2009 at 12:20, Simon Marlow wrote: > On 04/12/2009 11:18, Sean Leather wrote: > >> On Fri, Dec 4, 2009 at 00:30, Simon Marlow wrote: >> As noted before, the Wikipedia article for Haskell is a disorganised >> mess. >> >> http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 >> >> >> I'm confused. When I'm logged in to Wikipedia, I see a page that is >> vastly different from when I'm not logged in. I haven't played with >> Wikipedia in a long time, so perhaps there is some reason for this, of >> which I am not aware. >> > > Doesn't do that for me. Strange. > Well, it seems to be resolved now. I tried it in two different browsers though, so I swear it wasn't me! Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/adf8c49a/attachment.html From apfelmus at quantentunnel.de Fri Dec 4 06:34:22 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Dec 4 06:09:25 2009 Subject: [Haskell-cafe] Re: I miss OO In-Reply-To: References: <4B0D98DE.4070507@alumni.caltech.edu> <75cc17ac0911260207u446561c1r75de76ee9397955f@mail.gmail.com> <5fdc56d70911260444v1f619d3dx486a053215343d1f@mail.gmail.com> <75cc17ac0911260649g71da99cfj8e99b2a30219c0ac@mail.gmail.com> Message-ID: Peter Verswyvelen wrote: > It would be fantastic to have a little practical real-world challenge > (like building a simple music system, or a simple multi-channel sound > mixer), and work this out in an imperative language, an > object-oriented language, a functional language, and maybe other > languages too, like logic languages or constraint languages (does the > latter exist?) Related: Paul Hudak, Mark P. Jones. Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity http://www.haskell.org/papers/NSWC/jfp.ps Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From ivan.miljenovic at gmail.com Fri Dec 4 06:49:19 2009 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri Dec 4 06:24:02 2009 Subject: [Haskell-cafe] language-dot usage In-Reply-To: <40a414c20912040324p730b2d52w4a052b1c6102b6b6@mail.gmail.com> (minh thu's message of "Fri, 4 Dec 2009 12:24:44 +0100") References: <40a414c20912040324p730b2d52w4a052b1c6102b6b6@mail.gmail.com> Message-ID: <871vjbot6o.fsf@gmail.com> *Shameless plug* use my graphviz package! OK, relevant answer: minh thu writes: > I'm wondering how to make edges. I was expecting to generate something like > > 1 -> {2 ; 3} > > > but get in fact > > 1 > -> 2 -> 3 > > I used the (pseudo) statements > > [NodeStatement $ NodeID 1, EdgeStatement [NodeId 2, NodeId 3]] So you're wanting an edge from 1 to 2 and from 1 to 3, but getting from 1 to 2 and from 2 to 3 instead? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com From patc at pessce.net Fri Dec 4 06:51:10 2009 From: patc at pessce.net (Patrick Caldon) Date: Fri Dec 4 06:25:17 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... Message-ID: <4B18F7AE.4090303@pessce.net> I'm looking for the "right" concurrency library/semantics for what should be a reasonably simple problem. I have a little simulator: runWorldSim :: MTGen -> SimState -> IO SimState it takes about a second to run on a PC. It's functional except it whacks the rng, which needs IO. I run 5-10 of these jobs, and then use: mergeWorld :: [SimState] -> SimState to pick the best features of the runs and build another possible world (state). Then I use this new world to run another 5-10 jobs and so on. I run this through ~20000 iterations. It's an obvious place for parallelism. I'm looking for a concurrency library with something like: forkSequence :: Int -> [IO a] -> IO [a] which I could call with something like this: forkSequence 4 (take 10 (repeat (runWorldSim g ss))) this would construct 4 threads, then dispatch the 10 jobs onto the threads, and pack up the results into a list I could run through my merger. It strikes me as something someone would already have done, but I can't find anything in hackage. Probably I've missed something obvious? Any pointers? If not, what would be the best/easiest existing package to write an extension to? Thanks, Patrick. From ivan.miljenovic at gmail.com Fri Dec 4 06:52:33 2009 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri Dec 4 06:27:14 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <4B18F7AE.4090303@pessce.net> (Patrick Caldon's message of "Fri, 04 Dec 2009 22:51:10 +1100") References: <4B18F7AE.4090303@pessce.net> Message-ID: <87tyw7negu.fsf@gmail.com> Patrick Caldon writes: > it takes about a second to run on a PC. It's functional except it > whacks the rng, which needs IO. I run 5-10 of these jobs, and then > use: Which RNG are you using that it needs so much IO? > > mergeWorld :: [SimState] -> SimState > > to pick the best features of the runs and build another possible world > (state). Then I use this new world to run another 5-10 jobs and so > on. I run this through ~20000 iterations. > > It's an obvious place for parallelism. > > I'm looking for a concurrency library with something like: > > forkSequence :: Int -> [IO a] -> IO [a] > > which I could call with something like this: > > forkSequence 4 (take 10 (repeat (runWorldSim g ss))) > > this would construct 4 threads, then dispatch the 10 jobs onto the > threads, and pack up the > results into a list I could run through my merger. > > It strikes me as something someone would already have done, but I > can't find anything in hackage. Probably I've missed something > obvious? Any pointers? > > If not, what would be the best/easiest existing package to write an > extension to? > > Thanks, > Patrick. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com From patc at pessce.net Fri Dec 4 06:58:24 2009 From: patc at pessce.net (Patrick Caldon) Date: Fri Dec 4 06:32:31 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <87tyw7negu.fsf@gmail.com> References: <4B18F7AE.4090303@pessce.net> <87tyw7negu.fsf@gmail.com> Message-ID: <4B18F960.5070501@pessce.net> Ivan Lazar Miljenovic wrote: > Patrick Caldon writes: > >> it takes about a second to run on a PC. It's functional except it >> whacks the rng, which needs IO. I run 5-10 of these jobs, and then >> use: >> > Which RNG are you using that it needs so much IO? Mersenne Twister, System.Random.Mersenne. The ordinary rng kills performance. Patrick. From nccb2 at kent.ac.uk Fri Dec 4 07:07:12 2009 From: nccb2 at kent.ac.uk (Neil Brown) Date: Fri Dec 4 06:40:56 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <4B18F7AE.4090303@pessce.net> References: <4B18F7AE.4090303@pessce.net> Message-ID: <4B18FB70.5090400@kent.ac.uk> Patrick Caldon wrote: > > I'm looking for the "right" concurrency library/semantics for what > should be a reasonably simple problem. > > I have a little simulator: > > runWorldSim :: MTGen -> SimState -> IO SimState > > it takes about a second to run on a PC. It's functional except it > whacks the rng, which needs IO. I run 5-10 of these jobs, and then use: > > mergeWorld :: [SimState] -> SimState > > to pick the best features of the runs and build another possible world > (state). Then I use this new world to run another 5-10 jobs and so > on. I run this through ~20000 iterations. > > It's an obvious place for parallelism. > > I'm looking for a concurrency library with something like: > > forkSequence :: Int -> [IO a] -> IO [a] > > which I could call with something like this: > > forkSequence 4 (take 10 (repeat (runWorldSim g ss))) > > this would construct 4 threads, then dispatch the 10 jobs onto the > threads, and pack up the > results into a list I could run through my merger. Why particularly do you want to run the 10 jobs on 4 threads? Haskell's run-time is quite good at spreading out the lightweight threads onto all your cores, so the easiest thing to do is run the 10 jobs on 10 (light-weight) threads and let the run-time sort out the rest. So if what you want is a function: runPar :: [IO a] -> IO [a] you can easily construct this. Shameless plug: my CHP library effectively has this function already, runParallel :: [CHP a] -> CHP [a] (CHP being a slight layer on top of IO). But you can do it just as easily with, say, STM. Here is a version where order doesn't matter (apologies for the point-free style): import Control.Concurrent import Control.Concurrent.STM import Control.Monad modifyTVar :: TVar a -> (a -> a) -> STM () modifyTVar tv f = readTVar tv >>= writeTVar tv . f runPar :: [IO a] -> IO [a] runPar ps = do resVar <- newTVarIO [] mapM_ (forkIO . (>>= atomically . modifyTVar resVar . (:))) ps atomically $ do res <- readTVar resVar when (length res < length ps) retry return res If order does matter, you can zip the results with an index, and sort by the index afterwards. If efficiency matters, you can perform other tweaks. But the principle is quite straightforward. Or you can refactor your code to take the IO dependency out of your random number generation, and run the sets of pure code in parallel using the parallel library. If all you are using IO for is random numbers, that's probably the nicest approach. Thanks, Neil. P.S. take 10 . repeat is the same as replicate 10 From roman.salmin at gmail.com Fri Dec 4 07:14:07 2009 From: roman.salmin at gmail.com (Roman Salmin) Date: Fri Dec 4 06:48:45 2009 Subject: [Haskell-cafe] Haskell for Physicists In-Reply-To: <20091013184415.GI7864@whirlpool.galois.com> References: <20091013184415.GI7864@whirlpool.galois.com> Message-ID: On Tue, Oct 13, 2009 at 9:44 PM, Don Stewart wrote: > > > http://www.galois.com/blog/2009/10/13/domain-specific-languages-for-domain-specific-problems/ > > It advocates for Haskell + EDSLs, much as we have been discussing in > this thread. > I am think that use of EDSLs for Physics (and similar science) are very arguable: To use EDSL domain expert need to know language in which DSL embedded, which is more difficult than learn just DSL. Not better, if EDSL use only subset of base language: 1. because you need to teach this subset (probably rewrite of write new tutorials, books etc..) 2. and if someone use few EDSL with different subsets of base language it can (and probably will) became mess. _So easiness in implementation results in burden for users_ I see such situation in Particle Physics where I am working. All basic software: ROOT, Geant4 are actually EDSLs based on C++ (and crippled C++: CINT). In my opinion this slowdown progress tremendously! I am know many physicists who don't know ever necessary basic of C++, although they use ROOT and Geant4. I am sure that what prevent them from learning C++ will prevent them from learning any other general purpose language. _So my strong opinion that solution is only DSL not EDSL_ Roman. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/01ba41bb/attachment.html From apfelmus at quantentunnel.de Fri Dec 4 07:20:19 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Dec 4 06:55:20 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: <871vjcuw9e.fsf@malde.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> Message-ID: Ketil Malde wrote: > Although I don't care for the cutesy naming suggested in the 'Train' > datatype [...] > > data TerminatedList a e = Then a (TerminatedList a e) > | Finally e > > (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` "success!". Of > course, you might prefer symbols instead.) I don't mind Then and Finally as constructors. The thing about the Train is not so much the suggestive constructor names Wagon/Loco or Cabin/Caboose but that the concept itself has an evocative and short name, Train . In contrast, TerminatedList feels too much like an agglomeration of technical terms to me ("weak head normal form") where the names are fairly unrelated to the actual definition. (This particularly applies to "weak", one could as well have dubbed the whole thing "blue head normal form" without any loss of meaning.) Unfortunately, TerminatedList is also too long for extended use in type signatures. Something more evocative and short, similar to the good old "queue" or "stack" would be great. How about "trail" or "track", like in data Trail a b = Then a (Trail a b) | End b the idea being that the trail of say a dog eventually leads to the dog itself. Another, not entirely serious, suggestion: ;) data Life a b = Work a (Life a b) | TheEnd b Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From leather at cs.uu.nl Fri Dec 4 07:27:21 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Dec 4 07:02:18 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: References: <4B1849FD.2000706@gmail.com> <3c6288ab0912040318m1b608581q7d18caff103931c2@mail.gmail.com> Message-ID: <3c6288ab0912040427j49c1795ejf9e840423be539e6@mail.gmail.com> On Fri, Dec 4, 2009 at 13:11, Max Rabkin wrote: > On Fri, Dec 4, 2009 at 1:18 PM, Sean Leather wrote: > > I'm confused. When I'm logged in to Wikipedia, I see a page that is > vastly > > different from when I'm not logged in. I haven't played with Wikipedia in > a > > long time, so perhaps there is some reason for this, of which I am not > > aware. > > Wikipedia uses a caching proxy for non-logged-in users. > Ah, thanks. I talked to somebody else who had the same problem, so now we know. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/27d98b9d/attachment.html From patc at pessce.net Fri Dec 4 07:28:50 2009 From: patc at pessce.net (Patrick Caldon) Date: Fri Dec 4 07:02:56 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <4B18FB70.5090400@kent.ac.uk> References: <4B18F7AE.4090303@pessce.net> <4B18FB70.5090400@kent.ac.uk> Message-ID: <4B190082.6020909@pessce.net> Neil Brown wrote: > Patrick Caldon wrote: >> >> I'm looking for the "right" concurrency library/semantics for what >> should be a reasonably simple problem. >> >> I have a little simulator: >> >> runWorldSim :: MTGen -> SimState -> IO SimState >> >> it takes about a second to run on a PC. It's functional except it >> whacks the rng, which needs IO. I run 5-10 of these jobs, and then use: >> >> mergeWorld :: [SimState] -> SimState >> >> to pick the best features of the runs and build another possible >> world (state). Then I use this new world to run another 5-10 jobs >> and so on. I run this through ~20000 iterations. >> >> It's an obvious place for parallelism. >> >> I'm looking for a concurrency library with something like: >> >> forkSequence :: Int -> [IO a] -> IO [a] >> >> which I could call with something like this: >> >> forkSequence 4 (take 10 (repeat (runWorldSim g ss))) >> >> this would construct 4 threads, then dispatch the 10 jobs onto the >> threads, and pack up the >> results into a list I could run through my merger. > Why particularly do you want to run the 10 jobs on 4 threads? > Haskell's run-time is quite good at spreading out the lightweight > threads onto all your cores, so the easiest thing to do is run the 10 > jobs on 10 (light-weight) threads and let the run-time sort out the > rest. Thanks so much for that! I'll give it a go. Different threads is just because some of the jobs are memory hogs, and I want to minimize the number running simultaneously. I'll see what happens with a runPar-like approach, and use a queue-based approach if it becomes a problem. > So if what you want is a function: > > runPar :: [IO a] -> IO [a] > > you can easily construct this. Shameless plug: my CHP library > effectively has this function already, runParallel :: [CHP a] -> CHP > [a] (CHP being a slight layer on top of IO). But you can do it just > as easily with, say, STM. Here is a version where order doesn't > matter (apologies for the point-free style): > > import Control.Concurrent > import Control.Concurrent.STM > import Control.Monad > > modifyTVar :: TVar a -> (a -> a) -> STM () > modifyTVar tv f = readTVar tv >>= writeTVar tv . f > > runPar :: [IO a] -> IO [a] > runPar ps > = do resVar <- newTVarIO [] > mapM_ (forkIO . (>>= atomically . modifyTVar resVar . (:))) ps > atomically $ do res <- readTVar resVar > when (length res < length ps) retry > return res > > If order does matter, you can zip the results with an index, and sort > by the index afterwards. If efficiency matters, you can perform other > tweaks. But the principle is quite straightforward. Or you can > refactor your code to take the IO dependency out of your random number > generation, and run the sets of pure code in parallel using the > parallel library. If all you are using IO for is random numbers, > that's probably the nicest approach. > Good, fast random numbers are unfortunately necessary - I had a nice implementation using System.Random, but had to rewrite it because performance was poor :( . > P.S. take 10 . repeat is the same as replicate 10 Thanks again! Patrick. From ketil at malde.org Fri Dec 4 07:31:06 2009 From: ketil at malde.org (Ketil Malde) Date: Fri Dec 4 07:05:45 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> (Simon Peyton-Jones's message of "Fri, 4 Dec 2009 09:34:51 +0000") References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <87skbqkjjp.fsf@malde.org> Simon Peyton-Jones writes: > Respect, guys, please. Yes. Much as I enjoy the mangling of Shakespeare (finally some use out of that Eng.Lit. class all those years ago), I worry that this will finally be the thread that launched a thousand replies and burned the bottomless archives of the Haskell Caf?. Thus I humbly submit the following proposal for the FAQ: Q: Somebody made an obviously counterfactual statement implying Haskell is inferior to some lesser language (one that only a moron would use anyway). Although I know we try to keep things civil around here, this person is obviously doing this on purpose to provoke us, and as a responsible citizen of this forum, I shall be forced to go against the normal comme-il-faut (and my better judgement) and publicly humiliate him or her, just like he or she wants me to. How should I best go about it? A: Words are like sunrays, and each word or ray burns hotter when focused and terse And if you have nothing at all nice nice to say make sure that you say it in verse If somebody argues in endless recursion you'll find that it irks you at times So either give helpful advice for conversion or produce your harassment in rhymes Trees are more lovely than poems, it's true and words can burn hotter than wood Do you really have nothing else better to do? Then at least try to make it /sound/ good. -k (Who has lots of better things to do, unfortunately) -- If I haven't seen further, it is by standing in the footprints of giants From sebastian.sylvan at gmail.com Fri Dec 4 07:42:14 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Dec 4 07:16:52 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <4B190082.6020909@pessce.net> References: <4B18F7AE.4090303@pessce.net> <4B18FB70.5090400@kent.ac.uk> <4B190082.6020909@pessce.net> Message-ID: <3d96ac180912040442u127ba578k5062efb1423f1b37@mail.gmail.com> On Fri, Dec 4, 2009 at 12:28 PM, Patrick Caldon wrote: > Neil Brown wrote: > >> Patrick Caldon wrote: >> >>> >>> I'm looking for the "right" concurrency library/semantics for what should >>> be a reasonably simple problem. >>> >>> I have a little simulator: >>> >>> runWorldSim :: MTGen -> SimState -> IO SimState >>> >>> it takes about a second to run on a PC. It's functional except it whacks >>> the rng, which needs IO. I run 5-10 of these jobs, and then use: >>> >>> mergeWorld :: [SimState] -> SimState >>> >>> to pick the best features of the runs and build another possible world >>> (state). Then I use this new world to run another 5-10 jobs and so on. I >>> run this through ~20000 iterations. >>> >>> It's an obvious place for parallelism. >>> >>> I'm looking for a concurrency library with something like: >>> >>> forkSequence :: Int -> [IO a] -> IO [a] >>> >>> which I could call with something like this: >>> >>> forkSequence 4 (take 10 (repeat (runWorldSim g ss))) >>> >>> this would construct 4 threads, then dispatch the 10 jobs onto the >>> threads, and pack up the >>> results into a list I could run through my merger. >>> >> Why particularly do you want to run the 10 jobs on 4 threads? Haskell's >> run-time is quite good at spreading out the lightweight threads onto all >> your cores, so the easiest thing to do is run the 10 jobs on 10 >> (light-weight) threads and let the run-time sort out the rest. >> > > Thanks so much for that! I'll give it a go. > > Different threads is just because some of the jobs are memory hogs, and I > want to minimize the number running simultaneously. I'll see what happens > with a runPar-like approach, and use a queue-based approach if it becomes a > problem. > > So if what you want is a function: >> >> runPar :: [IO a] -> IO [a] >> >> you can easily construct this. Shameless plug: my CHP library effectively >> has this function already, runParallel :: [CHP a] -> CHP [a] (CHP being a >> slight layer on top of IO). But you can do it just as easily with, say, >> STM. Here is a version where order doesn't matter (apologies for the >> point-free style): >> >> import Control.Concurrent >> import Control.Concurrent.STM >> import Control.Monad >> >> modifyTVar :: TVar a -> (a -> a) -> STM () >> modifyTVar tv f = readTVar tv >>= writeTVar tv . f >> >> runPar :: [IO a] -> IO [a] >> runPar ps >> = do resVar <- newTVarIO [] >> mapM_ (forkIO . (>>= atomically . modifyTVar resVar . (:))) ps >> atomically $ do res <- readTVar resVar >> when (length res < length ps) retry >> return res >> >> If order does matter, you can zip the results with an index, and sort by >> the index afterwards. If efficiency matters, you can perform other tweaks. >> But the principle is quite straightforward. Or you can refactor your code >> to take the IO dependency out of your random number generation, and run the >> sets of pure code in parallel using the parallel library. If all you are >> using IO for is random numbers, that's probably the nicest approach. >> >> Good, fast random numbers are unfortunately necessary - I had a nice > implementation using System.Random, but had to rewrite it because > performance was poor :( . Have you tried this, pure, library? http://hackage.haskell.org/package/mersenne-random-pure64 -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/95d41bbc/attachment.html From noteed at gmail.com Fri Dec 4 07:48:08 2009 From: noteed at gmail.com (minh thu) Date: Fri Dec 4 07:23:04 2009 Subject: [Haskell-cafe] language-dot usage In-Reply-To: <871vjbot6o.fsf@gmail.com> References: <40a414c20912040324p730b2d52w4a052b1c6102b6b6@mail.gmail.com> <871vjbot6o.fsf@gmail.com> Message-ID: <40a414c20912040448s11a3f7bas18a6b64cb3533692@mail.gmail.com> 2009/12/4 Ivan Lazar Miljenovic : > > *Shameless plug* use my graphviz package! Ok. I see your DotEdge has explicit from/to nodes but not language-dot. I've not a lot of code, so using your package should be easy. But still I wonder what the intended usage of languge-dot is. > OK, relevant answer: > > minh thu writes: >> I'm wondering how to make edges. I was expecting to generate something like >> >> 1 -> {2 ; 3} >> >> >> but get in fact >> >> 1 >> -> 2 -> 3 >> >> I used the (pseudo) statements >> >> [NodeStatement $ NodeID 1, EdgeStatement [NodeId 2, NodeId 3]] > > So you're wanting an edge from 1 to 2 and from 1 to 3, but getting from > 1 to 2 and from 2 to 3 instead? Exactly. Also, if I write only [EdgeStatement [NodeId 2, NodeId 3]], it will produce -> 2 -> 3 (i.e. no 1, but sill the arc to 2). Thanks, Thu From dougal at dougalstanton.net Fri Dec 4 07:56:52 2009 From: dougal at dougalstanton.net (Dougal Stanton) Date: Fri Dec 4 07:31:28 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <2518b95d0912032236s32d6ad5arb6838a71a63177c4@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <7c21e7d30912032119h4051ca74kc0ac1458d774539e@mail.gmail.com> <2518b95d0912032236s32d6ad5arb6838a71a63177c4@mail.gmail.com> Message-ID: <2d3641330912040456w219645eewabc81fd1ab4d9cf2@mail.gmail.com> On Fri, Dec 4, 2009 at 6:36 AM, Evan Laforge wrote: >> I'd just like to point out or reiterate the odd rise in trolling and the >> recent announcements of haskell-2010... > > Just wait until haskell-2012 is announced with nonexistential aka > eschatological types spelled "notany a. World". > > It evaluates to a new form of bottom that blackholes the entire world... I hear prototypes are already being used at the LHC for this very purpose. Well-typed doomsday machines can't go wrong ;-) D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From Christian.Maeder at dfki.de Fri Dec 4 08:42:30 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Dec 4 08:17:08 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <200912022055.16082.daniel.is.fischer@web.de> References: <4B167061.10007@dfki.de> <200912021735.36264.daniel.is.fischer@web.de> <4B16A9EB.6090903@dfki.de> <200912022055.16082.daniel.is.fischer@web.de> Message-ID: <4B1911C6.9060304@dfki.de> Daniel Fischer schrieb: > Am Mittwoch 02 Dezember 2009 18:54:51 schrieb Christian Maeder: >> Daniel Fischer schrieb: >>> However, according to a couple of tests, the "funkyName" version is >>> somewhat faster and allocates less. >> My timing tests showed that your fpairs version is fastest. Interesting. Using a faster version of "sequence": http://www.haskell.org/pipermail/haskell-cafe/2009-November/069491.html \begin{code} allPossibilities :: [[a]] -> [[a]] allPossibilities [] = [[]] allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] funkyName :: (a -> b -> Bool) -> [a] -> [b] -> [[(a, b)]] funkyName p s l = case s of h : t -> [(h, a) : ys | a <- filter (p h) l, ys <- funkyName p t l] [] -> [[]] fpairs :: (a -> b -> Bool) -> [a] -> [b] -> [[(a, b)]] fpairs p s l = allPossibilities [[(a, b) | b <- filter (p a) l] | a <- s] \end{code} fpairs and funkyName are about equally fast. Cheers Christian From matthias.goergens at googlemail.com Fri Dec 4 08:43:42 2009 From: matthias.goergens at googlemail.com (=?ISO-8859-1?Q?Matthias_G=F6rgens?=) Date: Fri Dec 4 08:18:39 2009 Subject: [Haskell-cafe] Haskell for Physicists In-Reply-To: References: <20091013184415.GI7864@whirlpool.galois.com> Message-ID: > ?_So my strong opinion that solution is only DSL not EDSL_ Why do you think they will learn your DSL, if they don't learn any other language? And if your DSL includes general purpose stuff, like functions, control structures, data structures, you'll re-invent the wheel. Probably porly. From hthiel.char at zonnet.nl Fri Dec 4 08:45:39 2009 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Fri Dec 4 08:20:17 2009 Subject: [Haskell-cafe] Mushrooms (edible/poisonous) and Haskell Message-ID: <1259934339.3517.31.camel@dhcppc0> Hi All, About six months ago I uploaded version 0.6 to Hackage of Emping, a prototype tool using a new algorithm for data mining/machine learning. It won't build with the newer versions of GTk2Hs because the Gtk2Hs API changed since 0.9.13, and I used older versions of GHC and Gtk2Hs. For several reasons I don't have easy access to the newer versions, so I havn't fixed it yet. It should (that famous word) take no more than 15 minutes to change a Maybe Int into an Int in the main module. Apart from that it compiles warning free and (in my own opinion) the code is pretty clean now. See the user guide for some bugs I found and haven't fixed yet. The reason for this post is that I've been testing it, and have now built an iteractive demonstration of the result of a case study. This is a well known example of a table of 8124 rows and 23 columns, and the goal is to distinguish between poisonous and edible mushrooms. Emping found 3635 rules with antecedent length of 1 to 6, and the claim is that these rules fully describe all possibilities. So, I hope people will examine this case and, hopefully, will find no examples refuting this claim. As far as I know no one has ever analized this table in such detail, but that's another thing to be found out. With regard to Haskell, imo Haskell is very suitable and practical as a language for such a tool, because it is so modular. Changing something in one place is usually pretty safe. From a practical pov, amongst all the advantages and disadvantages, maintainability is surely a strength! Anyway, for anyone who's interested in the application, see http://muitovar.com/emp/emp_get.php and related links. Yes, unfortunately the demo is not in Haskell... Regards, Hans van Thiel From wren at freegeek.org Fri Dec 4 09:21:13 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Dec 4 08:50:30 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <4B185C9C.6040706@freegeek.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <1259845201.4896.103489.camel@localhost> <4B185C9C.6040706@freegeek.org> Message-ID: <4B191AD9.8090504@freegeek.org> wren ng thornton wrote: > One of the nice things about not having a Nil is that it lets you easily > be polymorphic over things ending in () ---a normal list---, (Maybe a) > ---a fallible list---, (Either a b) ---your progress type---, etc. > Whereas the version that has both Nil and End forces us into the (Maybe > a) scenario. A side effect of this is that the (Either a b) option isn't > available because we can only construct t=Mx.(x*t)+(1+a+b) not > t=Mx.(x*t)+(a+b). Er, I meant t=Mx.(c*x)+(1+a+b) vs t=Mx.(c*x)+(a+b). This is what I get for posting without coffee. -- Live well, ~wren From lrpalmer at gmail.com Fri Dec 4 10:02:14 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 4 09:36:51 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <4B1911C6.9060304@dfki.de> References: <4B167061.10007@dfki.de> <200912021735.36264.daniel.is.fischer@web.de> <4B16A9EB.6090903@dfki.de> <200912022055.16082.daniel.is.fischer@web.de> <4B1911C6.9060304@dfki.de> Message-ID: <7ca3f0160912040702o43c54f87g2d411516a7c32262@mail.gmail.com> On Fri, Dec 4, 2009 at 6:42 AM, Christian Maeder wrote: > Daniel Fischer schrieb: >> Am Mittwoch 02 Dezember 2009 18:54:51 schrieb Christian Maeder: >>> Daniel Fischer schrieb: >>>> However, according to a couple of tests, the "funkyName" version is >>>> somewhat faster and allocates less. >>> My timing tests showed that your fpairs version is fastest. > > Interesting. Using a faster version of "sequence": > > http://www.haskell.org/pipermail/haskell-cafe/2009-November/069491.html > > \begin{code} > allPossibilities :: [[a]] -> [[a]] > allPossibilities [] = [[]] > allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] I am confused. This is exactly sequence. How is this a faster version? Other than maybe avoiding some dictionary-passing? Incidentally there is a "better" version of sequence for finding products of lists: allPossibilities :: [[a]] -> [[a]] allPossibilities [] = [[]] allPossibilities (l:ls) = [ x : xs | xs <- allPossibilites ls, x <- l ] Or, the general form (I don't know of a use other than for lists, however): sequence' :: Applicative f => [f a] -> f [a] sequence' [] = pure [] sequence' (x:xs) = liftA2 (flip (:)) xs x The difference is that it binds the tail of the list first, so the generated tails are shared. This means less consing, less GC strain, and a lot less memory usage if you store them. Mind, the answers come out in a different order. Luke From duncan.coutts at googlemail.com Fri Dec 4 10:38:38 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Dec 4 10:13:16 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <4B18F7AE.4090303@pessce.net> References: <4B18F7AE.4090303@pessce.net> Message-ID: <1259941118.4778.275.camel@localhost> On Fri, 2009-12-04 at 22:51 +1100, Patrick Caldon wrote: > I'm looking for the "right" concurrency library/semantics for what > should be a reasonably simple problem. > > I have a little simulator: > > runWorldSim :: MTGen -> SimState -> IO SimState > > it takes about a second to run on a PC. It's functional except it whacks > the rng, which needs IO. Wait! This is not going to work! You cannot use the MTGen from the mersenne-random in a concurrent IO program because the C code uses a single global mutable RNG state. Your "independent" simulations would not be independent and you would not get reproducible results. Indeed you could get incorrect results or segfaults because the C code does not expect to be called from multiple threads simultaneously (there is no locking). Personally I would attack this by eliminating the IO. There's no justification for a random number generator being in IO. And look at the problems it causes! There are other MT implementations that do not use C code which assumes it's ok to use one single global mutable RNG state for an entire process. There are pure-Haskell MT impls that use mutable variables in ST but give an overall pure lazy list of random numbers. If you don't need MT specifically then there are other fast RNGs too. Duncan From Christian.Maeder at dfki.de Fri Dec 4 10:48:25 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Dec 4 10:23:04 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <7ca3f0160912040702o43c54f87g2d411516a7c32262@mail.gmail.com> References: <4B167061.10007@dfki.de> <200912021735.36264.daniel.is.fischer@web.de> <4B16A9EB.6090903@dfki.de> <200912022055.16082.daniel.is.fischer@web.de> <4B1911C6.9060304@dfki.de> <7ca3f0160912040702o43c54f87g2d411516a7c32262@mail.gmail.com> Message-ID: <4B192F49.3020600@dfki.de> Luke Palmer schrieb: >> \begin{code} >> allPossibilities :: [[a]] -> [[a]] >> allPossibilities [] = [[]] >> allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] > > I am confused. This is exactly sequence. How is this a faster > version? Other than maybe avoiding some dictionary-passing? I suppose, dictionary-passing is really the reason for slower code. > Incidentally there is a "better" version of sequence for finding > products of lists: > > allPossibilities :: [[a]] -> [[a]] > allPossibilities [] = [[]] > allPossibilities (l:ls) = [ x : xs | xs <- allPossibilites ls, x <- l ] I cannot really observe a speed up, with this version, but there are probably examples where any version is faster than the other. > Or, the general form (I don't know of a use other than for lists, however): "Maybe" should be another useful instance. > sequence' :: Applicative f => [f a] -> f [a] > sequence' [] = pure [] > sequence' (x:xs) = liftA2 (flip (:)) xs x > > The difference is that it binds the tail of the list first, so the > generated tails are shared. This means less consing, less GC strain, > and a lot less memory usage if you store them. This argument it too complicated for me. > Mind, the answers come out in a different order. Yes, thanks. Christian From lemming at henning-thielemann.de Fri Dec 4 10:55:31 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Dec 4 10:27:24 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> Message-ID: <4B1930F3.30306@henning-thielemann.de> Gregory Crosswhite schrieb: > If there is one thing that we really don't have enough of in Haskell, it is *ways to handle errors*! Thus, I am pleased to announce the release of the "error-message" package to help in filling this, erm, gap. > > This philosophy behind this package is that it is often better to find out all of the errors that have occured in a computation and report them simultaneously, rather than aborting as soon as the first error is encountered. Towards this end, this package supplies a type of /combinable error messages/ (ErrorMessage in the Data.ErrorMessage module) so that all of the errors from subcomputations can be gathered and presented together. I would call such non-serious errors 'warnings'. Warnings can be collected using Writer monad. From lemming at henning-thielemann.de Fri Dec 4 10:57:44 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Dec 4 10:29:02 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> Message-ID: <4B193178.30106@henning-thielemann.de> Gregory Crosswhite schrieb: > When I uploaded my new package, "error-message", I also went ahead and created a new category: "Error Handling". "Error handling" is the same as "debugging" for you? I hope it is not intended for generating further confusion about "exception handling" and "debugging" (= help programmers to analyse errors). From leimy2k at gmail.com Fri Dec 4 10:58:20 2009 From: leimy2k at gmail.com (David Leimbach) Date: Fri Dec 4 10:32:58 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <3e1162e60912040758k3a1ff6f3udd41769f51f76b9@mail.gmail.com> Hi Simon and others, Personally I don't see anything wrong with this guy's line of questioning. He wants some proof that Haskell can live up to some of the claims made about it. There's a lot of selling of languages like Clojure, Scala, and Haskell going on that have real world examples showing how code compares from one language to the next (sometimes unfairly I'll add, in that the code that one person writes in one language, does not illustrate the best of that language). I will admit I missed out on the optimization thread that people refer to. I guess I could read the archives, but the tone of this thread makes me think it's not worthwhile. I think what it boils down to is Haskell use is a choice that every person gets to make for their spare time projects and if you're lucky enough to have such a choice at your job, why not check it out and see for yourself? If one disagrees with the claims of the salesmen, perhaps a trial period will convince one otherwise, it's not like it costs anything but time. There's not even a 90 day money back guarantee to worry about. As for trolls on the mailing list, I personally do not have time to read every message that comes through haskell-cafe because the level of activity is higher than my available bandwidth for reading emails. As such, I often press this lovely button the people who made my computer and operating system so thoughtfully designed called "delete". Man does that thing ever work wonders... Then people can refrain from increasing the magnitude of the denominator in the signal to noise ratio that has a nice value at the moment here in this community. Sadly I think I just did the opposite, but since this is a cafe, and I had something to say, and I said it, I don't feel so badly about it, and won't comment on it again. Just my 2 cents, which might be all I have left these days :-) Dave On Fri, Dec 4, 2009 at 1:34 AM, Simon Peyton-Jones wrote: > Friends > > One of the absolutely best things about the Haskell community is that it is > almost invariably respectful and usually friendly. People often remark on > this when they join the community. Beginner questions are greeted with > polite and helpful replies. Category theory and elementary type errors show > up in successive messages. Etc. > > But thread is an exception. > > If you think someone is talking nonsense, I think the best policy is to > ignore it or reply privately (not to the list); then the thread dies. I > find derogatory discussion of a particular person quite discouraging. It is > likely to be unjust, and it encourages more of the same. It's like > littering your own house. > > Respect, guys, please. > > Simon > > | >> This "troll" was, apparently, invited by one of the Simons > | >> onto the Haskell' list, then asked to move his spiels here. > | > | I am informed that the "invitation" I was referring to was actually > | about his being invited *out*, not in, so his origin is still a > | mystery and "troll" is likely appropriate. (I can't say he's > | demonstrated much of a mathematical basis for his trollery; only a > | propensity for pompous declarations, and deflection when challenged on > | them. Put up or shut up, troll.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/374fe00c/attachment-0001.html From leimy2k at gmail.com Fri Dec 4 11:08:02 2009 From: leimy2k at gmail.com (David Leimbach) Date: Fri Dec 4 10:50:49 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: <87aaxzcs0p.fsf@gregorycollins.net> References: <87aaxzcs0p.fsf@gregorycollins.net> Message-ID: <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> d On Thu, Dec 3, 2009 at 7:55 PM, Gregory Collins wrote: > Conal Elliott writes: > > > I'd like to make some FRPish toys that keep files updated to have > > functional relationships with other files. hinotify looks like just > > the sort of underlying magic I could use for efficient implementation > > on linux. Is there any support for mac os x? Could support be either > > added to hinotify or maybe inotify and a mac-friendly library be > > abstracted into a common Haskell interface? I'm fine with an > > imperative interface, since I can abstract into a functional library, > > which I guess would be a sort of persistent simplified FRP. > > On Mac & BSD you have to use kqueue, and on Windows it's > ReadDirectoryChangesW. A platform-agnostic Haskell library for detecting > filesystem change notifications is something that I would really > appreciate! > launchd does everything on mac os x, like literally everything. My mother said if I can't say something good about someone or something then don't say anything at all, and in this case, I'm taking her advice on what I think about launchd, however if you click the link below you might get an idea of how that works on Mac OS X. http://stackoverflow.com/questions/1515730/is-there-a-command-like-watch-or-inotifywait-on-the-mac Dave > > G > -- > Gregory Collins > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/1641b62b/attachment.html From rmm-haskell at z.odi.ac Fri Dec 4 11:31:48 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Fri Dec 4 11:06:28 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> References: <87aaxzcs0p.fsf@gregorycollins.net> <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> Message-ID: <562B3367-F0F8-4266-9D44-4F9E5B665961@z.odi.ac> kqueue is the "low level" interface, but requires that you handle all file system events as they happen, and fast. There is a higher level interface called fsevents (with accompanying daemon fseventsd) which allows you a more calm way to read the file system events. http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html I think launchd just happens to have an integration to kqueue or fseventsd, I'm not sure launching a program every time a file changes would be the best thing :-) -Ross On Dec 4, 2009, at 11:08 AM, David Leimbach wrote: > d > > On Thu, Dec 3, 2009 at 7:55 PM, Gregory Collins > wrote: > Conal Elliott writes: > > > I'd like to make some FRPish toys that keep files updated to have > > functional relationships with other files. hinotify looks like just > > the sort of underlying magic I could use for efficient > implementation > > on linux. Is there any support for mac os x? Could support be > either > > added to hinotify or maybe inotify and a mac-friendly library be > > abstracted into a common Haskell interface? I'm fine with an > > imperative interface, since I can abstract into a functional > library, > > which I guess would be a sort of persistent simplified FRP. > > On Mac & BSD you have to use kqueue, and on Windows it's > ReadDirectoryChangesW. A platform-agnostic Haskell library for > detecting > filesystem change notifications is something that I would really > appreciate! > > launchd does everything on mac os x, like literally everything. My > mother said if I can't say something good about someone or something > then don't say anything at all, and in this case, I'm taking her > advice on what I think about launchd, however if you click the link > below you might get an idea of how that works on Mac OS X. > > http://stackoverflow.com/questions/1515730/is-there-a-command-like-watch-or-inotifywait-on-the-mac > > Dave > > G > -- > Gregory Collins > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/cd03e5a5/attachment.html From keithshep at gmail.com Fri Dec 4 11:34:57 2009 From: keithshep at gmail.com (Keith Sheppard) Date: Fri Dec 4 11:09:33 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <3e1162e60912040758k3a1ff6f3udd41769f51f76b9@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> <3e1162e60912040758k3a1ff6f3udd41769f51f76b9@mail.gmail.com> Message-ID: <92e42b740912040834m794faa08hc2cc27e90593e6b0@mail.gmail.com> There is nothing wrong with constructive criticism and debate. We should welcome it and I think that the initial response did. But the OP's follow up of: "It will be better for all of you to figure it out for yourselves and gain more experience about what is out there. Haskell isn't the world. Haskell would be the cutting edge if it didn't have competition." tells me that the post was not intended to be constructive Best -Keith On Fri, Dec 4, 2009 at 10:58 AM, David Leimbach wrote: > Hi Simon and others, > Personally I don't see anything wrong with this guy's line of questioning. > ?He wants some proof that Haskell can live up to some of the claims made > about it. ?There's a lot of selling of languages like Clojure, Scala, and > Haskell going on that have real world examples showing how code compares > from one language to the next (sometimes unfairly I'll add, in that the code > that one person writes in one language, does not illustrate the best of that > language). > I will admit I missed out on the optimization thread that people refer to. > ?I guess I could read the archives, but the tone of this thread makes me > think it's not worthwhile. > I think what it boils down to is Haskell use is a choice that every person > gets to make for their spare time projects and if you're lucky enough to > have such a choice at your job, why not check it out and see for yourself? > If one disagrees with the claims of the salesmen, perhaps a trial period > will convince one otherwise, it's not like it costs anything but time. > ?There's not even a 90 day money back guarantee to worry about. > As for trolls on the mailing list, I personally do not have time to read > every message that comes through haskell-cafe because the level of activity > is higher than my available bandwidth for reading emails. ?As such, I often > press this lovely button the people who made my computer and operating > system so thoughtfully designed called "delete". ?Man does that thing ever > work wonders... > Then people can refrain from increasing the magnitude of the denominator in > the signal to noise ratio that has a nice value at the moment here in this > community. ?Sadly I think I just did the opposite, but since this is a cafe, > and I had something to say, and I said it, I don't feel so badly about it, > and won't comment on it again. > Just my 2 cents, which might be all I have left these days :-) > Dave > > On Fri, Dec 4, 2009 at 1:34 AM, Simon Peyton-Jones > wrote: >> >> Friends >> >> One of the absolutely best things about the Haskell community is that it >> is almost invariably respectful and usually friendly. ?People often remark >> on this when they join the community. ?Beginner questions are greeted with >> polite and helpful replies. ?Category theory and elementary type errors show >> up in successive messages. ?Etc. >> >> But thread is an exception. >> >> If you think someone is talking nonsense, I think the best policy is to >> ignore it or reply privately (not to the list); then the thread dies. ?I >> find derogatory discussion of a particular person quite discouraging. ?It is >> likely to be unjust, and it encourages more of the same. ?It's like >> littering your own house. >> >> Respect, guys, please. >> >> Simon >> >> | >> This "troll" was, apparently, invited by one of the Simons >> | >> onto the Haskell' list, then asked to move his spiels here. >> | >> | I am informed that the "invitation" I was referring to was actually >> | about his being invited *out*, not in, so his origin is still a >> | mystery and "troll" is likely appropriate. ?(I can't say he's >> | demonstrated much of a mathematical basis for his trollery; only a >> | propensity for pompous declarations, and deflection when challenged on >> | them. ?Put up or shut up, troll.) >> _______________________________________________ >> 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 > > -- keithsheppard.name From svein.ove at aas.no Fri Dec 4 11:39:35 2009 From: svein.ove at aas.no (Svein Ove Aas) Date: Fri Dec 4 11:14:13 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: <562B3367-F0F8-4266-9D44-4F9E5B665961@z.odi.ac> References: <87aaxzcs0p.fsf@gregorycollins.net> <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> <562B3367-F0F8-4266-9D44-4F9E5B665961@z.odi.ac> Message-ID: <221b53ab0912040839i76725f9l28ad512864a8c534@mail.gmail.com> On Fri, Dec 4, 2009 at 5:31 PM, Ross Mellgren wrote: > kqueue is the "low level" interface, but requires that you handle all file > system events as they happen, and fast. > For the purposes of creating a binding in haskell, my preferred way would be to use the low-level interface and build saner abstractions on top of that; it would be trivial to buffer them haskell-side. That said.. you say you have to handle the events "fast". What happens if you don't? -- Svein Ove Aas From markl at glyphic.com Fri Dec 4 11:44:44 2009 From: markl at glyphic.com (Mark Lentczner) Date: Fri Dec 4 11:19:20 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> Message-ID: <1E783BA7-16E6-4146-8F66-77CC187BEAB1@glyphic.com> On Dec 4, 2009, at 2:43 AM, Luke Palmer wrote: > So GHC leaves it to the user to specify sharing. If you want an > expression shared, let bind it and reuse. Does GHC treat where and let the same in this regard? Or in code, are these treated the same? > x'' = sum l + product l where l = [1..10^6] > x' = let l = [1..10^6] in sum l + product l I couldn't tell if the report implies that or not. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ mark@glyphic.com From gladstein at gladstein.com Fri Dec 4 11:44:45 2009 From: gladstein at gladstein.com (gladstein@gladstein.com) Date: Fri Dec 4 11:19:29 2009 Subject: [Haskell-cafe] Is Haskell a =?UTF-8?Q?Fanatic=3F?= Message-ID: <20091204094445.75469f813b58c2e0e98e8a30424d5d59.c7eeb01f00.wbe@email05.secureserver.net> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/f7422c9b/attachment.html From roman.salmin at gmail.com Fri Dec 4 11:49:39 2009 From: roman.salmin at gmail.com (Roman Salmin) Date: Fri Dec 4 11:24:15 2009 Subject: [Haskell-cafe] Haskell for Physicists In-Reply-To: References: <20091013184415.GI7864@whirlpool.galois.com> Message-ID: On Fri, Dec 04, 2009 at 01:43:42PM +0000, Matthias G?rgens wrote: > > _So my strong opinion that solution is only DSL not EDSL_ > > Why do you think they will learn your DSL, if they don't learn any > other language? I didn't said that they didn't learn any language. They learn languages, but only part that is necessary to do particular task. f.e. ROOT CINT(C++ interpreter) didn't distinguish object from pointer to object, i.e. statement h.ls(); works as well as h->ls(); independently of either h has type TH1F or TH1F*, so beginning ROOT user didn't need know what is pointer, memory management helps him. But early or latter one need to write more complicated code, then one need to spend months to reading big C++ books, and struggling with compilers errors, segfaults etc..^(1) (instead of doing assigned task!) or, what is more usually, trying Ad hoc methods for writing software. So people will learn DSL because: 1. DSL is simpler than general purpose language 2. DSL describe already known domain for user, (one probably don't need monads, continuations, virtual methods, template instantiation etc...etc...) so learning is easy, and didn't consume much time. > And if your DSL includes general purpose stuff, like > functions, control structures, data structures, you'll re-invent the > wheel. Probably porly. You didn't need to reinvent the wheel, because you DSL compiler can produce Haskell code: DSL -> General Purpose Language -> Executable And ever if you do, it saves allot of time of experts. Roman. (1) In Haskell this probably will sound like: reading allot of small tutorials and articles, grokking monads, struggling with type-check errors, infinite loops, laziness, etc... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/07be1bb0/attachment.html From daniel.is.fischer at web.de Fri Dec 4 11:49:26 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Dec 4 11:25:40 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <4B192F49.3020600@dfki.de> References: <4B167061.10007@dfki.de> <7ca3f0160912040702o43c54f87g2d411516a7c32262@mail.gmail.com> <4B192F49.3020600@dfki.de> Message-ID: <200912041749.27041.daniel.is.fischer@web.de> Am Freitag 04 Dezember 2009 16:48:25 schrieb Christian Maeder: > Luke Palmer schrieb: > >> \begin{code} > >> allPossibilities :: [[a]] -> [[a]] > >> allPossibilities [] = [[]] > >> allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] > > > > I am confused. This is exactly sequence. How is this a faster > > version? Other than maybe avoiding some dictionary-passing? > > I suppose, dictionary-passing is really the reason for slower code. I don't think so. With the code of sequence specialised to lists, I get the same performance as with Control.Monad.sequence (at least, the difference is too small to be reliably measured), while allPossibilities is significantly faster. Perhaps the code generator can handle list comprehensions better than folds? > > > Incidentally there is a "better" version of sequence for finding > > products of lists: > > > > allPossibilities :: [[a]] -> [[a]] > > allPossibilities [] = [[]] > > allPossibilities (l:ls) = [ x : xs | xs <- allPossibilites ls, x <- l ] > > I cannot really observe a speed up, with this version, but there are > probably examples where any version is faster than the other. I can, dafis@linux-mkk1:~/Haskell/CafeTesting> time ./pairs 7 9 20 5529600 0.18user 0.00system 0:00.18elapsed 102%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+521minor)pagefaults 0swaps dafis@linux-mkk1:~/Haskell/CafeTesting> time ./pairs +RTS -A200M -RTS 6 9 20 5529600 0.45user 0.26system 0:00.71elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+56604minor)pagefaults 0swaps > > > Or, the general form (I don't know of a use other than for lists, > > however): > > "Maybe" should be another useful instance. > > > sequence' :: Applicative f => [f a] -> f [a] > > sequence' [] = pure [] > > sequence' (x:xs) = liftA2 (flip (:)) xs x > > > > The difference is that it binds the tail of the list first, so the > > generated tails are shared. This means less consing, less GC strain, > > and a lot less memory usage if you store them. > > This argument it too complicated for me. aP1 [] = [[]] aP1 (h:t) = do x <- h xs <- aP1 t return (x:xs) for every x in h, we calculate the combinations of t anew. aP2 [] = [[]] aP2 (h:t) = do xs <- aP2 t x <- h return (x:xs) now we first calculate the combinations of t, for each of those, we cons the elements of h to it in turn and never reuse it afterwards. > > > Mind, the answers come out in a different order. > > Yes, thanks. > > Christian From duncan.coutts at googlemail.com Fri Dec 4 11:56:41 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Dec 4 11:31:20 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <4B185C9C.6040706@freegeek.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <1259845201.4896.103489.camel@localhost> <4B185C9C.6040706@freegeek.org> Message-ID: <1259945801.4778.606.camel@localhost> On Thu, 2009-12-03 at 19:49 -0500, wren ng thornton wrote: > Duncan Coutts wrote: > > I've got an open mind on the suggestion to amalgamate the two ways the > > list could end. I'm not especially in favour of generalising for the > > sake of generalising, especially if it looses the connection to the > > notion of annotating your "ordinary" data structure with extra errors. > > If I effectively always have to use an Either for the final value then > > perhaps it does not buy anything and just makes the folds uglier (since > > it might loose the connection with the ordinary fold). But it could make > > even that use case simpler so it's worth looking at in a few examples > > (eg the tar package). > > These days I view folds as automatically defined by the data type, so I > don't see any reason (on those grounds) to want to compare it to lists' > foldr as opposed to any other arbitrary catamorphism. Sure the fold is defined by the data type, except when we are pretending that one data type is another. This type is intended as a list that is annotated with errors. So I want to be able to switch between list versions and this version just by adding an extra error-handling parameter to the ordinary list fold. As another example of this, consider the VersionRange type in Cabal. It provides two different folds depending on what view you want. Neither matches the underlying constructors exactly. Duncan From rmm-haskell at z.odi.ac Fri Dec 4 11:57:38 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Fri Dec 4 11:32:18 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: <221b53ab0912040839i76725f9l28ad512864a8c534@mail.gmail.com> References: <87aaxzcs0p.fsf@gregorycollins.net> <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> <562B3367-F0F8-4266-9D44-4F9E5B665961@z.odi.ac> <221b53ab0912040839i76725f9l28ad512864a8c534@mail.gmail.com> Message-ID: <738C8EA9-6315-424E-9E34-BF178E59202B@z.odi.ac> Well, I don't think anything bad will happen, but I think I remember there being no/little buffering, so your program had to be responsive if you wanted to get the events. fseventsd is a daemon on top that keeps logs, so you can read them at leisure. I'm sorry I can't find the original article I had read to learn this, otherwise I'd link you directly so you could make your own judgements. I think the decision between the two is primarily based on your use case. If you are intended to run continuously and handling each event will probably not use that many resources (as to not bog down the system as you receive many file system events), and you need real-time tracking, kqueue is for you. Conversely, if you need to know things changed soon after, but not immediately, and especially if you don't want to be running continuously, then fseventsd is for you. This is my understanding, not having used either directly (I've only used inotify on linux). -Ross On Dec 4, 2009, at 11:39 AM, Svein Ove Aas wrote: > On Fri, Dec 4, 2009 at 5:31 PM, Ross Mellgren > wrote: >> kqueue is the "low level" interface, but requires that you handle >> all file >> system events as they happen, and fast. >> > For the purposes of creating a binding in haskell, my preferred way > would be to use the low-level interface and build saner abstractions > on top of that; it would be trivial to buffer them haskell-side. > > That said.. you say you have to handle the events "fast". What happens > if you don't? > > -- > Svein Ove Aas From gcross at phys.washington.edu Fri Dec 4 12:06:18 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Fri Dec 4 11:42:39 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <4B1930F3.30306@henning-thielemann.de> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> <4B1930F3.30306@henning-thielemann.de> Message-ID: <029ED0C1-E758-49CB-95DB-AAFFBC19CACE@phys.washington.edu> On Dec 4, 2009, at 7:55 AM, Henning Thielemann wrote: > Gregory Crosswhite schrieb: >> If there is one thing that we really don't have enough of in Haskell, it is *ways to handle errors*! Thus, I am pleased to announce the release of the "error-message" package to help in filling this, erm, gap. >> >> This philosophy behind this package is that it is often better to find out all of the errors that have occured in a computation and report them simultaneously, rather than aborting as soon as the first error is encountered. Towards this end, this package supplies a type of /combinable error messages/ (ErrorMessage in the Data.ErrorMessage module) so that all of the errors from subcomputations can be gathered and presented together. > > I would call such non-serious errors 'warnings'. Warnings can be > collected using Writer monad. > The errors are indeed serious because they prevent the computation from being finished; it's just that errors are often not "fatal" in the sense that you have to stop when you encounter the first one rather than seeing if anything else also went wrong. For example, consider compilation errors: any error causes the compilation to fail, but the compiler tries to uncover as many errors as it can at once so that it can show you the whole list rather than just the first one. On Dec 4, 2009, at 7:57 AM, Henning Thielemann wrote: > Gregory Crosswhite schrieb: > >> When I uploaded my new package, "error-message", I also went ahead and created a new category: "Error Handling". > > "Error handling" is the same as "debugging" for you? I hope it is not > intended for generating further confusion about "exception handling" and > "debugging" (= help programmers to analyse errors). No, but I can see how you would have gotten that impression since the examples I supply in my documentation are all programmer errors. The real purpose of this is to collect together errors that ultimately came from bad program inputs, i.e. "user errors". In particular, the motivation for this package was that I have written a build system, and I wanted to collect as many errors in the build as possible and show them all to the user at once. Cheers, Greg From duncan.coutts at googlemail.com Fri Dec 4 12:08:58 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Dec 4 11:43:36 2009 Subject: [Haskell-cafe] Optimization with Strings ? In-Reply-To: <20091203130302.6a67ad99@brouillard.aima.fr> References: <20091203130302.6a67ad99@brouillard.aima.fr> Message-ID: <1259946538.4778.657.camel@localhost> On Thu, 2009-12-03 at 13:03 +0100, Emmanuel CHANTREAU wrote: > Hello > > In my futur program, it use a lot of binary trees with strings (words) > as leaf. There is just arround 1000 words and they will appear a lot of > times. The program will possibly consume a lot of process and memory > (it is a mathematics proover). > > I began this program in C++ but haskell has a prety good speed and > memory footprint and is easier. But I don't know if it worth to do this > optimization: having a dictionary to translate string words in Int. > > The answer depends on the automatic optimizations in GHC, because GHC > could compare quickely two strings if it is the same object, so it > depends if program generated by GHC have a dictionary (tree) of strings > internaly. Someone knows this ? There's nothing automatic about it. It depends on the implementation of the type of string you are using. For the String type there is no equality short-cut, for ByteString there is. Duncan From lrpalmer at gmail.com Fri Dec 4 12:15:05 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 4 11:49:43 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <1E783BA7-16E6-4146-8F66-77CC187BEAB1@glyphic.com> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> <1E783BA7-16E6-4146-8F66-77CC187BEAB1@glyphic.com> Message-ID: <7ca3f0160912040915m7f26950eo7049183ca66f1edb@mail.gmail.com> On Fri, Dec 4, 2009 at 9:44 AM, Mark Lentczner wrote: > > On Dec 4, 2009, at 2:43 AM, Luke Palmer wrote: > >> So GHC leaves it to the user to specify sharing. ?If you want an >> expression shared, let bind it and reuse. > > Does GHC treat where and let the same in this regard? Or in code, are these treated the same? where is just sugar for let. > >> x'' = sum l + product l where l = [1..10^6] > >> x' = let l = [1..10^6] in sum l + product l > > > I couldn't tell if the report implies that or not. > > ? ? ? ?- Mark > > > > > Mark Lentczner > http://www.ozonehouse.com/mark/ > mark@glyphic.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lrpalmer at gmail.com Fri Dec 4 12:17:44 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 4 11:52:20 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <92e42b740912040834m794faa08hc2cc27e90593e6b0@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> <3e1162e60912040758k3a1ff6f3udd41769f51f76b9@mail.gmail.com> <92e42b740912040834m794faa08hc2cc27e90593e6b0@mail.gmail.com> Message-ID: <7ca3f0160912040917k2d09fedam1e807fb81c803089@mail.gmail.com> On Fri, Dec 4, 2009 at 9:34 AM, Keith Sheppard wrote: > There is nothing wrong with constructive criticism and debate. We > should welcome it and I think that the initial response did. But the > OP's follow up of: > > "It will be better for all of you to figure it out for yourselves and > gain more experience about what is out there. Haskell isn't the world. > Haskell would be the cutting edge if it didn't have competition." > > tells me that the post was not intended to be constructive In which case -- I believe David was arguing -- we ignore it and continue reading the constructive threads. Luke > Best > -Keith > > On Fri, Dec 4, 2009 at 10:58 AM, David Leimbach wrote: >> Hi Simon and others, >> Personally I don't see anything wrong with this guy's line of questioning. >> ?He wants some proof that Haskell can live up to some of the claims made >> about it. ?There's a lot of selling of languages like Clojure, Scala, and >> Haskell going on that have real world examples showing how code compares >> from one language to the next (sometimes unfairly I'll add, in that the code >> that one person writes in one language, does not illustrate the best of that >> language). >> I will admit I missed out on the optimization thread that people refer to. >> ?I guess I could read the archives, but the tone of this thread makes me >> think it's not worthwhile. >> I think what it boils down to is Haskell use is a choice that every person >> gets to make for their spare time projects and if you're lucky enough to >> have such a choice at your job, why not check it out and see for yourself? >> If one disagrees with the claims of the salesmen, perhaps a trial period >> will convince one otherwise, it's not like it costs anything but time. >> ?There's not even a 90 day money back guarantee to worry about. >> As for trolls on the mailing list, I personally do not have time to read >> every message that comes through haskell-cafe because the level of activity >> is higher than my available bandwidth for reading emails. ?As such, I often >> press this lovely button the people who made my computer and operating >> system so thoughtfully designed called "delete". ?Man does that thing ever >> work wonders... >> Then people can refrain from increasing the magnitude of the denominator in >> the signal to noise ratio that has a nice value at the moment here in this >> community. ?Sadly I think I just did the opposite, but since this is a cafe, >> and I had something to say, and I said it, I don't feel so badly about it, >> and won't comment on it again. >> Just my 2 cents, which might be all I have left these days :-) >> Dave >> >> On Fri, Dec 4, 2009 at 1:34 AM, Simon Peyton-Jones >> wrote: >>> >>> Friends >>> >>> One of the absolutely best things about the Haskell community is that it >>> is almost invariably respectful and usually friendly. ?People often remark >>> on this when they join the community. ?Beginner questions are greeted with >>> polite and helpful replies. ?Category theory and elementary type errors show >>> up in successive messages. ?Etc. >>> >>> But thread is an exception. >>> >>> If you think someone is talking nonsense, I think the best policy is to >>> ignore it or reply privately (not to the list); then the thread dies. ?I >>> find derogatory discussion of a particular person quite discouraging. ?It is >>> likely to be unjust, and it encourages more of the same. ?It's like >>> littering your own house. >>> >>> Respect, guys, please. >>> >>> Simon >>> >>> | >> This "troll" was, apparently, invited by one of the Simons >>> | >> onto the Haskell' list, then asked to move his spiels here. >>> | >>> | I am informed that the "invitation" I was referring to was actually >>> | about his being invited *out*, not in, so his origin is still a >>> | mystery and "troll" is likely appropriate. ?(I can't say he's >>> | demonstrated much of a mathematical basis for his trollery; only a >>> | propensity for pompous declarations, and deflection when challenged on >>> | them. ?Put up or shut up, troll.) >>> _______________________________________________ >>> 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 >> >> > > > > -- > keithsheppard.name > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From radek.micek at gmail.com Fri Dec 4 12:26:41 2009 From: radek.micek at gmail.com (Radek Micek) Date: Fri Dec 4 12:01:17 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) Message-ID: Hello. I have two types for expression: data Expr = Add Expr Expr | Mul Expr Expr | Const Int data AExpr = AAdd AExpr AExpr | AConst Int The first one supports addition and multiplication and the second only addition. I can write a function to simplify the first expression: simplify :: Expr -> Expr simplify = {- replaces: "a*1" and "1*a" by "a", "a+0" and "0+a" by a -} And I would like to use the function simplify for the second type AExpr. What can I do is to convert AExpr to Expr, simplify it and convert it back. But I don't like this solution because conversions take some time. I would prefer following: I say to the compiler that AAdd is like Add and AConst is like Const and the compiler derives function asimplify for AExpr. Is it possible to do this? In fact I want to have two distinct types where one is "extension" of the second (Expr is extension of AExpr) and I want to define a function for the extended type (Expr) and use it for the original type (AExpr). I assume that the function won't introduce Mul to the expression which had no Mul. Thanks in advance Radek Micek From ekirpichov at gmail.com Fri Dec 4 12:30:04 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Fri Dec 4 12:04:39 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) In-Reply-To: References: Message-ID: <5e0214850912040930u3cbacbf8uffbbb6f5e09ca3eb@mail.gmail.com> It is possible to do this automatically, but you'll have to program the automation yourself with Template Haskell. 2009/12/4 Radek Micek : > Hello. > > I have two types for expression: > > data Expr = Add Expr Expr | Mul Expr Expr | Const Int > > data AExpr = AAdd AExpr AExpr | AConst Int > > The first one supports addition and multiplication and the second > only addition. > > I can write a function to simplify the first expression: > > simplify :: Expr -> Expr > simplify = {- replaces: > "a*1" and "1*a" by "a", > "a+0" and "0+a" by a -} > > And I would like to use the function simplify for the second type > AExpr. What can I do is to convert AExpr to Expr, simplify it and > convert it back. But I don't like this solution because > conversions take some time. > > I would prefer following: I say to the compiler that AAdd is like Add > and AConst is like Const and the compiler derives function > asimplify for AExpr. > > Is it possible to do this? In fact I want to have two distinct types > where one is "extension" of the second (Expr is extension of AExpr) > and I want to define a function for the extended type (Expr) and > use it for the original type (AExpr). I assume that the function won't > introduce Mul to the expression which had no Mul. > > Thanks in advance > > Radek Micek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru From lrpalmer at gmail.com Fri Dec 4 12:50:54 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 4 12:25:30 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) In-Reply-To: References: Message-ID: <7ca3f0160912040950mee1f72dp8d8981b440339688@mail.gmail.com> On Fri, Dec 4, 2009 at 10:26 AM, Radek Micek wrote: > Hello. > > I have two types for expression: > > data Expr = Add Expr Expr | Mul Expr Expr | Const Int > > data AExpr = AAdd AExpr AExpr | AConst Int > > The first one supports addition and multiplication and the second > only addition. > > I can write a function to simplify the first expression: > > simplify :: Expr -> Expr > simplify = {- replaces: > "a*1" and "1*a" by "a", > "a+0" and "0+a" by a -} > > And I would like to use the function simplify for the second type > AExpr. What can I do is to convert AExpr to Expr, simplify it and > convert it back. But I don't like this solution because > conversions take some time. Well there are more involved reasons than simply the conversion taking time. If you would like the type system on your side, you have a decent modeling problem on your hands. How can you guarantee that simplify will return a type that will "fit" in AExpr? Simplify might turn "a+a" into "2*a", and then your trick no longer works. It would seem that you need to typecheck the function twice. You could attempt to go the other way, i.e. define a simplify on AExpr and map to and from Expr, but that will have trouble with expressions like 0+(2*a), because 2*a has no representation in AExpr. My hunch is that to do this "properly", you need to use some of the fixed point modeling that I can't find the paper about (!) (It's popular, someone please chime in :-). I.e. define a data type which, directed by type classes, may or may not support multiplication. Then define separately an additive simplifier and a multiplicative simplifier on that. There is some ugly bookkeeping involved, so that the code *locally* is not that pretty, but it has good large-scale engineering properties. And in the grand scheme of things, the conversions will not take that much time. The equivalent of a pointer indirection per node (+ some GC). And there is no difference in memory usage because of laziness. This is not the level at which you worry about speed in Haskell -- at least in my experience. Luke From derek.a.elkins at gmail.com Fri Dec 4 12:52:35 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Dec 4 12:27:11 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) In-Reply-To: References: Message-ID: <61f84eff0912040952t3f179f99xcd5153f671970769@mail.gmail.com> On Fri, Dec 4, 2009 at 11:26 AM, Radek Micek wrote: > Hello. > > I have two types for expression: > > data Expr = Add Expr Expr | Mul Expr Expr | Const Int > > data AExpr = AAdd AExpr AExpr | AConst Int > > The first one supports addition and multiplication and the second > only addition. > > I can write a function to simplify the first expression: > > simplify :: Expr -> Expr > simplify = {- replaces: > "a*1" and "1*a" by "a", > "a+0" and "0+a" by a -} > > And I would like to use the function simplify for the second type > AExpr. What can I do is to convert AExpr to Expr, simplify it and > convert it back. But I don't like this solution because > conversions take some time. > > I would prefer following: I say to the compiler that AAdd is like Add > and AConst is like Const and the compiler derives function > asimplify for AExpr. > > Is it possible to do this? In fact I want to have two distinct types > where one is "extension" of the second (Expr is extension of AExpr) > and I want to define a function for the extended type (Expr) and > use it for the original type (AExpr). I assume that the function won't > introduce Mul to the expression which had no Mul. What you'd ideally want is called refinement types which Haskell, and as far as I know, no practical language has. There is a paper about a way to encode these, but it is fairly heavy-weight. You could use phantom type trickery to combine the data types into one type but still statically check that only additive expressions are passed to certain functions, but that too is also probably more trouble than it's worth. From Christian.Maeder at dfki.de Fri Dec 4 13:00:33 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Dec 4 12:35:10 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <200912041749.27041.daniel.is.fischer@web.de> References: <4B167061.10007@dfki.de> <7ca3f0160912040702o43c54f87g2d411516a7c32262@mail.gmail.com> <4B192F49.3020600@dfki.de> <200912041749.27041.daniel.is.fischer@web.de> Message-ID: <4B194E41.90707@dfki.de> Daniel Fischer schrieb: >>> allPossibilities :: [[a]] -> [[a]] >>> allPossibilities [] = [[]] >>> allPossibilities (l:ls) = [ x : xs | xs <- allPossibilites ls, x <- l ] >> I cannot really observe a speed up, with this version, but there are >> probably examples where any version is faster than the other. > > I can, Oh yes, I can too. > aP1 [] = [[]] > aP1 (h:t) = do > x <- h > xs <- aP1 t > return (x:xs) > > for every x in h, we calculate the combinations of t anew. Do we? Isn't "aP1 t" one closure that's being evaluated only once? > aP2 [] = [[]] > aP2 (h:t) = do > xs <- aP2 t > x <- h > return (x:xs) > > now we first calculate the combinations of t, for each of those, we cons the elements of h > to it in turn and never reuse it afterwards. Thanks for explaining. C. From sebastian.sylvan at gmail.com Fri Dec 4 13:00:37 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Dec 4 12:35:19 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> Message-ID: <3d96ac180912041000s3762590cq39d3e12f14f6d446@mail.gmail.com> On Thu, Dec 3, 2009 at 5:09 PM, John D. Earle wrote: > See "[Haskell-cafe] Optimization with Strings ?" for background. > > Don Stewart wrote, "the guarantees of purity the type system provides are > extremely > useful for verification purposes". My response to this is in theory. This > is what caught my attention initially, but the language lacks polish and > does not appear to be going in a direction where it shows signs where it > will self-correct. It may even be beyond repair. I care about others and I > don't want people to be misled. > > I am already well aware of the numbers. They do not impress me. I have > written on this already. I have given Haskell the benefit of the doubt and > said, What's wrong with being uncompromising? There is something wrong with > it, if it has taken you off the path of truth. This is not uncompromising. > This is something else. It is called fanaticism and this is the opinion that > I have come to after due consideration. > > If you are going to argue your case, be constructive. Tell me how the type > system is not flawed and how the Haskell language is rigorous. What proof do > you have of this? Explain to me how Haskell has been merely uncompromising > in its pursuit of perfection and did not manage to step over the threshold > into fanaticism. Please remain on topic and on point. > I honestly don't understand what your beef is. Could you explain what you mean with some specifics? In what way does Haskell lack polish? What makes you think it's not going in a direction where it will self correct? What's the "path of truth" and in what way is Haskell not on it? I would very much appreciate if you could try to explain what you mean using specific examples. I read the other thread and the post of yours didn't really seem to make much sense to me there either. -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/0a14e471/attachment.html From rwbarton at math.harvard.edu Fri Dec 4 13:14:14 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Fri Dec 4 12:48:50 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) In-Reply-To: <61f84eff0912040952t3f179f99xcd5153f671970769@mail.gmail.com> References: <61f84eff0912040952t3f179f99xcd5153f671970769@mail.gmail.com> Message-ID: <20091204181414.GB3316@rwbarton.mit.edu> On Fri, Dec 04, 2009 at 11:52:35AM -0600, Derek Elkins wrote: > On Fri, Dec 4, 2009 at 11:26 AM, Radek Micek wrote: > > Hello. > > > > I have two types for expression: > > > > data Expr = Add Expr Expr | Mul Expr Expr | Const Int > > > > data AExpr = AAdd AExpr AExpr | AConst Int > > > > The first one supports addition and multiplication and the second > > only addition. > > > > I can write a function to simplify the first expression: > > > > simplify :: Expr -> Expr > > simplify = {- replaces: > > "a*1" and "1*a" by "a", > > "a+0" and "0+a" by a -} > > > > And I would like to use the function simplify for the second type > > AExpr. What can I do is to convert AExpr to Expr, simplify it and > > convert it back. But I don't like this solution because > > conversions take some time. > > > > I would prefer following: I say to the compiler that AAdd is like Add > > and AConst is like Const and the compiler derives function > > asimplify for AExpr. > > > > Is it possible to do this? In fact I want to have two distinct types > > where one is "extension" of the second (Expr is extension of AExpr) > > and I want to define a function for the extended type (Expr) and > > use it for the original type (AExpr). I assume that the function won't > > introduce Mul to the expression which had no Mul. > > What you'd ideally want is called refinement types which Haskell, and > as far as I know, no practical language has. There is a paper about a > way to encode these, but it is fairly heavy-weight. You could use > phantom type trickery to combine the data types into one type but > still statically check that only additive expressions are passed to > certain functions, but that too is also probably more trouble than > it's worth. In this particular case, with only two types Expr and AExpr, the encoding is not particularly onerous. {-# LANGUAGE GADTs, EmptyDataDecls, ViewPatterns #-} data M data Blah -- A value of type 'E a' can only involve multiplication when a is M data E a where Const :: Int -> E a Add :: E a -> E a -> E a Mul :: E M -> E M -> E M type Expr = E M type AExpr = E Blah -- The same simplify function we would write for the original Expr, -- with a different type simplify :: E a -> E a simplify (Const x) = Const x simplify (Add (simplify -> a) (simplify -> b)) = case (a, b) of (Const 0, _) -> b (_, Const 0) -> a _ -> Add a b simplify (Mul (simplify -> a) (simplify -> b)) = case (a, b) of (Const 1, _) -> b (_, Const 1) -> a _ -> Mul a b Regards, Reid Barton From jmccarty at sent.com Fri Dec 4 13:14:23 2009 From: jmccarty at sent.com (Jason McCarty) Date: Fri Dec 4 12:49:00 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <4B185C9C.6040706@freegeek.org> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <1259845201.4896.103489.camel@localhost> <4B185C9C.6040706@freegeek.org> Message-ID: <20091204181423.GA1109@quaternion> wren ng thornton wrote: > concat1 :: T a b -> (b -> T a b) -> T a b This could just as easily be concat :: T a b -> (b -> T a c) -> T a c right? It's a little weird to call this concatenation, but I bet it could come in handy. -- Jason McCarty From gcross at phys.washington.edu Fri Dec 4 13:14:06 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Fri Dec 4 12:50:55 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <3d96ac180912041000s3762590cq39d3e12f14f6d446@mail.gmail.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <3d96ac180912041000s3762590cq39d3e12f14f6d446@mail.gmail.com> Message-ID: <2AF3040F-59ED-42AB-B2A0-A57D35A6E01A@phys.washington.edu> Sebastian, It helps if you think of John as having already won in this discussion, since he succeeded in getting a lengthy high-noise emotional reaction from us. :-) Cheers, Greg On Dec 4, 2009, at 10:00 AM, Sebastian Sylvan wrote: > > > On Thu, Dec 3, 2009 at 5:09 PM, John D. Earle wrote: > See "[Haskell-cafe] Optimization with Strings ?" for background. > > Don Stewart wrote, "the guarantees of purity the type system provides are extremely > useful for verification purposes". My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. > > I am already well aware of the numbers. They do not impress me. I have written on this already. I have given Haskell the benefit of the doubt and said, What's wrong with being uncompromising? There is something wrong with it, if it has taken you off the path of truth. This is not uncompromising. This is something else. It is called fanaticism and this is the opinion that I have come to after due consideration. > > If you are going to argue your case, be constructive. Tell me how the type system is not flawed and how the Haskell language is rigorous. What proof do you have of this? Explain to me how Haskell has been merely uncompromising in its pursuit of perfection and did not manage to step over the threshold into fanaticism. Please remain on topic and on point. > > I honestly don't understand what your beef is. Could you explain what you mean with some specifics? In what way does Haskell lack polish? What makes you think it's not going in a direction where it will self correct? > What's the "path of truth" and in what way is Haskell not on it? > > I would very much appreciate if you could try to explain what you mean using specific examples. I read the other thread and the post of yours didn't really seem to make much sense to me there either. > > -- > Sebastian Sylvan > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/3f04e625/attachment.html From ddssff at gmail.com Fri Dec 4 13:19:45 2009 From: ddssff at gmail.com (David Fox) Date: Fri Dec 4 12:54:23 2009 Subject: [Haskell-cafe] SYB <> very, very mysteriously In-Reply-To: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> References: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> Message-ID: I have created an entry in the syb-with-class issue database here:http://code.google.com/p/syb-with-class/issues/detail?id=3 I attached a version of the code with the necessary bits of Happstack.Data.Default included in-line. On Thu, Dec 3, 2009 at 2:50 PM, Jeremy Shaw wrote: > I have the following program which loops under GHC 6.10.4: > > http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=13561#a13561 > > {-# LANGUAGE DeriveDataTypeable, FlexibleInstances, MultiParamTypeClasses, > UndecidableInstances #-} > module Main where > > import qualified Data.Data as Data > import Data.Typeable (Typeable) > import Happstack.Data.Default > import Data.Generics.SYB.WithClass.Basics > import Data.Generics.SYB.WithClass.Instances () > > data Proposition = Proposition Expression ?deriving (Show, Data.Data, > Typeable) > data Expression = Conjunction (Maybe Expression) deriving (Show, Data.Data, > Typeable) > > -- instance (Sat (ctx [Expression]), Sat (ctx Expression), Sat (ctx > Proposition)) => Data ctx Proposition where > instance Data DefaultD Proposition where > ? ?gunfold _ k z c = > ? ? ? ?case constrIndex c of > ? ? ? ? ?1 -> k (z Proposition) > instance Default Proposition > > constrExpr :: Constr > constrExpr = mkConstr dataTypeExpr "Conjuction" [] Prefix > > dataTypeExpr :: DataType > dataTypeExpr = mkDataType "Expression" [constrExpr] > > instance ( Data ctx [Expression] > ? ? ? ? , Sat ?(ctx Expression) > ? ? ? ? , Sat ?(ctx (Maybe Expression))) => Data ctx Expression where > {- > instance Data DefaultD Expression where > -} > ? ?gunfold _ k z c = > ? ? ? ?case constrIndex c of > ? ? ? ? ?1 -> k (z Conjunction) > ? ?dataTypeOf _ _ = dataTypeExpr > > instance Default Expression > > e :: Expression > e = ?defaultValueD dict > > main = print e > > I wish to explain the *many* ways in which it is mysterious. If you load the > program into GHCi and evaluate 'e' it will hang. If you compile the program > and run it, it will output <>. This behavior seems annoying, but not > very weird. But, here is where it gets fun: > > 1. if you load the program into GHCi and eval 'e' it will hang. But, if you > load the program and type, '(defaultValueD dict) :: Expression' at the > prompt, it works fine! > > 2. if you remove the (Data DefaultD Proposition) instance, it ?works fine. > (Even though Expression does not refer to Proposition in any way) > > 3. if you simply change the definition of 'gunfold' in the 'Data ctx > Proposition' instance to, error "foo". The application works fine. That's > right, if you change the body of a function that isn't even being called, > evaluating 'e' starts working. (Even though Expression does not refer to > Proposition in any way. And even though that gunfold instance is never > actually called). > > 4. if you change the constraint on, Data ctx Expression, ?from (Data ctx > [Expression]) to (Data ctx Expression) it works fine. (Or remove it all > together). > > 5. if you change 'instance (Data DefaultD Proposition) where' to the line > above it which is commented out, it works fine. > > 6. if you change the type of Proposition to, data Proposition = Proposition > (Expression, Expression), then it works fine. > > So far I have only tested this in GHC 6.10.4. > > Any idea what is going on here? I can't imagine how changing the body of > functions that aren't being called would fix things... > > - jeremy > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jason.dusek at gmail.com Fri Dec 4 13:46:05 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Dec 4 13:20:40 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <2B2C4635-4C93-493B-881B-92FC5DBA3D33@cs.uu.nl> <42784f260912032021w4263a341yd06de51801481c54@mail.gmail.com> <7197CEA8-BA82-484B-B615-6F39E03B3020@ece.cmu.edu> <59543203684B2244980D7E4057D5FBC1085065D3@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <42784f260912041046j56382159x97bd6e17f4e75bb8@mail.gmail.com> 2009/12/04 Simon Peyton-Jones : > If you think someone is talking nonsense, I think the best > policy is to ignore it or reply privately (not to the list); > then the thread dies. ?I find derogatory discussion of a > particular person quite discouraging. ?It is likely to be > unjust, and it encourages more of the same. ?It's like > littering your own house. +1 -- Jason Dusek From functionallyharmonious at yahoo.com Fri Dec 4 13:51:03 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 13:25:39 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? Message-ID: <447258.47845.qm@web113101.mail.gq1.yahoo.com> What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? I think the portaudio library is the only contender but when I try to install it I get: >cabal install portaudio Resolving dependencies... Downloading portaudio-0.0.1... Configuring portaudio-0.0.1... cabal: Missing dependency on a foreign library: * Missing C library: portaudio This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the configure step. The exception was: exit: ExitFailure 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/2f2022a1/attachment.html From ben.franksen at online.de Fri Dec 4 14:02:54 2009 From: ben.franksen at online.de (Ben Franksen) Date: Fri Dec 4 13:37:55 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: Blueprint 0.1 -- PREVIEW References: Message-ID: Gregory Crosswhite wrote: > I have posted Blueprint to Hackage so that people can see what I have done > and possibly play with it. Very interesting, this. However, I could not build it. I get ben@sarun[2]: ~/tmp > cabal install blueprint Resolving dependencies... cabal: There is no installed version of base Needless to say this is wrong: ben@sarun[2]: ~/tmp > ghc-pkg list base /usr/local/lib/ghc-6.10.4/./package.conf: base-3.0.3.1, base-4.1.0.0 /home/ben/.ghc/i386-linux-6.10.4/package.conf: This has not happened to me with any other packages from hackage. Cheers Ben From vanenkj at gmail.com Fri Dec 4 14:03:26 2009 From: vanenkj at gmail.com (John Van Enk) Date: Fri Dec 4 13:38:02 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <447258.47845.qm@web113101.mail.gq1.yahoo.com> References: <447258.47845.qm@web113101.mail.gq1.yahoo.com> Message-ID: Hi, portaudio is my embarrassing fault, but it does work most of the time. (Community, some one remind me to revisit this package after Christmas.) Are you running in Windows? Linux? If Linux, which flavor? /jve On Fri, Dec 4, 2009 at 1:51 PM, M Xyz wrote: > > What is the most minimal (preferably platform independent) library > available for writing bytes to the sound card? I see 60 wonderful libraries > on Hackage, but I really just need the Haskell equivalent of an > audio.write(byte[]) method. What sound api are these 60 libraries using? > > I think the portaudio library is the only contender but when I try to > install it I get: > > >cabal install portaudio > Resolving dependencies... > Downloading portaudio-0.0.1... > Configuring portaudio-0.0.1... > cabal: Missing dependency on a foreign library: > * Missing C library: portaudio > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > cabal: Error: some packages failed to install: > portaudio-0.0.1 failed during the configure step. The exception was: > exit: ExitFailure 1 > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/a344f60e/attachment.html From patrick.leboutillier at gmail.com Fri Dec 4 14:09:16 2009 From: patrick.leboutillier at gmail.com (Patrick LeBoutillier) Date: Fri Dec 4 13:43:52 2009 Subject: [Haskell-cafe] FFI and ghci Message-ID: Hi all, I have a small FFI-based library that I like to test like this: $ ghci -I../c -L../c/.libs -lmlp t.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) mlp ... done final link ... done [1 of 9] Compiling MLP ( MLP.hs, interpreted ) [2 of 9] Compiling MLP.Error ( MLP/Error.hs, interpreted ) [3 of 9] Compiling MLP.Context ( MLP/Context.hs, interpreted ) [4 of 9] Compiling MLP.Runtime ( MLP/Runtime.hs, interpreted ) [5 of 9] Compiling MLP.Object ( MLP/Object.hs, interpreted ) [6 of 9] Compiling MLP.Type ( MLP/Type.hs, interpreted ) [7 of 9] Compiling MLP.Value ( MLP/Value.hs, interpreted ) [8 of 9] Compiling MLP.Language ( MLP/Language.hs, interpreted ) [9 of 9] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: MLP, MLP.Object, Main, MLP.Runtime, MLP.Context, MLP.Error, MLP.Value, MLP.Type, MLP.Language. *Main> main Note: Inside libmlp.so, another shared object is loaded using dlopen(). When running this test program I get some sporadic segmentation faults, which seem to always occur at entrypoint to the shared object that is loaded with dlopen(). But when I compile it with ghc, i.e. $ ghc --make -I../c -L../c/.libs -lmlp t.hs I can't reproduce crash. Can anyone see why this could be happening? It's quite possible that there is really a bug in the C code, but if someone knows about a bug or something in ghci that can cause this behaviour I can stop looking... Thanks a lot, Patrick -- ===================== Patrick LeBoutillier Rosem?re, Qu?bec, Canada From daniel.is.fischer at web.de Fri Dec 4 14:11:12 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Dec 4 13:47:16 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <4B194E41.90707@dfki.de> References: <4B167061.10007@dfki.de> <200912041749.27041.daniel.is.fischer@web.de> <4B194E41.90707@dfki.de> Message-ID: <200912042011.13145.daniel.is.fischer@web.de> Am Freitag 04 Dezember 2009 19:00:33 schrieb Christian Maeder: > > > aP1 [] = [[]] > > aP1 (h:t) = do > > x <- h > > xs <- aP1 t > > return (x:xs) > > > > for every x in h, we calculate the combinations of t anew. > > Do we? Isn't "aP1 t" one closure that's being evaluated only once? That depends. Firstly, it depends on the optimisation level. ---------------------------------------------------------------------- module AllPossibilities where import Debug.Trace aP1 :: [[Int]] -> [[Int]] aP1 [] = [[]] aP1 l@(h:t) = trace ("aP1 " ++ show l) [x:xs | x <- h, xs <- aP1 t] aP2 :: [[Int]] -> [[Int]] aP2 [] = [[]] aP2 l@(h:t) = trace ("aP2 " ++ show l) [x:xs | xs <- aP2 t, x <- h] ---------------------------------------------------------------------- Compiled without optimisations (or interpreted): Prelude AllPossibilities> aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] [[1,4,7],[1,4,8],[1,4,9]aP1 [[7,8,9]] ,[1,5,7],[1,5,8],[1,5,9]aP1 [[7,8,9]] ,[1,6,7],[1,6,8],[1,6,9]aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] ,[2,4,7],[2,4,8],[2,4,9]aP1 [[7,8,9]] ,[2,5,7],[2,5,8],[2,5,9]aP1 [[7,8,9]] ,[2,6,7],[2,6,8],[2,6,9]aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] ,[3,4,7],[3,4,8],[3,4,9]aP1 [[7,8,9]] ,[3,5,7],[3,5,8],[3,5,9]aP1 [[7,8,9]] ,[3,6,7],[3,6,8],[3,6,9]] Prelude AllPossibilities> aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[4,5,6],[7,8,9]] aP2 [[7,8,9]] [[1,4,7],[2,4,7],[3,4,7],[1,5,7],[2,5,7],[3,5,7],[1,6,7],[2,6,7],[3,6,7],[1,4,8],[2,4,8], [3,4,8],[1,5,8],[2,5,8],[3,5,8],[1,6,8],[2,6,8],[3,6,8],[1,4,9],[2,4,9],[3,4,9],[1,5,9], [2,5,9],[3,5,9],[1,6,9],[2,6,9],[3,6,9]] it's evaluated multiple times. Compiled with optimisation (-O or -O2), Prelude AllPossibilities> aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] [[1,4,7],[1,4,8],[1,4,9],[1,5,7],[1,5,8],[1,5,9],[1,6,7],[1,6,8],[1,6,9],[2,4,7],[2,4,8], [2,4,9],[2,5,7],[2,5,8],[2,5,9],[2,6,7],[2,6,8],[2,6,9],[3,4,7],[3,4,8],[3,4,9],[3,5,7], [3,5,8],[3,5,9],[3,6,7],[3,6,8],[3,6,9]] Prelude AllPossibilities> aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[4,5,6],[7,8,9]] aP2 [[7,8,9]] [[1,4,7],[2,4,7],[3,4,7],[1,5,7],[2,5,7],[3,5,7],[1,6,7],[2,6,7],[3,6,7],[1,4,8],[2,4,8], [3,4,8],[1,5,8],[2,5,8],[3,5,8],[1,6,8],[2,6,8],[3,6,8],[1,4,9],[2,4,9],[3,4,9],[1,5,9], [2,5,9],[3,5,9],[1,6,9],[2,6,9],[3,6,9]] it's only evaluated once. But if we think about what happens when we have n lists of lengths l1, ..., ln, there are l2*...*ln combinations of the tail. Each of these combinations is used l1 times, once for each element of the first list. However, between two uses of a particular combination, all the other (l2*...*ln-1) combinations are used once. If l2*...*ln is large, only a tiny fraction of the combinations of the tail fit in the memory at once, so they simply can't be reused and have to be recalculated each time (theoretically, a handful could be kept in memory for reuse). On the other hand, in aP2, each combination of the tail is of course also used l1 times, but these are in direct succession, and the combination has been bound to a name for the entire scope, it's practically guaranteed to be calculated only once and garbage collected once. By the way, if the order in which the combinations are generated matters: aP1 === map reverse . aP2 . reverse > > > aP2 [] = [[]] > > aP2 (h:t) = do > > xs <- aP2 t > > x <- h > > return (x:xs) > > > > now we first calculate the combinations of t, for each of those, we cons > > the elements of h to it in turn and never reuse it afterwards. > > Thanks for explaining. > > C. From miguelimo38 at yandex.ru Fri Dec 4 14:18:04 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Dec 4 13:52:41 2009 Subject: [Haskell-cafe] Is Haskell a Fanatic? In-Reply-To: <2AF3040F-59ED-42AB-B2A0-A57D35A6E01A@phys.washington.edu> References: <0CA53C0010AD4A37937BF39F085D394B@JohnPC> <20091203163946.GA17116@whirlpool.galois.com> <578A58BDF59C4FFDA6077F58A4BCD736@JohnPC> <3d96ac180912041000s3762590cq39d3e12f14f6d446@mail.gmail.com> <2AF3040F-59ED-42AB-B2A0-A57D35A6E01A@phys.washington.edu> Message-ID: Well, since he thinks we're fanatics, getting a strong emotional reaction from us is something one certainly wouldn't desire. On 4 Dec 2009, at 21:14, Gregory Crosswhite wrote: > Sebastian, > > It helps if you think of John as having already won in this > discussion, since he succeeded in getting a lengthy high-noise > emotional reaction from us. :-) > > Cheers, > Greg > > > On Dec 4, 2009, at 10:00 AM, Sebastian Sylvan wrote: > >> >> >> On Thu, Dec 3, 2009 at 5:09 PM, John D. Earle >> wrote: >> See "[Haskell-cafe] Optimization with Strings ?" for background. >> >> Don Stewart wrote, "the guarantees of purity the type system >> provides are extremely >> useful for verification purposes". My response to this is in >> theory. This is what caught my attention initially, but the >> language lacks polish and does not appear to be going in a >> direction where it shows signs where it will self-correct. It may >> even be beyond repair. I care about others and I don't want people >> to be misled. >> >> I am already well aware of the numbers. They do not impress me. I >> have written on this already. I have given Haskell the benefit of >> the doubt and said, What's wrong with being uncompromising? There >> is something wrong with it, if it has taken you off the path of >> truth. This is not uncompromising. This is something else. It is >> called fanaticism and this is the opinion that I have come to after >> due consideration. >> >> If you are going to argue your case, be constructive. Tell me how >> the type system is not flawed and how the Haskell language is >> rigorous. What proof do you have of this? Explain to me how Haskell >> has been merely uncompromising in its pursuit of perfection and did >> not manage to step over the threshold into fanaticism. Please >> remain on topic and on point. >> >> I honestly don't understand what your beef is. Could you explain >> what you mean with some specifics? In what way does Haskell lack >> polish? What makes you think it's not going in a direction where it >> will self correct? >> What's the "path of truth" and in what way is Haskell not on it? >> >> I would very much appreciate if you could try to explain what you >> mean using specific examples. I read the other thread and the post >> of yours didn't really seem to make much sense to me there either. >> >> -- >> Sebastian Sylvan >> _______________________________________________ >> 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 From functionallyharmonious at yahoo.com Fri Dec 4 14:20:06 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 13:54:42 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: Message-ID: <794708.12647.qm@web113104.mail.gq1.yahoo.com> Hi, portaudio is my?embarrassing?fault, but it does work most of the time. (Community, some one remind me to revisit this package after Christmas.) Are you running in Windows? Linux? If Linux, which flavor? /jve I'm using Haskell on XP but I dual boot with Ubuntu 9 and I'd prefer not to break compatibility. I'm new to this, was I supposed to install portaudio for my OS before downloading the Haskell package? Are there other similar simple sound apis? On Fri, Dec 4, 2009 at 1:51 PM, M Xyz wrote: What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? I think the portaudio library is the only contender but when I try to install it I get: >cabal install portaudio Resolving dependencies... Downloading portaudio-0.0.1... Configuring portaudio-0.0.1... cabal: Missing dependency on a foreign library: * Missing C library: portaudio This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the configure step. The exception was: exit: ExitFailure 1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/df60ee1b/attachment.html From vanenkj at gmail.com Fri Dec 4 14:23:16 2009 From: vanenkj at gmail.com (John Van Enk) Date: Fri Dec 4 13:57:54 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <794708.12647.qm@web113104.mail.gq1.yahoo.com> References: <794708.12647.qm@web113104.mail.gq1.yahoo.com> Message-ID: You'll have to install the portaudio C libraries and header files before continuing. I never actually tested the package on XP, if you get it to work, I'd love to hear your experience. /jve On Fri, Dec 4, 2009 at 2:20 PM, M Xyz wrote: > > > Hi, > > portaudio is my embarrassing fault, but it does work most of the time. > (Community, some one remind me to revisit this package after Christmas.) > > Are you running in Windows? Linux? If Linux, which flavor? > > /jve > > > I'm using Haskell on XP but I dual boot with Ubuntu 9 and I'd prefer not to > break compatibility. I'm new to this, was I supposed to install portaudio > for my OS before downloading the Haskell package? Are there other similar > simple sound apis? > > > > > On Fri, Dec 4, 2009 at 1:51 PM, M Xyz > > wrote: > >> >> What is the most minimal (preferably platform independent) library >> available for writing bytes to the sound card? I see 60 wonderful libraries >> on Hackage, but I really just need the Haskell equivalent of an >> audio.write(byte[]) method. What sound api are these 60 libraries using? >> >> I think the portaudio library is the only contender but when I try to >> install it I get: >> >> >cabal install portaudio >> Resolving dependencies... >> Downloading portaudio-0.0.1... >> Configuring portaudio-0.0.1... >> cabal: Missing dependency on a foreign library: >> * Missing C library: portaudio >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the library is >> already installed but in a non-standard location then you can use the >> flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >> cabal: Error: some packages failed to install: >> portaudio-0.0.1 failed during the configure step. The exception was: >> exit: ExitFailure 1 >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/2dd651d6/attachment.html From paul at cogito.org.uk Fri Dec 4 14:23:29 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Fri Dec 4 13:58:07 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <4B18F7AE.4090303@pessce.net> References: <4B18F7AE.4090303@pessce.net> Message-ID: <4B1961B1.6090402@cogito.org.uk> On 04/12/09 11:51, Patrick Caldon wrote: > > I'm looking for the "right" concurrency library/semantics for what > should be a reasonably simple problem. > > I have a little simulator: > > runWorldSim :: MTGen -> SimState -> IO SimState > > it takes about a second to run on a PC. It's functional except it > whacks the rng, which needs IO. I run 5-10 of these jobs, and then use: > > mergeWorld :: [SimState] -> SimState > > to pick the best features of the runs and build another possible world > (state). Then I use this new world to run another 5-10 jobs and so > on. I run this through ~20000 iterations. > > It's an obvious place for parallelism. > If you can get rid of the need for IO then you can use Control.Parallel to evaluate pure functions instead. If you only use IO for the random numbers then you can either keep a StdGen in your SimState or else use a "State StdGen" monad. Since your random number use is presumably already in monadic IO you could probably switch to a state monad fairly trivially. Paul. From gcross at phys.washington.edu Fri Dec 4 14:26:13 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Fri Dec 4 14:02:32 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: Blueprint 0.1 -- PREVIEW In-Reply-To: References: Message-ID: <2BCB5052-CE53-4ABE-A4E5-3E2DA2A0F444@phys.washington.edu> Yes, that is because at this time Blueprint is presently of a lower quality than other packages on Hackage. ;-) At the moment you need to execute the setup script manually: runhaskell Setup.hs bootstrap ./Setup configure ./Setup build +RTS -N4 -RTS ./Setup install (The "+RTS -N4 -RTS" part is optional; it just tells Setup to use up to 4 threads to do building in parallel where possible.) I have known about the problem that you just mentioned --- that is, although running "cabal configure" and "cabal build" in the build directory works just fine, "cabal install" does not work --- but because my .cabal file looked fine I assumed until now that it was just a quirk of the "cabal" program. I only just now figured out that to make "cabal install" work I need to make sure that the build dependencies are listed in the Library section rather than only in the main section, as otherwise cabal refuses to simply run "Setup install" even though that actually takes care of everything for it! Anyway, thank you for checking out Blueprint! At this point it might be better to pull the sources directly from github (the "Home Page" link) since I have made many improvements since that release (though I haven't fixed the "cabal install" problem yet). And I do plan on thoroughly polishing and documenting Blueprint one of these days. :-) Cheers, Greg On Dec 4, 2009, at 11:02 AM, Ben Franksen wrote: > Gregory Crosswhite wrote: >> I have posted Blueprint to Hackage so that people can see what I have done >> and possibly play with it. > > Very interesting, this. However, I could not build it. I get > > ben@sarun[2]: ~/tmp > cabal install blueprint > Resolving dependencies... > cabal: There is no installed version of base > > Needless to say this is wrong: > > ben@sarun[2]: ~/tmp > ghc-pkg list base > /usr/local/lib/ghc-6.10.4/./package.conf: > base-3.0.3.1, base-4.1.0.0 > /home/ben/.ghc/i386-linux-6.10.4/package.conf: > > This has not happened to me with any other packages from hackage. > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dave at zednenem.com Fri Dec 4 14:29:40 2009 From: dave at zednenem.com (David Menendez) Date: Fri Dec 4 14:04:16 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <20091204181423.GA1109@quaternion> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <1259845201.4896.103489.camel@localhost> <4B185C9C.6040706@freegeek.org> <20091204181423.GA1109@quaternion> Message-ID: <49a77b7a0912041129v443eee92md15d02c958123db9@mail.gmail.com> On Fri, Dec 4, 2009 at 1:14 PM, Jason McCarty wrote: > wren ng thornton wrote: > >> ? ? concat1 :: T a b -> (b -> T a b) -> T a b > > This could just as easily be > > ?concat :: T a b -> (b -> T a c) -> T a c > > right? It's a little weird to call this concatenation, but I bet it > could come in handy. T a is, among other things, the free monad for the functor (,) a. The concat you describe is the monadic bind. data T a b = D b | W a (T a b) instance Monad (T a) where return = D D b >>= f = f b W a t >>= f = W a (t >>= f) -- Dave Menendez From paul at cogito.org.uk Fri Dec 4 14:33:11 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Fri Dec 4 14:07:49 2009 Subject: [Haskell-cafe] seems like I'm on the wrong track In-Reply-To: <4B15C8F4.4020506@alumni.caltech.edu> References: <4B15BC69.1020101@alumni.caltech.edu> <4B15C8F4.4020506@alumni.caltech.edu> Message-ID: <4B1963F7.7070104@cogito.org.uk> On 02/12/09 01:55, Michael Mossey wrote: > I have a quite messy problem which is describable as a big state > machine, at least in the way I think of it. An input "event" can > trigger a cascade of changes to the state. Channel numbers must be > assigned and tracked, table numbers as well, decisions about whether > to create a new table or re-use an old one, global variables and > commands added and/or modified, etc. So I am hoping for a comment from > that perspective. First, I wonder if some of the ideas in Functional Reactive Programming might help; its a very clean and declarative way of dealing with messy event-based stuff like this. Second, more generally, for Haskell design you need to take a step back and think about the mathematical relations between things in your domain that an application programmer cares about. Then you can think about how to map from your domain model to an implementation like CSound. Paul. From functionallyharmonious at yahoo.com Fri Dec 4 14:49:49 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 14:24:33 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: Message-ID: <619187.27009.qm@web113112.mail.gq1.yahoo.com> > if you get it to work As a spoiled Java programmer, this new role as pioneer is a bit intimidating, but I will give it a shot. :) I downloaded the portaudio v19 source and I'm attempting to build it. Apparently I have to register my Visual Studio Express with Microsoft. Deeper down the rabbit hole... (Interesting aside, on the registration form under "What programming language topics are you interested in?" neither F# or Haskell are listed) I wish there was a multimedia standard library for beginners like me. Writing audio to the speakers shouldn't be such a journey. You'll have to install the portaudio C libraries and header files before continuing. I never actually tested the package on XP, if you get it to work, I'd love to hear your experience. /jve On Fri, Dec 4, 2009 at 2:20 PM, M Xyz wrote: Hi, portaudio is my?embarrassing?fault, but it does work most of the time. (Community, some one remind me to revisit this package after Christmas.) Are you running in Windows? Linux? If Linux, which flavor? /jve I'm using Haskell on XP but I dual boot with Ubuntu 9 and I'd prefer not to break compatibility. I'm new to this, was I supposed to install portaudio for my OS before downloading the Haskell package? Are there other similar simple sound apis? On Fri, Dec 4, 2009 at 1:51 PM, M Xyz wrote: What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? I think the portaudio library is the only contender but when I try to install it I get: >cabal install portaudio Resolving dependencies... Downloading portaudio-0.0.1... Configuring portaudio-0.0.1... cabal: Missing dependency on a foreign library: * Missing C library: portaudio This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the configure step. The exception was: exit: ExitFailure 1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/fe554724/attachment.html From jeremy at n-heptane.com Fri Dec 4 14:51:14 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Fri Dec 4 14:25:53 2009 Subject: [Haskell-cafe] SYB <> very, very mysteriously In-Reply-To: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> References: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> Message-ID: I have stripped things down to the bare minimum, and test under GHC 6.10, GHC 6.12, Linux, and Mac OS X. Results are consistent. In the following code, 1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine 2. if you change the gunfold instance for Proposition to, error "gunfold" it stops hanging -- even though this code is never called. 3. if you change, ( Data ctx [Expression], Sat (ctx Expression) => Data ctx Expression, to (Data ctx Expression, ....) => ... it stops hanging. If someone could explain why each of these cases perform as they do, that would be awesome! Right now it is a big mystery to me.. e calls dict .. and there is only one instance of dict available, which should call error right away. I can't see how something could get in the way there... - jeremy {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, RankNTypes, ScopedTypeVariables, KindSignatures, EmptyDataDecls, NoMonomorphismRestriction #-} module Main where import qualified Data.Data as Data import Data.Typeable --- syb-with-class data Constr = Constr deriving (Eq, Show) data Proxy (a :: * -> *) class Sat a where dict :: a class (Typeable a, Sat (ctx a)) => Data ctx a where gunfold :: Proxy ctx -> (forall b r. Data ctx b => c (b -> r) -> c r) -> (forall r. r -> c r) -> Constr -> c a instance (Sat (ctx [a]),Data ctx a) => Data ctx [a] --- Default class (Data DefaultD a) => Default a where defaultValue :: a data DefaultD a = DefaultD { defaultValueD :: a } instance Default t => Sat (DefaultD t) where dict = error "Sat (DefaultD t) not implemented" instance Default a => Default [a] where defaultValue = error "Default [a] not implemented" --- Trouble data Proposition = Proposition Expression deriving (Show, Data.Data, Typeable) data Expression = Conjunction Expression deriving (Show, Data.Data, Typeable) -- instance (Sat (ctx [Expression]), Sat (ctx Expression), Sat (ctx Proposition)) => Data ctx Proposition where instance Data DefaultD Proposition where gunfold _ k z c = k (z Proposition) -- gunfold _ k z c = error "gunfold" instance Default Proposition -- Change Data ctx [Expression] to Data ctx Expression and main works. instance ( Data ctx [Expression] , Sat (ctx Expression) ) => Data ctx Expression instance Default Expression e :: Expression e = defaultValueD (dict :: DefaultD Expression) main = print e From noteed at gmail.com Fri Dec 4 15:31:45 2009 From: noteed at gmail.com (minh thu) Date: Fri Dec 4 15:06:43 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <619187.27009.qm@web113112.mail.gq1.yahoo.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> Message-ID: <40a414c20912041231h6e9aaa57ub1bb9900239aede7@mail.gmail.com> 2009/12/4 M Xyz > > > if you get it to work > > As a spoiled Java programmer, this new role as pioneer is a bit intimidating, but I will give it a shot. :) > > I downloaded the portaudio v19 source and I'm attempting to build it. Apparently I have to register my Visual Studio Express with Microsoft. Deeper down the rabbit hole... (Interesting aside, on the registration form under "What programming language topics are you interested in?" neither F# or Haskell are listed) > > I wish there was a multimedia standard library for beginners like me. Writing audio to the speakers shouldn't be such a journey. Hi, Did you look at synthesizer ? There is a short introductory file [1]. Be sure to look at the source (there is a link next to each function definition). Outputting list of values is easy, for instance Play.monoToInt16 (44100::Double) (map sin [0::Double,0.1..]) It uses SoX [2], which should be installed. Cheers, Thu [1] http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/Synthesizer-Plain-Tutorial.html [2] http://sox.sourceforge.net/ From radek.micek at gmail.com Fri Dec 4 15:49:01 2009 From: radek.micek at gmail.com (Radek Micek) Date: Fri Dec 4 15:23:36 2009 Subject: [Haskell-cafe] Re: From function over expression (+, *) derive function over expression (+) In-Reply-To: <20091204181414.GB3316@rwbarton.mit.edu> References: <61f84eff0912040952t3f179f99xcd5153f671970769@mail.gmail.com> <20091204181414.GB3316@rwbarton.mit.edu> Message-ID: Thank you for your reply. If I understand this correctly I can use your solution to have functions which work on any subsets of constructors like in this example: {-# LANGUAGE GADTs, EmptyDataDecls #-} data Yes data No data AnyType a b c where A :: AnyType Yes b c B :: AnyType a Yes c C :: AnyType a b Yes func :: AnyType a b No -> String func A = "A" func B = "B" func2 :: AnyType No No c -> String func2 C = "C" On Dec 4, 7:14?pm, Reid Barton wrote: > On Fri, Dec 04, 2009 at 11:52:35AM -0600, Derek Elkins wrote: > > On Fri, Dec 4, 2009 at 11:26 AM, Radek Micek wrote: > > > Hello. > > > > I have two types for expression: > > > > data Expr = Add Expr Expr | Mul Expr Expr | Const Int > > > > data AExpr = AAdd AExpr AExpr | AConst Int > > > > The first one supports addition and multiplication and the second > > > only addition. > > > > I can write a function to simplify the first expression: > > > > simplify :: Expr -> Expr > > > simplify = {- replaces: > > > "a*1" and "1*a" by "a", > > > "a+0" and "0+a" by a -} > > > > And I would like to use the function simplify for the second type > > > AExpr. What can I do is to convert AExpr to Expr, simplify it and > > > convert it back. But I don't like this solution because > > > conversions take some time. > > > > I would prefer following: I say to the compiler that AAdd is like Add > > > and AConst is like Const and the compiler derives function > > > asimplify for AExpr. > > > > Is it possible to do this? In fact I want to have two distinct types > > > where one is "extension" of the second (Expr is extension of AExpr) > > > and I want to define a function for the extended type (Expr) and > > > use it for the original type (AExpr). I assume that the function won't > > > introduce Mul to the expression which had no Mul. > > > What you'd ideally want is called refinement types which Haskell, and > > as far as I know, no practical language has. ?There is a paper about a > > way to encode these, but it is fairly heavy-weight. ?You could use > > phantom type trickery to combine the data types into one type but > > still statically check that only additive expressions are passed to > > certain functions, but that too is also probably more trouble than > > it's worth. > > In this particular case, with only two types Expr and AExpr, the > encoding is not particularly onerous. > > {-# LANGUAGE GADTs, EmptyDataDecls, ViewPatterns #-} > > data M > data Blah > > -- A value of type 'E a' can only involve multiplication when a is M > data E a where > ? Const :: Int -> E a > ? Add :: E a -> E a -> E a > ? Mul :: E M -> E M -> E M > > type Expr = E M > type AExpr = E Blah > > -- The same simplify function we would write for the original Expr, > -- with a different type > simplify :: E a -> E a > simplify (Const x) = Const x > simplify (Add (simplify -> a) (simplify -> b)) = case (a, b) of > ? (Const 0, _) -> b > ? (_, Const 0) -> a > ? _ -> Add a b > simplify (Mul (simplify -> a) (simplify -> b)) = case (a, b) of > ? (Const 1, _) -> b > ? (_, Const 1) -> a > ? _ -> Mul a b > > Regards, > Reid Barton > _______________________________________________ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe From jgm at berkeley.edu Fri Dec 4 16:09:57 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Fri Dec 4 15:45:58 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: References: Message-ID: <20091204210957.GA14889@protagoras.phil.berkeley.edu> > On Mon, Nov 23, 2009 at 12:29 PM, Antoine Latter wrote: > I finally had some time to test it. After running it multiple times > (of course, it would be nice to use criterion here), I'm getting > numbers in this neighborhood: > I used criterion to compare pandoc compiled with parsec2 to pandoc compiled with your version of parsec3. (The benchmark is converting testsuite.txt from markdown to HTML.) The difference was minor: parsec2: mean: 67.66576 ms, lb 67.56722 ms, ub 67.88983 ms, ci 0.950 std dev: 722.3878 us, lb 323.0343 us, ub 1.356013 ms, ci 0.950 parsec3: mean: 68.20847 ms, lb 68.16387 ms, ub 68.26284 ms, ci 0.950 std dev: 252.7773 us, lb 204.5512 us, ub 325.2424 us, ci 0.950 So, once you release the new parsec3, I am prepared to remove the "parsec < 3" restriction from the libraries I maintain: pandoc, highlighting-kate, filestore, gitit, and yst. John From caseyh at istar.ca Fri Dec 4 16:25:29 2009 From: caseyh at istar.ca (Casey Hawthorne) Date: Fri Dec 4 16:00:17 2009 Subject: [Haskell-cafe] Are there major inefficiencies in Haskell compared to OCaml? Message-ID: Are there major inefficiencies in Haskell compared to OCaml? If so, can something be done about them? -- Regards, Casey From dons at galois.com Fri Dec 4 16:29:05 2009 From: dons at galois.com (Don Stewart) Date: Fri Dec 4 16:03:42 2009 Subject: [Haskell-cafe] Are there major inefficiencies in Haskell compared to OCaml? In-Reply-To: References: Message-ID: <20091204212905.GK22945@whirlpool.galois.com> caseyh: > Are there major inefficiencies in Haskell compared to OCaml? > If so, can something be done about them? Can you be more specific? Looking at the u64q shootout: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=ocaml&box=1 Shows the two implementations tied for memory, and code size, but Haskell winning the speed tests more often. -- Don From moonpatio at gmail.com Fri Dec 4 16:32:26 2009 From: moonpatio at gmail.com (Matt Morrow) Date: Fri Dec 4 16:07:03 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> Message-ID: <1bc51a990912041332w3ffcd384x626bcdc41d2a269b@mail.gmail.com> Although, in Luke's example, > x = sum [1..10^6] + product [1..10^6] > x' = let l = [1..10^6] in sum l + product l We can do much much better, if we're sufficiently smart. -- Define: bar m n = foo (enumFromTo m n) foo xs = sum xs + prod xs -- We're given: sum = foldl (+) 0 product = foldl (*) 1 foldl f z xs = case xs of [] -> [] x:xs -> foldl f (f z x) xs enumFromTo m n = case m < n of True -> [] False -> m : enumFromTo (m+1) n -- The fused loop becomes: foo xs = go0 0 1 xs where go0 a b xs = case xs of [] -> a+b x:xs -> go0 (a+x) (b*x) xs -- Now inline foo in bar: bar m n = go2 0 1 m n where go2 = go0 a b (go1 m n) go0 a b xs = case xs of [] -> a+b x:xs -> go0 (a+x) (b*x) xs go1 m n = case m < n of True -> [] False -> m : go1 (m+1) n -- considering go2 go2 = go0 a b (go1 m n) ==> case (go1 m n) of [] -> a+b x:xs -> go0 (a+x) (b*x) xs ==> case (case m < n of True -> [] False -> m : go1 (m+1) n) of [] -> a+b x:xs -> go0 (a+x) (b*x) xs ==> case m < n of True -> case [] of [] -> a+b x:xs -> go0 (a+x) (b*x) xs False -> case (m : go1 (m+1) n) of [] -> a+b x:xs -> go0 (a+x) (b*x) xs ==> case m < n of True -> a+b False -> go0 (a+m) (b*m) (go1 (m+1) n) -- So, go2 = case m < n of True -> a+b False -> go0 (a+m) (b*m) (go1 (m+1) n) -- And by the original def of go2 go2 = go0 a b (go1 m n) -- We get go2 = case m < n of True -> a+b False -> go2 (a+m) (b*m) (m+1) n -- go0 and go1 and now dead in bar bar m n = go2 0 1 m n where go2 = case m < n of True -> a+b False -> go2 (a+m) (b*m) (m+1) n -- (furthermore, if (+) here is for Int/Double etc, -- we can reduce go2 further to operate on machine -- ints/doubles and be a register-only non-allocating loop) -- So now finally returning to our original code: > x = sum [1..10^6] + product [1..10^6] > x' = let l = [1..10^6] in sum l + product l -- We get: x' = bar 1 (10^6) And the intermediate list never exists at all. Matt On 12/4/09, Luke Palmer wrote: > On Fri, Dec 4, 2009 at 3:36 AM, Neil Brown wrote: >> But let's say you have: >> >> g x y = f x y * f x y >> >> Now the compiler (i.e. at compile-time) can do some magic. It can spot >> the >> common expression and know the result of f x y must be the same both >> times, >> so it can convert to: >> >> g x y = let z = f x y in z * z > > GHC does *not* do this by default, quite intentionally, even when > optimizations are enabled. The reason is because it can cause major > changes in the space complexity of a program. Eg. > > x = sum [1..10^6] + product [1..10^6] > x' = let l = [1..10^6] in sum l + product l > > x runs in constant space, but x' keeps the whole list in memory. The > CSE here has actually wasted both time and space, since it is harder > to save [1..10^6] than to recompute it! (Memory vs. arithmetic ops) > > So GHC leaves it to the user to specify sharing. If you want an > expression shared, let bind it and reuse. > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From rick.richardson at gmail.com Fri Dec 4 16:35:38 2009 From: rick.richardson at gmail.com (Rick R) Date: Fri Dec 4 16:10:13 2009 Subject: [Haskell-cafe] Are there major inefficiencies in Haskell compared to OCaml? In-Reply-To: References: Message-ID: <9810b81b0912041335y23c67d02s8918878dad839e6c@mail.gmail.com> On Fri, Dec 4, 2009 at 4:25 PM, Casey Hawthorne wrote: > Are there major inefficiencies in Haskell compared to OCaml? > If so, can something be done about them? > There are definitely some gotchas when it comes to performance, mostly in the realm of inadvertent space leaks and such. But that's just it, they are gotchas. A new haskeller will no doubt encounter them, but they are generally simple to fix. When Haskell and Ocaml are coded by their respective experts, I would, in general, trust Haskell to be faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/71db5005/attachment.html From porges at porg.es Fri Dec 4 16:44:50 2009 From: porges at porg.es (George Pollard) Date: Fri Dec 4 16:19:44 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <2518b95d0912032032p2e306912xb165819191d46b5@mail.gmail.com> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <2518b95d0912032032p2e306912xb165819191d46b5@mail.gmail.com> Message-ID: <6d942a4a0912041344l22e45406w403b856298f06584@mail.gmail.com> 2009/12/4 Evan Laforge : > The interesting thing is CAFs, which at the top level will never be > out of scope and hence live forever. Untrue! CAFs can be garbage collected as well. See: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-September/009051.html From mle+hs at mega-nerd.com Fri Dec 4 16:50:17 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Fri Dec 4 16:24:54 2009 Subject: [Haskell-cafe] Are there major inefficiencies in Haskell compared to OCaml? In-Reply-To: References: Message-ID: <20091205085017.bdcecc68.mle+hs@mega-nerd.com> Casey Hawthorne wrote: > Are there major inefficiencies in Haskell compared to OCaml? As a five plus year veteran of Ocaml and a one year user of Haskell I would say in general no. However, Ocaml's strict evaluation makes it easy for someone new to the language to have a pretty accurate guess about its run time and memory usage something which can be difficult in the face of Haskell's lazy evaluation (not that I have experienced any obvious manifestations of this myself). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From functionallyharmonious at yahoo.com Fri Dec 4 17:00:59 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 16:35:35 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <40a414c20912041231h6e9aaa57ub1bb9900239aede7@mail.gmail.com> Message-ID: <754017.91628.qm@web113102.mail.gq1.yahoo.com> Did you look at synthesizer ? There is a short introductory file [1]. Cheers, Thu [1] http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/Synthesizer-Plain-Tutorial.html Thanks for the tutorial link. As I'm new to Haskell, these 2 lines got me thinking: "Using plain lists is not very fast" and "Getting real-time performance is mostly an issue of the right signal data structure." What do you use as an efficient byte buffer in a value-oriented language? The array tutorial says "Obviously, a naive implementation of such an array semantics would be intolerably inefficient, either requiring a new copy of an array for each incremental redefinition, or taking linear time for array lookup; thus, serious attempts at using this approach employ sophisticated static analysis and clever run-time devices to avoid excessive copying." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/cdef5f35/attachment.html From mikesteele81 at gmail.com Fri Dec 4 17:03:42 2009 From: mikesteele81 at gmail.com (Michael Steele) Date: Fri Dec 4 16:38:18 2009 Subject: [Haskell-cafe] Greetings! 2D Graphics? In-Reply-To: <7ca3f0160912040007p251808f3oc353d0bef511899c@mail.gmail.com> References: <868304.88343.qm@web113112.mail.gq1.yahoo.com> <7ca3f0160912040007p251808f3oc353d0bef511899c@mail.gmail.com> Message-ID: > I admit author's bias, but I suggest graphics-drawingcombinators. It is a > 2D drawing library based on OpenGL with a pure interface (no IO, except to > finally render your drawing), and supports all the stuff you want except > clipping. > > It uses the SDL bindings, which I have heard are not easy to > install on windows, but go smooth as a baby's bottom on ubuntu. > > Luke I'll second this. I started using graphics-drawingcombinators about a month ago so I could easily convert SDL Surfaces into 2D sprites within OpenGL. The entire haddock synopsis fits on a single browser page, making it extremely easily to start using and build off of. You might also want to take a look at Conrad Barski's picnic tutorial at http://www.lisperati.com/haskell/, where he does some work with 2D graphics by generating .svg files. -- Michael Steele. From bos at serpentine.com Fri Dec 4 17:30:10 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Dec 4 17:04:45 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: <221b53ab0912040839i76725f9l28ad512864a8c534@mail.gmail.com> References: <87aaxzcs0p.fsf@gregorycollins.net> <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> <562B3367-F0F8-4266-9D44-4F9E5B665961@z.odi.ac> <221b53ab0912040839i76725f9l28ad512864a8c534@mail.gmail.com> Message-ID: On Fri, Dec 4, 2009 at 8:39 AM, Svein Ove Aas wrote: > > That said.. you say you have to handle the events "fast". What happens > if you don't? If you don't handle events quickly, they're typically thrown away by the kernel without you ever getting to read them. That is, for instance, what happens on Linux with inotify. Throwing away events means that your app's internal mirror of the filesystem state becomes wrong, which is Very Bad for most applications that care. (i.e. Ross's assertion than nothing bad will happen is generally not true.) *However*, with inotify you *also* can't afford to perform a single read system call per event, because that will cause your "watch the filesystem" event to soak up most of the system's CPU time. So what you have to do is select to listen for "there's an event ready to be read", then sleep a little while, *then* read in the hope that many (but not too many!) events will have been queued that you can all read at once. And at that point, you'll be getting a stale notification about a file or directory that may no longer even exist, or may have changed type. Consider: I create a file f, write data into it, rename it to g, then create a directory named f. You wake up 10 milliseconds later, and the first event you hear about is that a file named f was created. This is all by way of saying that working with filesystem change notification interfaces is extremely subtle and tricky, enormously more so than you'd think on casual inspection. It's very easy to write a program that uses these interfaces in ways that will make it either generate garbage or consume huge amounts of CPU, and in fact the common case is to write a program that does both. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/5d573816/attachment.html From rmm-haskell at z.odi.ac Fri Dec 4 17:46:16 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Fri Dec 4 17:20:55 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: References: <87aaxzcs0p.fsf@gregorycollins.net> <3e1162e60912040808r20f73707u7629a5b5a16baba3@mail.gmail.com> <562B3367-F0F8-4266-9D44-4F9E5B665961@z.odi.ac> <221b53ab0912040839i76725f9l28ad512864a8c534@mail.gmail.com> Message-ID: <91899621-1F6C-4C00-86BF-4A5F9659A15B@z.odi.ac> On Dec 4, 2009, at 5:30 PM, Bryan O'Sullivan wrote: > On Fri, Dec 4, 2009 at 8:39 AM, Svein Ove Aas > wrote: > > That said.. you say you have to handle the events "fast". What happens > if you don't? > > If you don't handle events quickly, they're typically thrown away by > the kernel without you ever getting to read them. That is, for > instance, what happens on Linux with inotify. Throwing away events > means that your app's internal mirror of the filesystem state > becomes wrong, which is Very Bad for most applications that care. > (i.e. Ross's assertion than nothing bad will happen is generally not > true.) Ah hah yeah, I meant in the context of it won't block the kernel or cause your computer to melt. It varies between applications whether dropping events is bad or not so I wasn't commenting there. > However, with inotify you also can't afford to perform a single read > system call per event, because that will cause your "watch the > filesystem" event to soak up most of the system's CPU time. So what > you have to do is select to listen for "there's an event ready to be > read", then sleep a little while, then read in the hope that many > (but not too many!) events will have been queued that you can all > read at once. > > And at that point, you'll be getting a stale notification about a > file or directory that may no longer even exist, or may have changed > type. Consider: I create a file f, write data into it, rename it to > g, then create a directory named f. You wake up 10 milliseconds > later, and the first event you hear about is that a file named f was > created. > > This is all by way of saying that working with filesystem change > notification interfaces is extremely subtle and tricky, enormously > more so than you'd think on casual inspection. It's very easy to > write a program that uses these interfaces in ways that will make it > either generate garbage or consume huge amounts of CPU, and in fact > the common case is to write a program that does both. Amen. I've written an application that does this kind of work using inotify and it was a nightmare. I think this is why fseventsd was invented for OS X, and I'm not sure if there's any linux equivalent. However, if someone were to write a library that uses kqueue / inotify / win32-call-I-forget-the-name-of-from-earlier-post in a way that is both efficient and correct, that would be totally awesome. -Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/faaa0a79/attachment.html From functionallyharmonious at yahoo.com Fri Dec 4 17:53:43 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 17:28:18 2009 Subject: [Haskell-cafe] Are there major inefficiencies in Haskell compared to OCaml? In-Reply-To: <20091205085017.bdcecc68.mle+hs@mega-nerd.com> Message-ID: <561381.80117.qm@web113108.mail.gq1.yahoo.com> However, Ocaml's strict evaluation makes it easy for someone new to the language to have a pretty accurate guess about its run time and memory usage something which can be difficult in the face of Haskell's lazy evaluation (not that I have experienced any obvious manifestations of this myself). Erik Speaking as "someone new to the language", this is one subject that confused me while reading RWH. They kept using the phrase "space leak" and I would think "Well, I understand that with laziness one simple call could trigger an explosion of calculations but how is that a 'leak'?" I had to go back and reread that section before I realized that the laziness was implemented as *runtime thunks* and I finally understood why they called it a "leak". Looking back I think they did a good job explaining it after all, I just totally missed it the first time through. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/668bd491/attachment.html From martijn at van.steenbergen.nl Fri Dec 4 18:00:23 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Fri Dec 4 17:35:01 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) In-Reply-To: <7ca3f0160912040950mee1f72dp8d8981b440339688@mail.gmail.com> References: <7ca3f0160912040950mee1f72dp8d8981b440339688@mail.gmail.com> Message-ID: <4B199487.7080008@van.steenbergen.nl> Luke Palmer wrote: > On Fri, Dec 4, 2009 at 10:26 AM, Radek Micek wrote: >> Hello. >> >> I have two types for expression: >> >> data Expr = Add Expr Expr | Mul Expr Expr | Const Int >> >> data AExpr = AAdd AExpr AExpr | AConst Int >> >> The first one supports addition and multiplication and the second >> only addition. >> >> I can write a function to simplify the first expression: >> >> simplify :: Expr -> Expr >> simplify = {- replaces: >> "a*1" and "1*a" by "a", >> "a+0" and "0+a" by a -} >> >> And I would like to use the function simplify for the second type >> AExpr. What can I do is to convert AExpr to Expr, simplify it and >> convert it back. But I don't like this solution because >> conversions take some time. > > Well there are more involved reasons than simply the conversion taking > time. If you would like the type system on your side, you have a > decent modeling problem on your hands. How can you guarantee that > simplify will return a type that will "fit" in AExpr? Simplify might > turn "a+a" into "2*a", and then your trick no longer works. It would > seem that you need to typecheck the function twice. > > You could attempt to go the other way, i.e. define a simplify on AExpr > and map to and from Expr, but that will have trouble with expressions > like 0+(2*a), because 2*a has no representation in AExpr. > > My hunch is that to do this "properly", you need to use some of the > fixed point modeling that I can't find the paper about (!) (It's > popular, someone please chime in :-). I.e. define a data type which, > directed by type classes, may or may not support multiplication. Then > define separately an additive simplifier and a multiplicative > simplifier on that. Perhaps you're looking for: Wouter Swierstra Data types ? la carte http://www.cse.chalmers.se/~wouter/Publications/DataTypesALaCarte.pdf Groetjes, Martijn. From moonpatio at gmail.com Fri Dec 4 18:03:00 2009 From: moonpatio at gmail.com (Matt Morrow) Date: Fri Dec 4 17:37:36 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: References: Message-ID: <1bc51a990912041503l26afc788t340e0bce307edf23@mail.gmail.com> Conal, If I were looking to do this, I'd read the relevant parts of the libev code. Matt On 12/3/09, Conal Elliott wrote: > I'd like to make some FRPish toys that keep files updated to have functional > relationships with other files. hinotify looks like just the sort of > underlying magic I could use for efficient implementation on linux. Is > there any support for mac os x? Could support be either added to hinotify > or maybe inotify and a mac-friendly library be abstracted into a common > Haskell interface? I'm fine with an imperative interface, since I can > abstract into a functional library, which I guess would be a sort of > persistent simplified FRP. > > - Conal > From jwlato at gmail.com Fri Dec 4 18:28:03 2009 From: jwlato at gmail.com (John Lato) Date: Fri Dec 4 18:02:39 2009 Subject: [Haskell-cafe] Re: Low Level Audio - Writing bytes to the sound card? Message-ID: <9979e72e0912041528o6ece9c66u29e8be8b4394c97d@mail.gmail.com> > From: M Xyz > >> if you get it to work > > As a spoiled Java programmer, this new role as pioneer is a bit intimidating, but I will give it a shot. :) > > I downloaded the portaudio v19 source and I'm attempting to build it. Apparently I have to register my Visual Studio Express with Microsoft. Deeper down the rabbit hole... (Interesting aside, on the registration form under "What programming language topics are you interested in?" neither F# or Haskell are listed) For doing cross-platform development, I would strongly recommend that you use MinGW (or cygwin) in preference to Visual Studio Express. This is because most Unix/Linux packages, and thus most cross-platform packages, are designed to be built with the GNU compiler toolchain (i.e. configure, make, make install), and getting them to work with Visual Studio can be a chore. I also would use PortAudio for what you describe, and have had good experience with it on OSX. Sox is a good choice as well if you don't mind piping output to another program. *shameless plug* you could also use hCsound, although it's probably higher-level than what you're looking for. Installing on Windows is tricky too, but you only need to do so once. John From bos at serpentine.com Fri Dec 4 18:30:44 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Dec 4 18:05:20 2009 Subject: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ... In-Reply-To: <1259941118.4778.275.camel@localhost> References: <4B18F7AE.4090303@pessce.net> <1259941118.4778.275.camel@localhost> Message-ID: On Fri, Dec 4, 2009 at 7:38 AM, Duncan Coutts wrote: > Wait! This is not going to work! > > You cannot use the MTGen from the mersenne-random in a concurrent IO > program because the C code uses a single global mutable RNG state. So use the PRNG in the statistics package instead. It's got some nice features that make it a better choice than mersenne-random for essentially all uses: - Faster than mersenne-random - State is encapsulated, so you can have independent PRNGs in different threads or different library modules - You can easily seed independent generators from your system's high-quality PRNG It can also generate normally distributed numbers as well as uniformly distributed numbers (which is all that mersenne-random gives you), and it uses a high-quality fast algorithm for the normal distribution, rather than the usual ziggurat which is somewhat broken. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/24af4b8b/attachment.html From martijn at van.steenbergen.nl Fri Dec 4 18:48:31 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Fri Dec 4 18:23:06 2009 Subject: [Haskell-cafe] From function over expression (+, *) derive function over expression (+) In-Reply-To: References: Message-ID: <4B199FCF.2020408@van.steenbergen.nl> Hi Radek, Radek Micek wrote: > I can write a function to simplify the first expression: > > simplify :: Expr -> Expr > simplify = {- replaces: > "a*1" and "1*a" by "a", > "a+0" and "0+a" by a -} > > And I would like to use the function simplify for the second type > AExpr. What can I do is to convert AExpr to Expr, simplify it and > convert it back. But I don't like this solution because > conversions take some time. Like Luke said, you can probably work out something using explicit fixed points. Or you can "cheat" a little and use generic programming: > {-# LANGUAGE DeriveDataTypeable #-} > > import Data.Generics > > data AddExpr = Const Int | Add AddExpr AddExpr > deriving (Eq, Show, Typeable, Data) > > data MulExpr = AddMul AddExpr | Mul MulExpr MulExpr > deriving (Eq, Show, Typeable, Data) Here you have explicitly encoded MulExpr as an extension of AddExpr through the constructor AddMul, just like you asked. Now we define the simplification steps you mentioned, one for each datatype. They perform only one simplification step instead of calling themselves recursively. The type of simplifyAddStep ensures that it doesn't accidentally introduce multiplications: > simplifyAddStep :: AddExpr -> AddExpr > simplifyAddStep expr = case expr of > Add (Const 0) y -> y > Add x (Const 0) -> x > _ -> expr > > simplifyMulStep :: MulExpr -> MulExpr > simplifyMulStep expr = case expr of > Mul (AddMul (Const 1)) x -> x > Mul x (AddMul (Const 1)) -> x > _ -> expr Using generic programming, we can combine these two steps and apply them recursively on entire trees, bottom-up: > simplify :: Data a => a -> a > simplify = everywhere (id `extT` simplifyAddStep `extT` simplifyMulStep) An example invocation: > *Main> simplify (AddMul (Const 1) `Mul` (AddMul (Const 2 `Add` Const 0))) > AddMul (Const 2) Hope this helps, Martijn. From functionallyharmonious at yahoo.com Fri Dec 4 19:23:01 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Fri Dec 4 18:57:36 2009 Subject: [Haskell-cafe] Re: Low Level Audio - Writing bytes to the sound card? In-Reply-To: <9979e72e0912041528o6ece9c66u29e8be8b4394c97d@mail.gmail.com> Message-ID: <770427.53837.qm@web113104.mail.gq1.yahoo.com> For doing cross-platform development, I would strongly recommend that you use MinGW (or cygwin) in preference to Visual Studio Express. MinGW is installed on our computers at work and its nice to work with. I tried installing it 2 years ago at home and I made a mess of it and gave up. I will certainly revisit it. Thanks. I also would use PortAudio for what you describe, and have had good experience with it on OSX.? That's reassuring! I finished compiling PortAudio on XP today, I'm just having trouble doing the Cabal install. I made a portaudio_x86.lib and .dll and blindly tried: >cabal install portaudio --extra-include-dirs=...\portaudio\include --extra-lib-dirs=...\portaudio\build\msvc\Win32\Release Where ... is the actual path shortened here. JVE has been kind to let me email him for help. *shameless plug* you could also use hCsound, although it's probably higher-level than what you're looking for.? Installing on Windows is tricky too, but you only need to do so once. John Seriously, I can't wait to play with all these Haskell libraries. As a beginner though I'm trying to work my way through the simple stuff yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091204/9c9ed22c/attachment.html From lemming at henning-thielemann.de Fri Dec 4 19:42:22 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Dec 4 19:13:54 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <754017.91628.qm@web113102.mail.gq1.yahoo.com> References: <754017.91628.qm@web113102.mail.gq1.yahoo.com> Message-ID: <4B19AC6E.4060104@henning-thielemann.de> M Xyz schrieb: > > Did you look at synthesizer ? There is a short introductory file [1]. > Cheers, > Thu > > [1] > http://hackage.haskell.org/packages/archive/synthesizer-core/0.2.1/doc/html/Synthesizer-Plain-Tutorial.html > > Thanks for the tutorial link. As I'm new to Haskell, these 2 lines got > me thinking: "Using plain lists is not very fast" and "Getting real-time > performance is mostly an issue of the right signal data structure." What > do you use as an efficient byte buffer in a value-oriented language? I have written some more details on it: http://hackage.haskell.org/packages/archive/synthesizer/0.2.0.1/doc/html/Synthesizer-Storage.html But I think that's not something one should start with ... http://www.haskell.org/haskellwiki/Sound_data_structures From moonpatio at gmail.com Fri Dec 4 19:51:17 2009 From: moonpatio at gmail.com (Matt Morrow) Date: Fri Dec 4 19:25:52 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <1bc51a990912041332w3ffcd384x626bcdc41d2a269b@mail.gmail.com> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> <1bc51a990912041332w3ffcd384x626bcdc41d2a269b@mail.gmail.com> Message-ID: <1bc51a990912041651s49059e31u784ba2e9f701f8b5@mail.gmail.com> Fixing my errors: > x = sum [1..10^6] + product [1..10^6] > x' = let l = [1..10^6] in sum l + product l -- Define: bar m n = foo (enumFromTo m n) foo xs = sum xs + prod xs -- We're given: sum = foldl (+) 0 product = foldl (*) 1 foldl f z xs = case xs of [] -> [] x:xs -> foldl f (f z x) xs enumFromTo m n = case n < m of True -> [] False -> m : enumFromTo (m+1) n -- The fused loop becomes: foo xs = go0 0 1 xs where go0 a b xs = case xs of [] -> a+b x:xs -> go0 (a+x) (b*x) xs -- Now inline foo in bar: bar m n = go2 0 1 m n where go2 a b m n = go0 a b (go1 m n) go0 a b xs = case xs of [] -> a+b x:xs -> go0 (a+x) (b*x) xs go1 m n = case m < n of True -> [] False -> m : go1 (m+1) n -- considering go2 go2 a b m n = go0 a b (go1 m n) ==> case (go1 m n) of [] -> a+b x:xs -> go0 (a+x) (b*x) xs ==> case (case n < m of True -> [] False -> m : go1 (m+1) n) of [] -> a+b x:xs -> go0 (a+x) (b*x) xs ==> case n < m of True -> case [] of [] -> a+b x:xs -> go0 (a+x) (b*x) xs False -> case (m : go1 (m+1) n) of [] -> a+b x:xs -> go0 (a+x) (b*x) xs ==> case n < m of True -> a+b False -> go0 (a+m) (b*m) (go1 (m+1) n) -- So, go2 a b m n = case n < m of True -> a+b False -> go0 (a+m) (b*m) (go1 (m+1) n) -- And by the original def of go2 go2 a b m n = go0 a b (go1 m n) -- We get go2 a b m n = case m < n of True -> a+b False -> go2 (a+m) (b*m) (m+1) n -- go0 and go1 and now dead in bar bar m n = go2 0 1 m n where go2 a b m n = case n < m of True -> a+b False -> go2 (a+m) (b*m) (m+1) n -- (furthermore, if (+) here is for Int/Double etc, -- we can reduce go2 further to operate on machine -- ints/doubles and be a register-only non-allocating loop) -- So now finally returning to our original code: > x = sum [1..10^6] + product [1..10^6] > x' = let l = [1..10^6] in sum l + product l -- We get: x' = bar 1 (10^6) Matt On 12/4/09, Matt Morrow wrote: > Although, in Luke's example, > >> x = sum [1..10^6] + product [1..10^6] >> x' = let l = [1..10^6] in sum l + product l > > We can do much much better, if we're sufficiently smart. > > -- Define: > bar m n = foo (enumFromTo m n) > foo xs = sum xs + prod xs > > -- We're given: > sum = foldl (+) 0 > product = foldl (*) 1 > foldl f z xs = > case xs of > [] -> [] > x:xs -> foldl f (f z x) xs > enumFromTo m n = > case m < n of > True -> [] > False -> m : enumFromTo (m+1) n > > -- The fused loop becomes: > foo xs = go0 0 1 xs > where go0 a b xs = > case xs of > [] -> a+b > x:xs -> go0 (a+x) (b*x) xs > > -- Now inline foo in bar: > bar m n = go2 0 1 m n > where go2 = go0 a b (go1 m n) > go0 a b xs = > case xs of > [] -> a+b > x:xs -> go0 (a+x) (b*x) xs > go1 m n = > case m < n of > True -> [] > False -> m : go1 (m+1) n > > -- considering go2 > go2 = go0 a b (go1 m n) > > ==> case (go1 m n) of > [] -> a+b > x:xs -> go0 (a+x) (b*x) xs > > ==> case (case m < n of > True -> [] > False -> m : go1 (m+1) n) of > [] -> a+b > x:xs -> go0 (a+x) (b*x) xs > > ==> case m < n of > True -> case [] of > [] -> a+b > x:xs -> go0 (a+x) (b*x) xs > > False -> case (m : go1 (m+1) n) of > [] -> a+b > x:xs -> go0 (a+x) (b*x) xs > > ==> case m < n of > True -> a+b > False -> go0 (a+m) (b*m) (go1 (m+1) n) > > -- So, > go2 = case m < n of > True -> a+b > False -> go0 (a+m) (b*m) (go1 (m+1) n) > > -- And by the original def of go2 > go2 = go0 a b (go1 m n) > > -- We get > go2 = case m < n of > True -> a+b > False -> go2 (a+m) (b*m) (m+1) n > > -- go0 and go1 and now dead in bar > bar m n = go2 0 1 m n > where go2 = case m < n of > True -> a+b > False -> go2 (a+m) (b*m) (m+1) n > > -- (furthermore, if (+) here is for Int/Double etc, > -- we can reduce go2 further to operate on machine > -- ints/doubles and be a register-only non-allocating loop) > > -- So now finally returning to our original code: >> x = sum [1..10^6] + product [1..10^6] >> x' = let l = [1..10^6] in sum l + product l > > -- We get: > x' = bar 1 (10^6) > > And the intermediate list never exists at all. > > Matt > > > > > On 12/4/09, Luke Palmer wrote: >> On Fri, Dec 4, 2009 at 3:36 AM, Neil Brown wrote: >>> But let's say you have: >>> >>> g x y = f x y * f x y >>> >>> Now the compiler (i.e. at compile-time) can do some magic. It can spot >>> the >>> common expression and know the result of f x y must be the same both >>> times, >>> so it can convert to: >>> >>> g x y = let z = f x y in z * z >> >> GHC does *not* do this by default, quite intentionally, even when >> optimizations are enabled. The reason is because it can cause major >> changes in the space complexity of a program. Eg. >> >> x = sum [1..10^6] + product [1..10^6] >> x' = let l = [1..10^6] in sum l + product l >> >> x runs in constant space, but x' keeps the whole list in memory. The >> CSE here has actually wasted both time and space, since it is harder >> to save [1..10^6] than to recompute it! (Memory vs. arithmetic ops) >> >> So GHC leaves it to the user to specify sharing. If you want an >> expression shared, let bind it and reuse. >> >> Luke >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From tanimoto at arizona.edu Fri Dec 4 20:47:34 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Fri Dec 4 20:22:27 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: <20091204210957.GA14889@protagoras.phil.berkeley.edu> References: <20091204210957.GA14889@protagoras.phil.berkeley.edu> Message-ID: Hi John, On Fri, Dec 4, 2009 at 3:09 PM, John MacFarlane wrote: > > I used criterion to compare pandoc compiled with parsec2 to > pandoc compiled with your version of parsec3. ?(The benchmark > is converting testsuite.txt from markdown to HTML.) The difference was > minor: > > parsec2: > mean: 67.66576 ms, lb 67.56722 ms, ub 67.88983 ms, ci 0.950 > std dev: 722.3878 us, lb 323.0343 us, ub 1.356013 ms, ci 0.950 > > parsec3: > mean: 68.20847 ms, lb 68.16387 ms, ub 68.26284 ms, ci 0.950 > std dev: 252.7773 us, lb 204.5512 us, ub 325.2424 us, ci 0.950 > > So, once you release the new parsec3, I am prepared to remove the > "parsec < 3" restriction from the libraries I maintain: pandoc, > highlighting-kate, filestore, gitit, and yst. > > John > Great! Antoine, other tests we should do? Derek, I apologize if you're already following this, but can you give us your opinion? Paulo From qdunkan at gmail.com Sat Dec 5 00:01:49 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Fri Dec 4 23:36:25 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: <20091204210957.GA14889@protagoras.phil.berkeley.edu> References: <20091204210957.GA14889@protagoras.phil.berkeley.edu> Message-ID: <2518b95d0912042101q124251d2ga15fc4a5fb9520bd@mail.gmail.com> On Fri, Dec 4, 2009 at 1:09 PM, John MacFarlane wrote: >> On Mon, Nov 23, 2009 at 12:29 PM, Antoine Latter wrote: > >> I finally had some time to test it. ?After running it multiple times >> (of course, it would be nice to use criterion here), I'm getting >> numbers in this neighborhood: >> > > I used criterion to compare pandoc compiled with parsec2 to > pandoc compiled with your version of parsec3. ?(The benchmark > is converting testsuite.txt from markdown to HTML.) The difference was > minor: Very nice, I was interested in parsec 3 but scared off by the reports of slowness, as I'm sure many others were. Is there any document out there describing the differences between 2 and 3? I gathered 3 allows more flexibility wrt the input, so you can more easily use ByteString or Text, but it would be nice to have a doc saying what the new features are and why we should be interested in upgrading. The old parsec docs were out of date even for parsec 2, and looks like they haven't been updated. The new ones look like they use haddock which is great, that was a gripe I had about the old doc. However, the haddock docs are less friendly than the old doc. So my suggestion is to paste the old introduction (with Daan permission, of course) or something similar into the Text.Parsec description field, along with links to more detailed descriptions and tutorial in the style of v2 on haskell.org along with a 2 vs. 3 doc, even if they're sketchy and brief. Or if it's ok I could just send some darcs patches :) From wren at freegeek.org Sat Dec 5 00:13:27 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Dec 4 23:42:42 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <20091204181423.GA1109@quaternion> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> <3283f7fe0911302010n6bc77a2ck3941bfe4a026d9b@mail.gmail.com> <1259670159.4896.91431.camel@localhost> <871vjcuw9e.fsf@malde.org> <1259845201.4896.103489.camel@localhost> <4B185C9C.6040706@freegeek.org> <20091204181423.GA1109@quaternion> Message-ID: <4B19EBF7.7040703@freegeek.org> Jason McCarty wrote: > wren ng thornton wrote: > >> concat1 :: T a b -> (b -> T a b) -> T a b > > This could just as easily be > > concat :: T a b -> (b -> T a c) -> T a c > > right? It's a little weird to call this concatenation, but I bet it > could come in handy. Er right, that's what I meant. (Again the posting without enough coffee to pave over the cognitive potholes ) -- Live well, ~wren From wren at freegeek.org Sat Dec 5 00:28:08 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Dec 4 23:57:21 2009 Subject: [Haskell-cafe] GHC magic optimization ? In-Reply-To: <7ca3f0160912040915m7f26950eo7049183ca66f1edb@mail.gmail.com> References: <20091203163215.48a8f21b@brouillard.aima.fr> <4B17E029.5070404@yandex.ru> <20091204024814.08f1824e@brouillard.aima.fr> <4B18E619.8020502@kent.ac.uk> <7ca3f0160912040243v476b418dvedd1ebb013cb5b2f@mail.gmail.com> <1E783BA7-16E6-4146-8F66-77CC187BEAB1@glyphic.com> <7ca3f0160912040915m7f26950eo7049183ca66f1edb@mail.gmail.com> Message-ID: <4B19EF68.80400@freegeek.org> Luke Palmer wrote: > On Fri, Dec 4, 2009 at 9:44 AM, Mark Lentczner wrote: >> On Dec 4, 2009, at 2:43 AM, Luke Palmer wrote: >> >>> So GHC leaves it to the user to specify sharing. If you want an >>> expression shared, let bind it and reuse. >> Does GHC treat where and let the same in this regard? Or in code, are these treated the same? > > where is just sugar for let. Well, they have different scoping properties because they're in different syntactic classes in the parser (let is an expression whereas where is a modifier on statements), but other than that yes they're the same. -- Live well, ~wren From derek.a.elkins at gmail.com Sat Dec 5 00:46:37 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Dec 5 00:21:11 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: <2518b95d0912042101q124251d2ga15fc4a5fb9520bd@mail.gmail.com> References: <20091204210957.GA14889@protagoras.phil.berkeley.edu> <2518b95d0912042101q124251d2ga15fc4a5fb9520bd@mail.gmail.com> Message-ID: <61f84eff0912042146n7d6e2406k5810aabfc8977ccc@mail.gmail.com> On Fri, Dec 4, 2009 at 11:01 PM, Evan Laforge wrote: > On Fri, Dec 4, 2009 at 1:09 PM, John MacFarlane wrote: >>> On Mon, Nov 23, 2009 at 12:29 PM, Antoine Latter wrote: >> >>> I finally had some time to test it. ?After running it multiple times >>> (of course, it would be nice to use criterion here), I'm getting >>> numbers in this neighborhood: >>> >> >> I used criterion to compare pandoc compiled with parsec2 to >> pandoc compiled with your version of parsec3. ?(The benchmark >> is converting testsuite.txt from markdown to HTML.) The difference was >> minor: > > Very nice, I was interested in parsec 3 but scared off by the reports > of slowness, as I'm sure many others were. > > Is there any document out there describing the differences between 2 > and 3? ?I gathered 3 allows more flexibility wrt the input, so you can > more easily use ByteString or Text, but it would be nice to have a doc > saying what the new features are and why we should be interested in > upgrading. Basically, the main (only) significant changes are that Parsec 3 provides a monad transformer rather than just a monad and the input has been generalized to take arbitrary "Streams" rather than lists of tokens. > The old parsec docs were out of date even for parsec 2, and looks like > they haven't been updated. ?The new ones look like they use haddock > which is great, that was a gripe I had about the old doc. ?However, > the haddock docs are less friendly than the old doc. ?So my suggestion > is to paste the old introduction (with Daan permission, of course) or > something similar into the Text.Parsec description field, along with > links to more detailed descriptions and tutorial in the style of v2 on > haskell.org along with a 2 vs. 3 doc, even if they're sketchy and > brief. The Parsec Letter applies to Parsec 3 readily. The only thing that needs changing is the module names and possibly one or two function names which the haddock documentation should readily point out. The letter obviously does not cover the new features of Parsec 3; for that there is only the haddock at this point. It would be nice to update the Parsec letter but that would ideally require the document source and necessarily require Daan's permission. Unfortunately, no one has been able to get in touch with Daan on this issue to my knowledge. > Or if it's ok I could just send some darcs patches :) You can certainly email me patches and I'll likely apply them if there are no copyright or licensing issues. From conal at conal.net Sat Dec 5 01:52:38 2009 From: conal at conal.net (Conal Elliott) Date: Sat Dec 5 01:27:31 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: <1bc51a990912041503l26afc788t340e0bce307edf23@mail.gmail.com> References: <1bc51a990912041503l26afc788t340e0bce307edf23@mail.gmail.com> Message-ID: Thanks, Matt. I see libev is available via macports. - Conal On Fri, Dec 4, 2009 at 3:03 PM, Matt Morrow wrote: > Conal, > > If I were looking to do this, I'd read the relevant parts of the libev > code. > > Matt > > > On 12/3/09, Conal Elliott wrote: > > I'd like to make some FRPish toys that keep files updated to have > functional > > relationships with other files. hinotify looks like just the sort of > > underlying magic I could use for efficient implementation on linux. Is > > there any support for mac os x? Could support be either added to > hinotify > > or maybe inotify and a mac-friendly library be abstracted into a common > > Haskell interface? I'm fine with an imperative interface, since I can > > abstract into a functional library, which I guess would be a sort of > > persistent simplified FRP. > > > > - Conal > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/9b0c315b/attachment.html From conal at conal.net Sat Dec 5 01:57:02 2009 From: conal at conal.net (Conal Elliott) Date: Sat Dec 5 01:31:56 2009 Subject: [Haskell-cafe] inotify-alike for mac os x? In-Reply-To: References: <1bc51a990912041503l26afc788t340e0bce307edf23@mail.gmail.com> Message-ID: Oh -- also libevent, described at http://www.monkey.org/~provos/libevent/ : Currently, *libevent* supports */dev/poll > *, *kqueue(2) > *, *event ports > *, *select(2)*, *poll(2)* and *epoll(4) > *. The internal event mechanism is completely independent of the exposed > event API, and a simple update of libevent can provide new functionality > without having to redesign the applications. As a result, *Libevent*allows for portable application development and provides the most scalable > event notification mechanism available on an operating system. Libevent can > also be used for multi-threaded applications; see Steven Grimm's > explanation. > *Libevent* should compile on Linux, *BSD, Mac OS X, Solaris and Windows. > On Fri, Dec 4, 2009 at 10:52 PM, Conal Elliott wrote: > Thanks, Matt. I see libev is available via macports. - Conal > > > On Fri, Dec 4, 2009 at 3:03 PM, Matt Morrow wrote: > >> Conal, >> >> If I were looking to do this, I'd read the relevant parts of the libev >> code. >> >> Matt >> >> >> On 12/3/09, Conal Elliott wrote: >> > I'd like to make some FRPish toys that keep files updated to have >> functional >> > relationships with other files. hinotify looks like just the sort of >> > underlying magic I could use for efficient implementation on linux. Is >> > there any support for mac os x? Could support be either added to >> hinotify >> > or maybe inotify and a mac-friendly library be abstracted into a common >> > Haskell interface? I'm fine with an imperative interface, since I can >> > abstract into a functional library, which I guess would be a sort of >> > persistent simplified FRP. >> > >> > - Conal >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/3d17b3e5/attachment.html From alexey.skladnoy at gmail.com Sat Dec 5 01:57:32 2009 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Sat Dec 5 01:32:07 2009 Subject: [Haskell-cafe] Haskell for Physicists In-Reply-To: References: <20091013184415.GI7864@whirlpool.galois.com> Message-ID: <8425cc0e0912042257w71bb21baqd139ed23a3d03429@mail.gmail.com> 2009/12/4 Roman Salmin : > On Fri, Dec 04, 2009 at 01:43:42PM +0000, Matthias G?rgens wrote: >> > _So my strong opinion that solution is only DSL not EDSL_ >> >> Why do you think they will learn your DSL, if they don't learn any >> other language? > I didn't said that they didn't learn any language. They learn languages, > but > only part that is necessary to do particular task. > f.e. ROOT CINT(C++ interpreter) didn't distinguish object from pointer to > object, i.e. > statement h.ls(); works as well as h->ls(); independently of either h has > type TH1F or TH1F*, > so beginning ROOT user didn't need know what is pointer, memory management > helps him. > But early or latter one need to write more complicated code, > then one need to spend months to reading big C++ books, and struggling with > compilers errors, segfaults etc..^(1) (instead of doing assigned task!) or, > what is more usually, trying Ad hoc methods for writing software. > So people will learn DSL because: > 1. DSL is simpler than general purpose language > 2. DSL describe already known domain for user, (one probably don't need > monads, continuations, virtual methods, template instantiation etc...etc...) > so learning is easy, and didn't consume much time. > >> And if your DSL includes general purpose stuff, like >> functions, control structures, data structures, you'll re-invent the >> wheel. Probably porly. > You didn't need to reinvent the wheel, because you DSL compiler can > produce Haskell code: > DSL -> General Purpose Language -> Executable > And ever if you do, it saves allot of time of experts. > > Roman. > > (1) In Haskell this probably will sound like: reading allot of small > tutorials and articles, grokking monads, > struggling with type-check errors, infinite loops, laziness, etc... > There is other side. As Matthias G?rgens mentioned earlier 1. One have to reinvent control structures. Multiple times. Lets assume that compiler would translate DSL to haskell code. But DSL's expressions which convert into haskell control structures are DSL's control structures. 2. There would be more than one DSL. If they are all EDSL there is no real problems with combining them in one program if necessity arises. Probably there would be ways to combine them if they are DSL but they will require expertise and most likely dirty hacks. 2.1 And all of them will have different conrol structures, abstraction mechanisms. 3. Turing tarpit. Users will constantly require more power and features in DSL. Most likely DSL designers wouldn't be great language designers so DSL will turn into utter mess. 4. One have all power (and libraries of host languages). Of course if he is able to utilize it. This is tradeoff between power and simplicity. If one have too much simplicity he is not able to solve difficult problems. If one have too much power at expense of simplicity he has to struggle with tool to have thing done. And it's possible to sacrifice simplicity and don't gain any power. From radek.micek at gmail.com Sat Dec 5 02:15:42 2009 From: radek.micek at gmail.com (Radek Micek) Date: Sat Dec 5 01:50:15 2009 Subject: [Haskell-cafe] Re: From function over expression (+, *) derive function over expression (+) In-Reply-To: <4B199FCF.2020408@van.steenbergen.nl> References: <4B199FCF.2020408@van.steenbergen.nl> Message-ID: Hi, thank you for your reply but your MulExpr does not support expressions like (2*3)+5 Radek On Dec 5, 12:48?am, Martijn van Steenbergen wrote: > Hi Radek, > > Radek Micek wrote: > > I can write a function to simplify the first expression: > > > simplify :: Expr -> Expr > > simplify = {- replaces: > > "a*1" and "1*a" by "a", > > "a+0" and "0+a" by a -} > > > And I would like to use the function simplify for the second type > > AExpr. What can I do is to convert AExpr to Expr, simplify it and > > convert it back. But I don't like this solution because > > conversions take some time. > > Like Luke said, you can probably work out something using explicit fixed > points. > > Or you can "cheat" a little and use generic programming: > > > {-# LANGUAGE DeriveDataTypeable #-} > > > import Data.Generics > > > data AddExpr = Const Int | Add AddExpr AddExpr > > ? deriving (Eq, Show, Typeable, Data) > > > data MulExpr = AddMul AddExpr | Mul MulExpr MulExpr > > ? deriving (Eq, Show, Typeable, Data) > > Here you have explicitly encoded MulExpr as an extension of AddExpr > through the constructor AddMul, just like you asked. > > Now we define the simplification steps you mentioned, one for each > datatype. They perform only one simplification step instead of calling > themselves recursively. The type of simplifyAddStep ensures that it > doesn't accidentally introduce multiplications: > > > simplifyAddStep :: AddExpr -> AddExpr > > simplifyAddStep expr = case expr of > > ? Add (Const 0) y -> y > > ? Add x (Const 0) -> x > > ? _ ? ? ? ? ? ? ? -> expr > > > simplifyMulStep :: MulExpr -> MulExpr > > simplifyMulStep expr = case expr of > > ? Mul (AddMul (Const 1)) x -> x > > ? Mul x (AddMul (Const 1)) -> x > > ? _ -> expr > > Using generic programming, we can combine these two steps and apply them > recursively on entire trees, bottom-up: > > > simplify :: Data a => a -> a > > simplify = everywhere (id `extT` simplifyAddStep `extT` simplifyMulStep) > > An example invocation: > > > *Main> simplify (AddMul (Const 1) `Mul` (AddMul (Const 2 `Add` Const 0))) > > AddMul (Const 2) > > Hope this helps, > > Martijn. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe From jfredett at gmail.com Sat Dec 5 02:17:52 2009 From: jfredett at gmail.com (jfredett@gmail.com) Date: Sat Dec 5 01:52:26 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 142 - December 05, 2009 Message-ID: <4b1a0920.9515f10a.0ea1.ffffe360@mx.google.com> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20091205 Issue 142 - December 05, 2009 --------------------------------------------------------------------------- Welcome to issue 142 of HWN, a newsletter covering developments in the [1]Haskell community. Occasionally, I have something silly or clever to say here. Usually I give a summary of the weeks news and end it with a bit of a cliche tagline, however, this is finals week, and as such, there is absolutely no brain cells left working to come up with any cleverness for here. I'll see you next week with (hopefully) more ability for humor. Until next week, the Haskell Weekly News! Announcements error-message. Gregory Crosswhite [2]announced a package for handling errors in haskell. To quote his message directly, 'If there is one thing that we really don't have enough of in Haskell, it is *ways to handle errors*!' atom-0.1.3. Tom Hawkins [3]announced a new version of the Atom DSL for designing hard realtime embedded software. Blueprint 0.1 -- PREVIEW. Gregory Crosswhite [4]announced a preview version of his 'Blueprint' configuration package. haskell-mode 2.7.0. Svein Ove Aas [5]announced another release of Haskell-mode for Emacs graphviz-2999.7.0.0. Ivan Lazar Miljenovic [6]announced a new version of his set of bindings to the graphviz tools for visualizing graphs. Haskell Job Openings (Pune, IN). Tom Hawkins [7]announced some job openings in Eaton's engineering center in Pune, India. SaC Tutorial at PPoPP 2010. Clemens Grelck [8]announced a tutorial to be held at PPoPP on SAC and it's auto-parallelizing compiler SAC2C. Call for papers: PAPP 2010, 7th International Workshop on Practical Aspects of High-level Parallel Programming. Clemens Grelck [9]announced a call for papers for the Seventh International Workshop on Practical Aspects of High-level Parallel Programming. PhD Studentships in Nottingham. Graham Hutton [10]announced some PhD openings at the University of Nottingham. Second Call for Copy: Monad.Reader Issue 15. Brent Yorgey [11]announced a second call for copy for the Monad.Reader. 3 full professor positions at DIKU. Fritz Henglein [12]announced three open professor positions at the the Department of Computer Science at the University of Copenhagen ([13]DIKU). Hubris 0.0.2, the Ruby-Haskell bridge. Mark Wotton [14]announced a new version of the Hubris package is now available on hackage. Discussion You are in a twisty maze of concurrency libraries, all different ... Patrick Caldon [15]asked about the 'right' concurrency package to use for his project. Greetings! 2D Graphics? M Xyz [16]asked (enthusiatically) about different ways to do 2-dimensional graphics in Haskell. Wikipedia article. Simon Marlow [17]rallied us all into fixing the (or at least starting to fix) wikipedia page for Haskell. Great Programs to Read? Michael Lesniak [18]asked about what programs were worth reading. Blog noise [19]Haskell news from the [20]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Michael Snoyman: [21]String-like. * Claude Heiland-Allen: [22]Heist: dataflow algebra. * Adam Jones: [23]Lambda Calculus Compiler: Part III: First-Order Functions. * Holumbus: [24]Hayoo! Update ⦠Again. * Mikael Vejdemo Johansson (Syzygy-): [25][MATH198] Lecture 10 (last lecture) posted. * Neil Brown: [26]Automated Wiring of Message-Passing Processes. * Computer Systems Design Laboratory at the University of Kansas: [27]ChalkBoard Release. * Bryan O'Sullivan: [28]Dense? Dense, you say?. * Ivan Lazar Miljenovic: [29]Waddaya know, testing WORKS!. * Ivan Lazar Miljenovic: [30]If wishes were tests, code would be perfect. * Ivan Lazar Miljenovic: [31]The Problems with Graphviz. Quotes of the Week * Badger: one does not simply >>= into mordor * Apocalisp: data CanHaz a = Haz a | ButIEatedIt * Apocalisp: You can't have your baby and eat it too * Dave_Benjamin: please talk to your son or daughter about parametric polymorphism * Cale: Beginners are confusing to beginners. I move that we remove them from the language altogether. * monochrom: I am 17-ary, going on 18-ary, I can take curry of you * jmillikin: [the real world is] an implementation detail of IO, pay it no mind * monochrom,ezyang: The Principle Of Idiot Savant: any sufficiently misguided opinion is indistinguishable from deep insight * Cale: I swear that most of higher-dimensional category theory must have been arrived at by some guys sitting around in a room with a blackboard and saying "What if a drew a diagram like *THIS*!?" and drawing some insane scribble up on the blackboard, and then everyone tries to figure out how to turn it into meaningful mathematics. * jbe: Here I am, happy my code compiles, and the runtime is thumbing its nose at Turing. * Ferdirand: I was TA for a C++ programming course aimed at 1st year physics once. Some girl asked for help "i wrote pseudo-code but I cannot translate it to C++". Her pseudo-code was valid haskell. I cried. * mmorrow: [regarding excessive use of categorical recursion schemes] a morphasm? * copumpkin: I'm on a rollomorphism * dons: but rumours are remarkably common when it comes to haskell * monochrom: If you read a haskell book or an FP book, by chapter 5 it's already doing data structures. It's chapter 10 in imperative books. About the Haskell Weekly News New editions are posted to [32]the Haskell mailing list as well as to [33]the Haskell Sequence and [34]Planet Haskell. [35]RSS is also available, and headlines appear on [36]haskell.org. To help create new editions of this newsletter, please see the information on [37]how to contribute. Send stories to jfredett . at . gmail . dot . com. The darcs repository is available at darcs get [38]http://patch-tag.com/r/jfredett/HWN2/pullrepo HWN2 . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67149 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67090 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/66924 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/66923 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/66920 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/66904 8. http://article.gmane.org/gmane.comp.lang.haskell.general/17661 9. http://article.gmane.org/gmane.comp.lang.haskell.general/17660 10. http://article.gmane.org/gmane.comp.lang.haskell.general/17659 11. http://article.gmane.org/gmane.comp.lang.haskell.general/17657 12. http://article.gmane.org/gmane.comp.lang.haskell.general/17656 13. http://www.diku.dk/ 14. http://article.gmane.org/gmane.comp.lang.haskell.general/17653 15. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67211 16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67184 17. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67158 18. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/66917 19. http://planet.haskell.org/ 20. http://haskell.org/haskellwiki/Blog_articles 21. http://snoyberg.wordpress.com/2009/12/04/string-like/ 22. http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html 23. http://blog.finiteimprobability.com/2009/12/03/lambda-calculus-compiler-part-iii-first-order-functions/ 24. http://holumbus.fh-wedel.de/blog/?p=28 25. http://blog.mikael.johanssons.org/archive/2009/12/math198-lecture-10-last-lecture-posted/ 26. http://chplib.wordpress.com/2009/12/02/automated-wiring-of-message-passing-processes/ 27. http://www.ittc.ku.edu/csdlblog/?p=25 28. http://www.serpentine.com/blog/2009/12/01/dense-dense-you-say/ 29. http://ivanmiljenovic.wordpress.com/2009/11/17/waddaya-know-testing-works/ 30. http://ivanmiljenovic.wordpress.com/2009/11/26/if-wishes-were-tests-code-would-be-perfect/ 31. http://ivanmiljenovic.wordpress.com/2009/11/30/the-problems-with-graphviz/ 32. http://www.haskell.org/mailman/listinfo/haskell 33. http://sequence.complete.org/ 34. http://planet.haskell.org/ 35. http://sequence.complete.org/node/feed 36. http://haskell.org/ 37. http://haskell.org/haskellwiki/HWN 38. http://patch-tag.com/r/jfredett/HWN2/pullrepo%20HWN2 From ketil at malde.org Sat Dec 5 04:15:38 2009 From: ketil at malde.org (Ketil Malde) Date: Sat Dec 5 03:50:14 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <4B18D499.4070401@gmail.com> (Simon Marlow's message of "Fri, 04 Dec 2009 09:21:29 +0000") References: <4B1849FD.2000706@gmail.com> <20091203233622.GB17556@whirlpool.galois.com> <4B18D499.4070401@gmail.com> Message-ID: <874oo5kchx.fsf@malde.org> Simon Marlow writes: >> There's no need to do any page moving or anything; the new version can >> just be pasted in. > Ok, done! > http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 After conferring briefly with people on IRC (yeah, on a Saturday morning, who am I kidding?), I moved the talk page to an archive, and started a new one. (The archive is linked from the new talk page.) Most of the discussion seemed to be quite outdated, many of the issues had been addressed, and since we got a new structure on the main page, it seemed like a good idea to stow the old stuff and start afresh. But it was a long page, so if you had a cause you feel needs more arguing, please copy back from the old page or, perhaps better, restate your issues on the new one. Okay? -k -- If I haven't seen further, it is by standing in the footprints of giants From ekirpichov at gmail.com Sat Dec 5 04:31:23 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Sat Dec 5 04:05:56 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? Message-ID: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> Hello. Consider the type: (forall a . a) -> String. On one hand, it is rank-2 polymorphic, because it abstracts over a rank-1 polymorphic type. On the other hand, it is monomorphic because it isn't actually quantified itself: in my intuitive view, a parametrically polymorphic type has infinitely many instantiations (for example, Int -> Int is an instantiation of forall a . a -> a, and String -> String also is), and this type doesn't have any instantiations at all. Which is correct? Is there really a contradiction? What is the definition of rank of a polymorphic type? -- Eugene Kirpichov Web IR developer, market.yandex.ru From deniz.a.m.dogan at gmail.com Sat Dec 5 04:53:59 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Sat Dec 5 04:28:54 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <4B1849FD.2000706@gmail.com> References: <4B1849FD.2000706@gmail.com> Message-ID: <7b501d5c0912050153q5fadd059t5335ed8e893bb012@mail.gmail.com> 2009/12/4 Simon Marlow : > As noted before, the Wikipedia article for Haskell is a disorganised mess. > > http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 > > earlier this year, dons suggested reorganising it and posted a template on > the Haskell wiki: > > http://haskell.org/haskellwiki/WikipediaArticleDesign > > I've made a start on a new version of the page: > > http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 > > I've kept most of the existing information, but reorganised it more or less > according to Don's template, and I filled out the overview section. ?Also I > fixed numerous things, but the page still has a long way to go > > Does anyone mind if I spam the existing Haskell article with this new one, > or do people think we should continue editing the sandbox version until it's > in better shape? > > Cheers, > ? ? ? ?Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Could someone please do something about the horrible syntax highlighting for strings in the Wikipedia article? Black on dark green, really? -- Deniz Dogan From martijn at van.steenbergen.nl Sat Dec 5 04:58:00 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Sat Dec 5 04:32:36 2009 Subject: [Haskell-cafe] Re: From function over expression (+, *) derive function over expression (+) In-Reply-To: References: <4B199FCF.2020408@van.steenbergen.nl> Message-ID: <4B1A2EA8.4080301@van.steenbergen.nl> Radek Micek wrote: > Hi, > > thank you for your reply but your MulExpr > does not support expressions like > > (2*3)+5 Oh! You're right, how silly of me. Martijn. From sanzhiyan at gmail.com Sat Dec 5 05:38:25 2009 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Sat Dec 5 05:12:59 2009 Subject: [Haskell-cafe] SYB <> very, very mysteriously In-Reply-To: References: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> Message-ID: <8625cd9c0912050238g2ed403a4u1c0e82262f57168e@mail.gmail.com> On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw wrote: > I have stripped things down to the bare minimum, and test under GHC 6.10, > GHC 6.12, Linux, and Mac OS X. Results are consistent. > > In the following code, > > ?1. if you load the code into ghci and evaluate e it will hang, but > (defaultValueD dict) :: Expression returns fine > ?2. if you change the gunfold instance for Proposition to, error "gunfold" > it stops hanging -- even though this code is never called. > ?3. if you change, ( Data ctx [Expression], Sat (ctx Expression) => Data ctx > Expression, to (Data ctx Expression, ....) => ... it stops hanging. > > If someone could explain why each of these cases perform as they do, that > would be awesome! Right now it is a big mystery to me.. e calls dict .. and > there is only one instance of dict available, which should call error right > away. I can't see how something could get in the way there... > It's less of a mystery if you think about the actual dictionaries ghc uses to implement typeclasses. The instance for Data ctx [a] depends on Data ctx a, so by requiring Data ctx [Expression] in the Data ctx Expression instance you're indeed making a loop there, though typeclasses do allow this, and the implementation has to be lazy enough to permit it. Strange that with a direct Data ctx Expression => Data ctx Expression loop we don't get the same problem. The reason the implementation of Proposition's gunfold matters is probably that k gets passed the dictionary for Data DefaultD Expression at the site of its call and some optimization is making it stricter than necessary. Looks like we need a ghc dev here to fully unravel the mystery, in the meantime i'll try to reduce the test case even further. > - jeremy > > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances, > MultiParamTypeClasses, UndecidableInstances, RankNTypes, > ScopedTypeVariables, KindSignatures, EmptyDataDecls, > NoMonomorphismRestriction #-} > module Main where > > import qualified Data.Data as Data > import Data.Typeable > > --- syb-with-class > > data Constr = Constr deriving (Eq, Show) > > data Proxy (a :: * -> *) > > class Sat a where > ? ?dict :: a > > class (Typeable a, Sat (ctx a)) => Data ctx a where > ? ? gunfold :: Proxy ctx > ? ? ? ? ? ? -> (forall b r. Data ctx b => c (b -> r) -> c r) > ? ? ? ? ? ? -> (forall r. r -> c r) > ? ? ? ? ? ? -> Constr > ? ? ? ? ? ? -> c a > > instance (Sat (ctx [a]),Data ctx a) => Data ctx [a] > > --- Default > > class (Data DefaultD a) => Default a where > ? ?defaultValue :: a > > data DefaultD a = DefaultD { defaultValueD :: a } > > instance Default t => Sat (DefaultD t) where > ? ?dict = error "Sat (DefaultD t) not implemented" > > instance Default a => Default [a] where > ? ?defaultValue = error "Default [a] not implemented" > > --- Trouble > > data Proposition = Proposition Expression ?deriving (Show, Data.Data, > Typeable) > data Expression = Conjunction Expression deriving (Show, Data.Data, > Typeable) > > -- instance (Sat (ctx [Expression]), Sat (ctx Expression), Sat (ctx > Proposition)) => Data ctx Proposition where > instance Data DefaultD Proposition ?where > ? ?gunfold _ k z c = k (z Proposition) > -- ? ?gunfold _ k z c = error "gunfold" > > instance Default Proposition > > -- Change Data ctx [Expression] to Data ctx Expression and main works. > instance ( Data ctx [Expression] > ? ? ? ? , Sat (ctx Expression) > ? ? ? ? ) => Data ctx Expression > > instance Default Expression > > e :: Expression > e = defaultValueD (dict :: DefaultD Expression) > > main = print e > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From martijn at van.steenbergen.nl Sat Dec 5 05:58:50 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Sat Dec 5 05:33:24 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> Message-ID: <4B1A3CEA.8070402@van.steenbergen.nl> Eugene Kirpichov wrote: > Hello. > > Consider the type: (forall a . a) -> String. > > On one hand, it is rank-2 polymorphic, because it abstracts over a > rank-1 polymorphic type. > On the other hand, it is monomorphic because it isn't actually > quantified itself: in my intuitive view, a parametrically polymorphic > type has infinitely many instantiations (for example, Int -> Int is an > instantiation of forall a . a -> a, and String -> String also is), and > this type doesn't have any instantiations at all. > > Which is correct? Is there really a contradiction? What is the > definition of rank of a polymorphic type? There's a nice paper about this: Simon Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich and Mark Shields "Practical type inference for arbitrary-rank types" http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/putting.pdf Section 3.1 of that paper defines what rank types have: "The rank of a type describes the depth at which universal quantifiers appear contravariantly" Looking at the examples that are then given I'd say your example has rank 2 (but I'm no expert). It only mentions the depth of the forall, not whether it has any instantiations. HTH, Martijn. From mauricio.antunes at gmail.com Sat Dec 5 07:10:12 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Sat Dec 5 06:45:08 2009 Subject: [Haskell-cafe] Do you need Windows USB in Haskell? Message-ID: Hi, I keep this direct binding to libusb-1.0.x: http://hackage.haskell.org/package/bindings-libusb on top of which Bas maintains a nice USB library: http://hackage.haskell.org/package/usb Work has been done to support libusb-1.0.x in Windows. So, as long as my bindings-libusb works properly with that, Bas' as well as any other library based on it will work too. Problem is: I don't have a Windows machine where I could test this. So, if you need USB in windows, please keep in touch. I wouldn't ask you to write any code, but I need to know what builds and what doesn't. Best, Maur?cio From jaspervdj at gmail.com Sat Dec 5 07:35:24 2009 From: jaspervdj at gmail.com (Jasper van der Jeugt) Date: Sat Dec 5 07:08:06 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 Message-ID: Hello all, Hakyll is a simple static site generator library, mostly aimed at blogs. It supports markdown, tex and html templates. It is inspired by the ruby Jekyll program. It has a very small codebase because it makes extensive use of the excellent pandoc and Text.Template libraries. More information can be found on: http://hackage.haskell.org/package/hakyll-0.1 http://github.com/jaspervdj/Hakyll Kind regards, Jasper Van der Jeugt From gwern0 at gmail.com Sat Dec 5 08:55:37 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Dec 5 08:30:12 2009 Subject: [Haskell-cafe] Wikipedia article In-Reply-To: <7b501d5c0912050153q5fadd059t5335ed8e893bb012@mail.gmail.com> References: <4B1849FD.2000706@gmail.com> <7b501d5c0912050153q5fadd059t5335ed8e893bb012@mail.gmail.com> Message-ID: On Sat, Dec 5, 2009 at 4:53 AM, Deniz Dogan wrote: > 2009/12/4 Simon Marlow : >> As noted before, the Wikipedia article for Haskell is a disorganised mess. >> >> http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 >> >> earlier this year, dons suggested reorganising it and posted a template on >> the Haskell wiki: >> >> http://haskell.org/haskellwiki/WikipediaArticleDesign >> >> I've made a start on a new version of the page: >> >> http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 >> >> I've kept most of the existing information, but reorganised it more or less >> according to Don's template, and I filled out the overview section. ?Also I >> fixed numerous things, but the page still has a long way to go >> >> Does anyone mind if I spam the existing Haskell article with this new one, >> or do people think we should continue editing the sandbox version until it's >> in better shape? >> >> Cheers, >> ? ? ? ?Simon >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > Could someone please do something about the horrible syntax > highlighting for strings in the Wikipedia article? Black on dark > green, really? > Syntax highlighting on En for Haskell snippets is done, I believe, through GeSHi: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi So complain to them? -- gwern From stefan at cs.uu.nl Sat Dec 5 08:56:06 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sat Dec 5 08:30:39 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> Message-ID: Eugene, > Consider the type: (forall a . a) -> String. It's of rank 2. > What is the definition of rank of a polymorphic type? The minimal rank of a type is given by rank (forall a. t) = 1 `max` rank t rank (t -> u) = (if rank t == 0 then 0 else rank t + 1) `max` rank u rank _ = 0 HTH, Stefan From andrewcoppin at btinternet.com Sat Dec 5 10:08:29 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 09:42:56 2009 Subject: [Haskell-cafe] Finding HP In-Reply-To: <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> References: <4B16E984.7070504@btinternet.com> <20091203164329.GC17116@whirlpool.galois.com> <6CBB9CAE-DC0E-4ED7-8AF2-E52A96578E6E@cs.york.ac.uk> Message-ID: <4B1A776D.5040805@btinternet.com> Malcolm Wallace wrote: > The suggestion was to have a single Download button, leading to a > *page* of suitably described links, allowing the user to choose > whether they only wanted the basics (a choice of compiler/interpreter > + cabal), or the whole Platform, or something else. It would be the > ideal place to explain what cabal is and how to use hackage to get > more libraries than are contained in the platform. It would perhaps > reduce the clutter on the front page that some people complained of > (although I don't personally think it cluttered). It seems I'm contraversial even when I'm trying to be uncontraversial. :-} Anyway, the above suggestion sounds most optimal to me. Haskell tends to suffer from a frustrating degree of "information dragmentation" (I love whoever came up with that term...), and collecting a bunch of information in one place like this sounds very useful. I guess in a way, the current "implementations" page could become this page (or this new page makes the existing implementations page obsolete...) I also think it might be worth mentioning HP from the GHC homepage, just in case anybody has that bookmarked directly... From andrewcoppin at btinternet.com Sat Dec 5 10:40:23 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 10:14:50 2009 Subject: [Haskell-cafe] HP + Gtk2hs? Message-ID: <4B1A7EE7.70807@btinternet.com> So I decided to try out the Haskell Platform instead of just installing GHC directly. To be honest, I didn't really notice much difference, except for the files being installed in a different place. But then, initially HP ~= GHC; presumably the plan is for it to grow as time goes on. Anyway, I'm sure you can all see where I'm going with this: Latest Gtk2hs binary for Windows doesn't seem to like the latest HP installation. A few things: - It is unclear to be which Gtk2hs binaries require which GHC version. Can we tabulate this information somewhere? - It is also unclear to me which HP versions contain what stuff. The HP page tells you all about the *current* HP version, and contains a link to a raw directory listing for the older versions. (I especially love the way the server truncates the filenames to just before where the version number starts. Very helpful. :-D ) Can we get propper descriptions for _all_ releases of HP? A table summarising the GHC version and major packages/versions in each release would be nice. - Any idea why the HP says "beta" on it? - Apart from HP providing GHC 6.10.4 while Gtk2hs currently requires 6.10.3, it appears that the Gtk2hs installer package doesn't like GHC being installed in a path with spaces. Apparently Gtk2hs has a bug tracker. (I only just discovered this, so perhaps it needs to be more prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers. (I emphasize "visible". Maybe they've seen this and they're working on it, but there's no visible indication of activity.) Gtk2hs is currently the *only* GUI binding that actually works on Windows. It's always been slightly frustrating that every time a new version of GHC comes out, us Windows users have to beg for somebody to build a new binary. (Linux users, on the other hand, can just download the sources and compile them with any compiler they like.) Presumably going forward Gtk2hs will synchronise to the (less frequent) HP releases rather than the individual GHC releases, so many this particular frustration will be reduced. (It would be even less frustrating if Gtk2hs was *in* HP, but I gather this won't ever happen.) Of course, being able to actually build C bindings on Windows would be even better, but this is apparently infeasible... :-( That being the case, I'll settle for just a little bit more documentation. From tobi.huebner at t-online.de Sat Dec 5 10:42:06 2009 From: tobi.huebner at t-online.de (MeAdAstra) Date: Sat Dec 5 10:16:38 2009 Subject: [Haskell-cafe] Haskell-Newbie and Char-Function Message-ID: <26656676.post@talk.nabble.com> Hi guys, I only started learning Haskell some days ago. Maybe one of you can give me a hint on how to implement a function that needs a character in the range (a,b,...z) and an integer number k and returns the k-next neighbor of the character? For example, fct a 5 would result in output f. Tobias -- View this message in context: http://old.nabble.com/Haskell-Newbie-and-Char-Function-tp26656676p26656676.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From andrewcoppin at btinternet.com Sat Dec 5 10:44:39 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 10:19:05 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <619187.27009.qm@web113112.mail.gq1.yahoo.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> Message-ID: <4B1A7FE7.1080707@btinternet.com> M Xyz wrote: > > > if you get it to work > > As a spoiled Java programmer, this new role as pioneer is a bit > intimidating, but I will give it a shot. :) > > I wish there was a multimedia standard library for beginners like me. > Writing audio to the speakers shouldn't be such a journey. > Unfortunately, I've yet to find a single Haskell package that binds to C which will actually compile on Windows. :-( (It still makes me chuckle that even the COM bindings - which, by definition, can *only* work on Windows - also don't compile. One wonders how the author managed to test it...) Fortunately, for GUI work we have Gtk2hs, which works just fine on Windows. (Although obviously, Windows boxes don't usually have GTK+ installed.) But most of the really interesting stuff on Hackage is just unusable on Windows, sadly. If you ever do manage to get audio working, I'd be interested to know how. From jochem at functor.nl Sat Dec 5 10:48:26 2009 From: jochem at functor.nl (Jochem Berndsen) Date: Sat Dec 5 10:22:15 2009 Subject: [Haskell-cafe] Haskell-Newbie and Char-Function In-Reply-To: <26656676.post@talk.nabble.com> References: <26656676.post@talk.nabble.com> Message-ID: <4B1A80CA.2000904@functor.nl> MeAdAstra wrote: > Hi guys, > I only started learning Haskell some days ago. Maybe one of you can give me > a hint on how to implement a function that needs a character in the range > (a,b,...z) and an integer number k and returns the k-next neighbor of the > character? For example, fct a 5 would result in output f. You might want to use the functions ord and chr from Data.Char, and the mod function from the Prelude. Regards, Jochem -- Jochem Berndsen | jochem@functor.nl | jochem@????.com From michael at snoyman.com Sat Dec 5 10:52:11 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 10:26:44 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <4B193178.30106@henning-thielemann.de> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> Message-ID: <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> Careful Gregory, you've hit a hot-button issue: you have dared to refer to exceptions as errors! For the record, I find this pedanticism misplaced, as the line between the two is rather blurry. Nonetheless, for control-monad-failure and attempt, we purposely refer to the whole slew of "things not succeeding" as "failure"s. Not to be confused with public enemy number 2 of Haskell users: the "fail" function. Michael On Fri, Dec 4, 2009 at 5:57 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > Gregory Crosswhite schrieb: > > > When I uploaded my new package, "error-message", I also went ahead and > created a new category: "Error Handling". > > "Error handling" is the same as "debugging" for you? I hope it is not > intended for generating further confusion about "exception handling" and > "debugging" (= help programmers to analyse errors). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/29cc5b07/attachment.html From bulat.ziganshin at gmail.com Sat Dec 5 11:15:16 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Dec 5 10:49:58 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <4B1A7EE7.70807@btinternet.com> References: <4B1A7EE7.70807@btinternet.com> Message-ID: <924926435.20091205191516@gmail.com> Hello Andrew, Saturday, December 5, 2009, 6:40:23 PM, you wrote: > prominent?) Somebody pointed out this bug 6 months ago. Somebody else > posted a potential fix a month ago. There is no visible activity from > the developers. Developer. many Haskell problems is due to the fact that we have a few volunteers doing things and lot of consumers begging for features :) > Gtk2hs is currently the *only* GUI binding that actually works on > Windows. i thought that wx and even qt are in rather good shape now -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mauricio.antunes at gmail.com Sat Dec 5 12:04:24 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Sat Dec 5 11:39:44 2009 Subject: [Haskell-cafe] Re: Binding to C in Windows (was: Low Level Audio - Writing bytes to the sound card?) In-Reply-To: <4B1A7FE7.1080707@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> Message-ID: > Unfortunately, I've yet to find a single Haskell package that > binds to C which will actually compile on Windows. :-( Do you know how can we check dependencies to C libraries in Windows? Is pkg-config available? What about packages with no pkg-config configuration? Thanks, Maur?cio From stephen.tetley at gmail.com Sat Dec 5 12:14:04 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 5 11:48:38 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <4B1A7FE7.1080707@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> Message-ID: <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> Hello Andrew Plenty compile on Windows: Some OpenVG, OpenGL[1] (still? - I'm a bit behind the times) only compile with MinGW. Others are fine with Cygwin provided you have the dev packages installed (readline, pcre-light...). Yet others - no chance... If you can get the raw C library to work in either Cygwin or MinGW, you should have a good chance. The only sound software I've had working on Cygwin has been ChucK though I haven't tried many - ChucK uses RtAudio to talk to the soundcard which probably isn't easy to write a binding for as its C++. I had ChucK working two years ago, maybe things have improved in the Cygwin world regarding sound since then and other systems now work. http://www.music.mcgill.ca/~gary/rtaudio/ Best wishes Stephen [1] OpenGL worked fine when it was bundled with GHC, when it got unbundled things seemed to go amiss, plus it seemed to be the thing to use freeglut - hence the complicated instructions here: http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ From ross at soi.city.ac.uk Sat Dec 5 12:41:29 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Dec 5 12:16:32 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> Message-ID: <20091205174129.GA15215@soi.city.ac.uk> On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: > For the record, I find this pedanticism misplaced, ... I think you'll find that's "pedantry". From michael at snoyman.com Sat Dec 5 12:52:29 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 12:27:03 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <20091205174129.GA15215@soi.city.ac.uk> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> Message-ID: <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> On Sat, Dec 5, 2009 at 7:41 PM, Ross Paterson wrote: > On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: > > For the record, I find this pedanticism misplaced, ... > > I think you'll find that's "pedantry". > Hoped someone would comment exactly that ;). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/efe761cc/attachment.html From michael at snoyman.com Sat Dec 5 12:58:05 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 12:32:39 2009 Subject: [Haskell-cafe] Avoiding undecidables Message-ID: <29bf512f0912050958u1ce1cc8bo870b1333912b8543@mail.gmail.com> Hi all, Well, I've got two problems which both want to be solved with undecidable and overlapping instances. Obviously, I'd like to try and avoid them. For the record, the problems have to do with the control-monad-failure and convertible packages. The code below *should* make clear what I'm trying to accomplish: -- failure should not be limited to just monads, so... class Failure e f where failure :: e -> f v class (Functor f, Failure e f) => FunctorFailure e f instance (Functor f, Failure e f) => FunctorFailure e f -- undecidable, overlaps class (Applicative f, Failure e f) => ApplicativeFailure e f instance (Applicative f, Failure e f) => ApplicativeFailure e f -- undecidable, overlaps class (Monad f, Failure e f) => MonadFailure e f instance (Monad f, Failure e f) => MonadFailure e f -- undecidable, overlaps And now the convertible issue. I want two type classes: Convert for anything which *might* be convertible, but might not. For example, sometimes a String can be converted to an Int (like the string "5"), but sometimes it will fail (like "five"). TotalConvert is when something *is* convertible, such as Int to String (simply the show function). Thus the following: class Convert x y where convert :: x -> Maybe y class Convert x y => TotalConvert x y where totalConvert :: x -> y instance TotalConvert x y => Convert x y where -- Boom! convert = Just . totalConvert Any ideas are most welcome. Both of these seem like cases where the compiler could do some DWIMery, but isn't. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/46f1b654/attachment.html From functionallyharmonious at yahoo.com Sat Dec 5 13:14:33 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 12:49:05 2009 Subject: [Haskell-cafe] HP + Gtk2hs? Message-ID: <270803.43927.qm@web113110.mail.gq1.yahoo.com> - Apart from HP providing GHC 6.10.4 while Gtk2hs currently requires 6.10.3, it appears that the Gtk2hs installer package doesn't like GHC being installed in a path with spaces. Apparently Gtk2hs has a bug tracker. (I only just discovered this, so perhaps it needs to be more prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers. (I emphasize "visible". Maybe they've seen this and they're working on it, but there's no visible indication of activity.) Thank you so much for this post. I tried to install Gtk2hs yesterday to play with its Cairo bindings and I hit the "Setup found what appears to be a non-working installation of GHC" brickwall. I found a closed ticket about this problem: http://hackage.haskell.org/trac/gtk2hs/ticket/1117 I posted this issue on the Gtk2hs-devel mailing list and got a response today: http://sourceforge.net/mailarchive/forum.php?thread_name=EF0EE62B-259C-4F62-9BF2-65FA1F01949E%40di.ens.fr&forum_name=gtk2hs-devel I don't think I have the will to uninstall the Haskell Platform and everything I've set up just to install in a path with no spaces. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/9337dc00/attachment.html From gtener at gmail.com Sat Dec 5 13:47:33 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Sat Dec 5 13:22:06 2009 Subject: [Haskell-cafe] ANN: readline-statevar-1.0.1.0 Message-ID: <220e47b40912051047k2cfac6bbx50727f6827811597@mail.gmail.com> Hello I am happy to announce a release of small package called readline-statevar. It's a small wrapping library around readline, which in turn wraps libreadline. The reason I wrote it is because I wasn't happy with the API of readline. It was composed of tons of functions like setX/getX, where there could be just one StateVar instead, yielding OpenGL-kind API. This version aims to match readline-1.0.1.0. (Hence the version number chosen). I wrote it mostly manually, with a little help from my emacs-fu, so there is a chance I missed a thing or two. There is git repo available [1], along with issue tracker [2] and Hackage page [3]. Feel encouraged to: > cabal update > cabal install readline-statevar And give it a try! Best regards Krzysztof Skrz?tnicki [1] http://github.com/Tener/haskell-readline-statevar/ [2] http://github.com/Tener/haskell-readline-statevar/issues [3] http://hackage.haskell.org/package/readline-statevar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/9f676cd2/attachment.html From andrewcoppin at btinternet.com Sat Dec 5 13:55:24 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 13:29:49 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <961132.53528.qm@web113102.mail.gq1.yahoo.com> References: <961132.53528.qm@web113102.mail.gq1.yahoo.com> Message-ID: <4B1AAC9C.7050707@btinternet.com> M Xyz wrote: > > > > - Apart from HP providing GHC 6.10.4 while Gtk2hs currently > requires 6.10.3, it appears that the Gtk2hs installer package > doesn't like GHC being installed in a path with spaces. Apparently > Gtk2hs has a bug tracker. (I only just discovered this, so perhaps > it needs to be more prominent?) Somebody pointed out this bug 6 > months ago. Somebody else posted a potential fix a month ago. > There is no visible activity from the developers. (I emphasize > "visible". Maybe they've seen this and they're working on it, but > there's no visible indication of activity.) > > Thank you so much for this post. I tried to install Gtk2hs yesterday > to play with > its Cairo bindings and I hit the "Setup found what appears to be a > non-working installation of GHC" brickwall. I found a closed ticket > about this problem: http://hackage.haskell.org/trac/gtk2hs/ticket/1117 > I posted this issue on the Gtk2hs-devel mailing list and got a > response today: > http://sourceforge.net/mailarchive/forum.php?thread_name=EF0EE62B-259C-4F62-9BF2-65FA1F01949E%40di.ens.fr&forum_name=gtk2hs-devel > > I don't think I have the will to uninstall the Haskell Platform and > everything I've set up just to install in a path with no spaces. :) > > My information is from here: http://hackage.haskell.org/trac/gtk2hs/ticket/1165 In case it makes any difference to you. :-) From andrewcoppin at btinternet.com Sat Dec 5 14:14:17 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 13:48:43 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <924926435.20091205191516@gmail.com> References: <4B1A7EE7.70807@btinternet.com> <924926435.20091205191516@gmail.com> Message-ID: <4B1AB109.4080907@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Saturday, December 5, 2009, 6:40:23 PM, you wrote: > > >> prominent?) Somebody pointed out this bug 6 months ago. Somebody else >> posted a potential fix a month ago. There is no visible activity from >> the developers. >> > > Developer. many Haskell problems is due to the fact that we have a few > volunteers doing things and lot of consumers begging for features :) > That *does* in fact seem to be a recurring problem, yes. Now, how to fix this...? >> Gtk2hs is currently the *only* GUI binding that actually works on >> Windows. >> > > i thought that wx and even qt are in rather good shape now > I did try to get wxHaskell going once or twice. And the SDL binding. (I wasn't aware we have Qt now...) I've never got any of them to work yet. :-( Interestingly, while you can't compile bindings to external C libraries, GHC does appear to ship with all the header files for Windows, which is odd. It seems if you try to FFI to a standard Win32 function, it magically knows where the hell the header files are, and it Just Works(tm). Hell, I even followed a C++ guide to Win32 programming and managed to translate an "open a blank window" program to Haskell, and it worked. Maybe somebody just needs to sit down and write a nice binding for doing native GUI stuff under Win32? From wren at freegeek.org Sat Dec 5 14:47:07 2009 From: wren at freegeek.org (wren ng thornton) Date: Sat Dec 5 14:16:16 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <4B1A7FE7.1080707@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> Message-ID: <4B1AB8BB.8050401@freegeek.org> Andrew Coppin wrote: > Unfortunately, I've yet to find a single Haskell package that binds to C > which will actually compile on Windows. :-( Take a look at logfloat[1], it builds cleanly on Windows XP using GHC 6.10.1 without needing Cygwin nor Mingw/Msys (however GHCi has some DLL errors[2]). Not that that has anything to do with audio ;) [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat [2] If you know how to resolve these, I'd be much obliged. I don't have a Windows machine to test on but I've been much irked that there's still this outstanding portability bug. -- Live well, ~wren From bulat.ziganshin at gmail.com Sat Dec 5 14:36:51 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Dec 5 14:18:57 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <4B1AB109.4080907@btinternet.com> References: <4B1A7EE7.70807@btinternet.com> <924926435.20091205191516@gmail.com> <4B1AB109.4080907@btinternet.com> Message-ID: <1297085518.20091205223651@gmail.com> Hello Andrew, Saturday, December 5, 2009, 10:14:17 PM, you wrote: > I did try to get wxHaskell going once or twice. And the SDL binding. (I > wasn't aware we have Qt now...) I've never got any of them to work yet. it depends on when you have tried. wx made significant progress in last year or two -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From daniel.is.fischer at web.de Sat Dec 5 14:44:14 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 14:20:16 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <4B1AB109.4080907@btinternet.com> References: <4B1A7EE7.70807@btinternet.com> <924926435.20091205191516@gmail.com> <4B1AB109.4080907@btinternet.com> Message-ID: <200912052044.14713.daniel.is.fischer@web.de> Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin: > Bulat Ziganshin wrote: > > Hello Andrew, > > > > Saturday, December 5, 2009, 6:40:23 PM, you wrote: > >> prominent?) Somebody pointed out this bug 6 months ago. Somebody else > >> posted a potential fix a month ago. There is no visible activity from > >> the developers. > > > > Developer. many Haskell problems is due to the fact that we have a few > > volunteers doing things and lot of consumers begging for features :) > > That *does* in fact seem to be a recurring problem, yes. > > Now, how to fix this...? How about: get the sources, try proposed fix, if it works, send Duncan(*) the patch? Even better, become a gtk2hs developer yourself (though that's more work and probably requires some serious knowledge of gtk). (*) for gtk2hs, would be somebody else for other packages of course. > > >> Gtk2hs is currently the *only* GUI binding that actually works on > >> Windows. > > > > i thought that wx and even qt are in rather good shape now > > I did try to get wxHaskell going once or twice. And the SDL binding. (I > wasn't aware we have Qt now...) I've never got any of them to work yet. :-( > > Interestingly, while you can't compile bindings to external C libraries, > GHC does appear to ship with all the header files for Windows, which is > odd. It seems if you try to FFI to a standard Win32 function, it > magically knows where the hell the header files are, and it Just > Works(tm). Hell, I even followed a C++ guide to Win32 programming and > managed to translate an "open a blank window" program to Haskell, and it > worked. Maybe somebody just needs to sit down and write a nice binding > for doing native GUI stuff under Win32? > Maybe you could try to be that somebody? I'm sure the Windows folks would appreciate it very much. Or, if you think that's beyond your ken, try organising the writing. Perhaps create a windows-haskell mailing list where Windows users can help each other making things work on Windows. From chaddai.fouche at gmail.com Sat Dec 5 14:46:04 2009 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Sat Dec 5 14:20:39 2009 Subject: [Haskell-cafe] Haskell-Newbie and Char-Function In-Reply-To: <4B1A80CA.2000904@functor.nl> References: <26656676.post@talk.nabble.com> <4B1A80CA.2000904@functor.nl> Message-ID: On Sat, Dec 5, 2009 at 4:48 PM, Jochem Berndsen wrote: > MeAdAstra wrote: >> Hi guys, >> I only started learning Haskell some days ago. Maybe one of you can give me >> a hint on how to implement a function that needs a character in the range >> (a,b,...z) and an integer number k and returns the k-next neighbor of the >> character? For example, fct a 5 would result in output f. > > You might want to use the functions ord and chr from Data.Char, and the > mod function from the Prelude. Right, and by the way I would suggest you reverse the parameter order of your function so that it takes the shift first, then you can write : > shift :: Int -> Char -> Char > shift n c ... > > rot13 :: String -> String > rot13 = map (shift 13) -- Jeda? From stephen.tetley at gmail.com Sat Dec 5 14:54:32 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 5 14:29:04 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <4B1AB109.4080907@btinternet.com> References: <4B1A7EE7.70807@btinternet.com> <924926435.20091205191516@gmail.com> <4B1AB109.4080907@btinternet.com> Message-ID: <5fdc56d70912051154q4c7e664ct327366c183d2d2d@mail.gmail.com> 2009/12/5 Andrew Coppin : > Interestingly, while you can't compile bindings to external C libraries, Ah Mr Coppin, maybe you should change "you" to "I". I had (Haskell bindings) SDL-0.5.3 working August last year - so I think I would be using GHC 6.8.3 at that time, the version of the SDL C library was 1.2.13. SDL has no prepared package in the Cygwin package manager, so you have to download it yourself. I seem to remember it being more tricky to get SDL working under Cygwin as a C library (you need extra DirectX header files at least), than it was to compile the Haskell binding once the C library was working. Instructions for compiling the C library for Cygwin are on the SDL website. I haven't tried it since as I don't need SDL for anything I do, but don't I think it would be any harder (lemmih's binding seems to be pretty stable and at the time I used it, it was impressively tidy). Best wishes again Stephen From andrewcoppin at btinternet.com Sat Dec 5 15:31:39 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 15:06:05 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <200912052044.14713.daniel.is.fischer@web.de> References: <4B1A7EE7.70807@btinternet.com> <924926435.20091205191516@gmail.com> <4B1AB109.4080907@btinternet.com> <200912052044.14713.daniel.is.fischer@web.de> Message-ID: <4B1AC32B.6040204@btinternet.com> Daniel Fischer wrote: > Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin: > >> Bulat Ziganshin wrote: >> >>> Developer. many Haskell problems is due to the fact that we have a few >>> volunteers doing things and lot of consumers begging for features :) >>> >> That *does* in fact seem to be a recurring problem, yes. >> >> Now, how to fix this...? >> > > How about: > > get the sources, try proposed fix, if it works, send Duncan(*) the patch? > Even better, become a gtk2hs developer yourself (though that's more work and probably > requires some serious knowledge of gtk). > In order to do this, I'd have to know how to build Gtk2hs from source on Windows. I imagine this is quite nontrivial. >> Interestingly, while you can't compile bindings to external C libraries, >> GHC does appear to ship with all the header files for Windows, which is >> odd. It seems if you try to FFI to a standard Win32 function, it >> magically knows where the hell the header files are, and it Just >> Works(tm). Hell, I even followed a C++ guide to Win32 programming and >> managed to translate an "open a blank window" program to Haskell, and it >> worked. Maybe somebody just needs to sit down and write a nice binding >> for doing native GUI stuff under Win32? >> >> > Maybe you could try to be that somebody? I'm sure the Windows folks would appreciate it > very much The thought has certainly crossed my mind. If I could write such a package, I imagine a lot of people would find it seriously useful. Native Windows GUI programs, without any 3rd party DLLs to distribute with your compiled binary... It'd be great, wouldn't it? Of course, thinking about how great it would be doesn't get the code written. ;-) I'd have to learn how to call Win32 from C first, for a start... o_O The various I/O libraries sometimes return weird results, and I'm told this is because GHC is using the emulated POSIX interfaces rather than native Win32 calls. I did think about turning my attention to fixing that. However, I notice the next version of GHC seems to have a radically reworked set of I/O libraries, so maybe it's already fixed? From andrewcoppin at btinternet.com Sat Dec 5 15:33:15 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 15:07:40 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> Message-ID: <4B1AC38B.7090507@btinternet.com> Stephen Tetley wrote: > Hello Andrew > > Plenty compile on Windows: > > Some OpenVG, OpenGL[1] (still? - I'm a bit behind the times) only > compile with MinGW. > > Others are fine with Cygwin provided you have the dev packages > installed (readline, pcre-light...). > You're talking about MinGW and Cygwin. So... Unix emulators, basically. I don't think it should be necessary to install a Unix emulator just so that I can write Windows programs. Maybe others disagree. > If you can get the raw C library to work in either Cygwin or MinGW, > you should have a good chance. I'm by no means an expert here, but isn't it usual for C libraries on Windows to be supplied as a compiled DLL and a header file for using it? I don't quite understand why you need a C compiler. > [1] OpenGL worked fine when it was bundled with GHC, when it got > unbundled things seemed to go amiss. Apparently there is some talk of removing OpenGL from the Haskell Platform. And if this happens, it'll be one more thing I can't use on Windows. :-( Personally, I'd like to see *more* C bindings in HP, so that I can start doing cool stuff on Windows. From pepeiborra at gmail.com Sat Dec 5 15:33:10 2009 From: pepeiborra at gmail.com (=?iso-8859-1?Q?Jos=E9_Iborra?=) Date: Sat Dec 5 15:07:50 2009 Subject: [Haskell-cafe] Avoiding undecidables In-Reply-To: <29bf512f0912050958u1ce1cc8bo870b1333912b8543@mail.gmail.com> References: <29bf512f0912050958u1ce1cc8bo870b1333912b8543@mail.gmail.com> Message-ID: <5B134F5C-3650-4B0E-84B2-035F60C56966@gmail.com> On Dec 5, 2009, at 6:58 PM, Michael Snoyman wrote: > Hi all, > > Well, I've got two problems which both want to be solved with undecidable and overlapping instances. Obviously, I'd like to try and avoid them. For the record, the problems have to do with the control-monad-failure and convertible packages. The code below *should* make clear what I'm trying to accomplish: > > -- failure should not be limited to just monads, so... > class Failure e f where > failure :: e -> f v > class (Functor f, Failure e f) => FunctorFailure e f > instance (Functor f, Failure e f) => FunctorFailure e f -- undecidable, overlaps > class (Applicative f, Failure e f) => ApplicativeFailure e f > instance (Applicative f, Failure e f) => ApplicativeFailure e f -- undecidable, overlaps > class (Monad f, Failure e f) => MonadFailure e f > instance (Monad f, Failure e f) => MonadFailure e f -- undecidable, overlaps > (Functor|Monad|Applicative)Failure are little more than class synonyms, right ? Or equivalently, do you envision the need of writing, say, a MonadFailure instance for a type A which which works differently than the existing Failure instance for A? If the answer is no as I presume, then you don't want overlapping instances. Regarding undecidable instances, I will say that from my point of view they do not constitute a language extension. MPTCs are the language extension here. Since MPTCs can lead to non-terminating type checking, a compiler can either allow any use of them, employ a termination prover to ensure that only well-behaved instances are defined, or impose a set of restrictions that ensure termination. GHC does the latter, rather conservatively in some cases, and undecidable instances is just a compiler flag that puts the burden of termination checking on the user. In this case it is obvious that non-termination is not going to be a problem for the instances defined above. Since you have already decided MPTCs are ok, in my opinion undecidable instances are fine here. But I realize this is not the usual stance, so I might be wrong. > And now the convertible issue. I want two type classes: Convert for anything which *might* be convertible, but might not. For example, sometimes a String can be converted to an Int (like the string "5"), but sometimes it will fail (like "five"). TotalConvert is when something *is* convertible, such as Int to String (simply the show function). Thus the following: > > class Convert x y where > convert :: x -> Maybe y > class Convert x y => TotalConvert x y where > totalConvert :: x -> y > instance TotalConvert x y => Convert x y where -- Boom! > convert = Just . totalConvert In this case Convert is not just a class synonym, so you are going to run into trouble with that code. I would do this as follows: class Convert x y => TotalConvert x y where totalConvert :: x -> y totalConvert = fromJust . convert For instance, instance Convert Integer Double where convert = Just . fromIntegral instance TotalConvert Double -- that's all Cheers, pepe From miguelimo38 at yandex.ru Sat Dec 5 15:43:13 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Dec 5 15:17:48 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <4B1AC38B.7090507@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> Message-ID: <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> I'm constantly amused by those who manage to use Windows without installing Cygwin. On 5 Dec 2009, at 23:33, Andrew Coppin wrote: > Stephen Tetley wrote: >> Hello Andrew >> >> Plenty compile on Windows: >> >> Some OpenVG, OpenGL[1] (still? - I'm a bit behind the times) only >> compile with MinGW. >> >> Others are fine with Cygwin provided you have the dev packages >> installed (readline, pcre-light...). >> > > You're talking about MinGW and Cygwin. So... Unix emulators, > basically. > > I don't think it should be necessary to install a Unix emulator just > so that I can write Windows programs. Maybe others disagree. > >> If you can get the raw C library to work in either Cygwin or MinGW, >> you should have a good chance. > > I'm by no means an expert here, but isn't it usual for C libraries > on Windows to be supplied as a compiled DLL and a header file for > using it? I don't quite understand why you need a C compiler. > >> [1] OpenGL worked fine when it was bundled with GHC, when it got >> unbundled things seemed to go amiss. > > Apparently there is some talk of removing OpenGL from the Haskell > Platform. And if this happens, it'll be one more thing I can't use > on Windows. :-( > > Personally, I'd like to see *more* C bindings in HP, so that I can > start doing cool stuff on Windows. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From me at rkit.pp.ru Sat Dec 5 16:02:11 2009 From: me at rkit.pp.ru (=?windows-1252?Q?=3F=3F=3F=3F=3F=3F=3F_=3F=3F=3F=3F=3F=3F?=) Date: Sat Dec 5 15:21:57 2009 Subject: [Haskell-cafe] Haskell-Newbie and Char-Function In-Reply-To: <26656676.post@talk.nabble.com> References: <26656676.post@talk.nabble.com> Message-ID: <4B1ACA53.7040503@rkit.pp.ru> fct a n = (snd $ break (==a) ['a'..'z']) !! n > Hi guys, > I only started learning Haskell some days ago. Maybe one of you can give me > a hint on how to implement a function that needs a character in the range > (a,b,...z) and an integer number k and returns the k-next neighbor of the > character? For example, fct a 5 would result in output f. > > Tobias > From michael at snoyman.com Sat Dec 5 15:51:26 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 15:25:59 2009 Subject: [Haskell-cafe] Avoiding undecidables In-Reply-To: <5B134F5C-3650-4B0E-84B2-035F60C56966@gmail.com> References: <29bf512f0912050958u1ce1cc8bo870b1333912b8543@mail.gmail.com> <5B134F5C-3650-4B0E-84B2-035F60C56966@gmail.com> Message-ID: <29bf512f0912051251u74d246afxafdfb9e5ea24342c@mail.gmail.com> On Sat, Dec 5, 2009 at 10:33 PM, Jos? Iborra wrote: > > On Dec 5, 2009, at 6:58 PM, Michael Snoyman wrote: > > > Hi all, > > > > Well, I've got two problems which both want to be solved with undecidable > and overlapping instances. Obviously, I'd like to try and avoid them. For > the record, the problems have to do with the control-monad-failure and > convertible packages. The code below *should* make clear what I'm trying to > accomplish: > > > > -- failure should not be limited to just monads, so... > > class Failure e f where > > failure :: e -> f v > > class (Functor f, Failure e f) => FunctorFailure e f > > instance (Functor f, Failure e f) => FunctorFailure e f -- undecidable, > overlaps > > class (Applicative f, Failure e f) => ApplicativeFailure e f > > instance (Applicative f, Failure e f) => ApplicativeFailure e f -- > undecidable, overlaps > > class (Monad f, Failure e f) => MonadFailure e f > > instance (Monad f, Failure e f) => MonadFailure e f -- undecidable, > overlaps > > > > (Functor|Monad|Applicative)Failure are little more than class synonyms, > right ? > Or equivalently, do you envision the need of writing, say, a MonadFailure > instance for a type A which which works differently than the existing > Failure instance for A? > If the answer is no as I presume, then you don't want overlapping > instances. > > Regarding undecidable instances, I will say that from my point of view they > do not constitute a language extension. > MPTCs are the language extension here. Since MPTCs can lead to > non-terminating type checking, > a compiler can either allow any use of them, employ a termination prover to > ensure that only well-behaved instances are defined, > or impose a set of restrictions that ensure termination. GHC does the > latter, rather conservatively in some cases, and undecidable > instances is just a compiler flag that puts the burden of termination > checking on the user. > > In this case it is obvious that non-termination is not going to be a > problem for the instances defined above. > Since you have already decided MPTCs are ok, in my opinion undecidable > instances are fine here. > But I realize this is not the usual stance, so I might be wrong. > > Sounds reasonable to me. I'm waiting for the boogey man to jump out though and explain why undecidables here will get me gored to death by a raptor [1]. > > > And now the convertible issue. I want two type classes: Convert for > anything which *might* be convertible, but might not. For example, sometimes > a String can be converted to an Int (like the string "5"), but sometimes it > will fail (like "five"). TotalConvert is when something *is* convertible, > such as Int to String (simply the show function). Thus the following: > > > > class Convert x y where > > convert :: x -> Maybe y > > class Convert x y => TotalConvert x y where > > totalConvert :: x -> y > > instance TotalConvert x y => Convert x y where -- Boom! > > convert = Just . totalConvert > > > In this case Convert is not just a class synonym, so you are going to run > into trouble with that code. > > I would do this as follows: > > class Convert x y => TotalConvert x y where > totalConvert :: x -> y > totalConvert = fromJust . convert > > For instance, > > instance Convert Integer Double where convert = Just . fromIntegral > instance TotalConvert Double -- that's all > > Interestng approach. The current approach is *almost* the same, just leaves off the default definition. I'd be wary of putting in a definition like that; although it saves a line of typing, it let's a partial function get in which could cause trouble for unsuspecting users. But it is a possibility. > > Cheers, > pepe [1] http://xkcd.com/292/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/4682b2d8/attachment.html From stephen.tetley at gmail.com Sat Dec 5 15:58:14 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 5 15:32:46 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <4B1AC38B.7090507@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> Message-ID: <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> Hi Andrew 2009/12/5 Andrew Coppin : > I don't think it should be necessary to install a Unix emulator just so that > I can write Windows programs. Maybe others disagree. > ... > > I'm by no means an expert here, but isn't it usual for C libraries on > Windows to be supplied as a compiled DLL and a header file for using it? I > don't quite understand why you need a C compiler. The thing is, all the bindings on Hackage (or at least something most likely above 95%) are to "Unix" C libraries so you need a C compiler and a Unix emulator to use them. I do have have some sympathy with your point though - it is possible to get things to compile once you have Cygwin, but deployment on any other machine Windows thereafter is 'challenging' to say the least. > Apparently there is some talk of removing OpenGL from the Haskell Platform. > And if this happens, it'll be one more thing I can't use on Windows. :-( I didn't realise until I looked today that OpenGL was in the Haskell Platform. If the proposal to remove it is from Sven Panne then fair enough, otherwise it would be a bit disappointing - it always "just worked" when it was part of GHCs extralibs... Best wishes Stephen From ekirpichov at gmail.com Sat Dec 5 16:00:51 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Sat Dec 5 15:35:22 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> Message-ID: <5e0214850912051300r3ebd0e44n61a4d6e020c94f4c@mail.gmail.com> 2009/12/5 Stefan Holdermans : > Eugene, > >> Consider the type: (forall a . a) -> String. > > It's of rank 2. > >> What is the definition of rank of a polymorphic type? > > The minimal rank of a type is given by > > ?rank (forall a. t) = 1 `max` rank t > ?rank (t -> u) ? ? ?= (if rank t == 0 then 0 else rank t + 1) `max` rank u > ?rank _ ? ? ? ? ? ? = 0 > Thanks! 1) Does there exist an authoritative source saying the same? Not that I'm doubting, just supposing that the source would have other interesting information, too :) 2) Is it true that rank (forall a . a, forall a . a) == 0 ? > HTH, > > ?Stefan > -- Eugene Kirpichov Web IR developer, market.yandex.ru From andrewcoppin at btinternet.com Sat Dec 5 16:14:40 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 15:49:07 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> Message-ID: <4B1ACD40.3040507@btinternet.com> Miguel Mitrofanov wrote: > I'm constantly amused by those who manage to use Windows without > installing Cygwin. I'm constantly puzzled by those who think that Cygwin is a mandatory part of Windows. ;-) From daniel.is.fischer at web.de Sat Dec 5 16:20:00 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 15:56:53 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <4B1AC32B.6040204@btinternet.com> References: <4B1A7EE7.70807@btinternet.com> <200912052044.14713.daniel.is.fischer@web.de> <4B1AC32B.6040204@btinternet.com> Message-ID: <200912052220.00317.daniel.is.fischer@web.de> Am Samstag 05 Dezember 2009 21:31:39 schrieb Andrew Coppin: > Daniel Fischer wrote: > > Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin: > >> Bulat Ziganshin wrote: > >>> Developer. many Haskell problems is due to the fact that we have a few > >>> volunteers doing things and lot of consumers begging for features :) > >> > >> That *does* in fact seem to be a recurring problem, yes. > >> > >> Now, how to fix this...? > > > > How about: > > > > get the sources, try proposed fix, if it works, send Duncan(*) the patch? > > Even better, become a gtk2hs developer yourself (though that's more work > > and probably requires some serious knowledge of gtk). > > In order to do this, I'd have to know how to build Gtk2hs from source on > Windows. I imagine this is quite nontrivial. I thought in this case, it was a proposed change in the installer, so you'd only have to change that and could leave the gtk2hs binary untouched. Of course that can only work if Windows installers are some sort of script or otherwise customisable. Are they? > > >> Interestingly, while you can't compile bindings to external C libraries, > >> GHC does appear to ship with all the header files for Windows, which is > >> odd. It seems if you try to FFI to a standard Win32 function, it > >> magically knows where the hell the header files are, and it Just > >> Works(tm). Hell, I even followed a C++ guide to Win32 programming and > >> managed to translate an "open a blank window" program to Haskell, and it > >> worked. Maybe somebody just needs to sit down and write a nice binding > >> for doing native GUI stuff under Win32? > > > > Maybe you could try to be that somebody? I'm sure the Windows folks would > > appreciate it very much > > The thought has certainly crossed my mind. If I could write such a > package, I imagine a lot of people would find it seriously useful. > Native Windows GUI programs, without any 3rd party DLLs to distribute > with your compiled binary... It'd be great, wouldn't it? > > Of course, thinking about how great it would be doesn't get the code > written. ;-) I'd have to learn how to call Win32 from C first, for a > start... o_O Yes, of course, ultra posse nemo obligatur. As long as you can't do something, you can only hope somebody else can and does. From daniel.is.fischer at web.de Sat Dec 5 16:25:28 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 16:01:29 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> Message-ID: <200912052225.28597.daniel.is.fischer@web.de> Am Samstag 05 Dezember 2009 21:43:13 schrieb Miguel Mitrofanov: > I'm constantly amused by those who manage to use Windows without ? > installing Cygwin. I'm constantly amazed by those who manage to use Windows. (In case you want to misunderstand, it's not a Windows bashing, I just never managed to work with it) From byorgey at seas.upenn.edu Sat Dec 5 16:28:49 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Dec 5 16:03:19 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> Message-ID: <20091205212848.GA23711@seas.upenn.edu> On Thu, Dec 03, 2009 at 01:50:06PM -0800, Gregory Crosswhite wrote: > > Or, even more concisely: > > ================================================== > sumWithError_3 = liftM2 (+) > ================================================== > > Unfortunately though, neither of these definitions have the same semantics as the original @sumWithError@, as using both we get the following error message for @showSumOrErrorOf (-1) (-2)@: > > ================================================== > Error computing the square root of -1: > Square roots cannot be taken of negative numbers. > ================================================== > > That is, we have lost the second of the two error messages. The reason for this is that 'Monad'-style error processing expresses the computation as a sequence, and gives up as soon as it sees any error. In this case of @sumWithError@, however, the evaluation of the second argument can proceed even if there was an error in the first argument. Thus, rather than using a 'Monad' pattern, we use an 'Applicative' pattern: > > ================================================== > sumWithError_4 = liftA2 (+) > ================================================== > > Now both error messages are displayed. I see no inherent reason that liftM2 (+) cannot collect both error messages. No one says that "monad-style error processing" *must* stop as soon as it sees an error. And having different semantics for liftA2 and liftM2 (etc.) is strange at best. They ought to be equivalent for any type constructor with both Monad and Applicative instances. -Brent From hgolden at socal.rr.com Sat Dec 5 16:36:13 2009 From: hgolden at socal.rr.com (Howard B. Golden) Date: Sat Dec 5 16:10:47 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: <20091205044252.E4A0A324385@www.haskell.org> References: <20091205044252.E4A0A324385@www.haskell.org> Message-ID: <200912051336.13792.hgolden@socal.rr.com> On Friday December 4, 2009, John MacFarlane wrote: > I used criterion to compare pandoc compiled with parsec2 to > pandoc compiled with your version of parsec3. (The benchmark > is converting testsuite.txt from markdown to HTML.) The difference > was minor: > > parsec2: > mean: 67.66576 ms, lb 67.56722 ms, ub 67.88983 ms, ci 0.950 > std dev: 722.3878 us, lb 323.0343 us, ub 1.356013 ms, ci 0.950 > > parsec3: > mean: 68.20847 ms, lb 68.16387 ms, ub 68.26284 ms, ci 0.950 > std dev: 252.7773 us, lb 204.5512 us, ub 325.2424 us, ci 0.950 > > So, once you release the new parsec3, I am prepared to remove the > "parsec < 3" restriction from the libraries I maintain: pandoc, > highlighting-kate, filestore, gitit, and yst. I don't know what the performance of the current parsec3 is compared to parsec2. It would be helpful if you could run your benchmark for that also and include it. If the only issue is performance, I respectfully request that you remove the parsec < 3 requirement even before the new version of parsec3 is released. Thank you. Howard From daniel.is.fischer at web.de Sat Dec 5 16:43:03 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 16:19:02 2009 Subject: [Haskell-cafe] Avoiding undecidables In-Reply-To: <29bf512f0912051251u74d246afxafdfb9e5ea24342c@mail.gmail.com> References: <29bf512f0912050958u1ce1cc8bo870b1333912b8543@mail.gmail.com> <5B134F5C-3650-4B0E-84B2-035F60C56966@gmail.com> <29bf512f0912051251u74d246afxafdfb9e5ea24342c@mail.gmail.com> Message-ID: <200912052243.03144.daniel.is.fischer@web.de> Am Samstag 05 Dezember 2009 21:51:26 schrieb Michael Snoyman: > On Sat, Dec 5, 2009 at 10:33 PM, Jos? Iborra wrote: > > Since you have already decided MPTCs are ok, in my opinion undecidable > > instances are fine here. > > But I realize this is not the usual stance, so I might be wrong. > > As far as I understand, all UndecidableInstances does is tell the compiler "Maybe instance checking won't terminate, try anyway", so they're dangerous *only during compilation*, once things compile, everything's dandy. > Sounds reasonable to me. I'm waiting for the boogey man to jump out > though > > and explain why undecidables here will get me gored to death by a raptor > [1]. They won't. They might suck you into a black hole, but raptors are very specialised. > > > > instance Convert Integer Double where convert = Just . fromIntegral > > instance TotalConvert Double -- that's all instance TotalConvert Integer Double > > > Interestng approach. The current approach is *almost* the same, just > leaves > > off the default definition. I'd be wary of putting in a definition like > that; although it saves a line of typing, it let's a partial function get > in which could cause trouble for unsuspecting users. But it is a > possibility. But only if they declare misbehaved instances of TotalConvert. Whenever a reasonable instance TotalConvert x y exists, the Convert instance should satisfy the demands of the default definition. > > > Cheers, > > pepe > > [1] http://xkcd.com/292/ From stefan at cs.uu.nl Sat Dec 5 16:57:01 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sat Dec 5 16:31:29 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <5e0214850912051300r3ebd0e44n61a4d6e020c94f4c@mail.gmail.com> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> <5e0214850912051300r3ebd0e44n61a4d6e020c94f4c@mail.gmail.com> Message-ID: <0B59A706-8C41-47B9-A858-5ACE297581E1@cs.uu.nl> Eugene, > 1) Does there exist an authoritative source saying the same? Not that > I'm doubting, just supposing that the source would have other > interesting information, too :) You may want to have a look at the already mentioned JFP-article by Peyton Jones et al. and perhaps the work of Kfoury and Wells. > 2) Is it true that rank (forall a . a, forall a . a) == 0 ? No, for pairs one takes the maximum of the constituent types. So, here you'd get rank 1. Note that this is an impredicative type, which is yet another extension of the standard Hindley-Milner typing discipline. Cheers, Stefan > >> From jgm at berkeley.edu Sat Dec 5 16:57:07 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Sat Dec 5 16:33:04 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: <200912051336.13792.hgolden@socal.rr.com> References: <20091205044252.E4A0A324385@www.haskell.org> <200912051336.13792.hgolden@socal.rr.com> Message-ID: <20091205215707.GA6161@protagoras.phil.berkeley.edu> +++ Howard B. Golden [Dec 05 09 13:36 ]: > On Friday December 4, 2009, John MacFarlane wrote: > > > I used criterion to compare pandoc compiled with parsec2 to > > pandoc compiled with your version of parsec3. (The benchmark > > is converting testsuite.txt from markdown to HTML.) The difference > > was minor: > > > > parsec2: > > mean: 67.66576 ms, lb 67.56722 ms, ub 67.88983 ms, ci 0.950 > > std dev: 722.3878 us, lb 323.0343 us, ub 1.356013 ms, ci 0.950 > > > > parsec3: > > mean: 68.20847 ms, lb 68.16387 ms, ub 68.26284 ms, ci 0.950 > > std dev: 252.7773 us, lb 204.5512 us, ub 325.2424 us, ci 0.950 > > > > So, once you release the new parsec3, I am prepared to remove the > > "parsec < 3" restriction from the libraries I maintain: pandoc, > > highlighting-kate, filestore, gitit, and yst. > > I don't know what the performance of the current parsec3 is compared to > parsec2. It would be helpful if you could run your benchmark for that > also and include it. parsec 2.1.0.1 from HackageDB: mean: 67.71456 ms, lb 67.65181 ms, ub 67.82660 ms, ci 0.950 std dev: 416.1303 us, lb 274.0063 us, ub 761.6995 us, ci 0.950 parsec 3.0.1 from HackageDB: mean: 188.5380 ms, lb 188.3217 ms, ub 188.7615 ms, ci 0.950 std dev: 1.136199 ms, lb 964.3489 us, ub 1.366720 ms, ci 0.950 parsec 3.0.1 from Antoine: mean: 69.29665 ms, lb 69.22450 ms, ub 69.48016 ms, ci 0.950 std dev: 551.3562 us, lb 263.7954 us, ub 1.156183 ms, ci 0.950 > If the only issue is performance, I respectfully request that you remove > the parsec < 3 requirement even before the new version of parsec3 is > released. Thank you. Sorry, I don't want to do that. Lots of people have both parsec-2 and parsec-3 installed, and if I remove the restriction, their pandoc (and gitit and...) will be much slower unless they take special steps. John From functionallyharmonious at yahoo.com Sat Dec 5 17:00:01 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 16:34:34 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <200912052220.00317.daniel.is.fischer@web.de> Message-ID: <471726.55822.qm@web113106.mail.gq1.yahoo.com> --- On Sat, 12/5/09, Daniel Fischer wrote: I thought in this case, it was a proposed change in the installer, so you'd only have to change that and could leave the gtk2hs binary untouched. Of course that can only work if Windows installers are some sort of script or otherwise customisable. Are they? If they used a tool like NSIS then it would be as easy as modifying the script. I emailed a Gtk developer offering to help if that were the case. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/57309846/attachment.html From andrewcoppin at btinternet.com Sat Dec 5 17:00:27 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 16:34:54 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <200912052225.28597.daniel.is.fischer@web.de> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> <200912052225.28597.daniel.is.fischer@web.de> Message-ID: <4B1AD7FB.8050704@btinternet.com> Daniel Fischer wrote: > I'm constantly amazed by those who manage to use Windows. > > > (In case you want to misunderstand, it's not a Windows bashing, I just never managed to > work with it I've not had a lot of luck with Linux. I imagine this is merely due to having a lot more experience with Windows. FWIW, I used to hate Windows too - AmigaOS is far nicer. ;-) But now we're drifting wildly off-topic. For better or worse, Windows is the most popular desktop OS currently. From stephen.tetley at gmail.com Sat Dec 5 17:00:53 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 5 16:35:26 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <447258.47845.qm@web113101.mail.gq1.yahoo.com> References: <447258.47845.qm@web113101.mail.gq1.yahoo.com> Message-ID: <5fdc56d70912051400h663a25a9w4f9b2e065a5b395e@mail.gmail.com> Compiling the C PortAudio library for either Cygwin or MinGW will be challenging at the moment. The current release doesn't compile as is, and although there should be patch for the configure script as an attachment to this message it seems to have gone amiss: http://music.columbia.edu/pipermail/portaudio/2009-May/009116.html I'd look for a different library to talk to the sound card... Best wishes Stephen 2009/12/4 M Xyz > > What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? > > I think the portaudio library is the only contender but when I try to install it I get: > From miguelimo38 at yandex.ru Sat Dec 5 17:02:13 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Dec 5 16:36:53 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <4B1AD7FB.8050704@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> <200912052225.28597.daniel.is.fischer@web.de> <4B1AD7FB.8050704@btinternet.com> Message-ID: <1B613EE3-B4F8-4F6E-8A36-74BACF0C86FC@yandex.ru> Try Mac. On 6 Dec 2009, at 01:00, Andrew Coppin wrote: > Daniel Fischer wrote: >> I'm constantly amazed by those who manage to use Windows. >> >> >> (In case you want to misunderstand, it's not a Windows bashing, I >> just never managed to work with it > > I've not had a lot of luck with Linux. I imagine this is merely due > to having a lot more experience with Windows. > > FWIW, I used to hate Windows too - AmigaOS is far nicer. ;-) > > But now we're drifting wildly off-topic. For better or worse, > Windows is the most popular desktop OS currently. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From andrewcoppin at btinternet.com Sat Dec 5 17:09:18 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Dec 5 16:43:43 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <1B613EE3-B4F8-4F6E-8A36-74BACF0C86FC@yandex.ru> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> <200912052225.28597.daniel.is.fischer@web.de> <4B1AD7FB.8050704@btinternet.com> <1B613EE3-B4F8-4F6E-8A36-74BACF0C86FC@yandex.ru> Message-ID: <4B1ADA0E.5070207@btinternet.com> Miguel Mitrofanov wrote: > Try Mac. > > You're not the first to suggest this either. ;-) Maybe once I get hired by some financial modelling consultants and get paid shedloads of money to write Haskell all day, I'll be able to afford a Mac. But until then... From gcross at phys.washington.edu Sat Dec 5 17:13:10 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Sat Dec 5 16:48:05 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <20091205212848.GA23711@seas.upenn.edu> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> <20091205212848.GA23711@seas.upenn.edu> Message-ID: <36C40624-B050-4A8C-8CAF-F15D84467180@phys.washington.edu> Recall that the definition of liftM2 is ================================================== liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) } ================================================== which, if I understand correctly, desugars to ================================================== liftM2 f m1 m2 = m1 >>= ( \x1 -> m2 >>= ( \x2 -> return (f x1 x2) ) ) ================================================== The problem comes from the fact that >>= takes a *function* as its second argument, and so if the first argument is an error then we can't evaluate the second argument in order to see if it has an error as well. For example, consider the following script: =================================================== import Control.Applicative import Control.Monad import Data.ErrorMessage newtype E a = E (Either String a) instance Functor E where fmap _ (E (Left error)) = E (Left error) fmap f (E (Right argument)) = E (Right (f argument)) instance Applicative E where pure = E . Right (<*>) (E (Left error2)) (E (Left error1)) = E (Left (error1 ++ error2)) (<*>) (E (Left error)) _ = E (Left error) (<*>) _ (E (Left error)) = E (Left error) (<*>) (E (Right function)) (E (Right argument)) = E (Right (function argument)) instance Monad E where return = E . Right E (Left l) >>= _ = E (Left l) E (Right r) >>= f = f r fail msg = E (Left msg) sum_using_monad :: Either String Int (E sum_using_monad) = (liftM2 (+)) (E (Left "A")) (E (Left "B")) sum_using_applicative :: Either String Int (E sum_using_applicative) = (liftA2 (+)) (E (Left "A")) (E (Left "B")) main = do putStrLn . show $ sum_using_monad putStrLn . show $ sum_using_applicative =================================================== (Sorry about all of the annoying E's; I needed to do this in order to override the instance declaration for Either String.) Run this script and you will see: Left "A" Left "BA" Thus, the difference in the semantics is inherent from the way that >>= and liftM2 are defined. The only way that I can think to get around this is change the definition of >>= so that if the first argument is an error then it calls the second argument with "undefined"; if this returns a (Left error) then combine the two errors, and if it returns anything else or throws an exception (e.g. Prelude.undefined) then ignore it and just return the first argument. Cheers, Greg On Dec 5, 2009, at 1:28 PM, Brent Yorgey wrote: > On Thu, Dec 03, 2009 at 01:50:06PM -0800, Gregory Crosswhite wrote: >> >> Or, even more concisely: >> >> ================================================== >> sumWithError_3 = liftM2 (+) >> ================================================== >> >> Unfortunately though, neither of these definitions have the same semantics as the original @sumWithError@, as using both we get the following error message for @showSumOrErrorOf (-1) (-2)@: >> >> ================================================== >> Error computing the square root of -1: >> Square roots cannot be taken of negative numbers. >> ================================================== >> >> That is, we have lost the second of the two error messages. The reason for this is that 'Monad'-style error processing expresses the computation as a sequence, and gives up as soon as it sees any error. In this case of @sumWithError@, however, the evaluation of the second argument can proceed even if there was an error in the first argument. Thus, rather than using a 'Monad' pattern, we use an 'Applicative' pattern: >> >> ================================================== >> sumWithError_4 = liftA2 (+) >> ================================================== >> >> Now both error messages are displayed. > > I see no inherent reason that liftM2 (+) cannot collect both error > messages. No one says that "monad-style error processing" *must* stop > as soon as it sees an error. And having different semantics for liftA2 > and liftM2 (etc.) is strange at best. They ought to be equivalent > for any type constructor with both Monad and Applicative instances. > > -Brent > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jvlask at hotmail.com Sat Dec 5 17:17:45 2009 From: jvlask at hotmail.com (john lask) Date: Sat Dec 5 16:52:17 2009 Subject: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? In-Reply-To: <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com>, <4B1A7FE7.1080707@btinternet.com>, <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com>, <4B1AC38B.7090507@btinternet.com>, <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> Message-ID: I think there are some misapprehensions here:- many haskell packages binding to c libraries will compile with ghc without problems on windows - without cygwin, without mingw/msys system. Some such packages build "out of the box" on windows, like the zlib package which contains the c source for the c zlib library. GHC is able to compile and build this packages without any other c compiler/libraries/unix emulators etc because ghc itself contains part of the gcc c compiler tool chain and comes with all c standard headers, c++ headers and c/c++ runtime libraries. Other packages such as SDL package are relatively straightforward to build on windows - all that is required is to have an import library corresponding to your dll (or static lib) and the headers. You then update the library path field in the cabal file and include path. There is only one gotch-ya - you need to have a import library for the gcc tool chain (thats what ghc uses) i.e. a ".a" library and not the native windows ".LIB" import library. If you don't have ".a" import library but have the dll then the '.a' import library be built for any dll relativley easily. The correct '.a' import libraries and the libraries themselves for many standard unix/gnu packages can be found under the gnuwin32 project. Many unix libraries provide a windows build based on the mingw port of the gcc tool chain which will contain the correct import library. the bigest problem hamperring cleaner builds of haskell packages on windows is the lack of any standardised scheme for the installation of c-libraries and header files (and of course the availability of a suitable build of the library) Another problem hampering the install of haskell packages on windows is the use of the unix autoconf build system (./configure) , for which there is no substitute on windows other than cygwin and to lesser extent msys/mingw, this problem could be obviated by the provision of a standard win32 conf (forgetting about win64 for the moment) - package writters note! > Date: Sat, 5 Dec 2009 20:58:14 +0000 > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? > From: stephen.tetley@gmail.com > To: Haskell-Cafe@haskell.org > CC: > > Hi Andrew > > > > 2009/12/5 Andrew Coppin : > > > I don't think it should be necessary to install a Unix emulator just so that > > I can write Windows programs. Maybe others disagree. > > > > ... > > > > > I'm by no means an expert here, but isn't it usual for C libraries on > > Windows to be supplied as a compiled DLL and a header file for using it? I > > don't quite understand why you need a C compiler. > > The thing is, all the bindings on Hackage (or at least something most > likely above 95%) are to "Unix" C libraries so you need a C compiler > and a Unix emulator to use them. I do have have some sympathy with > your point though - it is possible to get things to compile once you > have Cygwin, but deployment on any other machine Windows thereafter is > 'challenging' to say the least. > > > > > > Apparently there is some talk of removing OpenGL from the Haskell Platform. > > And if this happens, it'll be one more thing I can't use on Windows. :-( > > > I didn't realise until I looked today that OpenGL was in the Haskell > Platform. If the proposal to remove it is from Sven Panne then fair > enough, otherwise it would be a bit disappointing - it always "just > worked" when it was part of GHCs extralibs... > > Best wishes > > Stephen > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _________________________________________________________________ If It Exists, You'll Find it on SEEK Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/0abf8b3f/attachment.html From lemming at henning-thielemann.de Sat Dec 5 17:17:17 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Dec 5 16:52:28 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> Message-ID: On Sat, 5 Dec 2009, Michael Snoyman wrote: > On Sat, Dec 5, 2009 at 7:41 PM, Ross Paterson wrote: > On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: > > For the record, I find this pedanticism misplaced, ... > > I think you'll find that's "pedantry". > > > Hoped someone would comment exactly that ;). :-) Nonetheless: Although there might be cases, where it is not immediately clear what is "error" and what is "exception" (not to mention, that different people prefer to use the words for the corresponding concepts in a different way, if they would do so consistently, it would be ok), in most cases it is clear. Have you ever tried to handle an "array index out of range" situation at run-time? I think, it cannot be sensibly handled by the program automatically. Thus there is no other way than terminating the program. Thus I'd call this situation an "error" not an "exception". Of course, people like to throw in here a web server as counterexample. So to speak: With respect to exceptions web servers are an exception. From michael at snoyman.com Sat Dec 5 17:23:03 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 16:57:36 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> Message-ID: <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> On Sun, Dec 6, 2009 at 12:17 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Sat, 5 Dec 2009, Michael Snoyman wrote: > > On Sat, Dec 5, 2009 at 7:41 PM, Ross Paterson >> wrote: >> On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: >> > For the record, I find this pedanticism misplaced, ... >> >> I think you'll find that's "pedantry". >> >> >> Hoped someone would comment exactly that ;). >> > > :-) > > Nonetheless: Although there might be cases, where it is not immediately > clear what is "error" and what is "exception" (not to mention, that > different people prefer to use the words for the corresponding concepts in a > different way, if they would do so consistently, it would be ok), in most > cases it is clear. Have you ever tried to handle an "array index out of > range" situation at run-time? I think, it cannot be sensibly handled by the > program automatically. Thus there is no other way than terminating the > program. Thus I'd call this situation an "error" not an "exception". Of > course, people like to throw in here a web server as counterexample. So to > speak: With respect to exceptions web servers are an exception. > > I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the "wrong" sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/a3412adf/attachment.html From lemming at henning-thielemann.de Sat Dec 5 17:55:35 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Dec 5 17:30:07 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> Message-ID: On Sun, 6 Dec 2009, Michael Snoyman wrote: > I think there are plenty of examples like web servers. A text editor with plugins? I > don't want to lose three hours worth of work just because some plugin wasn't written > correctly. For many classes of programs, the distinction between error and exception is > not only blurred, it's fully irrelevant. Harping on people every time they use error in > the "wrong" sense seems unhelpful. > > Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. From michael at snoyman.com Sat Dec 5 18:00:02 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 17:34:35 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> Message-ID: <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Sun, 6 Dec 2009, Michael Snoyman wrote: > > I think there are plenty of examples like web servers. A text editor with >> plugins? I >> don't want to lose three hours worth of work just because some plugin >> wasn't written >> correctly. For many classes of programs, the distinction between error and >> exception is >> not only blurred, it's fully irrelevant. Harping on people every time they >> use error in >> the "wrong" sense seems unhelpful. >> >> Hope my commenting on this subject doesn't become my own form of >> *pedantry*. >> > > In an earlier thread I have explained that one can consider a software > architecture as divided into levels. What is an error in one level (text > editor plugin, web server thread, operating system process) is an exception > in the next higher level (text editor, web server, shell respectively). This > doesn't reduce the importance to distinguish between errors and exceptions > within one level. All approaches so far that I have seen in Haskell just mix > exceptions and errors in an arbitrary way. > I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/b2dddcbe/attachment.html From functionallyharmonious at yahoo.com Sat Dec 5 18:10:05 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 17:44:39 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <5fdc56d70912051400h663a25a9w4f9b2e065a5b395e@mail.gmail.com> Message-ID: <988935.41750.qm@web113115.mail.gq1.yahoo.com> Stephen, I had no problem compiling the portaudio binaries on Windows. It came with a msvc project that worked. The problem I'm getting currently is that when I "cabal install portaudio etc etc" I get a "c2hs.exe does not exist error" when c2hs.exe clearly exists and is in my system path. Just like this post from months ago: http://www.mail-archive.com/haskell-art@lurk.org/msg00101.html --- On Sat, 12/5/09, Stephen Tetley wrote: From: Stephen Tetley Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? To: haskell-cafe@haskell.org Date: Saturday, December 5, 2009, 5:00 PM Compiling the C PortAudio library for either Cygwin or MinGW will be challenging at the moment. The current release doesn't compile as is, and although there should be patch for the configure script as an attachment to this message it seems to have gone amiss: http://music.columbia.edu/pipermail/portaudio/2009-May/009116.html I'd look for a different library to talk to the sound card... Best wishes Stephen 2009/12/4 M Xyz > > What is the most minimal (preferably platform independent) library available for writing bytes to the sound card? I see 60 wonderful libraries on Hackage, but I really just need the Haskell equivalent of an audio.write(byte[]) method. What sound api are these 60 libraries using? > > I think the portaudio library is the only contender but when I try to install it I get: > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/0da947e4/attachment.html From stephen.tetley at gmail.com Sat Dec 5 18:14:24 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 5 17:48:56 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? In-Reply-To: References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> Message-ID: <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> Hi John Fair points - but aren't you always going to 'need' at least MinGW? (for some degree of 'need' of course, I use it quite a bit though prefer Cygwin, I suppose Andrew C. would care not to use either). GHC brings with it gcc and ld, ar ... but not much else, so when a C library isn't all but self-contained, you would have to use MinGW to get the .a file - SDL for instance just distributes the .dll in the runtime library package. Also gnuwin32 is a wee bit spartan by my consideration [1], but perhaps you could knock my 95% guess for Hackage bindings libraries needing Unix emulation down to 60%, or 50%. Likely I was wrong with my guestimate in the first place by thinking mainly about 'multimedia' libraries. Best wishes Stephen [1] Presumably you mean here? http://gnuwin32.sourceforge.net/ http://gnuwin32.sourceforge.net/packages.html From gcross at phys.washington.edu Sat Dec 5 18:25:38 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Sat Dec 5 18:00:48 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> Message-ID: <112531AD-4A0E-403E-94F2-972FF61E6537@phys.washington.edu> On Dec 5, 2009, at 3:00 PM, Michael Snoyman wrote: > I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. > > On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? As I understand it, an error is a problem which aborts a computation and an exception is a problem that simply needs to be dealt with before the computation can continue. You are correct that there should be as few irrecoverable errors as possible in an application. In particular, if we think of an application as being a whole bunch of sub-computation tied together into a larger computation, then in a sense what we want is for no the failure of no sub-computation to cause the whole application-wide computation to fail. This, however, does not mean that there will be no circumstances under which any sub-computation fails, such as in the case of discovering in the middle of leading a file that it is irrecoverably corrupt. When these circumstances occur, one has an error and not an exception because there is no way to finish loading the file. However, at a higher lever, the sub-computation of loading the file was not necessary for the application to keep running, and so an error in the sub-computation becomes merely an exception when propagated up to the application level. Cheers, Greg From daniel.is.fischer at web.de Sat Dec 5 18:32:46 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 18:08:46 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <988935.41750.qm@web113115.mail.gq1.yahoo.com> References: <988935.41750.qm@web113115.mail.gq1.yahoo.com> Message-ID: <200912060032.47295.daniel.is.fischer@web.de> Am Sonntag 06 Dezember 2009 00:10:05 schrieb M Xyz: > Stephen, > I had no problem compiling the portaudio binaries on Windows. It came with > a msvc project that worked. The problem I'm getting currently is that when > I "cabal install portaudio etc etc" I get a "c2hs.exe does not exist error" > when c2hs.exe clearly exists and is in my system path. Just like this post > from months ago: > http://www.mail-archive.com/haskell-art@lurk.org/msg00101.html Try cabal install --with-c2hs="C:\path\to\c2hs.exe" portaudio maybe that'll work. If not, run cabal --verbose=3 install portaudio, perhaps that gives more information about what went wrong. From functionallyharmonious at yahoo.com Sat Dec 5 18:47:38 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 18:22:11 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <200912060032.47295.daniel.is.fischer@web.de> Message-ID: <152612.63410.qm@web113109.mail.gq1.yahoo.com> --- On Sat, 12/5/09, Daniel Fischer wrote: Try cabal install --with-c2hs="C:\path\to\c2hs.exe" portaudio maybe that'll work. If not, run cabal --verbose=3 install portaudio, perhaps that gives more information about what went wrong. Daniel, Thank you for your thoughtful reply. I didn't know about those flags. The log is fairly long, and as I'm new to Haskell and Cabal it is mostly meaningless to me. I see very many incidences of "searching for ___ in path. Cannot find ___ on the path" so maybe this is all as simple as me not setting my environment correctly. Log: cabal install portaudio --verbose=3 --with-c2hs="C:\Program Files\Haskell\bin\c2hs.exe" --extra-include-dirs="C:\A\install\programming\portaudio\portaudio\include" --extra-lib-dirs="C:\A\install\programming\portaudio\portaudio\build\msvc\Win32\Release" >log.txt searching for ghc in path. found ghc at C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--numeric-version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in C:\Program Files\Haskell Platform\2009.2.0.2\bin found package tool in C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe is version 6.10.4 ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["dump","--global"]) Reading available packages... Resolving dependencies... selecting portaudio-0.0.1 (hackage) and discarding mtl-1.0 selecting mtl-1.1.0.2 (installed or hackage) and discarding mtl-1.1.0.0 and 1.1.0.1 selecting haskell98-1.0.1.0 (installed or hackage) and discarding haskell98-1.0 selecting random-1.0.0.1 (installed or hackage) and discarding random-1.0.0.0 selecting process-1.0.1.1 (installed or hackage) and discarding filepath-1.0 and process-1.0.0.0 selecting directory-1.0.0.3 (installed or hackage) and discarding directory-1.0.0.0 selecting old-time-1.0.0.2 (installed or hackage) and discarding old-time-1.0.0.0 selecting old-locale-1.0.0.1 (installed or hackage) and discarding old-locale-1.0.0.0 selecting filepath-1.1.0.2 (installed or hackage) and discarding filepath-1.1.0.0 and 1.1.0.1 selecting Win32-2.2.0.0 (installed or hackage) and discarding Win32-2.1 and 2.1.0.0 selecting bytestring-0.9.1.4 (installed or hackage) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3 and 0.9.1.5 selecting ghc-prim-0.1.0.0 (installed) selecting rts-1.0 (installed) selecting array-0.2.0.0 (installed or hackage) and discarding array-0.1.0.0 selecting base-3.0.3.1 (installed) and 4.1.0.0 (installed) and discarding syb-0.1.0.0 and 0.1.0.1 selecting integer-0.1.0.1 (installed) selecting syb-0.1.0.1 (installed) In order, the following would be installed: portaudio-0.0.1 (new package) portaudio-0.0.1 has already been downloaded. Extracting C:\Documents and Settings\M\Application Data\cabal\packages\hackage.haskell.org\portaudio\0.0.1\portaudio-0.0.1.tar.gz to C:\DOCUME~1\M\LOCALS~1\Temp\portaudio-0.0.13824... Using internal setup method with build-type Simple and args: ["configure","--verbose=3","--ghc","--global","--extra-include-dirs=C:\\A\\install\\programming\\portaudio\\portaudio\\include","--extra-lib-dirs=C:\\A\\install\\programming\\portaudio\\portaudio\\build\\msvc\\Win32\\Release","--constraint=base ==3.0.3.1","--constraint=haskell98 ==1.0.1.0","--constraint=mtl ==1.1.0.2","--with-c2hs=C:\\Program Files\\Haskell\\bin\\c2hs.exe"] Configuring portaudio-0.0.1... Creating dist (and its parents) searching for ghc in path. found ghc at C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--numeric-version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in C:\Program Files\Haskell Platform\2009.2.0.2\bin found package tool in C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe is version 6.10.4 ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc-pkg.exe",["dump","--global"]) Dependency base >3 && ==3.0.3.1: using base-3.0.3.1 Dependency haskell98 -any && ==1.0.1.0: using haskell98-1.0.1.0 Dependency mtl >=1.1.0.0 && ==1.1.0.2: using mtl-1.1.0.2 searching for alex in path. found alex at C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\alex.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\extralibs\\bin\\alex.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\alex.exe is version 2.3.1 searching for ar in path. found ar at C:\Program Files\Haskell Platform\2009.2.0.2\bin\ar.exe ("C:\\Program Files\\Haskell\\bin\\c2hs.exe",["--numeric-version"]) C:\Program Files\Haskell\bin\c2hs.exe is version 0.16.0 searching for cpphs in path. Cannot find cpphs on the path searching for ffihugs in path. Cannot find ffihugs on the path ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc.exe",["-dumpversion"]) C:\Program Files\Haskell Platform\2009.2.0.2\gcc.exe is version 3.4.5 searching for greencard in path. Cannot find greencard on the path searching for haddock in path. found haddock at C:\Program Files\Haskell Platform\2009.2.0.2\bin\haddock.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\haddock.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\haddock.exe is version 2.4.2 searching for happy in path. found happy at C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\happy.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\extralibs\\bin\\happy.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\happy.exe is version 1.18.4 searching for hmake in path. Cannot find hmake on the path searching for hsc2hs in path. found hsc2hs at C:\Program Files\Haskell Platform\2009.2.0.2\bin\hsc2hs.exe ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\hsc2hs.exe",["--version"]) C:\Program Files\Haskell Platform\2009.2.0.2\bin\hsc2hs.exe is version 0.67 searching for HsColour in path. Cannot find HsColour on the path searching for hugs in path. Cannot find hugs on the path searching for jhc in path. Cannot find jhc on the path ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\bin\\ghc.exe",["-c","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.c","-o","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.o"]) ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc-lib\\ld.exe",["-x","-r","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.o","-o","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3825.o"]) searching for nhc98 in path. Cannot find nhc98 on the path searching for pkg-config in path. Cannot find pkg-config on the path searching for ranlib in path. Cannot find ranlib on the path searching for strip in path. Cannot find strip on the path searching for tar in path. Cannot find tar on the path Using Cabal-1.6.0.3 compiled by ghc-6.10 Using compiler: ghc-6.10.4 Using install prefix: C:\Program Files\Haskell Binaries installed in: C:\Program Files\Haskell\bin Libraries installed in: C:\Program Files\Haskell\portaudio-0.0.1\ghc-6.10.4 Private binaries installed in: C:\Program Files\Haskell\portaudio-0.0.1 Data files installed in: C:\Program Files\Haskell\portaudio-0.0.1 Documentation installed in: C:\Program Files\Haskell\doc\portaudio-0.0.1 Using alex version 2.3.1 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\alex.exe Using ar found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\ar.exe Using c2hs version 0.16.0 given by user at: C:\Program Files\Haskell\bin\c2hs.exe No cpphs found No ffihugs found Using gcc version 3.4.5 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\gcc.exe Using ghc version 6.10.4 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc.exe Using ghc-pkg version 6.10.4 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\ghc-pkg.exe No greencard found Using haddock version 2.4.2 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\haddock.exe Using happy version 1.18.4 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\extralibs\bin\happy.exe No hmake found Using hsc2hs version 0.67 found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\bin\hsc2hs.exe No hscolour found No hugs found No jhc found Using ld found on system at: C:\Program Files\Haskell Platform\2009.2.0.2\gcc-lib\ld.exe No nhc98 found No pkg-config found No ranlib found No strip found No tar found ("C:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc.exe",["-BC:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc-lib","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\include\\mingw","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824.c","-o","C:\\DOCUME~1\\M\\LOCALS~1\\Temp\\3824","-BC:\\Program Files\\Haskell Platform\\2009.2.0.2\\gcc-lib","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\include\\mingw","-D__GLASGOW_HASKELL__=610","-IC:\\A\\install\\programming\\portaudio\\portaudio\\include","-I.","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\process-1.0.1.1\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\directory-1.0.0.3\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\old-time-1.0.0.2\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\Win32-2.2.0.0\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\bytestring-0.9.1.4\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2\\base-4.1.0.0\\include","-IC:\\Program Files\\Haskell Platform\\2009.2.0.2/include","-lportaudio","-LC:\\A\\install\\programming\\portaudio\\portaudio\\build\\msvc\\Win32\\Release"]) Using internal setup method with build-type Simple and args: ["build","--verbose=3"] Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library portaudio-0.0.1... Creating dist\build\Sound\PortAudio (and its parents) ("C:\\Program Files\\Haskell\\bin\\c2hs.exe",["--include=dist\\build","--cppopts=-D__GLASGOW_HASKELL__=610","--cppopts=-IC:\\A\\install\\programming\\portaudio\\portaudio\\include","--output-dir=dist\\build","--output=Sound\\PortAudio\\Base.hs",".\\Sound\\PortAudio\\Base.chs"]) c2hs.exe: does not exist C:\Program Files\Haskell\bin\c2hs.exe returned ExitFailure 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/10779b73/attachment-0001.html From daniel.is.fischer at web.de Sat Dec 5 19:24:17 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 19:00:19 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <152612.63410.qm@web113109.mail.gq1.yahoo.com> References: <152612.63410.qm@web113109.mail.gq1.yahoo.com> Message-ID: <200912060124.18057.daniel.is.fischer@web.de> Am Sonntag 06 Dezember 2009 00:47:38 schrieb M Xyz: > Daniel, Thank you for your thoughtful reply. I didn't know about those > flags. The log is fairly long, and as I'm new to Haskell and Cabal it is > mostly meaningless to me. I see very many incidences of "searching for ___ > in path. Cannot find ___ on the path" so maybe this is all as simple as me > not setting my environment correctly. If you have cpphs, hugs, jhc, greencard etc., it is probably something about your environment. If you don't have them, it's clear that they aren't found. On the other hand, that doesn't explain Using c2hs version 0.16.0 given by user at: C:\Program Files\Haskell\bin\c2hs.exe -- so it finds c2hs, and can apparently run c2hs --version ("C:\\Program Files\\Haskell\\bin\\c2hs.exe",["--include=dist\\build","--cppopts=- D__GLASGOW_HASKELL__=610","--cppopts=-IC: \\A\\install\\programming\\portaudio\\portaudio\\include","--output-dir=dist\\build","-- output=Sound\\PortAudio\\Base.hs",".\\Sound\\PortAudio\\Base.chs"]) c2hs.exe: does not exist C:\Program Files\Haskell\bin\c2hs.exe returned ExitFailure 1 -- bang To ascertain whether c2hs works at all, can you try to run it manually? (cd to an appropriate directory, cabal unpack portaudio cd portaudio (or whatever, so that Base.chs is found via .\Sound\PortAudio\Base.chs md dist\build c2hs.exe --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=610 --cppopts=-IC: \A\install\programming\portaudio\portaudio\include --output-dir=dist\build -- output=Sound\PortAudio\Base.hs .\Sound\PortAudio\Base.chs ) If that works, the problem is somewhere in cabal, otherwise in c2hs, either way, we'll know more. From functionallyharmonious at yahoo.com Sat Dec 5 19:34:52 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 19:09:24 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <4B1AC32B.6040204@btinternet.com> Message-ID: <675014.88319.qm@web113110.mail.gq1.yahoo.com> --- On Sat, 12/5/09, Andrew Coppin wrote: >> Hell, I even followed a C++ guide to Win32 programming and >> managed to translate an "open a blank window" program to Haskell, and it >> worked. Maybe somebody just needs to sit down and write a nice binding >> for doing native GUI stuff under Win32? Well there's http://haskell.org/ghc/docs/latest/html/libraries/Win32/Graphics-Win32.html for opening blank windows. ;) This relates to my question a couple days ago about a good cross platform 2d library. I wonder why there isnt a Haskell library that follows in the footsteps of Java's Swing - by that I mean, just have a very simple low level way of opening a window, getting mouse clicks, and an abstracted drawing layer... and make the GUIs with that. The GUIs are drawn and not OS widgets. That's exactly why I was looking for something like Cairo. My interest is in composable fudgets (stealing the word from fudgets). This way every platform can share the same GUI library and HP can ship with the minimal tools to open a window and draw on every system. Plus OS guis are the wrong thing for Haskell. You need to retain the power to make better abstractions. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/8ca5e6d1/attachment.html From functionallyharmonious at yahoo.com Sat Dec 5 19:49:49 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 19:24:21 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <200912060124.18057.daniel.is.fischer@web.de> Message-ID: <622238.98035.qm@web113115.mail.gq1.yahoo.com> --- On Sat, 12/5/09, Daniel Fischer wrote: If you have cpphs, hugs, jhc, greencard etc., it is probably something about your environment. If you don't have them, it's clear that they aren't found. I don't know what those things are. I have nothing but what came with HP other than installing c2hs today. If that works, the problem is somewhere in cabal, otherwise in c2hs, either way, we'll know more. Alright, I followed the instructions and everything was as you said. I still get "c2hs.exe does not exist". C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>"C:\Program Files\Has kell\bin\c2hs.exe" --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=610 --cp popts=-IC:\A\install\programming\portaudio\portaudio\include --output-dir=dist\b uild --output=Sound\PortAudio\Base.hs .\Sound\PortAudio\Base.chs c2hs.exe: does not exist C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>pause Press any key to continue . . . By the way, I have posted this problem to the c2hs mailing list in case they have some insight. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/def478fc/attachment.html From daniel.is.fischer at web.de Sat Dec 5 20:34:17 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 5 20:10:17 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <622238.98035.qm@web113115.mail.gq1.yahoo.com> References: <622238.98035.qm@web113115.mail.gq1.yahoo.com> Message-ID: <200912060234.17706.daniel.is.fischer@web.de> Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: I just had another idea. dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs c2hs: does not exist it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! Try installing from the unpacked sources (cd portaudio; cabal install) or the old- fashioned way: cd portaudio-0.0.1 ghc --make Setup ./Setup configure --help (choose your options, prefix, profiling, ...) ./Setup configure $OPTIONS ./Setup build if all's well, ./Setup haddock ./Setup install (dies for me with dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder Verzeichnisnicht gefunden c2hs: Error during preprocessing custom header file cabal: Error: some packages failed to install: portaudio-0.0.1 failed during the building phase. The exception was: exit: ExitFailure 1 because I don't have portaudio installed) From jvlask at hotmail.com Sat Dec 5 21:03:32 2009 From: jvlask at hotmail.com (john lask) Date: Sat Dec 5 20:38:04 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <200912060234.17706.daniel.is.fischer@web.de> References: <622238.98035.qm@web113115.mail.gq1.yahoo.com>, <200912060234.17706.daniel.is.fischer@web.de> Message-ID: I don't know whether this will help you but I just downloaded an built the haskell portaudio package ... (I had a windows msvc build of portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 make an import lib for ghc from dll: pexports libpa19.dll > libpa19.def dlltool --input-def libpa19.def --output-lib libpa19.a edit the .cabal file or use command line flags extra-Libraries: pa19 extra-lib-dirs: c:\portaudio19\lib include-dirs: c:\portaudio19\include runghc setup configure make sure you have cpp i.e. the c-preprocessor on your exe path, otherwise you will get 'cpp' is not recognized as an internal or external command, operable program or batch file. c2hs.exe: Error during preprocessing custom header file runghc setup build builds ok ...?? > From: daniel.is.fischer@web.de > To: functionallyharmonious@yahoo.com > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? > Date: Sun, 6 Dec 2009 02:34:17 +0100 > CC: haskell-cafe@haskell.org > > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > I just had another idea. > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > c2hs: does not exist > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > Try installing from the unpacked sources (cd portaudio; cabal install) or the old- > fashioned way: > > cd portaudio-0.0.1 > > ghc --make Setup > > ./Setup configure --help > (choose your options, prefix, profiling, ...) > > ./Setup configure $OPTIONS > ./Setup build > > if all's well, > > ./Setup haddock > ./Setup install > > (dies for me with > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder > Verzeichnisnicht gefunden > c2hs: Error during preprocessing custom header file > cabal: Error: some packages failed to install: > portaudio-0.0.1 failed during the building phase. The exception was: > exit: ExitFailure 1 > because I don't have portaudio installed) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _________________________________________________________________ If It Exists, You'll Find it on SEEK Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/fb336f09/attachment.html From lemming at henning-thielemann.de Sat Dec 5 21:05:30 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Dec 5 20:40:05 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> Message-ID: On Sat, 5 Dec 2009, Henning Thielemann wrote: > On Sun, 6 Dec 2009, Michael Snoyman wrote: > >> I think there are plenty of examples like web servers. A text editor with >> plugins? I >> don't want to lose three hours worth of work just because some plugin >> wasn't written >> correctly. For many classes of programs, the distinction between error and >> exception is >> not only blurred, it's fully irrelevant. Harping on people every time they >> use error in >> the "wrong" sense seems unhelpful. >> >> Hope my commenting on this subject doesn't become my own form of >> *pedantry*. > > In an earlier thread I have explained that one can consider a software > architecture as divided into levels. What is an error in one level (text > editor plugin, web server thread, operating system process) is an exception > in the next higher level (text editor, web server, shell respectively). This > doesn't reduce the importance to distinguish between errors and exceptions > within one level. All approaches so far that I have seen in Haskell just mix > exceptions and errors in an arbitrary way. I have just written more details on this topic: http://www.haskell.org/haskellwiki/Error_vs._Exception From functionallyharmonious at yahoo.com Sat Dec 5 21:08:07 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 20:42:38 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <200912060234.17706.daniel.is.fischer@web.de> Message-ID: <630863.11462.qm@web113107.mail.gq1.yahoo.com> --- On Sat, 12/5/09, Daniel Fischer wrote: cd portaudio-0.0.1 ghc --make Setup ../Setup configure --help (choose your options, prefix, profiling, ...) ../Setup configure $OPTIONS ../Setup build Everything went well until "Setup build" which yielded our friend "c2hs.exe does not exist". C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>ghc --make Setup [1 of 1] Compiling Main???????????? ( Setup.hs, Setup.o ) Linking Setup.exe ... C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup configure --hel p Usage: Setup configure [FLAGS] Flags for configure: .......(edited out)................ C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup configure --ext ra-include-dirs="C:\A\install\programming\portaudio\portaudio\include" --extra-l ib-dirs="C:\A\install\programming\portaudio\portaudio\build\msvc\Win32\Release" Configuring portaudio-0.0.1... C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup build Preprocessing library portaudio-0.0.1... c2hs.exe: does not exist -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/19b2f19f/attachment.html From functionallyharmonious at yahoo.com Sat Dec 5 21:17:29 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 20:52:01 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: Message-ID: <904556.63252.qm@web113104.mail.gq1.yahoo.com> I am going to give this a try. Thanks. Where can I get the pexports and dlltool utilities? Google yields: http://www.emmestech.com/software/pexports-0.43/download_pexports.html http://sourceware.org/binutils/ Are those correct? --- On Sat, 12/5/09, john lask wrote: From: john lask Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? To: daniel.is.fischer@web.de, functionallyharmonious@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, December 5, 2009, 9:03 PM I don't know whether this will help you but I just downloaded an built the haskell portaudio package ... (I had a windows msvc build of portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 make an import lib for ghc from dll: pexports libpa19.dll > libpa19.def dlltool --input-def libpa19.def --output-lib libpa19.a edit the .cabal file or use command line flags ? extra-Libraries: pa19 ? extra-lib-dirs: c:\portaudio19\lib ? include-dirs:?? c:\portaudio19\include ?runghc setup configure make sure you have cpp i.e. the c-preprocessor on your exe path, otherwise you will get 'cpp' is not recognized as an internal or external command, operable program or batch file. c2hs.exe: Error during preprocessing custom header file runghc setup build builds ok ...?? > From: daniel.is.fischer@web.de > To: functionallyharmonious@yahoo.com > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? > Date: Sun, 6 Dec 2009 02:34:17 +0100 > CC: haskell-cafe@haskell.org > > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > I just had another idea. > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > c2hs: does not exist > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > Try installing from the unpacked sources (cd portaudio; cabal install) or the old- > fashioned way: > > cd portaudio-0.0.1 > > ghc --make Setup > > ./Setup configure --help > (choose your options, prefix, profiling, ...) > > ./Setup configure $OPTIONS > ./Setup build > > if all's well, > > ./Setup haddock > ./Setup install > > (dies for me with > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder > Verzeichnisnicht gefunden > c2hs: Error during preprocessing custom header file > cabal: Error: some packages failed to install: > portaudio-0.0.1 failed during the building phase. The exception was: > exit: ExitFailure 1 > because I don't have portaudio installed) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Australia's #1 job site If It Exists, You'll Find it on SEEK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/8d1b205d/attachment.html From functionallyharmonious at yahoo.com Sat Dec 5 22:47:04 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sat Dec 5 22:21:36 2009 Subject: [Haskell-cafe] PortAudio library successfully built on Windows In-Reply-To: Message-ID: <829870.23732.qm@web113101.mail.gq1.yahoo.com> John Lask, The steps you enumerated below successfully built portaudio for me! Thank you! I wonder though, you said to rename the dll to libpa19.dll from portaudio_x86.dll and to change the .cabal entry from "extra-Libraries: portaudio" to "extra-Libraries: pa19". Since my .dll name and .cabal file entry were mismatched, was that what could have been wrong all along? Was the creation of a .a file necessary? I would delete the .a file and retry with libportaudio.dll but I won't push my luck. Now if I could just get Gtk2hs working now, I could be happy *and* productive. :) --- On Sat, 12/5/09, john lask wrote: From: john lask Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? To: daniel.is.fischer@web.de, functionallyharmonious@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, December 5, 2009, 9:03 PM I don't know whether this will help you but I just downloaded an built the haskell portaudio package ... (I had a windows msvc build of portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 make an import lib for ghc from dll: pexports libpa19.dll > libpa19.def dlltool --input-def libpa19.def --output-lib libpa19.a edit the .cabal file or use command line flags ? extra-Libraries: pa19 ? extra-lib-dirs: c:\portaudio19\lib ? include-dirs:?? c:\portaudio19\include ?runghc setup configure make sure you have cpp i.e. the c-preprocessor on your exe path, otherwise you will get 'cpp' is not recognized as an internal or external command, operable program or batch file. c2hs.exe: Error during preprocessing custom header file runghc setup build builds ok ...?? > From: daniel.is.fischer@web.de > To: functionallyharmonious@yahoo.com > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? > Date: Sun, 6 Dec 2009 02:34:17 +0100 > CC: haskell-cafe@haskell.org > > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > I just had another idea. > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > c2hs: does not exist > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > Try installing from the unpacked sources (cd portaudio; cabal install) or the old- > fashioned way: > > cd portaudio-0.0.1 > > ghc --make Setup > > ./Setup configure --help > (choose your options, prefix, profiling, ...) > > ./Setup configure $OPTIONS > ./Setup build > > if all's well, > > ./Setup haddock > ./Setup install > > (dies for me with > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder > Verzeichnisnicht gefunden > c2hs: Error during preprocessing custom header file > cabal: Error: some packages failed to install: > portaudio-0.0.1 failed during the building phase. The exception was: > exit: ExitFailure 1 > because I don't have portaudio installed) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Australia's #1 job site If It Exists, You'll Find it on SEEK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/9d386771/attachment.html From michael at snoyman.com Sun Dec 6 00:04:46 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sat Dec 5 23:39:19 2009 Subject: [Haskell-cafe] When are undecidables ok? Message-ID: <29bf512f0912052104ia36a42k556df47c1b143223@mail.gmail.com> I know this is basically a rewording of a previous e-mail, but I realized this is the question I *really* wanted to ask. We have this language extension UndecidableInstances (not to mention OverlappingInstances), which seem to divide the Haskell camp into two factions: * Hey, GHC said to turn on this flag. Ok! * Undecidables are the devil! I get the feeling the truth lies in the middle. As I understand it (please correct me if I am wrong), the problem with undecidables is that they can create non-terminating instances. However, for certain cases the programmer should be able to prove to him/herself that the instances will terminate. My question is: how can you make such a proof? I've had to cases in particular that made me want undecidables. Both of them, IMO, could be solved by creating new extensions to GHC which would not require undecidables. Nonetheless, for now we only have undecidables at our disposal. The examples are: * Context synonyms (eg, MonadFailure = Monad + Failure). * Subclass function defaulting For an example of the second, a nifty definition of Monad would be: class Applicative m => Monad m where >>= ... return ... pure = return (<*>) = ap fmap = liftM Of course, neither of these is possible in Haskell, so we can use undecidables. How can a programmer prove that a set of instances is, in fact, safe? And if they make a mistake and right a bad set of undecidable/overlapping instances, what's the worst case scenario? Is it a compile-time or run-time error*? Michael * Yes, I mean error. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091205/d6ba84d5/attachment.html From lrpalmer at gmail.com Sun Dec 6 00:36:43 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Dec 6 00:11:14 2009 Subject: [Haskell-cafe] When are undecidables ok? In-Reply-To: <29bf512f0912052104ia36a42k556df47c1b143223@mail.gmail.com> References: <29bf512f0912052104ia36a42k556df47c1b143223@mail.gmail.com> Message-ID: <7ca3f0160912052136v65984da0l797d3a683388d9f8@mail.gmail.com> On Sat, Dec 5, 2009 at 10:04 PM, Michael Snoyman wrote: > I know this is basically a rewording of a previous e-mail, but I realized > this is the question I *really* wanted to ask. > > We have this language extension UndecidableInstances (not to mention > OverlappingInstances), which seem to divide the Haskell camp into two > factions: > > * Hey, GHC said to turn on this flag. Ok! > * Undecidables are the devil! > > I get the feeling the truth lies in the middle. As I understand it (please > correct me if I am wrong), the problem with undecidables is that they can > create non-terminating instances. However, for certain cases the programmer > should be able to prove to him/herself that the instances will terminate. My > question is: how can you make such a proof? Well, the reasoning for the "devil" camp (which I admit to being firmly in[1]) is that such proofs must rely on the algorithm the compiler uses to resolve instances. You might be able to prove it, but the proof is necessarily only valid for (possibly current versions of) GHC. The typeclass resolution algorithm is not in the report, and there are several conceivable ways of of going about it. So it is fine to use them if you are okay with making your code unportable and future-brittle. I am typically against the mere existence of code that that is future-brittle, because it encourages compiler authors not to innovate (and by that token, unportable too, because it discourages compiler competition). Luke [1] http://lukepalmer.wordpress.com/2008/04/08/stop-using-undecidable-instances/ From michael at snoyman.com Sun Dec 6 01:20:09 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sun Dec 6 00:54:40 2009 Subject: [Haskell-cafe] When are undecidables ok? In-Reply-To: <7ca3f0160912052136v65984da0l797d3a683388d9f8@mail.gmail.com> References: <29bf512f0912052104ia36a42k556df47c1b143223@mail.gmail.com> <7ca3f0160912052136v65984da0l797d3a683388d9f8@mail.gmail.com> Message-ID: <29bf512f0912052220n29650296p8952bdd606994a00@mail.gmail.com> On Sun, Dec 6, 2009 at 7:36 AM, Luke Palmer wrote: > On Sat, Dec 5, 2009 at 10:04 PM, Michael Snoyman > wrote: > > I know this is basically a rewording of a previous e-mail, but I realized > > this is the question I *really* wanted to ask. > > > > We have this language extension UndecidableInstances (not to mention > > OverlappingInstances), which seem to divide the Haskell camp into two > > factions: > > > > * Hey, GHC said to turn on this flag. Ok! > > * Undecidables are the devil! > > > > I get the feeling the truth lies in the middle. As I understand it > (please > > correct me if I am wrong), the problem with undecidables is that they can > > create non-terminating instances. However, for certain cases the > programmer > > should be able to prove to him/herself that the instances will terminate. > My > > question is: how can you make such a proof? > > Well, the reasoning for the "devil" camp (which I admit to being > firmly in[1]) is that such proofs must rely on the algorithm the > compiler uses to resolve instances. You might be able to prove it, > but the proof is necessarily only valid for (possibly current versions > of) GHC. The typeclass resolution algorithm is not in the report, and > there are several conceivable ways of of going about it. > > So it is fine to use them if you are okay with making your code > unportable and future-brittle. I am typically against the mere > existence of code that that is future-brittle, because it encourages > compiler authors not to innovate (and by that token, unportable too, > because it discourages compiler competition). > > Luke > > [1] > http://lukepalmer.wordpress.com/2008/04/08/stop-using-undecidable-instances/ > So in that case, perhaps the compiler authors can give us some ideas as to when it's safe to use undecidables? Seems like we should go straight to the horse's mouth. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/1fd1ce2b/attachment.html From valgarv at gmx.net Sun Dec 6 01:34:16 2009 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Sun Dec 6 01:08:51 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <029ED0C1-E758-49CB-95DB-AAFFBC19CACE@phys.washington.edu> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> <4B1930F3.30306@henning-thielemann.de> <029ED0C1-E758-49CB-95DB-AAFFBC19CACE@phys.washington.edu> Message-ID: <1260081256.3165.9.camel@lnx-arielb> > In particular, the motivation for this package was that I have written > a build system, and I wanted to collect as many errors in the build as > possible and show them all to the user at once. YMMV, but at least for me a deluge of errors is less helpful than a short list I can fix quickly, then try again. Often by fixing one error from the list a sizeable portion of the rest just vanish (I forget the English term for that kind of error). (In before "you can use sth like quickfix to go through the first few errors and compile again whenever you feel like it".) -- Ariel J. Birnbaum From ekirpichov at gmail.com Sun Dec 6 01:42:34 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Sun Dec 6 01:17:05 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <0B59A706-8C41-47B9-A858-5ACE297581E1@cs.uu.nl> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> <5e0214850912051300r3ebd0e44n61a4d6e020c94f4c@mail.gmail.com> <0B59A706-8C41-47B9-A858-5ACE297581E1@cs.uu.nl> Message-ID: <5e0214850912052242v4010c273r3d8363d3709117b1@mail.gmail.com> 2009/12/6 Stefan Holdermans : > Eugene, > >> 1) Does there exist an authoritative source saying the same? Not that >> I'm doubting, just supposing that the source would have other >> interesting information, too :) > > You may want to have a look at the already mentioned JFP-article by Peyton > Jones et al. and perhaps the work of Kfoury and Wells. > >> 2) Is it true that rank (forall a . a, forall a . a) == 0 ? > > No, for pairs one takes the maximum of the constituent types. So, here you'd > get rank 1. > > Note that this is an impredicative type, which is yet another extension of > the standard Hindley-Milner typing discipline. OK, thanks. However, isn't the type (forall a . a) -> String impredicative because it instantiates a type variable of the type constructor (->) p q with p = forall a . a? > > Cheers, > > ?Stefan >> >>> > -- Eugene Kirpichov Web IR developer, market.yandex.ru From dekudekuplex at yahoo.com Sun Dec 6 02:14:06 2009 From: dekudekuplex at yahoo.com (Benjamin L.Russell) Date: Sun Dec 6 01:49:12 2009 Subject: [Haskell-cafe] Re: universal binary version of Haskell Platform? References: <34heh5557a7pdou2jokj05ia77dlc2e7kb@4ax.com> <1259837555.4896.102798.camel@localhost> Message-ID: On Thu, 03 Dec 2009 10:52:35 +0000, Duncan Coutts wrote: >[...] > >There no binary platform installer for OSX PPC. You'll have to grab >ghc-6.10.4 for PPC from the ghc download page and then install the >platform from the generic source tarball. Ah, that's too bad. That means that I won't be able to invoke GHC outside of the Terminal application by default, and that even if I create a Darwin shell script and alias to invoke it from Aqua, the icon for that shell script will only be generic by default. I'd rather click on an application icon in the Dock. > >If you'd like to help us next time to make a platform binary for PPC >then that'd be great. I don't think we have the setup to make universal >binaries but it should be possible to make a PPC build if we have a >volunteer. Sure, barring job-related time constraints, I'd be happy to volunteer. My Mac just went out of service because of a hardware problem with the memory, so I'm order new replacement RAM this weekend. As soon as that arrives and I install it, the problem should be resolved. What should I do? -- Benjamin L. Russell From dan.doel at gmail.com Sun Dec 6 02:48:09 2009 From: dan.doel at gmail.com (Dan Doel) Date: Sun Dec 6 02:22:43 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <5e0214850912052242v4010c273r3d8363d3709117b1@mail.gmail.com> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> <0B59A706-8C41-47B9-A858-5ACE297581E1@cs.uu.nl> <5e0214850912052242v4010c273r3d8363d3709117b1@mail.gmail.com> Message-ID: <200912060248.09823.dan.doel@gmail.com> On Sunday 06 December 2009 1:42:34 am Eugene Kirpichov wrote: > OK, thanks. > However, isn't the type (forall a . a) -> String impredicative because > it instantiates a type variable of the type constructor (->) p q with > p = forall a . a? There's probably no clear cut answer to this independent of how you think of (->). For instance, if we explain the Haskell type system by way of a pure type system, (->) is a special case of a pi type, which looks like: pi x : k. t where any xs in t are bound by the pi. We then have: p -> q = pi _ : p. q forall a : k. b = pi a : k. b pi types are given types by sets of rules, which look like triples. If (s,t,u) is a rule, then: G |- k : s G, a : k |- b : t ------------------------------- G |- (pi a : k. b) : u is the corresponding typing rule. Type systems like Haskell's are commonly thought of in terms of the lambda cube, which has constant sorts * and [], with * : []. The rule (*,*,*) gives you ordinary functions. (*,[],[]) gives you dependent types, so that's out. ([],*,*) is an impredicative rule for polymorphism. This says that, for instance: forall a. a -> a = (pi a : *. pi _ : a. a) : * because (pi _ : a. a) : * if a : *, by the (*,*,*) rule, and then we apply the impredicative rule for the universal quantification. One could also use the predicative rule ([],*,[]), which would result in forall a. a -> a having type []. However, Haskell also has arbitrarily higher-order types. This is given by the rule ([],[],[]), which allows expressions like: (* -> *) -> * = pi _ : (pi _ : *. *). * This type system is called F_omega, while just the ([],*,?) rule is known as F_2. However, the F_omega rule also allows for arbitrary rank polymorphism even with the predicative universal quantifier rule above (predicative F_2 allows a little, but it's very limited*). For instance, the higher rank type: forall a. (forall b. b) -> a checks thusly: (forall b. b) : [] via ([],*,[]) ((forall b. b) -> a) : [] via ([],*,[]) (forall a. (forall b. b) -> a) : [] via ([],[],[]) Data types, by contrast, have kinds like * -> *, so using say, Maybe (forall a. a -> a) genuinely relies on the impredicative rule. GHC's type system isn't exactly set up in this way, but (->) is similarly special in that it somehow isn't quite just another type constructor with kind * -> * -> * (or even whatever special kinds GHC uses to support unboxed values and such). Hope that wasn't too confusing. :) -- Dan * Predicative F_2 will essentially allow one universal quantifier somewhere in the type. This can be: forall a. a -> a or it can be: (((forall a. a) -> T) -> U) -> V for T, U and V of kind * (the only kind in F_2), which is a rank-4 type. It doesn't allow: forall a b. a -> b even, because the inner (forall b. a -> b) : [], so adding the forall a requires the F_omega rule. Predicative F_2 and F_w also blow up with quantification on the right of an arrow, because it looks like the rule for dependent types: T -> (forall a. a) T : *, (forall a. a) : [] so the rule (*,[],[]) would be invoked. GHC doesn't have this sort of hierarchy, and so doesn't have these sorts of weird cases, despite being predicative of a sort. Instead it distinguishes somehow between monotypes ([Float], String -> Int, a -> b) and polytypes (forall a. a, ...), although it doesn't really display the difference. Quantifiers are only supposed to range over kinds that classify monotypes (or monotype constructors), which keeps the predicativity (although, even this gets fudged some: If I have forall a. a -> a, I can instantiate a to the polytype forall a. a -> a with rank-n polymorphism, because it only seems to worry about the validity of the resulting type, and (->) is special; by contrast, the same cannot be said for forall a. Maybe a, because Maybe genuinely only accepts monotypes without -XImpredicativeTypes). From bulat.ziganshin at gmail.com Sun Dec 6 03:13:21 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Dec 6 02:50:06 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <4B1ADA0E.5070207@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> <200912052225.28597.daniel.is.fischer@web.de> <4B1AD7FB.8050704@btinternet.com> <1B613EE3-B4F8-4F6E-8A36-74BACF0C86FC@yandex.ru> <4B1ADA0E.5070207@btinternet.com> Message-ID: <1444885451.20091206111321@gmail.com> Hello Andrew, Sunday, December 6, 2009, 1:09:18 AM, you wrote: > Maybe once I get hired by some financial modelling consultants and get > paid shedloads of money to write Haskell all day, I'll be able to afford > a Mac. But until then... with such attitude you will never be hired by financial sector. try instead: mac? great! windows? i love it! unix? i've used it since 60's -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From apfelmus at quantentunnel.de Sun Dec 6 05:28:25 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Sun Dec 6 05:03:20 2009 Subject: [Haskell-cafe] Re: universal binary version of Haskell Platform? In-Reply-To: References: <34heh5557a7pdou2jokj05ia77dlc2e7kb@4ax.com> <1259837555.4896.102798.camel@localhost> Message-ID: Benjamin L.Russell wrote: > Ah, that's too bad. That means that I won't be able to invoke GHC > outside of the Terminal application by default, and that even if I > create a Darwin shell script and alias to invoke it from Aqua, the > icon for that shell script will only be generic by default. I'd > rather click on an application icon in the Dock. You can write an applescript similar to Open Terminal Here from http://www.entropy.ch/software/applescript/ and endow it with a custom icon. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From andrewcoppin at btinternet.com Sun Dec 6 08:05:19 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Dec 6 07:39:41 2009 Subject: [Haskell-cafe] Low Level Audio - Writing bytes to the sound card? In-Reply-To: <1444885451.20091206111321@gmail.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <32776939-36DE-4AAC-B948-F3149BAEAA09@yandex.ru> <200912052225.28597.daniel.is.fischer@web.de> <4B1AD7FB.8050704@btinternet.com> <1B613EE3-B4F8-4F6E-8A36-74BACF0C86FC@yandex.ru> <4B1ADA0E.5070207@btinternet.com> <1444885451.20091206111321@gmail.com> Message-ID: <4B1BAC0F.2080206@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Sunday, December 6, 2009, 1:09:18 AM, you wrote: > > >> Maybe once I get hired by some financial modelling consultants and get >> paid shedloads of money to write Haskell all day, I'll be able to afford >> a Mac. But until then... >> > > with such attitude you will never be hired by financial sector. try instead: > > mac? great! windows? i love it! unix? i've used it since 60's > That's OK. I'm reasonably sure I will never get hired by the financial sector /anyway/. :-( From andrewcoppin at btinternet.com Sun Dec 6 08:18:59 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Dec 6 07:53:24 2009 Subject: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? In-Reply-To: References: <619187.27009.qm@web113112.mail.gq1.yahoo.com>, <4B1A7FE7.1080707@btinternet.com>, <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com>, <4B1AC38B.7090507@btinternet.com>, <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> Message-ID: <4B1BAF43.10704@btinternet.com> john lask wrote: > I think there are some misapprehensions here:- > > Many haskell packages binding to c libraries will compile with ghc > without problems on windows - without cygwin, without mingw/msys system. OK, well I haven't tried building every C binding on all of Hackage, just a few of them. So far none of them have worked. (Including wxHaskell, SDL, one of the database packages, etc.) It's got to the point where I've simply given up trying. Most such packages just don't seem to work on Windows, and nobody on the mailing lists or on IRC has any clue why. (I guess because few people in the Haskell community use Windows and understand how it's supposed to work.) > Some such packages build "out of the box" on windows, like the zlib > package which contains the c source for the c zlib library. GHC is able > to compile and build this packages without any other c > compiler/libraries/unix emulators etc because ghc itself contains part > of the gcc c compiler tool chain and comes with all c standard headers, > c++ headers and c/c++ runtime libraries. Yes, I realised long ago that GHC uses GCC and other GNU build tools. (Presumably this makes porting to Windows far easier.) More recently I realised that it also includes a surprisingly large set of header files, seemingly including the entire Win32 API, which is interesting. > There > is only one gotch-ya - you need to have a import library for the gcc > tool chain (thats what ghc uses) i.e. a ".a" library and not the native > windows ".LIB" import library. They're different?? o_O Oh. Suddenly several things seem clearer... > If you don't have ".a" import library > but have the dll then the '.a' import library be built for any dll > relativley easily. Any idea how? > the bigest problem hamperring cleaner builds of haskell packages on > windows is the lack of any standardised scheme for the installation of > c-libraries and header files (and of course the availability of a > suitable build of the library). Isn't one of Cabal's jobs to figure out where stuff is? Can't we get Cabal on Windows to say "hey, I need to find foo.h, you know where that is?" Or something like that? > Another problem hampering the install of haskell packages on windows is > the use of the unix autoconf build system (./configure) - package > writters note! Heh. I found one Wiki page once describing how to set up a Cabal package. When it started talking about how to integrate Automake, I hung my head is dispair. (I believe the page in question is fixed now. But a lot of package authors seem to assume that everybody just uses Unix of some kind...) From andrewcoppin at btinternet.com Sun Dec 6 08:25:27 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Dec 6 07:59:49 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> Message-ID: <4B1BB0C7.9050902@btinternet.com> Stephen Tetley wrote: > Hi John > > Fair points - but aren't you always going to 'need' at least MinGW? > (for some degree of 'need' of course, I use it quite a bit though > prefer Cygwin, I suppose Andrew C. would care not to use either). > I guess there's a difference in culture here. On Unix, it is usual to distribute programs as source, and build from source. (I guess in part because each one of the 12,657,234 different Unix variants is slightly different, and the program needs to work differently.) On Windows, it is usual to distribute everything as compiled binaries. (Indeed, for most commercial software, the sources simply aren't available at all.) And users get a binary program and binary DLLs or whatever. Developers get a binary DLL and whatever header files or import libraries are necessary to use it. > GHC brings with it gcc and ld, ar ... but not much else. If I'm understanding this correctly, John is saying that GCC requires a different form of import library before you can access a DLL. For binary-only DLLs, this presumably won't be available. Hence the (abnormal) requirement to build the whole library from source, rather than just drop in a DLL and be done with it. Unix *expects* you to build everything from source, and so there are standard toolchains which are almost always available, and standard installation locations and so on and so forth. Windows does *not* expect you to be building things from source, and so is less-well set up in that regard. I don't suppose there's any danger of GHC ever switching to a native Win32 toolchain? (I don't actually know if one even exists with a sufficiently liberal license...) From dan.doel at gmail.com Sun Dec 6 08:39:05 2009 From: dan.doel at gmail.com (Dan Doel) Date: Sun Dec 6 08:13:37 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <5e0214850912052242v4010c273r3d8363d3709117b1@mail.gmail.com> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> <0B59A706-8C41-47B9-A858-5ACE297581E1@cs.uu.nl> <5e0214850912052242v4010c273r3d8363d3709117b1@mail.gmail.com> Message-ID: <200912060839.05428.dan.doel@gmail.com> Apologies for the double-reply... Your mail prompted me to finally get around to adding a mono/polytype system to an interpreter I've been working on for pure type systems, to see what a GHC-alike type system would look like. Here's what I came up with. Constants are: *m, []m, *p and []p Axioms are: *m : []m, *p : []p Rules go as follows: (*m,*m,*m) This is obvious, because it allows normal functions. ([]m,[]m,[]m) This gives arbitrary order type constructors (that is, it expands the m-kinds to km ::= *m | km -> km) ([]m,*m,*p) ([]m,*p,*p) These allows quantification over types. Note that if you erase the mono/poly distinctions, you get the single rule ([],*,*), which is the impredicative rule for the lambda cube. However, this system tracks a distinction, so it remains predicative (universal quantifiers don't range over types that contain universal quantifiers). With just these rules, I think we accept just the types valid in ordinary Haskell. We have higher order types, but we can only have polytypes in prenex normal form, because quantification sticks a type into *p, and the only thing we can do with a *p is add more quantifiers (over []m) to the beginning.r To get rank-n types back, we need to be able to write functions that accept and return polytypes as arguments. This corresponds to the rules: (*m,*p,*p) (*p,*m,*p) (*p,*p,*p) Note that []p never appears in our rules; it exists only to give *p a type (which may not strictly be necessary, even, but it doesn't hurt). Data types would have kinds like: Maybe : *m -> *m and so types like Maybe (forall a. a -> a) would be invalid, because it's trying to use the type constructor with a *p. This type system is a bit stricter than the one GHC uses for rank-n types, as if you have: id : forall a : *m. a -> a You cannot instantiate a to forall a. a -> a, because it has kind *p. GHC allows that sort of impredicative instantiation with just rank-n types turned on. As alluded to earlier, one can recover an ordinary impredicative F_w by erasing the mono/poly distinctions. The rules collapse to: (*,*,*) ([],*,*) ([],[],[]) If anyone's interested in playing with the checker, it can be found at http://code.haskell.org/~dolio/ in the pts repository (I'll try to get a little documentation for the REPL uploaded). And let me know if you find something that types but shouldn't, or some such nonsense. Cheers, -- Dan From stephen.tetley at gmail.com Sun Dec 6 09:39:57 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sun Dec 6 09:14:28 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4B1BB0C7.9050902@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> Message-ID: <5fdc56d70912060639j9dbada2sf60686065d1cfd49@mail.gmail.com> Hi Andrew 2009/12/6 Andrew Coppin : > > On Windows, it is usual to distribute everything as compiled binaries. > (Indeed, for most commercial software, the sources simply aren't available > at all.) And users get a binary program and binary DLLs or whatever. > Developers get a binary DLL and whatever header files or import libraries > are necessary to use it. Indeed, but the Haskell libraries you want to use are in source form, no? Being a Haskell developer you're at least one step out of the usual, and most of the libraries are coming from developers on Unix so they can't be expected to package things for Windows. > If I'm understanding this correctly, John is saying that GCC requires a > different form of import library before you can access a DLL. For > binary-only DLLs, this presumably won't be available. Hence the (abnormal) > requirement to build the whole library from source, rather than just drop in > a DLL and be done with it. John mentioned pexports in another message. I'd never come across it before - it would seem to improve the situation significantly, certainly for libraries that are more easily compilable with MSVCC like PortAudio, Shiva OpenVG, or where you have a reasonable DLL distributed like SDL. Best wishes Stephen From mauricio.antunes at gmail.com Sun Dec 6 11:36:01 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Sun Dec 6 11:10:55 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4B1BB0C7.9050902@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> Message-ID: > I guess there's a difference in culture here. > > On Unix, it is usual to distribute programs as source, and build > from source. I see more than a cultural issue here. Suppose you write bindings to somelib-1.0.2, and release it with somelib-1.0.2. Then, somelib-1.0.3 is released to solve a serious security issue with 1.0.2. Linux or unix distributions will update their repositories, but users of your bindings will blindly keep using 1.0.2. Best, Maur?cio From aslatter at gmail.com Sun Dec 6 11:40:00 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Dec 6 11:14:30 2009 Subject: [Haskell-cafe] Re: Optimizing Parsec 3 -- was: Wiki software? In-Reply-To: References: <20091204210957.GA14889@protagoras.phil.berkeley.edu> Message-ID: <694519c50912060840y371ebedaw8f9d21660268e518@mail.gmail.com> On Fri, Dec 4, 2009 at 7:47 PM, Paulo Tanimoto wrote: > > Great! ?Antoine, other tests we should do? ?Derek, I apologize if > you're already following this, but can you give us your opinion? > > Paulo > Well, the more eyes and test cases we can get on the new code the better. I'd also like to encourage anyone who's familiar with the idea of how parsec works to take a look at my changes to make sure they're comprehensible. Antoine From jeremy.odonoghue at gmail.com Sun Dec 6 12:08:22 2009 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Sun Dec 6 11:42:51 2009 Subject: [Haskell-cafe] HP + Gtk2hs? In-Reply-To: <1297085518.20091205223651@gmail.com> References: <4B1A7EE7.70807@btinternet.com><924926435.20091205191516@gmail.com><4B1AB109.4080907@btinternet.com> <1297085518.20091205223651@gmail.com> Message-ID: <1260119302.11982.1348709277@webmail.messagingengine.com> Hi Andrew, On 5 Dec 2009, at 16:15, Bulat Ziganshin wrote: > Saturday, December 5, 2009, 6:40:23 PM, you wrote: >> Gtk2hs is currently the *only* GUI binding that actually works on >> Windows. > > i thought that wx and even qt are in rather good shape now Thanks for the vote, Bulat. wxHaskell installs out of the box easily on Windows now. See http:// haskell.org/haskellwiki/WxHaskell/Building. The hardest part is building wxWidgets itself. Prerequisites are: - MinGW C++ compiler Make, with MSys shell (to build wxWidgets) - wx-config binary for Windows To build wxWidgets, download the Windows source package from wxWidgets. 1) You will need the Windows port of wx-config in your path. This can be downloaded from http://wxconfig.googlepages.com/ 2) You will need to compile wxWidgets using MSys. We have tested against MinGW 5.1.6 with g++ compiler, MinGW Make, MSYS-1.0.11, wxMSW-2.8.10, which are the latest versions, and can be downloaded from their respective websites. I used a completely clean install of the latest Haskell Platform to validate the procedure. Please note: all commands to be entered in an MSys shell. cd /c/path/to/wxWidgets-2.8.10/build/msw mingw32-make -f makefile.gcc BUILD=release MONOLITHIC=1 SHARED=1 UNICODE=1 set PATH=$PATH:/c/path/to/wx-config set WXWIN=/c/path/to/wxWidgets-2.8.10 set WXCFG=gcc_dll/mswu At this point you have installed and configured wxWidgets on Windows. The Haskell part is more or less trivial: cabal install wx I'd encourage you to try wxHaskell again, and let us know how you get on. Regards Jeremy -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com From jochem at functor.nl Sun Dec 6 14:01:35 2009 From: jochem at functor.nl (Jochem Berndsen) Date: Sun Dec 6 13:36:05 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: readline-statevar-1.0.1.0 In-Reply-To: <220e47b40912051047k2cfac6bbx50727f6827811597@mail.gmail.com> References: <220e47b40912051047k2cfac6bbx50727f6827811597@mail.gmail.com> Message-ID: <4B1BFF8F.9050302@functor.nl> nerds From jochem at functor.nl Sun Dec 6 14:04:53 2009 From: jochem at functor.nl (Jochem Berndsen) Date: Sun Dec 6 13:39:22 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: readline-statevar-1.0.1.0 In-Reply-To: <4B1BFF8F.9050302@functor.nl> References: <220e47b40912051047k2cfac6bbx50727f6827811597@mail.gmail.com> <4B1BFF8F.9050302@functor.nl> Message-ID: <4B1C0055.3030505@functor.nl> Jochem Berndsen wrote: > nerds This was a friend of mine trying to be funny. Apologies, Jochem -- Jochem Berndsen | jochem@functor.nl | jochem@????.com From chaddai.fouche at gmail.com Sun Dec 6 14:46:38 2009 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Sun Dec 6 14:21:07 2009 Subject: [Haskell-cafe] Haskell-Newbie and Char-Function In-Reply-To: <4B1ACA53.7040503@rkit.pp.ru> References: <26656676.post@talk.nabble.com> <4B1ACA53.7040503@rkit.pp.ru> Message-ID: On Sat, Dec 5, 2009 at 10:02 PM, ??????? ?????? wrote: > fct a n = (snd $ break (==a) ['a'..'z']) !! n Not bad but you forgot that it might need to wrap around, besides break isn't really the best function to use here since we don't need the first part of the pair : > shift n ch = dropWhile (/=ch) (cycle ['a'..'z']) !! n Still I think the ord and mod version will be faster. -- Jeda? From dynasticon at mac.com Sun Dec 6 15:05:58 2009 From: dynasticon at mac.com (Jeffrey Scofield) Date: Sun Dec 6 15:04:43 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> Message-ID: Andrew Coppin writes: > I guess there's a difference in culture here. > > On Unix, it is usual to distribute programs as source, and build from > source. (I guess in part because each one of the 12,657,234 different > Unix variants is slightly different, and the program needs to work > differently.) > > On Windows, it is usual to distribute everything as compiled > binaries. I think the real cultural difference is that you aren't a user, you're a prospective Haskell developer, as others have said. Developers pretty much have to install tools (like compilers and preprocessors) and have to work with source code. Traditionally, Unix *comes with* thousands of tools that are useful to developers. Windows traditionally came with none, at least none that I was ever able to find. Since many of the traditional Unix tools are available free, it makes sense that somebody would want to port them to Windows *for doing development*. It's not so much a Unix emulation as a solution to the lack of native Windows tools. Of course this makes sense especially to somebody who has gotten used to the Unix tools (such as myself). I would never try to *develop* seriously under Windows using just what comes preinstalled. Users of Unix (not developers) are just as used to getting compiled binaries as users of Windows. A good example of this in today's world is Mac OS X (or the iPhone, which is a small Unix system in essence). In earlier times, I assure you that users of Solaris (say) didn't expect to get a source release of Oracle and compile it up from scratch. There were indeed a few different supported versions of Solaris (different releases and hardware platforms), but this was Sun's and/or Oracle's problem. The open source movement has complicated this picture (mostly for the good, from the user's standpoint), but this just makes more people into developers in essence. This is the price you pay for getting stuff for free. It seems to me it doesn't make a lot of sense to complain about this. If you don't want to be a developer you can usually find something to buy that will be precompiled for you, or you can hire somebody. This is not to say that on a given day it isn't frustrating when you can't get something to compile, especially if it's just a tool you need to compile something else. But this is why developers are so wealthy, they have the fortitude to work through these problems. (Ha ha.) Regards, Jeff Scofield Seattle From byorgey at seas.upenn.edu Sun Dec 6 15:50:55 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sun Dec 6 15:25:25 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <36C40624-B050-4A8C-8CAF-F15D84467180@phys.washington.edu> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> <20091205212848.GA23711@seas.upenn.edu> <36C40624-B050-4A8C-8CAF-F15D84467180@phys.washington.edu> Message-ID: <20091206205055.GA24755@seas.upenn.edu> On Sat, Dec 05, 2009 at 02:13:10PM -0800, Gregory Crosswhite wrote: > > The problem comes from the fact that >>= takes a *function* as its > second argument, and so if the first argument is an error then we > can't evaluate the second argument in order to see if it has an > error as well. Hmm, that's true. I guess I misspoke about liftM2 (+) being able to collect both error messages. > instance Functor E where > fmap _ (E (Left error)) = E (Left error) > fmap f (E (Right argument)) = E (Right (f argument)) > > instance Applicative E where > pure = E . Right > (<*>) (E (Left error2)) (E (Left error1)) = E (Left (error1 ++ error2)) > (<*>) (E (Left error)) _ = E (Left error) > (<*>) _ (E (Left error)) = E (Left error) > (<*>) (E (Right function)) (E (Right argument)) = E (Right (function argument)) OK, this looks like a perfectly valid Applicative instance for E (it satisfies the Applicative laws). So what we have here, it seems, is a type with at least two reasonable Applicative instances, one of which does *not* correspond to a Monad instance. My argument is that it is very strange (I might even go so far as to call it a bug) to have a type with an Applicative instance and a Monad instance which do not correspond, in the sense that pure = return (<*>) = ap although I certainly understand the motivation in this case. Hmm, I'll have to think about this a bit more. The Monad instance which tries passing undefined to the right-hand side of >>= if the left-hand side is an error is strangely compelling, if semantically unsound... -Brent From ben.franksen at online.de Sun Dec 6 16:54:56 2009 From: ben.franksen at online.de (Ben Franksen) Date: Sun Dec 6 16:29:47 2009 Subject: [Haskell-cafe] Re: Re: ANNOUNCE: Blueprint 0.1 -- PREVIEW References: <2BCB5052-CE53-4ABE-A4E5-3E2DA2A0F444@phys.washington.edu> Message-ID: Gregory Crosswhite wrote: > On Dec 4, 2009, at 11:02 AM, Ben Franksen wrote: >> Gregory Crosswhite wrote: >>> I have posted Blueprint to Hackage so that people can see what I have >>> done and possibly play with it. >> Very interesting, this. However, I could not build it. I get [...] > At the moment you need to execute the setup script manually: > > runhaskell Setup.hs bootstrap > ./Setup configure > ./Setup build +RTS -N4 -RTS > ./Setup install > > (The "+RTS -N4 -RTS" part is optional; it just tells Setup to use up to 4 > threads to do building in parallel where possible.) Thanks. I recommend adding a small readme.txt explaining stuff like that. > Anyway, thank you for checking out Blueprint! At this point it might be > better to pull the sources directly from github (the "Home Page" link) Will do. > since I have made many improvements since that release (though I haven't > fixed the "cabal install" problem yet). And I do plan on thoroughly > polishing and documenting Blueprint one of these days. :-) Thanks & Cheers Ben From asviraspossible at gmail.com Sun Dec 6 17:31:29 2009 From: asviraspossible at gmail.com (Victor Nazarov) Date: Sun Dec 6 17:05:58 2009 Subject: [Haskell-cafe] diff implementation in haskell Message-ID: Are there pure haskell implementations of diff and diff3 algorithms. Like: > data Diff a = Deleted [a] | Common [a] | Added [a] > > diff :: Eq a => [a] -> [a] -> [Diff a] > > diff3 :: Eq a => [a] -> [a] -> [a] -> [a] or smth more general like: > class Diff a where > type Difference a > diff :: a -> a -> Difference a > patch :: a -> Difference a -> a > > prop_diffpatch a b = patch a (diff a b) == b ? If not, where can I start towards the implementation? What's the way to do it more functionally? -- Victor Nazarov From dons at galois.com Sun Dec 6 17:38:55 2009 From: dons at galois.com (Don Stewart) Date: Sun Dec 6 17:13:26 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: References: Message-ID: <20091206223855.GC920@whirlpool.galois.com> asviraspossible: > Are there pure haskell implementations of diff and diff3 algorithms. Like: > > > data Diff a = Deleted [a] | Common [a] | Added [a] > > > > diff :: Eq a => [a] -> [a] -> [Diff a] > > > > diff3 :: Eq a => [a] -> [a] -> [a] -> [a] > There's at least one on Hackage: http://hackage.haskell.org/package/Diff -- Donn From tehgeekmeister at gmail.com Sun Dec 6 18:12:31 2009 From: tehgeekmeister at gmail.com (Ezekiel Smithburg) Date: Sun Dec 6 17:47:25 2009 Subject: [Haskell-cafe] help Message-ID: On Sun, Dec 6, 2009 at 4:53 AM, wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe@haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request@haskell.org > > You can reach the person managing the list at > haskell-cafe-owner@haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > Today's Topics: > > 1. Re: Low Level Audio - Writing bytes to the sound card? > (Daniel Fischer) > 2. Re: HP + Gtk2hs? (M Xyz) > 3. Re: Low Level Audio - Writing bytes to the sound card? (M Xyz) > 4. Re: Low Level Audio - Writing bytes to the sound card? > (Daniel Fischer) > 5. RE: Low Level Audio - Writing bytes to the sound card? (john lask) > 6. Re: New Hackage category: Error Handling (Henning Thielemann) > 7. Re: Low Level Audio - Writing bytes to the sound card? (M Xyz) > 8. RE: Low Level Audio - Writing bytes to the sound card? (M Xyz) > 9. PortAudio library successfully built on Windows (M Xyz) > 10. When are undecidables ok? (Michael Snoyman) > 11. Re: When are undecidables ok? (Luke Palmer) > 12. Re: When are undecidables ok? (Michael Snoyman) > 13. Re: ANNOUNCE: error-message (Ariel J. Birnbaum) > 14. Re: What is the rank of a polymorphic type? (Eugene Kirpichov) > 15. Re: universal binary version of Haskell Platform? > (Benjamin L.Russell) > 16. Re: What is the rank of a polymorphic type? (Dan Doel) > 17. Re[2]: [Haskell-cafe] Low Level Audio - Writing bytes to the > sound card? (Bulat Ziganshin) > 18. Re: universal binary version of Haskell Platform? > (Heinrich Apfelmus) > 19. Re: Low Level Audio - Writing bytes to the sound card? > (Andrew Coppin) > 20. Re: binding to C libraries on Windows was Low Level Audio - > Writing bytes to the sound card? (Andrew Coppin) > > > ---------- Forwarded message ---------- > From: Daniel Fischer > To: haskell-cafe@haskell.org > Date: Sun, 6 Dec 2009 01:24:17 +0100 > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > Am Sonntag 06 Dezember 2009 00:47:38 schrieb M Xyz: > > Daniel, Thank you for your thoughtful reply. I didn't know about those > > flags. The log is fairly long, and as I'm new to Haskell and Cabal it is > > mostly meaningless to me. I see very many incidences of "searching for > ___ > > in path. Cannot find ___ on the path" so maybe this is all as simple as > me > > not setting my environment correctly. > > If you have cpphs, hugs, jhc, greencard etc., it is probably something > about your > environment. If you don't have them, it's clear that they aren't found. > > On the other hand, that doesn't explain > > Using c2hs version 0.16.0 given by user at: C:\Program > Files\Haskell\bin\c2hs.exe > > -- so it finds c2hs, and can apparently run c2hs --version > > ("C:\\Program > Files\\Haskell\\bin\\c2hs.exe",["--include=dist\\build","--cppopts=- > D__GLASGOW_HASKELL__=610","--cppopts=-IC: > > \\A\\install\\programming\\portaudio\\portaudio\\include","--output-dir=dist\\build","-- > output=Sound\\PortAudio\\Base.hs",".\\Sound\\PortAudio\\Base.chs"]) > c2hs.exe: does not exist > C:\Program Files\Haskell\bin\c2hs.exe returned ExitFailure 1 > > -- bang > > To ascertain whether c2hs works at all, can you try to run it manually? > > (cd to an appropriate directory, > > cabal unpack portaudio > > cd portaudio (or whatever, so that Base.chs is found via > .\Sound\PortAudio\Base.chs > > md dist\build > > c2hs.exe --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=610 > --cppopts=-IC: > \A\install\programming\portaudio\portaudio\include --output-dir=dist\build > -- > output=Sound\PortAudio\Base.hs .\Sound\PortAudio\Base.chs > ) > If that works, the problem is somewhere in cabal, otherwise in c2hs, either > way, we'll > know more. > > > > ---------- Forwarded message ---------- > From: M Xyz > To: haskell-cafe@haskell.org, Andrew Coppin > Date: Sat, 5 Dec 2009 16:34:52 -0800 (PST) > Subject: Re: [Haskell-cafe] HP + Gtk2hs? > > > --- On *Sat, 12/5/09, Andrew Coppin * wrote: > > >> Hell, I even followed a C++ guide to Win32 programming and > >> managed to translate an "open a blank window" program to Haskell, and it > >> worked. Maybe somebody just needs to sit down and write a nice binding > >> for doing native GUI stuff under Win32? > > Well there's > http://haskell.org/ghc/docs/latest/html/libraries/Win32/Graphics-Win32.htmlfor opening blank windows. ;) > > This relates to my question a couple days ago about a good cross platform > 2d library. I wonder why there isnt a Haskell library that follows in the > footsteps of Java's Swing - by that I mean, just have a very simple low > level way of opening a window, getting mouse clicks, and an abstracted > drawing layer... and make the GUIs with that. The GUIs are drawn and not OS > widgets. That's exactly why I was looking for something like Cairo. My > interest is in composable fudgets (stealing the word from fudgets). > > This way every platform can share the same GUI library and HP can ship with > the minimal tools to open a window and draw on every system. Plus OS guis > are the wrong thing for Haskell. You need to retain the power to make better > abstractions. > > > > > > ---------- Forwarded message ---------- > From: M Xyz > To: haskell-cafe@haskell.org, Daniel Fischer > Date: Sat, 5 Dec 2009 16:49:49 -0800 (PST) > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > > > --- On *Sat, 12/5/09, Daniel Fischer * wrote: > > > > If you have cpphs, hugs, jhc, greencard etc., it is probably something > about your > environment. If you don't have them, it's clear that they aren't found. > > I don't know what those things are. I have nothing but what came with HP > other than installing c2hs today. > > If that works, the problem is somewhere in cabal, otherwise in c2hs, either > way, we'll > know more. > > Alright, I followed the instructions and everything was as you said. I > still get "c2hs.exe does not exist". > > C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>"C:\Program > Files\Has > kell\bin\c2hs.exe" --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=610 > --cp > popts=-IC:\A\install\programming\portaudio\portaudio\include > --output-dir=dist\b > uild --output=Sound\PortAudio\Base.hs .\Sound\PortAudio\Base.chs > c2hs.exe: does not exist > > C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>pause > Press any key to continue . . . > > By the way, I have posted this problem to the c2hs mailing list in case > they have some insight. > > > > > ---------- Forwarded message ---------- > From: Daniel Fischer > To: M Xyz > Date: Sun, 6 Dec 2009 02:34:17 +0100 > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > I just had another idea. > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > c2hs: does not exist > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > Try installing from the unpacked sources (cd portaudio; cabal install) or > the old- > fashioned way: > > cd portaudio-0.0.1 > > ghc --make Setup > > ./Setup configure --help > (choose your options, prefix, profiling, ...) > > ./Setup configure $OPTIONS > ./Setup build > > if all's well, > > ./Setup haddock > ./Setup install > > (dies for me with > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei oder > Verzeichnisnicht gefunden > c2hs: Error during preprocessing custom header file > cabal: Error: some packages failed to install: > portaudio-0.0.1 failed during the building phase. The exception was: > exit: ExitFailure 1 > because I don't have portaudio installed) > > > > ---------- Forwarded message ---------- > From: john lask > To: , > Date: Sun, 6 Dec 2009 02:03:32 +0000 > Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > > > I don't know whether this will help you but I just downloaded an built > the haskell portaudio package ... (I had a windows msvc build of > portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 > > make an import lib for ghc from dll: > pexports libpa19.dll > libpa19.def > dlltool --input-def libpa19.def --output-lib libpa19.a > > edit the .cabal file or use command line flags > > extra-Libraries: pa19 > extra-lib-dirs: c:\portaudio19\lib > include-dirs: c:\portaudio19\include > > runghc setup configure > > make sure you have cpp i.e. the c-preprocessor on your exe path, > otherwise you will get > 'cpp' is not recognized as an internal or external command, > operable program or batch file. > c2hs.exe: Error during preprocessing custom header file > > runghc setup build > > builds ok ...?? > > > > From: daniel.is.fischer@web.de > > To: functionallyharmonious@yahoo.com > > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > > Date: Sun, 6 Dec 2009 02:34:17 +0100 > > CC: haskell-cafe@haskell.org > > > > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > > > I just had another idea. > > > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > > c2hs: does not exist > > > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > > > Try installing from the unpacked sources (cd portaudio; cabal install) or > the old- > > fashioned way: > > > > cd portaudio-0.0.1 > > > > ghc --make Setup > > > > ./Setup configure --help > > (choose your options, prefix, profiling, ...) > > > > ./Setup configure $OPTIONS > > ./Setup build > > > > if all's well, > > > > ./Setup haddock > > ./Setup install > > > > (dies for me with > > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei > oder > > Verzeichnisnicht gefunden > > c2hs: Error during preprocessing custom header file > > cabal: Error: some packages failed to install: > > portaudio-0.0.1 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > because I don't have portaudio installed) > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ------------------------------ > Australia's #1 job site If It Exists, You'll Find it on SEEK > > > ---------- Forwarded message ---------- > From: Henning Thielemann > To: Michael Snoyman > Date: Sun, 06 Dec 2009 03:05:30 +0100 (CET) > Subject: Re: [Haskell-cafe] New Hackage category: Error Handling > > On Sat, 5 Dec 2009, Henning Thielemann wrote: > > On Sun, 6 Dec 2009, Michael Snoyman wrote: >> >> I think there are plenty of examples like web servers. A text editor with >>> plugins? I >>> don't want to lose three hours worth of work just because some plugin >>> wasn't written >>> correctly. For many classes of programs, the distinction between error >>> and exception is >>> not only blurred, it's fully irrelevant. Harping on people every time >>> they use error in >>> the "wrong" sense seems unhelpful. >>> >>> Hope my commenting on this subject doesn't become my own form of >>> *pedantry*. >>> >> >> In an earlier thread I have explained that one can consider a software >> architecture as divided into levels. What is an error in one level (text >> editor plugin, web server thread, operating system process) is an exception >> in the next higher level (text editor, web server, shell respectively). This >> doesn't reduce the importance to distinguish between errors and exceptions >> within one level. All approaches so far that I have seen in Haskell just mix >> exceptions and errors in an arbitrary way. >> > > > I have just written more details on this topic: > http://www.haskell.org/haskellwiki/Error_vs._Exception > > > > ---------- Forwarded message ---------- > From: M Xyz > To: Daniel Fischer > Date: Sat, 5 Dec 2009 18:08:07 -0800 (PST) > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > > > --- On *Sat, 12/5/09, Daniel Fischer * wrote: > > > > cd portaudio-0.0.1 > > ghc --make Setup > > ./Setup configure --help > (choose your options, prefix, profiling, ...) > > ./Setup configure $OPTIONS > ./Setup build > > > Everything went well until "Setup build" which yielded our friend "c2hs.exe > does not exist". > > > C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>ghc --make Setup > [1 of 1] Compiling Main ( Setup.hs, Setup.o ) > Linking Setup.exe ... > > C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup configure > --hel > p > Usage: Setup configure [FLAGS] > > Flags for configure: .......(edited out)................. > > C:\A\install\programming\portaudio\haskell\portaudio-0..0.1>Setup configure > --ext > ra-include-dirs="C:\A\install\programming\portaudio\portaudio\include" > --extra-l > > ib-dirs="C:\A\install\programming\portaudio\portaudio\build\msvc\Win32\Release" > Configuring portaudio-0.0.1... > > C:\A\install\programming\portaudio\haskell\portaudio-0.0.1>Setup build > Preprocessing library portaudio-0.0.1... > c2hs.exe: does not exist > > > > > > > ---------- Forwarded message ---------- > From: M Xyz > To: daniel.is.fischer@web.de, john lask > Date: Sat, 5 Dec 2009 18:17:29 -0800 (PST) > Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > I am going to give this a try. Thanks. > Where can I get the pexports and dlltool utilities? > > Google yields: > http://www.emmestech.com/software/pexports-0.43/download_pexports.html > http://sourceware.org/binutils/ > > Are those correct? > > --- On *Sat, 12/5/09, john lask * wrote: > > > From: john lask > Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > To: daniel.is.fischer@web.de, functionallyharmonious@yahoo.com > Cc: haskell-cafe@haskell.org > Date: Saturday, December 5, 2009, 9:03 PM > > > > I don't know whether this will help you but I just downloaded an built > the haskell portaudio package ... (I had a windows msvc build of > portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 > > make an import lib for ghc from dll: > pexports libpa19.dll > libpa19.def > dlltool --input-def libpa19.def --output-lib libpa19.a > > edit the .cabal file or use command line flags > > extra-Libraries: pa19 > extra-lib-dirs: c:\portaudio19\lib > include-dirs: c:\portaudio19\include > > runghc setup configure > > make sure you have cpp i.e. the c-preprocessor on your exe path, > otherwise you will get > 'cpp' is not recognized as an internal or external command, > operable program or batch file. > c2hs.exe: Error during preprocessing custom header file > > runghc setup build > > builds ok ...?? > > > > From: daniel.is.fischer@web.de > > To: functionallyharmonious@yahoo.com > > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > > Date: Sun, 6 Dec 2009 02:34:17 +0100 > > CC: haskell-cafe@haskell.org > > > > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > > > I just had another idea. > > > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > > c2hs: does not exist > > > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > > > Try installing from the unpacked sources (cd portaudio; cabal install) or > the old- > > fashioned way: > > > > cd portaudio-0.0.1 > > > > ghc --make Setup > > > > ./Setup configure --help > > (choose your options, prefix, profiling, ...) > > > > ./Setup configure $OPTIONS > > ./Setup build > > > > if all's well, > > > > ./Setup haddock > > ./Setup install > > > > (dies for me with > > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei > oder > > Verzeichnisnicht gefunden > > c2hs: Error during preprocessing custom header file > > cabal: Error: some packages failed to install: > > portaudio-0.0.1 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > because I don't have portaudio installed) > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ------------------------------ > Australia's #1 job site If It Exists, You'll Find it on SEEK > > > > > ---------- Forwarded message ---------- > From: M Xyz > To: john lask , vanenkj@gmail.com > Date: Sat, 5 Dec 2009 19:47:04 -0800 (PST) > Subject: [Haskell-cafe] PortAudio library successfully built on Windows > > John Lask, > The steps you enumerated below successfully built portaudio for me! Thank > you! > > I wonder though, you said to rename the dll to libpa19.dll from > portaudio_x86.dll > and to change the .cabal entry from "extra-Libraries: portaudio" to > "extra-Libraries: pa19". > Since my .dll name and .cabal file entry were mismatched, was that what > could have been wrong all along? Was the creation of a .a file necessary? > I would delete the .a file and retry with libportaudio.dll but I won't push > my luck. > > Now if I could just get Gtk2hs working now, I could be happy *and* > productive. :) > > --- On *Sat, 12/5/09, john lask * wrote: > > > From: john lask > Subject: RE: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > To: daniel.is.fischer@web.de, functionallyharmonious@yahoo.com > Cc: haskell-cafe@haskell.org > Date: Saturday, December 5, 2009, 9:03 PM > > > > I don't know whether this will help you but I just downloaded an built > the haskell portaudio package ... (I had a windows msvc build of > portaudio dll already) the process I used ... ghc 6.10.4, portaudio-19 > > make an import lib for ghc from dll: > pexports libpa19.dll > libpa19.def > dlltool --input-def libpa19.def --output-lib libpa19.a > > edit the .cabal file or use command line flags > > extra-Libraries: pa19 > extra-lib-dirs: c:\portaudio19\lib > include-dirs: c:\portaudio19\include > > runghc setup configure > > make sure you have cpp i.e. the c-preprocessor on your exe path, > otherwise you will get > 'cpp' is not recognized as an internal or external command, > operable program or batch file. > c2hs.exe: Error during preprocessing custom header file > > runghc setup build > > builds ok ...?? > > > > From: daniel.is.fischer@web.de > > To: functionallyharmonious@yahoo.com > > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > > Date: Sun, 6 Dec 2009 02:34:17 +0100 > > CC: haskell-cafe@haskell.org > > > > Am Sonntag 06 Dezember 2009 01:49:49 schrieb M Xyz: > > > > I just had another idea. > > > > dafis@linux-mkk1:~> c2hs -o memyself.hs memyself.chs > > c2hs: does not exist > > > > it's not that c2hs isn't found or something, c2hs doesn't find Base.chs! > > > > Try installing from the unpacked sources (cd portaudio; cabal install) or > the old- > > fashioned way: > > > > cd portaudio-0.0.1 > > > > ghc --make Setup > > > > ./Setup configure --help > > (choose your options, prefix, profiling, ...) > > > > ./Setup configure $OPTIONS > > ./Setup build > > > > if all's well, > > > > ./Setup haddock > > ./Setup install > > > > (dies for me with > > dist/build/Sound/PortAudio/Base.chs.h:1:23: error: portaudio.h: Datei > oder > > Verzeichnisnicht gefunden > > c2hs: Error during preprocessing custom header file > > cabal: Error: some packages failed to install: > > portaudio-0.0.1 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > because I don't have portaudio installed) > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ------------------------------ > Australia's #1 job site If It Exists, You'll Find it on SEEK > > > > > ---------- Forwarded message ---------- > From: Michael Snoyman > To: Haskell Cafe > Date: Sun, 6 Dec 2009 07:04:46 +0200 > Subject: [Haskell-cafe] When are undecidables ok? > I know this is basically a rewording of a previous e-mail, but I realized > this is the question I *really* wanted to ask. > > We have this language extension UndecidableInstances (not to mention > OverlappingInstances), which seem to divide the Haskell camp into two > factions: > > * Hey, GHC said to turn on this flag. Ok! > * Undecidables are the devil! > > I get the feeling the truth lies in the middle. As I understand it (please > correct me if I am wrong), the problem with undecidables is that they can > create non-terminating instances. However, for certain cases the programmer > should be able to prove to him/herself that the instances will terminate. My > question is: how can you make such a proof? > > I've had to cases in particular that made me want undecidables. Both of > them, IMO, could be solved by creating new extensions to GHC which would not > require undecidables. Nonetheless, for now we only have undecidables at our > disposal. The examples are: > > * Context synonyms (eg, MonadFailure = Monad + Failure). > * Subclass function defaulting > > For an example of the second, a nifty definition of Monad would be: > > class Applicative m => Monad m where > >>= ... > return ... > pure = return > (<*>) = ap > fmap = liftM > > Of course, neither of these is possible in Haskell, so we can use > undecidables. How can a programmer prove that a set of instances is, in > fact, safe? And if they make a mistake and right a bad set of > undecidable/overlapping instances, what's the worst case scenario? Is it a > compile-time or run-time error*? > > Michael > > * Yes, I mean error. > > > ---------- Forwarded message ---------- > From: Luke Palmer > To: Michael Snoyman > Date: Sat, 5 Dec 2009 22:36:43 -0700 > Subject: Re: [Haskell-cafe] When are undecidables ok? > On Sat, Dec 5, 2009 at 10:04 PM, Michael Snoyman > wrote: > > I know this is basically a rewording of a previous e-mail, but I realized > > this is the question I *really* wanted to ask. > > > > We have this language extension UndecidableInstances (not to mention > > OverlappingInstances), which seem to divide the Haskell camp into two > > factions: > > > > * Hey, GHC said to turn on this flag. Ok! > > * Undecidables are the devil! > > > > I get the feeling the truth lies in the middle. As I understand it > (please > > correct me if I am wrong), the problem with undecidables is that they can > > create non-terminating instances. However, for certain cases the > programmer > > should be able to prove to him/herself that the instances will terminate. > My > > question is: how can you make such a proof? > > Well, the reasoning for the "devil" camp (which I admit to being > firmly in[1]) is that such proofs must rely on the algorithm the > compiler uses to resolve instances. You might be able to prove it, > but the proof is necessarily only valid for (possibly current versions > of) GHC. The typeclass resolution algorithm is not in the report, and > there are several conceivable ways of of going about it. > > So it is fine to use them if you are okay with making your code > unportable and future-brittle. I am typically against the mere > existence of code that that is future-brittle, because it encourages > compiler authors not to innovate (and by that token, unportable too, > because it discourages compiler competition). > > Luke > > [1] > http://lukepalmer.wordpress.com/2008/04/08/stop-using-undecidable-instances/ > > > > ---------- Forwarded message ---------- > From: Michael Snoyman > To: Luke Palmer > Date: Sun, 6 Dec 2009 08:20:09 +0200 > Subject: Re: [Haskell-cafe] When are undecidables ok? > > > On Sun, Dec 6, 2009 at 7:36 AM, Luke Palmer wrote: > >> On Sat, Dec 5, 2009 at 10:04 PM, Michael Snoyman >> wrote: >> > I know this is basically a rewording of a previous e-mail, but I >> realized >> > this is the question I *really* wanted to ask. >> > >> > We have this language extension UndecidableInstances (not to mention >> > OverlappingInstances), which seem to divide the Haskell camp into two >> > factions: >> > >> > * Hey, GHC said to turn on this flag. Ok! >> > * Undecidables are the devil! >> > >> > I get the feeling the truth lies in the middle. As I understand it >> (please >> > correct me if I am wrong), the problem with undecidables is that they >> can >> > create non-terminating instances. However, for certain cases the >> programmer >> > should be able to prove to him/herself that the instances will >> terminate. My >> > question is: how can you make such a proof? >> >> Well, the reasoning for the "devil" camp (which I admit to being >> firmly in[1]) is that such proofs must rely on the algorithm the >> compiler uses to resolve instances. You might be able to prove it, >> but the proof is necessarily only valid for (possibly current versions >> of) GHC. The typeclass resolution algorithm is not in the report, and >> there are several conceivable ways of of going about it. >> >> So it is fine to use them if you are okay with making your code >> unportable and future-brittle. I am typically against the mere >> existence of code that that is future-brittle, because it encourages >> compiler authors not to innovate (and by that token, unportable too, >> because it discourages compiler competition). >> >> Luke >> >> [1] >> http://lukepalmer.wordpress.com/2008/04/08/stop-using-undecidable-instances/ >> > > So in that case, perhaps the compiler authors can give us some ideas as to > when it's safe to use undecidables? Seems like we should go straight to the > horse's mouth. > > Michael > > > > ---------- Forwarded message ---------- > From: "Ariel J. Birnbaum" > To: Gregory Crosswhite > Date: Sun, 06 Dec 2009 08:34:16 +0200 > Subject: Re: [Haskell-cafe] ANNOUNCE: error-message > > In particular, the motivation for this package was that I have written > > a build system, and I wanted to collect as many errors in the build as > > possible and show them all to the user at once. > > YMMV, but at least for me a deluge of errors is less helpful than a > short list I can fix quickly, then try again. Often by fixing one error > from the list a sizeable portion of the rest just vanish (I forget the > English term for that kind of error). > > (In before "you can use sth like quickfix to go through the first few > errors and compile again whenever you feel like it".) > > -- > Ariel J. Birnbaum > > > > > ---------- Forwarded message ---------- > From: Eugene Kirpichov > To: Stefan Holdermans > Date: Sun, 6 Dec 2009 09:42:34 +0300 > Subject: Re: [Haskell-cafe] What is the rank of a polymorphic type? > 2009/12/6 Stefan Holdermans : > > Eugene, > > > >> 1) Does there exist an authoritative source saying the same? Not that > >> I'm doubting, just supposing that the source would have other > >> interesting information, too :) > > > > You may want to have a look at the already mentioned JFP-article by > Peyton > > Jones et al. and perhaps the work of Kfoury and Wells. > > > >> 2) Is it true that rank (forall a . a, forall a . a) == 0 ? > > > > No, for pairs one takes the maximum of the constituent types. So, here > you'd > > get rank 1. > > > > Note that this is an impredicative type, which is yet another extension > of > > the standard Hindley-Milner typing discipline. > > OK, thanks. > However, isn't the type (forall a . a) -> String impredicative because > it instantiates a type variable of the type constructor (->) p q with > p = forall a . a? > > > > > Cheers, > > > > Stefan > >> > >>> > > > > > > -- > Eugene Kirpichov > Web IR developer, market.yandex.ru > > > > ---------- Forwarded message ---------- > From: Benjamin L.Russell > To: haskell-cafe@haskell.org > Date: Sun, 06 Dec 2009 16:14:06 +0900 > Subject: [Haskell-cafe] Re: universal binary version of Haskell Platform? > On Thu, 03 Dec 2009 10:52:35 +0000, Duncan Coutts > wrote: > > >[...] > > > >There no binary platform installer for OSX PPC. You'll have to grab > >ghc-6.10.4 for PPC from the ghc download page and then install the > >platform from the generic source tarball. > > Ah, that's too bad. That means that I won't be able to invoke GHC > outside of the Terminal application by default, and that even if I > create a Darwin shell script and alias to invoke it from Aqua, the > icon for that shell script will only be generic by default. I'd > rather click on an application icon in the Dock. > > > > >If you'd like to help us next time to make a platform binary for PPC > >then that'd be great. I don't think we have the setup to make universal > >binaries but it should be possible to make a PPC build if we have a > >volunteer. > > Sure, barring job-related time constraints, I'd be happy to volunteer. > My Mac just went out of service because of a hardware problem with the > memory, so I'm order new replacement RAM this weekend. As soon as > that arrives and I install it, the problem should be resolved. > > What should I do? > > -- Benjamin L. Russell > > > > > ---------- Forwarded message ---------- > From: Dan Doel > To: haskell-cafe@haskell.org > Date: Sun, 6 Dec 2009 02:48:09 -0500 > Subject: Re: [Haskell-cafe] What is the rank of a polymorphic type? > On Sunday 06 December 2009 1:42:34 am Eugene Kirpichov wrote: > > OK, thanks. > > However, isn't the type (forall a . a) -> String impredicative because > > it instantiates a type variable of the type constructor (->) p q with > > p = forall a . a? > > There's probably no clear cut answer to this independent of how you think > of > (->). For instance, if we explain the Haskell type system by way of a pure > type system, (->) is a special case of a pi type, which looks like: > > pi x : k. t > > where any xs in t are bound by the pi. We then have: > > p -> q = pi _ : p. q > forall a : k. b = pi a : k. b > > pi types are given types by sets of rules, which look like triples. If > (s,t,u) > is a rule, then: > > G |- k : s G, a : k |- b : t > ------------------------------- > G |- (pi a : k. b) : u > > is the corresponding typing rule. Type systems like Haskell's are commonly > thought of in terms of the lambda cube, which has constant sorts * and [], > with * : []. The rule (*,*,*) gives you ordinary functions. (*,[],[]) gives > you dependent types, so that's out. > > ([],*,*) is an impredicative rule for polymorphism. This says that, for > instance: > > forall a. a -> a = (pi a : *. pi _ : a. a) : * > > because (pi _ : a. a) : * if a : *, by the (*,*,*) rule, and then we apply > the > impredicative rule for the universal quantification. One could also use the > predicative rule ([],*,[]), which would result in forall a. a -> a having > type > []. > > However, Haskell also has arbitrarily higher-order types. This is given by > the > rule ([],[],[]), which allows expressions like: > > (* -> *) -> * = pi _ : (pi _ : *. *). * > > This type system is called F_omega, while just the ([],*,?) rule is known > as > F_2. > > However, the F_omega rule also allows for arbitrary rank polymorphism even > with the predicative universal quantifier rule above (predicative F_2 > allows a > little, but it's very limited*). For instance, the higher rank type: > > forall a. (forall b. b) -> a > > checks thusly: > > (forall b. b) : [] via ([],*,[]) > ((forall b. b) -> a) : [] via ([],*,[]) > (forall a. (forall b. b) -> a) : [] via ([],[],[]) > > Data types, by contrast, have kinds like * -> *, so using say, > > Maybe (forall a. a -> a) > > genuinely relies on the impredicative rule. GHC's type system isn't exactly > set up in this way, but (->) is similarly special in that it somehow isn't > quite just another type constructor with kind * -> * -> * (or even whatever > special kinds GHC uses to support unboxed values and such). > > Hope that wasn't too confusing. :) > > -- Dan > > * Predicative F_2 will essentially allow one universal quantifier somewhere > in > the type. This can be: > > forall a. a -> a > > or it can be: > > (((forall a. a) -> T) -> U) -> V > > for T, U and V of kind * (the only kind in F_2), which is a rank-4 type. It > doesn't allow: > > forall a b. a -> b > > even, because the inner (forall b. a -> b) : [], so adding the forall a > requires the F_omega rule. > > Predicative F_2 and F_w also blow up with quantification on the right of an > arrow, because it looks like the rule for dependent types: > > T -> (forall a. a) > > T : *, (forall a. a) : [] > > so the rule (*,[],[]) would be invoked. > > GHC doesn't have this sort of hierarchy, and so doesn't have these sorts of > weird cases, despite being predicative of a sort. Instead it distinguishes > somehow between monotypes ([Float], String -> Int, a -> b) and polytypes > (forall a. a, ...), although it doesn't really display the difference. > Quantifiers are only supposed to range over kinds that classify monotypes > (or > monotype constructors), which keeps the predicativity (although, even this > gets fudged some: If I have forall a. a -> a, I can instantiate a to the > polytype forall a. a -> a with rank-n polymorphism, because it only seems > to > worry about the validity of the resulting type, and (->) is special; by > contrast, the same cannot be said for forall a. Maybe a, because Maybe > genuinely only accepts monotypes without -XImpredicativeTypes). > > > > ---------- Forwarded message ---------- > From: Bulat Ziganshin > To: Andrew Coppin > Date: Sun, 6 Dec 2009 11:13:21 +0300 > Subject: Re[2]: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > Hello Andrew, > > Sunday, December 6, 2009, 1:09:18 AM, you wrote: > > > Maybe once I get hired by some financial modelling consultants and get > > paid shedloads of money to write Haskell all day, I'll be able to afford > > a Mac. But until then... > > with such attitude you will never be hired by financial sector. try > instead: > > mac? great! windows? i love it! unix? i've used it since 60's > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > > ---------- Forwarded message ---------- > From: Heinrich Apfelmus > To: haskell-cafe@haskell.org > Date: Sun, 06 Dec 2009 11:28:25 +0100 > Subject: [Haskell-cafe] Re: universal binary version of Haskell Platform? > Benjamin L.Russell wrote: > > Ah, that's too bad. That means that I won't be able to invoke GHC > > outside of the Terminal application by default, and that even if I > > create a Darwin shell script and alias to invoke it from Aqua, the > > icon for that shell script will only be generic by default. I'd > > rather click on an application icon in the Dock. > > You can write an applescript similar to > > Open Terminal Here > from http://www.entropy.ch/software/applescript/ > > and endow it with a custom icon. > > > Regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > > > ---------- Forwarded message ---------- > From: Andrew Coppin > To: haskell-cafe@haskell.org > Date: Sun, 06 Dec 2009 13:05:19 +0000 > Subject: Re: [Haskell-cafe] Low Level Audio - Writing bytes to the sound > card? > Bulat Ziganshin wrote: > >> Hello Andrew, >> >> Sunday, December 6, 2009, 1:09:18 AM, you wrote: >> >> >> >>> Maybe once I get hired by some financial modelling consultants and get >>> paid shedloads of money to write Haskell all day, I'll be able to afford >>> a Mac. But until then... >>> >>> >> >> with such attitude you will never be hired by financial sector. try >> instead: >> >> mac? great! windows? i love it! unix? i've used it since 60's >> >> > > That's OK. I'm reasonably sure I will never get hired by the financial > sector /anyway/. :-( > > > > > ---------- Forwarded message ---------- > From: Andrew Coppin > To: haskell-cafe@haskell.org > Date: Sun, 06 Dec 2009 13:18:59 +0000 > Subject: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level > Audio - Writing bytes to the sound card? > john lask wrote: > >> I think there are some misapprehensions here:- >> >> Many haskell packages binding to c libraries will compile with ghc >> without problems on windows - without cygwin, without mingw/msys system. >> > > OK, well I haven't tried building every C binding on all of Hackage, just a > few of them. So far none of them have worked. (Including wxHaskell, SDL, one > of the database packages, etc.) It's got to the point where I've simply > given up trying. Most such packages just don't seem to work on Windows, and > nobody on the mailing lists or on IRC has any clue why. (I guess because few > people in the Haskell community use Windows and understand how it's supposed > to work.) > > Some such packages build "out of the box" on windows, like the zlib >> package which contains the c source for the c zlib library. GHC is able >> to compile and build this packages without any other c >> compiler/libraries/unix emulators etc because ghc itself contains part >> of the gcc c compiler tool chain and comes with all c standard headers, >> c++ headers and c/c++ runtime libraries. >> > > Yes, I realised long ago that GHC uses GCC and other GNU build tools. > (Presumably this makes porting to Windows far easier.) More recently I > realised that it also includes a surprisingly large set of header files, > seemingly including the entire Win32 API, which is interesting. > > There >> is only one gotch-ya - you need to have a import library for the gcc >> tool chain (thats what ghc uses) i.e. a ".a" library and not the native >> windows ".LIB" import library. >> > > They're different?? o_O > > Oh. Suddenly several things seem clearer... > > If you don't have ".a" import library >> but have the dll then the '.a' import library be built for any dll >> relativley easily. >> > > Any idea how? > > the bigest problem hamperring cleaner builds of haskell packages on >> windows is the lack of any standardised scheme for the installation of >> c-libraries and header files (and of course the availability of a >> suitable build of the library). >> > > Isn't one of Cabal's jobs to figure out where stuff is? Can't we get Cabal > on Windows to say "hey, I need to find foo.h, you know where that is?" Or > something like that? > > Another problem hampering the install of haskell packages on windows is >> the use of the unix autoconf build system (./configure) - package >> writters note! >> > > Heh. I found one Wiki page once describing how to set up a Cabal package. > When it started talking about how to integrate Automake, I hung my head is > dispair. (I believe the page in question is fixed now. But a lot of package > authors seem to assume that everybody just uses Unix of some kind...) > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/e6dc44d5/attachment-0001.html From tanimoto at arizona.edu Sun Dec 6 18:14:28 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Sun Dec 6 17:49:15 2009 Subject: [Haskell-cafe] Do you need Windows USB in Haskell? In-Reply-To: References: Message-ID: Hi Mauricio, 2009/12/5 Maur??cio CA : > > Problem is: I don't have a Windows machine where I could test > this. So, if you need USB in windows, please keep in touch. I > wouldn't ask you to write any code, but I need to know what builds > and what doesn't. > I don't need usb and I can't say I'm a windows user, but I'd be glad to test it since I have it on a virtual machine. In my case, installation fails on "bindings-common". Is there something I need to do first? I do have mingw32 and msys installed, if that's necessary. Log attached. Take care, Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: usb.log Type: text/x-log Size: 9534 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/2206e36c/usb.bin From hjgtuyl at chello.nl Sun Dec 6 18:26:23 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun Dec 6 18:01:03 2009 Subject: [Haskell-cafe] help In-Reply-To: References: Message-ID: What is your problem? What is your location? Do I need to call 911? Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- On Mon, 07 Dec 2009 00:12:31 +0100, Ezekiel Smithburg wrote: > On Sun, Dec 6, 2009 at 4:53 AM, wrote: > >> Send Haskell-Cafe mailing list submissions to >> haskell-cafe@haskell.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> or, via email, send a message with subject or body 'help' to >> haskell-cafe-request@haskell.org >> >> You can reach the person managing the list at >> haskell-cafe-owner@haskell.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Haskell-Cafe digest..." >> -- From lemming at henning-thielemann.de Sun Dec 6 18:46:00 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Dec 6 18:17:10 2009 Subject: [Haskell-cafe] Insert a laziness break into strict ST Message-ID: <4B1C4238.5030408@henning-thielemann.de> I have lot of ST actions that shall be bound strictly (they write to a buffer), but somewhere between these actions I like to have a "laziness break". I thought I could do this by temporarily switching to Lazy.ST, but this does not work. It follows a simplified example Prelude> :module Control.Monad.ST.Lazy Prelude Control.Monad.ST.Lazy> runST (Monad.liftM2 (,) (return 'a') (undefined::Monad m => m Char)) ('a',*** Exception: Prelude.undefined Prelude Control.Monad.ST.Lazy> Control.Monad.ST.runST (lazyToStrictST $ Monad.liftM2 (,) (return 'a') (undefined::Monad m => m Char)) *** Exception: Prelude.undefined I hoped to get the first answer also for the second command. It seems that conversion from lazy to strict ST also removes laziness breaks. It seems that I have to stick to unsafeInterleaveIO, but I like to know, why the above method does not work. From ross at soi.city.ac.uk Sun Dec 6 19:04:28 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Dec 6 18:39:29 2009 Subject: [Haskell-cafe] ANNOUNCE: error-message In-Reply-To: <20091206205055.GA24755@seas.upenn.edu> References: <5928BB88-FF4E-4335-B473-D02779DCB60A@phys.washington.edu> <20091205212848.GA23711@seas.upenn.edu> <36C40624-B050-4A8C-8CAF-F15D84467180@phys.washington.edu> <20091206205055.GA24755@seas.upenn.edu> Message-ID: <20091207000428.GA31223@soi.city.ac.uk> On Sun, Dec 06, 2009 at 03:50:55PM -0500, Brent Yorgey wrote: > So what we have here, it seems, is a type with at least two reasonable > Applicative instances, one of which does *not* correspond to a Monad > instance. My argument is that it is very strange (I might even go so > far as to call it a bug) to have a type with an Applicative instance > and a Monad instance which do not correspond, in the sense that > > pure = return > (<*>) = ap There are several of these. Another is the possible Applicative instance for lists with pure = repeat (<*>) = zipWith id In these cases we usually make the Applicative instance match the Monad one and define an equivalent type for each other Applicative instance (e.g. ZipList in Control.Applicative). From functionallyharmonious at yahoo.com Sun Dec 6 19:29:02 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Sun Dec 6 19:03:32 2009 Subject: [Haskell-cafe] ANNOUNCE: PortAudio Windows Tutorial and Binaries Message-ID: <727150.29310.qm@web113109.mail.gq1.yahoo.com> I got a lot of great help this weekend from Haskell-Cafe, thanks. Now that I have portaudio up and running I put up a tutorial and a 103 kb download of all the windows binaries and files. I hope this helps people exploring digital audio with Haskell. http://www.subreddits.org/misc/haskell/portaudio.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/c0dd6e43/attachment.html From ivan.miljenovic at gmail.com Sun Dec 6 19:31:01 2009 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Sun Dec 6 19:05:29 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: readline-statevar-1.0.1.0 In-Reply-To: <4B1C0055.3030505@functor.nl> References: <220e47b40912051047k2cfac6bbx50727f6827811597@mail.gmail.com> <4B1BFF8F.9050302@functor.nl> <4B1C0055.3030505@functor.nl> Message-ID: 2009/12/7 Jochem Berndsen : > Jochem Berndsen wrote: >> nerds > > This was a friend of mine trying to be funny. You allow your friends (and what kind of a friend does this anyway) access to your email? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com Ogden Nash - "The trouble with a kitten is that when it grows up, it's always a cat." - http://www.brainyquote.com/quotes/authors/o/ogden_nash.html From felipe.lessa at gmail.com Sun Dec 6 19:43:02 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Dec 6 19:17:35 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: readline-statevar-1.0.1.0 In-Reply-To: References: <220e47b40912051047k2cfac6bbx50727f6827811597@mail.gmail.com> <4B1BFF8F.9050302@functor.nl> <4B1C0055.3030505@functor.nl> Message-ID: <20091207004302.GA31180@kira.casa> On Mon, Dec 07, 2009 at 10:31:01AM +1000, Ivan Miljenovic wrote: > You allow your friends (and what kind of a friend does this anyway) > access to your email? Accessing one's computer when the owner goes to the bathroom is not unheard of here. However people usually avoid sending these messages to serious mailing lists. -- Felipe. From duane.johnson at gmail.com Sun Dec 6 20:11:48 2009 From: duane.johnson at gmail.com (Duane Johnson) Date: Sun Dec 6 19:46:21 2009 Subject: [Haskell-cafe] Is anyone reading Pattern Calculus by Barry Jay? Message-ID: <1A26D96F-E122-41F1-A0A8-83945BB1C0A1@gmail.com> I just bought a copy of Pattern Calculus [1] by Barry Jay and I would like to discuss the lambda- and pattern-calculus with anyone who is interested. Is there anyone else here who is reading the book and would like to discuss here (if it is appropriate) or take the discussion elsewhere? My knowledge of types has come primarily through reading this Haskell Cafe list, so I am by no means an expert. Just a tinkerer :) Regards, Duane Johnson [1] http://lambda-the-ultimate.org/node/3695 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/8609eeee/attachment.html From aslatter at gmail.com Sun Dec 6 20:26:57 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Dec 6 20:01:26 2009 Subject: [Haskell-cafe] Insert a laziness break into strict ST In-Reply-To: <4B1C4238.5030408@henning-thielemann.de> References: <4B1C4238.5030408@henning-thielemann.de> Message-ID: <694519c50912061726r7c384bc0t525735921347d5e6@mail.gmail.com> On Sun, Dec 6, 2009 at 5:46 PM, Henning Thielemann wrote: > I have lot of ST actions that shall be bound strictly (they write to a > buffer), but somewhere between these actions I like to have a "laziness > break". I thought I could do this by temporarily switching to Lazy.ST, > but this does not work. It follows a simplified example > > > I hoped to get the first answer also for the second command. It seems > that conversion from lazy to strict ST also removes laziness breaks. > > It seems that I have to stick to unsafeInterleaveIO, but I like to know, > why the above method does not work. This isn't the answer you want, but there is an unsafeInterleaveST. Antoine From ml.nwgreen at gmail.com Sun Dec 6 20:48:37 2009 From: ml.nwgreen at gmail.com (drostin77) Date: Sun Dec 6 20:23:06 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) Message-ID: <26669924.post@talk.nabble.com> Hello Hopefully Helpful Haskell Community! (I really wanted that to be alliteration... couldn't come up with an h word for community) I've just started learning Haskell (working my way through "Real World Haskell" and really liking it)! I have started to appreciate that there are a lot of Haskell libraries I will want to search and access quite regularly when I work on Haskell projects, so I had the following questions: 1. Hoogle and Hayoo: I'm a bit confused by the difference here. From initial impressions it seems that Hayoo is linked to Hackage, but Hoogle is not? And it seems that Hayoo is, well, "Similar to Hoogle, but with less focus on type search." Should I check both of these when I want a library, or choose one and go with it...? Or is it indeed better to search Hayoo when I'm thinking of a named library and Hoogle when I think I know the type signature for just the function I need? 2. I much prefer a command line search interface to a browser, I see Hoogle offers such a tool, does Hayoo? P.S. If these questions are in the wrong place, or if they are already answered in detail somewhere that my Googling didn't find please feel free to paste a link and tell me to search better next time! -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26669924.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From ok at cs.otago.ac.nz Sun Dec 6 21:39:31 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Dec 6 21:14:03 2009 Subject: [Haskell-cafe] Haskell-Newbie and Char-Function In-Reply-To: <26656676.post@talk.nabble.com> References: <26656676.post@talk.nabble.com> Message-ID: <8B99420D-ADB7-472C-A5BE-32310372A806@cs.otago.ac.nz> On Dec 6, 2009, at 4:42 AM, MeAdAstra wrote: > I only started learning Haskell some days ago. Maybe one of you can > give me > a hint on how to implement a function that needs a character in the > range > (a,b,...z) and an integer number k and returns the k-next neighbor > of the > character? For example, fct a 5 would result in output f. I'm reading between the lines here. I think you want alphabetic_successor :: Int -> Char -> Char {- alphabetic_successor k c requires k >= 0 and c `elem` lower_case_letters ensures result `elem` lower_case_letters where lower_case_letters = "abcdefghijklmnopqrstuvwxyz" -} What's not clear from your description is what's supposed to happen if you ask for alphabetic_successor 5 'z'. I'll assume you want to think of the letters being in a circle. It is possible to hack this using character->integer and integer->character conversion, but I'm going to do it another way that doesn't depend on the characters being contiguous in the Unicode character set. You could use the code to find the successor in a sequence of consonants, for example. A. We want to find the position of c in lower_case_letters. The first thing to do is to read the documentation and see if there is a suitable function. There's one in the List module: elemIndex :: Eq x => x -> [x] -> Maybe Int. This will work for any type x (including characters) that supports equality (==). It takes an item, a list of items, and either returns Nothing (the item wasn't found) or (Just n) -- the item was found at position n, 0 offset. B. We add k to n and reduce it modulo the length of the list. C. Given our new position, we want to find the character at that position in the list. The function for that is list !! index. import List (elemIndex) alphabetic_successor k c = lower_case_letters !! new_index where Just index = List.elemIndex c lower_case_letters new_index = (k + index) `mod` length lower_case_letters lower_case_letters = "abcdefghijklmnopqrstuvwxyz" From ben.franksen at online.de Sun Dec 6 22:30:34 2009 From: ben.franksen at online.de (Ben Franksen) Date: Sun Dec 6 22:05:26 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> Message-ID: Michael Snoyman wrote: > On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann < > lemming@henning-thielemann.de> wrote: >> On Sun, 6 Dec 2009, Michael Snoyman wrote: >> I think there are plenty of examples like web servers. A text editor >> with >>> plugins? I >>> don't want to lose three hours worth of work just because some plugin >>> wasn't written >>> correctly. For many classes of programs, the distinction between error >>> and exception is >>> not only blurred, it's fully irrelevant. Harping on people every time >>> they use error in >>> the "wrong" sense seems unhelpful. >>> >>> Hope my commenting on this subject doesn't become my own form of >>> *pedantry*. >>> >> In an earlier thread I have explained that one can consider a software >> architecture as divided into levels. What is an error in one level (text >> editor plugin, web server thread, operating system process) is an >> exception in the next higher level (text editor, web server, shell >> respectively). This doesn't reduce the importance to distinguish between >> errors and exceptions within one level. All approaches so far that I have >> seen in Haskell just mix exceptions and errors in an arbitrary way. >> > I think we can all appreciate why it would be a bad thing is we treat > exceptions as errors. For example, I don't want my program to crash on a > file not found. > > On the other hand, what's so bad about treating errors as exceptions? If > instead of the program crashing on an array-out-of-bound or pattern-match > it throws an exception which can be caught, so what? The error gets hidden instead of fixed? Cheers Ben From mdaniels at lanl.gov Sun Dec 6 23:10:59 2009 From: mdaniels at lanl.gov (Marcus G. Daniels) Date: Sun Dec 6 22:45:27 2009 Subject: [Haskell-cafe] OpenCL target for DPH? Message-ID: <56780.130.55.132.67.1260159059.squirrel@webmail.lanl.gov> Hi, I'm wondering if anyone has looked at OpenCL as target for Data Parallel Haskell? Specifically, having Haskell generate CL kernels, i.e. SIMD vector type aware C language backend, as opposed to just a Haskell language binding. Thanks, Marcus From dave at zednenem.com Sun Dec 6 23:43:29 2009 From: dave at zednenem.com (David Menendez) Date: Sun Dec 6 23:17:58 2009 Subject: [Haskell-cafe] What is the rank of a polymorphic type? In-Reply-To: <200912060839.05428.dan.doel@gmail.com> References: <5e0214850912050131u7aaba10buf908c8ba28c6658b@mail.gmail.com> <0B59A706-8C41-47B9-A858-5ACE297581E1@cs.uu.nl> <5e0214850912052242v4010c273r3d8363d3709117b1@mail.gmail.com> <200912060839.05428.dan.doel@gmail.com> Message-ID: <49a77b7a0912062043m1039a842u44e4da40f0a63462@mail.gmail.com> On Sun, Dec 6, 2009 at 8:39 AM, Dan Doel wrote: > Apologies for the double-reply... > > Your mail prompted me to finally get around to adding a mono/polytype system > to an interpreter I've been working on for pure type systems, to see what a > GHC-alike type system would look like. Here's what I came up with. Have you read "Henk: a typed intermediate language" by Simon Peyton Jones and Erik Meijer? In section 4, they describe a PTS very similar to yours. -- Dave Menendez From michael at snoyman.com Sun Dec 6 23:58:44 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sun Dec 6 23:33:13 2009 Subject: [Haskell-cafe] ANNOUNCE: new installment of failure framework Message-ID: <29bf512f0912062058m4076b4dcvae3a38cf71bae54f@mail.gmail.com> We'd like to announce the next installment of the Failure Framework. Based on feedback, our main goals in this release is to reduce the number of external dependencies and avoid complications with monad transformer libraries at the core of the framework. We have made the following changes: * Failure is not tied directly to monads anymore. The main typeclass is Failure, which provides the failure function. MonadFailure, ApplicativeFailure and FunctorFailure are provided for convenience. * The Failure typeclass is now located in the failure package, which has no dependencies. All code dealing with transformers and mtl has been factored into control-monad-failure and control-monad-failure-mtl, respectively. In addition, we are simultaneously releasing the following packages: * safe-failure provides safe versions of dangerous, non total functions, such as head, by returning failures. It depends exclusively on failure. * attempt provides a concrete data type for handling extensible exceptions as failures. It depends exclusively on failure. * control-monad-attempt provides a monad transformer for attempt using the transformers library. We do not provide currently an mtl version of this package, but can provide one if there is demand. * control-monad-exception, explicitly typed, checked exceptions with monadic stack traces. Below are the links to the packages just released. Enjoy! http://hackage.haskell.org/package/failure-0.0.0 http://hackage.haskell.org/package/control-monad-failure-0.6.0 http://hackage.haskell.org/package/control-monad-failure-mtl-0.6.0 http://hackage.haskell.org/package/safe-failure-0.4.0 http://hackage.haskell.org/package/attempt-0.2.0 http://hackage.haskell.org/package/control-monad-attempt-0.0.0 http://hackage.haskell.org/package/control-monad-exception-0.8.0 http://hackage.haskell.org/package/control-monad-exception-mtl-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadsfd-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadstf-0.8.0 Michael Snoyman, Pepe Iborra, Nicolas Pouillard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/c5d5a119/attachment.html From michael at snoyman.com Mon Dec 7 00:04:26 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sun Dec 6 23:38:55 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> Message-ID: <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen wrote: > Michael Snoyman wrote: > > On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann < > > lemming@henning-thielemann.de> wrote: > >> On Sun, 6 Dec 2009, Michael Snoyman wrote: > >> I think there are plenty of examples like web servers. A text editor > >> with > >>> plugins? I > >>> don't want to lose three hours worth of work just because some plugin > >>> wasn't written > >>> correctly. For many classes of programs, the distinction between error > >>> and exception is > >>> not only blurred, it's fully irrelevant. Harping on people every time > >>> they use error in > >>> the "wrong" sense seems unhelpful. > >>> > >>> Hope my commenting on this subject doesn't become my own form of > >>> *pedantry*. > >>> > >> In an earlier thread I have explained that one can consider a software > >> architecture as divided into levels. What is an error in one level (text > >> editor plugin, web server thread, operating system process) is an > >> exception in the next higher level (text editor, web server, shell > >> respectively). This doesn't reduce the importance to distinguish between > >> errors and exceptions within one level. All approaches so far that I > have > >> seen in Haskell just mix exceptions and errors in an arbitrary way. > >> > > I think we can all appreciate why it would be a bad thing is we treat > > exceptions as errors. For example, I don't want my program to crash on a > > file not found. > > > > On the other hand, what's so bad about treating errors as exceptions? If > > instead of the program crashing on an array-out-of-bound or pattern-match > > it throws an exception which can be caught, so what? > > The error gets hidden instead of fixed? > > Cheers > Ben > > You're right; bad programmers could do this. A good programmer will know to do one of two things when it gets an exception it does not know how to handle: * Die with an error message. * In cases like web servers, print an informative error message (eg, hopefully more useful than "Prelude: head") and continue doing something else. I think the kind of programmers who just ignore exceptions and try to keep going are what I think of as over-defensive programmers, who in a misguided attempt to make their code more robust think that they should eliminate any possibility of not returning a result. I saw my share of this kind of code at my previous job, and when you're dealing with data processing programs, it's *very* irritating when suddenly you have garbage data because someone thought "huh, this should be negative, will just use the abs function." However, these people will find ways of doing these evils even without exceptions. Bonus: My favorite error-handling line of code at the company was a bit of VBA that went: On Error Goto Hell Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091206/11243bf8/attachment.html From alexander.dunlap at gmail.com Mon Dec 7 01:40:46 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Dec 7 01:15:34 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> Message-ID: <57526e770912062240v44e1de0m1cabe010d1d4f820@mail.gmail.com> On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman wrote: > > > On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann > wrote: >> >> On Sun, 6 Dec 2009, Michael Snoyman wrote: >> >>> I think there are plenty of examples like web servers. A text editor with >>> plugins? I >>> don't want to lose three hours worth of work just because some plugin >>> wasn't written >>> correctly. For many classes of programs, the distinction between error >>> and exception is >>> not only blurred, it's fully irrelevant. Harping on people every time >>> they use error in >>> the "wrong" sense seems unhelpful. >>> >>> Hope my commenting on this subject doesn't become my own form of >>> *pedantry*. >> >> In an earlier thread I have explained that one can consider a software >> architecture as divided into levels. What is an error in one level (text >> editor plugin, web server thread, operating system process) is an exception >> in the next higher level (text editor, web server, shell respectively). This >> doesn't reduce the importance to distinguish between errors and exceptions >> within one level. All approaches so far that I have seen in Haskell just mix >> exceptions and errors in an arbitrary way. > > I think we can all appreciate why it would be a bad thing is we treat > exceptions as errors. For example, I don't want my program to crash on a > file not found. > > On the other hand, what's so bad about treating errors as exceptions? If > instead of the program crashing on an array-out-of-bound or pattern-match it > throws an exception which can be caught, so what? > > Michael > I think the key is in the difference between the user/client and programmer/developer. As Henning has been saying, these roles change as you go through the different levels of the program, but I see the difference between an error and an exception as this: when a problem is relevant to the user/client, it's an exception; when it is irrelevant to the user/client, it's an error. Suppose you were using some sort of exception framework and you got an error from a piece of library code (not the head function) saying that "head" had failed somewhere. This is absolutely meaningless to a client. It just means there's a problem in the library code; it doesn't mean anything is amiss in the client's space. The client basically has to throw the function out, whether by gracefully aborting the program, disabling the plugin, etc. Contrast this with an exception, such as "index not in map." This is entirely relevant to the client. All of the code knows exactly what is going on; it's just that the index isn't in the map. The client can recover from this by, say, substituting a default value, adding the index to the map, etc. Now, suppose the client knew a priori that the index was *supposed* to be in the map. Now this becomes an *error* to the *client* of the client, since there is a bug in the first client's code. I guess my point is that if I have a function, say, sort :: Ord a => [a] -> [a], and sort calls head somewhere in it, there's no point having "sort" throw an exception for "Prelude.head: []" since that means nothing to the client. It would make more sense to have an InternalError type that just says "OK, sorry client, I screwed up, just clean things up as best you can". If really were something that the client could have responded to, sort should have caught the head error inside the function definition and rethrown a different exception; say, SortEmptyListError if your sort function didn't work on empty lists (contrived example, sorry). Alex From florbitous at gmail.com Mon Dec 7 01:41:06 2009 From: florbitous at gmail.com (Bernie Pope) Date: Mon Dec 7 01:15:39 2009 Subject: [Haskell-cafe] Is anyone reading Pattern Calculus by Barry Jay? In-Reply-To: <1A26D96F-E122-41F1-A0A8-83945BB1C0A1@gmail.com> References: <1A26D96F-E122-41F1-A0A8-83945BB1C0A1@gmail.com> Message-ID: <4d8ad03a0912062241h2c0e8a04y1a71fe25185a52f3@mail.gmail.com> 2009/12/7 Duane Johnson : > I just bought a copy of Pattern Calculus [1] by Barry Jay and I would like > to discuss the lambda- and pattern-calculus with anyone who is interested. > ?Is there anyone else here who is reading the book and would like to discuss > here (if it is appropriate) or take the discussion elsewhere? ?My knowledge > of types has come primarily through reading this Haskell Cafe list, so I am > by no means an expert. ?Just a tinkerer :) > Regards, > Duane Johnson > > [1]?http://lambda-the-ultimate.org/node/3695 Hi Duane, The Melbourne FPU (functional programming union) is interested in topics like this, and some of us have a copy, or are about to get a copy of the book. http://groups.google.com.au/group/fpunion There's already a short thread on the topic - please feel free to sign up to the group. We welcome stimulating discussion. Cheers, Bernie. From colinpauladams at googlemail.com Mon Dec 7 01:43:12 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Mon Dec 7 01:17:40 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <26669924.post@talk.nabble.com> References: <26669924.post@talk.nabble.com> Message-ID: <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> 2009/12/7 drostin77 : > > Hello Hopefully Helpful Haskell Community! > > (I really wanted that to be alliteration... couldn't come up with an h word > for community) House? From maydwell at gmail.com Mon Dec 7 01:44:45 2009 From: maydwell at gmail.com (Lyndon Maydwell) Date: Mon Dec 7 01:19:13 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> References: <26669924.post@talk.nabble.com> <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> Message-ID: 'Hood? On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams wrote: > 2009/12/7 drostin77 : >> >> Hello Hopefully Helpful Haskell Community! >> >> (I really wanted that to be alliteration... couldn't come up with an h word >> for community) > > House? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From alexander.dunlap at gmail.com Mon Dec 7 01:45:09 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Dec 7 01:19:57 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <57526e770912062240v44e1de0m1cabe010d1d4f820@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <57526e770912062240v44e1de0m1cabe010d1d4f820@mail.gmail.com> Message-ID: <57526e770912062245w16de8e5bs93623711d865a4ea@mail.gmail.com> On Sun, Dec 6, 2009 at 10:40 PM, Alexander Dunlap wrote: > On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman wrote: >> >> >> On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann >> wrote: >>> >>> On Sun, 6 Dec 2009, Michael Snoyman wrote: >>> >>>> I think there are plenty of examples like web servers. A text editor with >>>> plugins? I >>>> don't want to lose three hours worth of work just because some plugin >>>> wasn't written >>>> correctly. For many classes of programs, the distinction between error >>>> and exception is >>>> not only blurred, it's fully irrelevant. Harping on people every time >>>> they use error in >>>> the "wrong" sense seems unhelpful. >>>> >>>> Hope my commenting on this subject doesn't become my own form of >>>> *pedantry*. >>> >>> In an earlier thread I have explained that one can consider a software >>> architecture as divided into levels. What is an error in one level (text >>> editor plugin, web server thread, operating system process) is an exception >>> in the next higher level (text editor, web server, shell respectively). This >>> doesn't reduce the importance to distinguish between errors and exceptions >>> within one level. All approaches so far that I have seen in Haskell just mix >>> exceptions and errors in an arbitrary way. >> >> I think we can all appreciate why it would be a bad thing is we treat >> exceptions as errors. For example, I don't want my program to crash on a >> file not found. >> >> On the other hand, what's so bad about treating errors as exceptions? If >> instead of the program crashing on an array-out-of-bound or pattern-match it >> throws an exception which can be caught, so what? >> >> Michael >> > > I think the key is in the difference between the user/client and > programmer/developer. As Henning has been saying, these roles change > as you go through the different levels of the program, but I see the > difference between an error and an exception as this: when a problem > is relevant to the user/client, it's an exception; when it is > irrelevant to the user/client, it's an error. Suppose you were using > some sort of exception framework and you got an error from a piece of > library code (not the head function) saying that "head" had failed > somewhere. This is absolutely meaningless to a client. It just means > there's a problem in the library code; it doesn't mean anything is > amiss in the client's space. The client basically has to throw the > function out, whether by gracefully aborting the program, disabling > the plugin, etc. Contrast this with an exception, such as "index not > in map." This is entirely relevant to the client. All of the code > knows exactly what is going on; it's just that the index isn't in the > map. The client can recover from this by, say, substituting a default > value, adding the index to the map, etc. Now, suppose the client knew > a priori that the index was *supposed* to be in the map. Now this > becomes an *error* to the *client* of the client, since there is a bug > in the first client's code. > > I guess my point is that if I have a function, say, sort :: Ord a => > [a] -> [a], and sort calls head somewhere in it, there's no point > having "sort" throw an exception for "Prelude.head: []" since that > means nothing to the client. It would make more sense to have an > InternalError type that just says "OK, sorry client, I screwed up, > just clean things up as best you can". If really were something that > the client could have responded to, sort should have caught the head > error inside the function definition and rethrown a different > exception; say, SortEmptyListError if your sort function didn't work > on empty lists (contrived example, sorry). > > Alex > (Sorry for replying to myself.) This is, of course, assuming that a non-empty list was not an invariant of the sort function, in which case it would be a programming error on the part of the client that called sort if that happened. Alex From michael at snoyman.com Mon Dec 7 02:00:21 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Dec 7 01:34:53 2009 Subject: [Haskell-cafe] New Hackage category: Error Handling In-Reply-To: <57526e770912062240v44e1de0m1cabe010d1d4f820@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <57526e770912062240v44e1de0m1cabe010d1d4f820@mail.gmail.com> Message-ID: <29bf512f0912062300j285bdf6i4b4ee949192cfa47@mail.gmail.com> On Mon, Dec 7, 2009 at 8:40 AM, Alexander Dunlap wrote: > On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman > wrote: > > > > > > On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann > > wrote: > >> > >> On Sun, 6 Dec 2009, Michael Snoyman wrote: > >> > >>> I think there are plenty of examples like web servers. A text editor > with > >>> plugins? I > >>> don't want to lose three hours worth of work just because some plugin > >>> wasn't written > >>> correctly. For many classes of programs, the distinction between error > >>> and exception is > >>> not only blurred, it's fully irrelevant. Harping on people every time > >>> they use error in > >>> the "wrong" sense seems unhelpful. > >>> > >>> Hope my commenting on this subject doesn't become my own form of > >>> *pedantry*. > >> > >> In an earlier thread I have explained that one can consider a software > >> architecture as divided into levels. What is an error in one level (text > >> editor plugin, web server thread, operating system process) is an > exception > >> in the next higher level (text editor, web server, shell respectively). > This > >> doesn't reduce the importance to distinguish between errors and > exceptions > >> within one level. All approaches so far that I have seen in Haskell just > mix > >> exceptions and errors in an arbitrary way. > > > > I think we can all appreciate why it would be a bad thing is we treat > > exceptions as errors. For example, I don't want my program to crash on a > > file not found. > > > > On the other hand, what's so bad about treating errors as exceptions? If > > instead of the program crashing on an array-out-of-bound or pattern-match > it > > throws an exception which can be caught, so what? > > > > Michael > > > > I think the key is in the difference between the user/client and > programmer/developer. As Henning has been saying, these roles change > as you go through the different levels of the program, but I see the > difference between an error and an exception as this: when a problem > is relevant to the user/client, it's an exception; when it is > irrelevant to the user/client, it's an error. Suppose you were using > some sort of exception framework and you got an error from a piece of > library code (not the head function) saying that "head" had failed > somewhere. This is absolutely meaningless to a client. It just means > there's a problem in the library code; it doesn't mean anything is > amiss in the client's space. The client basically has to throw the > function out, whether by gracefully aborting the program, disabling > the plugin, etc. Contrast this with an exception, such as "index not > in map." This is entirely relevant to the client. All of the code > knows exactly what is going on; it's just that the index isn't in the > map. The client can recover from this by, say, substituting a default > value, adding the index to the map, etc. Now, suppose the client knew > a priori that the index was *supposed* to be in the map. Now this > becomes an *error* to the *client* of the client, since there is a bug > in the first client's code. > > I guess my point is that if I have a function, say, sort :: Ord a => > [a] -> [a], and sort calls head somewhere in it, there's no point > having "sort" throw an exception for "Prelude.head: []" since that > means nothing to the client. It would make more sense to have an > InternalError type that just says "OK, sorry client, I screwed up, > just clean things up as best you can". If really were something that > the client could have responded to, sort should have caught the head > error inside the function definition and rethrown a different > exception; say, SortEmptyListError if your sort function didn't work > on empty lists (contrived example, sorry). > > Alex > The WrapFailure typeclass in the the failure package makes this kind of library design fairly straightforward. I think you're making an argument for treating errors and exceptions the same way. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/4d74ace0/attachment-0001.html From ketil at malde.org Mon Dec 7 03:07:47 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Dec 7 02:42:15 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: <20091206223855.GC920@whirlpool.galois.com> (Don Stewart's message of "Sun, 6 Dec 2009 14:38:55 -0800") References: <20091206223855.GC920@whirlpool.galois.com> Message-ID: <87iqcjfbqk.fsf@malde.org> Don Stewart writes: >> Are there pure haskell implementations of diff and diff3 algorithms? > http://hackage.haskell.org/package/Diff Wherein we can read: | This is an implementation of the O(ND) diff algorithm [...]. It is O(mn) | in space. At first I thought 'N' and 'M' would be the lengths of the lists, and 'D' is the number of differences, but then the space bound doesn't make sense. I tried to find the reference, but Citeseer is down (again. sigh). Anybody know what the bounds really are? -k -- If I haven't seen further, it is by standing in the footprints of giants From ketil at malde.org Mon Dec 7 03:09:46 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Dec 7 02:44:14 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: (Lyndon Maydwell's message of "Mon, 7 Dec 2009 14:44:45 +0800") References: <26669924.post@talk.nabble.com> <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> Message-ID: <87ein7fbn9.fsf@malde.org> Lyndon Maydwell writes: > On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams> wrote: >> 2009/12/7 drostin77 : >>> Hello Hopefully Helpful Haskell Community! >>> (I really wanted that to be alliteration... couldn't come up with an h word >>> for community) >> House? > 'Hood? Horde? And of course, haskell.org is the Hopefully Helpful Haskell Hoard. -k -- If I haven't seen further, it is by standing in the footprints of giants From dons at galois.com Mon Dec 7 03:14:00 2009 From: dons at galois.com (Don Stewart) Date: Mon Dec 7 02:48:30 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: <87iqcjfbqk.fsf@malde.org> References: <20091206223855.GC920@whirlpool.galois.com> <87iqcjfbqk.fsf@malde.org> Message-ID: <20091207081400.GC2966@whirlpool.galois.com> ketil: > Don Stewart writes: > > >> Are there pure haskell implementations of diff and diff3 algorithms? > > > http://hackage.haskell.org/package/Diff > > Wherein we can read: > > | This is an implementation of the O(ND) diff algorithm [...]. It is O(mn) > | in space. > > At first I thought 'N' and 'M' would be the lengths of the lists, and > 'D' is the number of differences, but then the space bound doesn't make > sense. I tried to find the reference, but Citeseer is down > (again. sigh). > > Anybody know what the bounds really are? > This looks like the paper, http://www.xmailserver.org/diff2.pdf Page 2, "The algorithm can be refined to use linear space", N and M appear to be the length of the sequences, D is the size of the minimum edit script. -- Don From ml.nwgreen at gmail.com Mon Dec 7 03:52:39 2009 From: ml.nwgreen at gmail.com (drostin77) Date: Mon Dec 7 03:27:06 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <87ein7fbn9.fsf@malde.org> References: <26669924.post@talk.nabble.com> <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> <87ein7fbn9.fsf@malde.org> Message-ID: <26674323.post@talk.nabble.com> I take 'Hood. Er... any responses to my questions? Ketil Malde-5 wrote: > > Lyndon Maydwell writes: > >> On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams> >> wrote: > >>> 2009/12/7 drostin77 : > >>>> Hello Hopefully Helpful Haskell Community! > >>>> (I really wanted that to be alliteration... couldn't come up with an h >>>> word >>>> for community) > >>> House? > >> 'Hood? > > Horde? And of course, haskell.org is the Hopefully Helpful Haskell Hoard. > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26674323.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From simonpj at microsoft.com Mon Dec 7 03:59:54 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 7 03:34:38 2009 Subject: [Haskell-cafe] When are undecidables ok? In-Reply-To: <29bf512f0912052220n29650296p8952bdd606994a00@mail.gmail.com> References: <29bf512f0912052104ia36a42k556df47c1b143223@mail.gmail.com> <7ca3f0160912052136v65984da0l797d3a683388d9f8@mail.gmail.com> <29bf512f0912052220n29650296p8952bdd606994a00@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC108507AFE@DB3EX14MBXC310.europe.corp.microsoft.com> I don?t think it?s all that complicated or fragile. To resolve the constraint (C T1 T2), use the appropriate instance declaration to express it in terms of (hopefully simpler) constraints. Keep doing that. If you terminate, GHC should. Example: to resolve Eq [Int], use the instance declaration instance Eq a => Eq [a] That gives rise to the new constraint Eq Int. Use the instance declaration instance Eq Int That gives rise to no new instances. Done. If you terminate and GHC does not, write down your reasoning (ie how you resolved the instance) and send it in. [NB: There is a wrinkle for ?recursive dictionaries?, described in the SYB3 paper.] Simon Well, the reasoning for the "devil" camp (which I admit to being firmly in[1]) is that such proofs must rely on the algorithm the compiler uses to resolve instances. You might be able to prove it, but the proof is necessarily only valid for (possibly current versions of) GHC. The typeclass resolution algorithm is not in the report, and there are several conceivable ways of of going about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/43da049d/attachment.html From mle+hs at mega-nerd.com Mon Dec 7 04:09:29 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon Dec 7 03:44:02 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: <20091207081400.GC2966@whirlpool.galois.com> References: <20091206223855.GC920@whirlpool.galois.com> <87iqcjfbqk.fsf@malde.org> <20091207081400.GC2966@whirlpool.galois.com> Message-ID: <20091207200929.94993225.mle+hs@mega-nerd.com> Don Stewart wrote: > This looks like the paper, http://www.xmailserver.org/diff2.pdf > > Page 2, "The algorithm can be refined to use linear space", N and M > appear to be the length of the sequences, D is the size of the minimum > edit script. T'would be lovely to have that in the docs for the package :-). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From maydwell at gmail.com Mon Dec 7 04:24:37 2009 From: maydwell at gmail.com (Lyndon Maydwell) Date: Mon Dec 7 03:59:04 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <26674323.post@talk.nabble.com> References: <26669924.post@talk.nabble.com> <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> <87ein7fbn9.fsf@malde.org> <26674323.post@talk.nabble.com> Message-ID: I had heard that Hoogle actually compiled any type-signatures, where as Hayoo just did a text comparison. I'm not actually sure if this is true or not though. If it is, it would mean that "[q] -> [r] -> [(q,r)]" would return zip in Hoogle, but not Hayoo. Am I right about this? On Mon, Dec 7, 2009 at 4:52 PM, drostin77 wrote: > > I take 'Hood. ?Er... any responses to my questions? > > > Ketil Malde-5 wrote: >> >> Lyndon Maydwell writes: >> >>> On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams> >>> wrote: >> >>>> 2009/12/7 drostin77 : >> >>>>> Hello Hopefully Helpful Haskell Community! >> >>>>> (I really wanted that to be alliteration... couldn't come up with an h >>>>> word >>>>> for community) >> >>>> House? >> >>> 'Hood? >> >> Horde? ?And of course, haskell.org is the Hopefully Helpful Haskell Hoard. >> >> -k >> -- >> If I haven't seen further, it is by standing in the footprints of giants >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > -- > View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26674323.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From vandijk.roel at gmail.com Mon Dec 7 04:28:49 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Mon Dec 7 04:03:17 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: References: <26669924.post@talk.nabble.com> <1afdeaec0912062243k3b803326gacb0206067ff7af8@mail.gmail.com> <87ein7fbn9.fsf@malde.org> <26674323.post@talk.nabble.com> Message-ID: On Mon, Dec 7, 2009 at 10:24 AM, Lyndon Maydwell wrote: > I had heard that Hoogle actually compiled any type-signatures, where > as Hayoo just did a text comparison. > > I'm not actually sure if this is true or not though. > > If it is, it would mean that "[q] -> [r] -> [(q,r)]" would return zip > in Hoogle, but not Hayoo. > > Am I right about this? You are right: http://haskell.org/hoogle/?hoogle=[q]%20-%3E%20[r]%20-%3E%20[%28q%2Cr%29] But Hayoo searches all of hackage while Hoogle also searches a lot, but not all. If I'm searching for a function that is probably in base or containers, I use hoogle. Otherwise I use hayoo. In short: They are both very useful. From lemming at henning-thielemann.de Mon Dec 7 04:38:24 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 04:12:53 2009 Subject: [Haskell-cafe] Insert a laziness break into strict ST In-Reply-To: <694519c50912061726r7c384bc0t525735921347d5e6@mail.gmail.com> References: <4B1C4238.5030408@henning-thielemann.de> <694519c50912061726r7c384bc0t525735921347d5e6@mail.gmail.com> Message-ID: On Sun, 6 Dec 2009, Antoine Latter wrote: > On Sun, Dec 6, 2009 at 5:46 PM, Henning Thielemann > >> I hoped to get the first answer also for the second command. It seems >> that conversion from lazy to strict ST also removes laziness breaks. >> >> It seems that I have to stick to unsafeInterleaveIO, but I like to know, >> why the above method does not work. > > This isn't the answer you want, but there is an unsafeInterleaveST. This was a typo, I actually meant unsafeInterleaveST. So, I'm still uncertain why the conversion to lazy ST and back does not work. I feel, that I have still not understood what "lazy" ST actually means. From t.h at gmx.info Mon Dec 7 05:16:35 2009 From: t.h at gmx.info (Timo B. =?utf-8?q?H=C3=BCbel?=) Date: Mon Dec 7 04:51:06 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: References: <26669924.post@talk.nabble.com> <26674323.post@talk.nabble.com> Message-ID: <200912071116.35108.t.h@gmx.info> On Monday 07 December 2009 10:24:37 Lyndon Maydwell wrote: > I had heard that Hoogle actually compiled any type-signatures, where > as Hayoo just did a text comparison. > > I'm not actually sure if this is true or not though. > > If it is, it would mean that "[q] -> [r] -> [(q,r)]" would return zip > in Hoogle, but not Hayoo. > > Am I right about this? Yes, we (in Hayoo!) only do text based stuff. Is is possbile to search for signatures, but no generalization etc. is done at all. This is very primitive in Hayoo! and I really suggest using Hoogle for type searches. As for the question about a command line interface: There is nothing like that for Hayoo!, although one could easily hack something together, just using some wget-grep-cut-magic. I also have some code lying around for primitive command line searches using an offline Hayoo! index. Maybe I could get that into proper shape, given enough public demand ;) Cheers, Timo From lemming at henning-thielemann.de Mon Dec 7 05:23:26 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 04:54:39 2009 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces In-Reply-To: <4AF4D102.80701@xiscosoft.es> References: <4AF02F06.2030105@henning-thielemann.de> <4AF4D102.80701@xiscosoft.es> Message-ID: <4B1CD79E.1060008@henning-thielemann.de> klondike schrieb: > Henning Thielemann escribi?: > >> It seems again to me, that mixing of (programming) errors and >> exceptions is going on, and I assumed that the purpose of >> control-monad-exception is to separate them in a better way. > You know, could you tell me when using head on an empty list is a > programming error and when it is a exception, I have seen both cases... The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: "What about web servers?", please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception From lemming at henning-thielemann.de Mon Dec 7 05:29:32 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 05:00:37 2009 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces In-Reply-To: <4AF586CD.9010504@xiscosoft.es> References: <4AF02F06.2030105@henning-thielemann.de> <4AF4D352.1090107@xiscosoft.es> <7ca3f0160911061847k763c6073g4f055069b53c577d@mail.gmail.com> <4AF586CD.9010504@xiscosoft.es> Message-ID: <4B1CD90C.3040302@henning-thielemann.de> klondike schrieb: > Now comes the time when I have to show you that not every exception > could be handled, IE a file not found exception when looking for the > config file can be fatal and force the program to stop. But what if this > is on a library? How do you suggest that the programmer knows that the > File Not Found exception is due to the lack of that config file, > specially when the code is badly (or not) documented. A library function that reads a config file may declare to be able to throw the exception "File not found", or it may introduce a new exception "Could not read Config file" with an extra field for the reason, why the file could not be read. This way you can construct a call stack that helps the user (and not the programmer). Then the message reported to the user might be: Program could not be started, because Config file could not be read because Config file does not exist in dir0, dir1, dir2 but the exception handler may also decide to use a default configuration instead or ask the user, how to proceed. Anyway, such a call stack for the user requires different information than a call stack for programmer for debugging. From gcross at phys.washington.edu Mon Dec 7 05:42:25 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Mon Dec 7 05:18:11 2009 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces In-Reply-To: <4B1CD79E.1060008@henning-thielemann.de> References: <4AF02F06.2030105@henning-thielemann.de> <4AF4D102.80701@xiscosoft.es> <4B1CD79E.1060008@henning-thielemann.de> Message-ID: <5E75C81F-CFFA-47BA-A841-D3D81BC75960@phys.washington.edu> Ah, I had been meaning to read your article, so I appreciate you posting the link to it a second time. :-) Out of curiosity, how would you classify an "error" that results from a perfectly fine program, but ill-formed user input, such as when compiling a source file? Cheers, Greg On Dec 7, 2009, at 2:23 AM, Henning Thielemann wrote: > klondike schrieb: >> Henning Thielemann escribi?: >> >>> It seems again to me, that mixing of (programming) errors and >>> exceptions is going on, and I assumed that the purpose of >>> control-monad-exception is to separate them in a better way. >> You know, could you tell me when using head on an empty list is a >> programming error and when it is a exception, I have seen both cases... > > The case of (head []) is simple: It is a programming error, since the > precondition for calling 'head' is that the argument list is non-empty. > The caller of 'head' is responsible to check this. If the list comes > from user input, then the program part that receives this list from the > user is responsible to check for the empty list before calling 'head'. > If there is no such check, this is a programming error, and it will not > be possible to handle this (like an exception). Before you answer: "What > about web servers?", please read on the article I have written recently > to sum up the confusion about errors and exceptions: > > http://www.haskell.org/haskellwiki/Error_vs._Exception > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mauricio.antunes at gmail.com Mon Dec 7 06:00:16 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Mon Dec 7 05:35:08 2009 Subject: [Haskell-cafe] Re: Do you need Windows USB in Haskell? In-Reply-To: References: Message-ID: > I don't need usb and I can't say I'm a windows user, but I'd > be glad to test it since I have it on a virtual machine. In my > case, installation fails on "bindings-common". bindings-common fails on windows due to an old version of C library with GHC's windows version of gcc. Current version of bindings-libusb uses bindings-DSL. I'm glad that you offered to help. But usb is not supposed to work on windows yet. The windows version of the C library has been worked on recently, so, I would need someone who would follow closely this still alpha code and maybe even sugesting adaptations to libusb-1.x build system if necessary. I don't think it's fair to expect that from someone who isn't going to use the library. Thanks! Best, Maur?cio From lemming at henning-thielemann.de Mon Dec 7 06:56:20 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 06:27:28 2009 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces In-Reply-To: <5E75C81F-CFFA-47BA-A841-D3D81BC75960@phys.washington.edu> References: <4AF02F06.2030105@henning-thielemann.de> <4AF4D102.80701@xiscosoft.es> <4B1CD79E.1060008@henning-thielemann.de> <5E75C81F-CFFA-47BA-A841-D3D81BC75960@phys.washington.edu> Message-ID: <4B1CED64.9000709@henning-thielemann.de> Gregory Crosswhite schrieb: > Ah, I had been meaning to read your article, so I appreciate you posting the link to it a second time. :-) > > Out of curiosity, how would you classify an "error" that results from a perfectly fine program, but ill-formed user input, such as when compiling a source file? I thought I just used this as an example in the article ... ill-formed input is clearly an exception, since it is not the fault of the compiler developer. From hoknamahn at gmail.com Mon Dec 7 07:09:35 2009 From: hoknamahn at gmail.com (Olex P) Date: Mon Dec 7 06:44:03 2009 Subject: [Haskell-cafe] OpenCL target for DPH? In-Reply-To: <56780.130.55.132.67.1260159059.squirrel@webmail.lanl.gov> References: <56780.130.55.132.67.1260159059.squirrel@webmail.lanl.gov> Message-ID: Hi, Good question. I'd like to know the answer too. Cheers, Alex. On Mon, Dec 7, 2009 at 4:10 AM, Marcus G. Daniels wrote: > Hi, > > I'm wondering if anyone has looked at OpenCL as target for Data Parallel > Haskell? Specifically, having Haskell generate CL kernels, i.e. SIMD > vector type aware C language backend, as opposed to just a Haskell > language binding. > > Thanks, > > Marcus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/01f73c16/attachment.html From lemming at henning-thielemann.de Mon Dec 7 07:13:00 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 06:44:29 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B193178.30106@henning-thielemann.de> <29bf512f0912050752r3a6013eej18564a8f5c138266@mail.gmail.com> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> Message-ID: <4B1CF14C.5090302@henning-thielemann.de> Michael Snoyman schrieb: > > > On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen > wrote: > > Michael Snoyman wrote: > > > On the other hand, what's so bad about treating errors as exceptions? If > > instead of the program crashing on an array-out-of-bound or pattern-match > > it throws an exception which can be caught, so what? > > The error gets hidden instead of fixed? > > Cheers > Ben > > You're right; bad programmers could do this. A good programmer will know > to do one of two things when it gets an exception it does not know how > to handle: It is certainly not the task of a programming language or a library to parent its users. Despite an interesting idea, it will not work, since programmers will simply switch to a different language or library if they feel pushed around. There is an important reason to not simply catch an error and proceed as if it were only an exception: The error might have corrupted some data and there is no general way to recover from that. Say, after detecting an error you might want to close a file that you were working on. But since you are coping with an error, something you did not foresee, you cannot tell whether the file was already closed again or never opened. So it is better to just abort the program. The next higher level, the shell calling your program or the browser calling your plugin, might have registered what have opened and allocated and can reliably free those resources. From ndmitchell at gmail.com Mon Dec 7 07:31:30 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Dec 7 07:05:58 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <26669924.post@talk.nabble.com> References: <26669924.post@talk.nabble.com> Message-ID: <404396ef0912070431m51f5daecn275385716ef7444@mail.gmail.com> Hi, It probably helps to know some of the history, as it explains a lot of what you see today. Hoogle was written first (about 5 years ago now), before there was hackage (so it doesn't search hackage), and with an emphasis on type search (as that's cool). Hayoo came a lot later (about 2 years ago at most). Hoogle will be gaining the ability to do a full search of Hackage - I'm just waiting to get some bits sorted out first. There isn't really a technical obstacle, I've just not had the time to finish the implementation. Use whichever you choose, but if you use Hayoo for some reason other than Hoogle not searching all packages, I'd love to know. Thanks, Neil 2009/12/7 drostin77 : > > Hello Hopefully Helpful Haskell Community! > > (I really wanted that to be alliteration... couldn't come up with an h word > for community) > > ?I've just started learning Haskell (working my way through "Real World > Haskell" and really liking it)! ?I have started to appreciate that there are > a lot of Haskell libraries I will want to search and access quite regularly > when I work on Haskell projects, so I had the following questions: > > 1. ?Hoogle and Hayoo: ?I'm a bit confused by the difference here. ?From > initial impressions it seems that Hayoo is linked to Hackage, but Hoogle is > not? ?And it seems that Hayoo is, well, "Similar to Hoogle, but with less > focus on type search." ?Should I check both of these when I want a library, > or choose one and go with it...? ?Or is it indeed better to search Hayoo > when I'm thinking of a named library and Hoogle when I think I know the type > signature for just the function I need? > > 2. ?I much prefer a command line search interface to a browser, I see Hoogle > offers such a tool, does Hayoo? > > P.S. ?If these questions are in the wrong place, or if they are already > answered in detail somewhere that my Googling didn't find please feel free > to paste a link and tell me to search better next time! > -- > View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26669924.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ndmitchell at gmail.com Mon Dec 7 07:31:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Dec 7 07:06:04 2009 Subject: [Haskell-cafe] Hoogle Down In-Reply-To: <4B129AAF.2010401@gmail.com> References: <4B129AAF.2010401@gmail.com> Message-ID: <404396ef0912070431o1f1c74f6mcd567f48d29a9da4@mail.gmail.com> Hi Elliot, It is the right place, and Hoogle is now back up. Unfortunately the server it was run was out of disk space, which caused Hoogle to fail. Hopefully it won't happen again. Thanks, Neil 2009/11/29 Elliot Wolk : > hello! > im not sure that this is the correct mailing list for saying so, and also whether or not today's down-ness is just scheduled maintenance, but hoogle appears to be down again. sorry if this is known/redundant/not the right place! > > thanks, elliot > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From Christian.Maeder at dfki.de Mon Dec 7 07:38:08 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Dec 7 07:12:36 2009 Subject: [Haskell-cafe] Re: computing lists of pairs In-Reply-To: <200912042011.13145.daniel.is.fischer@web.de> References: <4B167061.10007@dfki.de> <200912041749.27041.daniel.is.fischer@web.de> <4B194E41.90707@dfki.de> <200912042011.13145.daniel.is.fischer@web.de> Message-ID: <4B1CF730.6020501@dfki.de> Thanks again for your patience with me, your answers to this list (and the beginners list) are in general a real pleasure! Christian Daniel Fischer schrieb: > Am Freitag 04 Dezember 2009 19:00:33 schrieb Christian Maeder: >>> aP1 [] = [[]] >>> aP1 (h:t) = do >>> x <- h >>> xs <- aP1 t >>> return (x:xs) >>> >>> for every x in h, we calculate the combinations of t anew. >> Do we? Isn't "aP1 t" one closure that's being evaluated only once? > > That depends. Firstly, it depends on the optimisation level. > ---------------------------------------------------------------------- > module AllPossibilities where > > import Debug.Trace > > aP1 :: [[Int]] -> [[Int]] > aP1 [] = [[]] > aP1 l@(h:t) = trace ("aP1 " ++ show l) [x:xs | x <- h, xs <- aP1 t] > > aP2 :: [[Int]] -> [[Int]] > aP2 [] = [[]] > aP2 l@(h:t) = trace ("aP2 " ++ show l) [x:xs | xs <- aP2 t, x <- h] > ---------------------------------------------------------------------- > > Compiled without optimisations (or interpreted): > > Prelude AllPossibilities> aP1 [[1,2,3],[4,5,6],[7,8,9]] > aP1 [[1,2,3],[4,5,6],[7,8,9]] > aP1 [[4,5,6],[7,8,9]] > aP1 [[7,8,9]] > [[1,4,7],[1,4,8],[1,4,9]aP1 [[7,8,9]] > ,[1,5,7],[1,5,8],[1,5,9]aP1 [[7,8,9]] > ,[1,6,7],[1,6,8],[1,6,9]aP1 [[4,5,6],[7,8,9]] > aP1 [[7,8,9]] > ,[2,4,7],[2,4,8],[2,4,9]aP1 [[7,8,9]] > ,[2,5,7],[2,5,8],[2,5,9]aP1 [[7,8,9]] > ,[2,6,7],[2,6,8],[2,6,9]aP1 [[4,5,6],[7,8,9]] > aP1 [[7,8,9]] > ,[3,4,7],[3,4,8],[3,4,9]aP1 [[7,8,9]] > ,[3,5,7],[3,5,8],[3,5,9]aP1 [[7,8,9]] > ,[3,6,7],[3,6,8],[3,6,9]] > Prelude AllPossibilities> aP2 [[1,2,3],[4,5,6],[7,8,9]] > aP2 [[1,2,3],[4,5,6],[7,8,9]] > aP2 [[4,5,6],[7,8,9]] > aP2 [[7,8,9]] > [[1,4,7],[2,4,7],[3,4,7],[1,5,7],[2,5,7],[3,5,7],[1,6,7],[2,6,7],[3,6,7],[1,4,8],[2,4,8], > [3,4,8],[1,5,8],[2,5,8],[3,5,8],[1,6,8],[2,6,8],[3,6,8],[1,4,9],[2,4,9],[3,4,9],[1,5,9], > [2,5,9],[3,5,9],[1,6,9],[2,6,9],[3,6,9]] > > it's evaluated multiple times. Compiled with optimisation (-O or -O2), > > Prelude AllPossibilities> aP1 [[1,2,3],[4,5,6],[7,8,9]] > aP1 [[1,2,3],[4,5,6],[7,8,9]] > aP1 [[4,5,6],[7,8,9]] > aP1 [[7,8,9]] > [[1,4,7],[1,4,8],[1,4,9],[1,5,7],[1,5,8],[1,5,9],[1,6,7],[1,6,8],[1,6,9],[2,4,7],[2,4,8], > [2,4,9],[2,5,7],[2,5,8],[2,5,9],[2,6,7],[2,6,8],[2,6,9],[3,4,7],[3,4,8],[3,4,9],[3,5,7], > [3,5,8],[3,5,9],[3,6,7],[3,6,8],[3,6,9]] > Prelude AllPossibilities> aP2 [[1,2,3],[4,5,6],[7,8,9]] > aP2 [[1,2,3],[4,5,6],[7,8,9]] > aP2 [[4,5,6],[7,8,9]] > aP2 [[7,8,9]] > [[1,4,7],[2,4,7],[3,4,7],[1,5,7],[2,5,7],[3,5,7],[1,6,7],[2,6,7],[3,6,7],[1,4,8],[2,4,8], > [3,4,8],[1,5,8],[2,5,8],[3,5,8],[1,6,8],[2,6,8],[3,6,8],[1,4,9],[2,4,9],[3,4,9],[1,5,9], > [2,5,9],[3,5,9],[1,6,9],[2,6,9],[3,6,9]] > > it's only evaluated once. It's also evaluated only once (unoptimized) if given as follows, although I would not write it that way: aP1 :: [[Int]] -> [[Int]] aP1 [] = [[]] aP1 l@(h:t) = trace ("aP1 " ++ show l) $ let r = aP1 t in [x:xs | x <- h, xs <- r] > But if we think about what happens when we have n lists of lengths l1, ..., ln, there are > l2*...*ln combinations of the tail. Each of these combinations is used l1 times, once for > each element of the first list. However, between two uses of a particular combination, all > the other (l2*...*ln-1) combinations are used once. If l2*...*ln is large, only a tiny > fraction of the combinations of the tail fit in the memory at once, so they simply can't > be reused and have to be recalculated each time (theoretically, a handful could be kept in > memory for reuse). Right, memory consumption is still the problem (maybe unless everything is needed eventually). > On the other hand, in aP2, each combination of the tail is of course also used l1 times, > but these are in direct succession, and the combination has been bound to a name for the > entire scope, it's practically guaranteed to be calculated only once and garbage collected > once. Yes, I see that reusing and sharing one element of xs is far easier in aP2. > By the way, if the order in which the combinations are generated matters: > > aP1 === map reverse . aP2 . reverse The order does not matter for me. But it is good to see (from a second perspective) that both variants basically produce the same combinations. >>> aP2 [] = [[]] >>> aP2 (h:t) = do >>> xs <- aP2 t >>> x <- h >>> return (x:xs) >>> >>> now we first calculate the combinations of t, for each of those, we cons >>> the elements of h to it in turn and never reuse it afterwards. >> Thanks for explaining. >> >> C. > From jwlato at gmail.com Mon Dec 7 07:41:28 2009 From: jwlato at gmail.com (John Lato) Date: Mon Dec 7 07:15:57 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww Message-ID: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive. Even then, there's no guarantee the right version will be found (google "DLL Hell" for examples of the chaos that ensues). This is particularly true for developers, who frequently have multiple versions of libraries installed. The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step. One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows. John From ivan.miljenovic at gmail.com Mon Dec 7 07:42:03 2009 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon Dec 7 07:16:36 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <404396ef0912070431m51f5daecn275385716ef7444@mail.gmail.com> (Neil Mitchell's message of "Mon, 7 Dec 2009 12:31:30 +0000") References: <26669924.post@talk.nabble.com> <404396ef0912070431m51f5daecn275385716ef7444@mail.gmail.com> Message-ID: <87tyw3x8f8.fsf@gmail.com> Neil Mitchell writes: > but if you use Hayoo for some reason other than Hoogle not searching > all packages, I'd love to know. Isn't it obvious? We all use Hayoo for the Web 2.0 interface! :p /me is just kidding -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com From ddssff at gmail.com Mon Dec 7 09:38:51 2009 From: ddssff at gmail.com (David Fox) Date: Mon Dec 7 09:13:20 2009 Subject: [Haskell-cafe] SYB <> very, very mysteriously In-Reply-To: <8625cd9c0912050238g2ed403a4u1c0e82262f57168e@mail.gmail.com> References: <740BE15A-8247-422E-B0FD-D52CC11717E4@n-heptane.com> <8625cd9c0912050238g2ed403a4u1c0e82262f57168e@mail.gmail.com> Message-ID: On Sat, Dec 5, 2009 at 2:38 AM, Andrea Vezzosi wrote: > On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw wrote: >> I have stripped things down to the bare minimum, and test under GHC 6.10, >> GHC 6.12, Linux, and Mac OS X. Results are consistent. >> >> In the following code, >> >> ?1. if you load the code into ghci and evaluate e it will hang, but >> (defaultValueD dict) :: Expression returns fine >> ?2. if you change the gunfold instance for Proposition to, error "gunfold" >> it stops hanging -- even though this code is never called. >> ?3. if you change, ( Data ctx [Expression], Sat (ctx Expression) => Data ctx >> Expression, to (Data ctx Expression, ....) => ... it stops hanging. >> >> If someone could explain why each of these cases perform as they do, that >> would be awesome! Right now it is a big mystery to me.. e calls dict .. and >> there is only one instance of dict available, which should call error right >> away. I can't see how something could get in the way there... >> > > It's less of a mystery if you think about the actual dictionaries ghc > uses to implement typeclasses. > The instance for Data ctx [a] depends on Data ctx a, so by requiring > Data ctx [Expression] in the Data ctx Expression instance you're > indeed making a loop there, though typeclasses do allow this, and the > implementation has to be lazy enough to permit it. > Strange that with a direct Data ctx Expression => Data ctx Expression > loop we don't get the same problem. > The reason the implementation of Proposition's gunfold matters is > probably that k gets passed the dictionary for Data DefaultD > Expression at the site of its call and some optimization is making it > stricter than necessary. > > Looks like we need a ghc dev here to fully unravel the mystery, in the > meantime i'll try to reduce the test case even further. I have posted a ghc bug for this: http://hackage.haskell.org/trac/ghc/ticket/3731 and an syb-with-class bug, in case it is not a ghc bug (perhaps due to undecidable instances?):http://code.google.com/p/syb-with-class/issues/detail?id=3 From klondikehaskellcafe at xiscosoft.es Mon Dec 7 09:49:11 2009 From: klondikehaskellcafe at xiscosoft.es (klondike) Date: Mon Dec 7 09:23:52 2009 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces In-Reply-To: <4B1CD90C.3040302@henning-thielemann.de> References: <4AF02F06.2030105@henning-thielemann.de> <4AF4D352.1090107@xiscosoft.es> <7ca3f0160911061847k763c6073g4f055069b53c577d@mail.gmail.com> <4AF586CD.9010504@xiscosoft.es> <4B1CD90C.3040302@henning-thielemann.de> Message-ID: <4B1D15E7.5040102@xiscosoft.es> Henning Thielemann escribi?: > A library function that reads a config file may declare to be able to > throw the exception "File not found", or it may introduce a new > exception "Could not read Config file" with an extra field for the > reason, why the file could not be read. This way you can construct a > call stack that helps the user (and not the programmer). Then the > message reported to the user might be: > > Program could not be started, > because Config file could not be read > because Config file does not exist in dir0, dir1, dir2 > > but the exception handler may also decide to use a default configuration > instead or ask the user, how to proceed. > > Anyway, such a call stack for the user requires different information > than a call stack for programmer for debugging. > The point here being? My point has been "As programming errors are something common lets at least make them easy to solve". If you make such a fancy stack the programmer is still clueless about where the unhandled exception was generated and can't solve it. There is also another important point here which is error recovery, it's not unusual to see on servers and other high availability programs a last barrier which would show info on the error and then restart/resume the server as if nothing has happened. Following your definition, now we have exceptions, not errors, as they are expected, though they made some harm to our transaction. Henning Thielemann escribi?: > The case of (head []) is simple: It is a programming error, since the > precondition for calling 'head' is that the argument list is non-empty. > The caller of 'head' is responsible to check this. If the list comes > from user input, then the program part that receives this list from the > user is responsible to check for the empty list before calling 'head'. > If there is no such check, this is a programming error, and it will not > be possible to handle this (like an exception). Before you answer: "What > about web servers?", please read on the article I have written recently > to sum up the confusion about errors and exceptions: > > http://www.haskell.org/haskellwiki/Error_vs._Exception > Well I got used to going back to the previous state without crashing when I got a precondition violation due to user input. Though I assume that was asking a bit too much of Haskell. Of course crashing the whole program as default behaviour is a better way to solve the problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/cc3de382/signature.bin From vanenkj at gmail.com Mon Dec 7 10:04:36 2009 From: vanenkj at gmail.com (John Van Enk) Date: Mon Dec 7 09:39:04 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: PortAudio Windows Tutorial and Binaries In-Reply-To: <727150.29310.qm@web113109.mail.gq1.yahoo.com> References: <727150.29310.qm@web113109.mail.gq1.yahoo.com> Message-ID: Very cool. On Sun, Dec 6, 2009 at 7:29 PM, M Xyz wrote: > > I got a lot of great help this weekend from Haskell-Cafe, thanks. > Now that I have portaudio up and running I put up a tutorial and a 103 kb > download > of all the windows binaries and files. I hope this helps people exploring > digital audio with Haskell. > > http://www.subreddits.org/misc/haskell/portaudio.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/68affc3b/attachment-0001.html From RafaelGCPP.Linux at gmail.com Mon Dec 7 11:24:49 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Mon Dec 7 10:59:18 2009 Subject: [Haskell-cafe] Is it possible: Haskell platform - portable edition Message-ID: <351ff25e0912070824g7ea1317csaec821b6e587704d@mail.gmail.com> Hello, Has anyone considered the possibility of making a *Portable* Haskell Platform distribution (portable meaning on a USB stick) for Windows? This worked form me: I installed GHC on one machine, copied it to a USB stick and created a batch to set the environment path and open a command prompt. This gives me the freedom to use Haskell wherever I am! The only downside is that I have to edit packages.conf by hand everytime I install a package. I would like to improve this, by making it more automatic. Do you haskellers think it is possible? Regards, Rafael Gustavo da Cunha Pereira Pinto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/b82adda5/attachment.html From leaveye.guo at gmail.com Mon Dec 7 11:45:59 2009 From: leaveye.guo at gmail.com (L.Guo) Date: Mon Dec 7 11:20:34 2009 Subject: [Haskell-cafe] A bug of groupBy implement Message-ID: <200912080045548287459@gmail.com> Hi there: My friend asked me a question, and i suppose he has found a bug of `groupBy'. Here is the code piece: > List.groupBy (\a b -> Foreign.unsafePerformIO (Text.Printf.printf "\t%d <= %d ?: %s\n" a b (show (a<=b)) >> return (a<=b))) [7,3,5,9,6,8,3,5,4] I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): 7 <= 3 ?: False 3 <= 5 ?: True 3 <= 9 ?: True 3 <= 6 ?: True 3 <= 8 ?: True 3 <= 3 ?: True 3 <= 5 ?: True 3 <= 4 ?: True [[7],[3,5,9,6,8,3,5,4]] Regards -------------- L.Guo 2009-12-08 From stephen.tetley at gmail.com Mon Dec 7 12:11:01 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Mon Dec 7 11:45:29 2009 Subject: [Haskell-cafe] A bug of groupBy implement In-Reply-To: <200912080045548287459@gmail.com> References: <200912080045548287459@gmail.com> Message-ID: <5fdc56d70912070911t79797d76j75558d0a8e99dce9@mail.gmail.com> Could it not be a bug in a) printf b) unsafePerformIO c) >> d) return e) <= f) show g) GHC or GHCi? All of the above? Best wishes Stephen 2009/12/7 L.Guo : > Hi there: > > My friend asked me a question, and i suppose he has found a bug of `groupBy'. > > Here is the code piece: > >> List.groupBy (\a b -> Foreign.unsafePerformIO (Text.Printf.printf "\t%d <= %d ?: %s\n" a b (show (a<=b)) >> return (a<=b))) [7,3,5,9,6,8,3,5,4] > > I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): > > ? ? ? ?7 <= 3 ?: False > ? ? ? ?3 <= 5 ?: True > ? ? ? ?3 <= 9 ?: True > ? ? ? ?3 <= 6 ?: True > ? ? ? ?3 <= 8 ?: True > ? ? ? ?3 <= 3 ?: True > ? ? ? ?3 <= 5 ?: True > ? ? ? ?3 <= 4 ?: True > [[7],[3,5,9,6,8,3,5,4]] > > > ? ?Regards > -------------- > L.Guo > 2009-12-08 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Mon Dec 7 12:15:31 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 7 11:50:09 2009 Subject: [Haskell-cafe] A bug of groupBy implement In-Reply-To: <5fdc56d70912070911t79797d76j75558d0a8e99dce9@mail.gmail.com> References: <200912080045548287459@gmail.com> <5fdc56d70912070911t79797d76j75558d0a8e99dce9@mail.gmail.com> Message-ID: <1429577090.20091207201531@gmail.com> Hello Stephen, Monday, December 7, 2009, 8:11:01 PM, you wrote: it's just what goupBy compares with the first element of group rather than comparing two adjancent elements. look at the trace it's not a bug, but misunderstanding of specification :) > Could it not be a bug in > a) printf > b) unsafePerformIO c) >>> > d) return > e) <= > f) show > g) GHC or GHCi? > All of the above? > Best wishes > Stephen > 2009/12/7 L.Guo : >> Hi there: >> >> My friend asked me a question, and i suppose he has found a bug of `groupBy'. >> >> Here is the code piece: >> >>> List.groupBy (\a b -> Foreign.unsafePerformIO (Text.Printf.printf "\t%d <= %d ?: %s\n" a b (show (a<=b)) >> return (a<=b))) [7,3,5,9,6,8,3,5,4] >> >> I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): >> >> ? ? ? ?7 <= 3 ?: False >> ? ? ? ?3 <= 5 ?: True >> ? ? ? ?3 <= 9 ?: True >> ? ? ? ?3 <= 6 ?: True >> ? ? ? ?3 <= 8 ?: True >> ? ? ? ?3 <= 3 ?: True >> ? ? ? ?3 <= 5 ?: True >> ? ? ? ?3 <= 4 ?: True >> [[7],[3,5,9,6,8,3,5,4]] >> >> >> ? ?Regards >> -------------- >> L.Guo >> 2009-12-08 >> >> _______________________________________________ >> 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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From byorgey at seas.upenn.edu Mon Dec 7 12:15:45 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Mon Dec 7 11:50:16 2009 Subject: [Haskell-cafe] A bug of groupBy implement In-Reply-To: <200912080045548287459@gmail.com> References: <200912080045548287459@gmail.com> Message-ID: <20091207171545.GA27105@seas.upenn.edu> On Tue, Dec 08, 2009 at 12:45:59AM +0800, L.Guo wrote: > Hi there: > > My friend asked me a question, and i suppose he has found a bug of `groupBy'. > > Here is the code piece: > > > List.groupBy (\a b -> Foreign.unsafePerformIO (Text.Printf.printf "\t%d <= %d ?: %s\n" a b (show (a<=b)) >> return (a<=b))) [7,3,5,9,6,8,3,5,4] > > I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): > > 7 <= 3 ?: False > 3 <= 5 ?: True > 3 <= 9 ?: True > 3 <= 6 ?: True > 3 <= 8 ?: True > 3 <= 3 ?: True > 3 <= 5 ?: True > 3 <= 4 ?: True > [[7],[3,5,9,6,8,3,5,4]] This looks like the right result to me. What makes you think it is wrong? What result do you expect? -Brent From dons at galois.com Mon Dec 7 12:16:25 2009 From: dons at galois.com (Don Stewart) Date: Mon Dec 7 11:50:53 2009 Subject: [Haskell-cafe] The Haskell Web News: December 2009 Edition Message-ID: <20091207171625.GA5314@whirlpool.galois.com> The Haskell Web News is a monthly summary of the hottest news about the Haskell programming language, as found in our online communities. If you want to catch up with what?s been happening in Haskell, this might be the journal for you. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ What?s been happening with the Haskell programming language for the past month, as voted by readers of The Haskell Reddit. This is the first edition of the Web News, so feedback on the content, schedule and goals is welcome. -- Don From matthijs at stdin.nl Mon Dec 7 12:19:37 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon Dec 7 11:54:03 2009 Subject: [Haskell-cafe] A bug of groupBy implement In-Reply-To: <200912080045548287459@gmail.com> References: <200912080045548287459@gmail.com> Message-ID: <20091207171937.GY13955@katherina.student.utwente.nl> Hi, > I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): > > 7 <= 3 ?: False > 3 <= 5 ?: True > 3 <= 9 ?: True > 3 <= 6 ?: True > 3 <= 8 ?: True > 3 <= 3 ?: True > 3 <= 5 ?: True > 3 <= 4 ?: True > [[7],[3,5,9,6,8,3,5,4]] What exactly is wrong with this result? All of the above comparisons seem to get the right result, and they say 7 is not in the same categorie as 3, but all other numbers are in the same category as 3. So the returned list looks ok too. Perhaps you had expected another output list (please tell us what you think you've found a bug!)? In fact, it seems that any output list would have been correct, since you're using a comparison function that is not symmetrical. In other words, you're say 7 should be in the same category as 3, but 3 should not be in the same category as 7. Since nothing is guaranteed about the order in which groupBy compares elements, any grouping could be achieved by letting groupBy choose the "right" ordering. So, it seems your comparison function is wrong since it does not satisfy the (unwritten) requirement of symmetry? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/efe27fcc/attachment.bin From byorgey at seas.upenn.edu Mon Dec 7 12:20:40 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Mon Dec 7 11:55:06 2009 Subject: [Haskell-cafe] A bug of groupBy implement In-Reply-To: <20091207171545.GA27105@seas.upenn.edu> References: <200912080045548287459@gmail.com> <20091207171545.GA27105@seas.upenn.edu> Message-ID: <20091207172040.GA27289@seas.upenn.edu> On Mon, Dec 07, 2009 at 12:15:45PM -0500, Brent Yorgey wrote: > On Tue, Dec 08, 2009 at 12:45:59AM +0800, L.Guo wrote: > > Hi there: > > > > My friend asked me a question, and i suppose he has found a bug of `groupBy'. > > > > Here is the code piece: > > > > > List.groupBy (\a b -> Foreign.unsafePerformIO (Text.Printf.printf "\t%d <= %d ?: %s\n" a b (show (a<=b)) >> return (a<=b))) [7,3,5,9,6,8,3,5,4] > > > > I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): > > > > 7 <= 3 ?: False > > 3 <= 5 ?: True > > 3 <= 9 ?: True > > 3 <= 6 ?: True > > 3 <= 8 ?: True > > 3 <= 3 ?: True > > 3 <= 5 ?: True > > 3 <= 4 ?: True > > [[7],[3,5,9,6,8,3,5,4]] > > This looks like the right result to me. What makes you think it is > wrong? What result do you expect? I just realized I think I understand what the confusion is. You think it should return [[7],[3,5,9],[6,8],[3,5],[4]]? But in fact, groupBy only works that way for equivalence relations, where it makes perfect sense to just compare the first thing in each sublist against all the rest, instead of comparing each pair of adjacent elements. The behavior you want is something I have been planning to add to the Data.List.Split module for a while. -Brent From deniz.a.m.dogan at gmail.com Mon Dec 7 12:25:46 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Mon Dec 7 12:00:33 2009 Subject: [Haskell-cafe] The Haskell Web News: December 2009 Edition In-Reply-To: <20091207171625.GA5314@whirlpool.galois.com> References: <20091207171625.GA5314@whirlpool.galois.com> Message-ID: <7b501d5c0912070925t20723b90o7ce5b5eec87e1e33@mail.gmail.com> 2009/12/7 Don Stewart : > The Haskell Web News is a monthly summary of the hottest news about the > Haskell programming language, as found in our online communities. If you > want to catch up with what?s been happening in Haskell, this might be > the journal for you. > > ? ?http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ > > What?s been happening with the Haskell programming language for the past > month, as voted by readers of The Haskell Reddit. This is the first > edition of the Web News, so feedback on the content, schedule and goals > is welcome. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > I think the correct URL should be: http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ Yours didn't work for me. -- Deniz Dogan From korpios at korpios.com Mon Dec 7 12:28:10 2009 From: korpios at korpios.com (Tom Tobin) Date: Mon Dec 7 12:02:39 2009 Subject: [Haskell-cafe] The Haskell Web News: December 2009 Edition In-Reply-To: <7b501d5c0912070925t20723b90o7ce5b5eec87e1e33@mail.gmail.com> References: <20091207171625.GA5314@whirlpool.galois.com> <7b501d5c0912070925t20723b90o7ce5b5eec87e1e33@mail.gmail.com> Message-ID: On Mon, Dec 7, 2009 at 11:25 AM, Deniz Dogan wrote: > 2009/12/7 Don Stewart : >> The Haskell Web News is a monthly summary of the hottest news about the >> Haskell programming language, as found in our online communities. If you >> want to catch up with what?s been happening in Haskell, this might be >> the journal for you. >> >> ? ?http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ > > I think the correct URL should be: > http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ Actually, I think it's: http://haskellwebnews.wordpress.com/2009/12/06/whats-new-in-haskell-december-2009/ From dons at galois.com Mon Dec 7 12:29:09 2009 From: dons at galois.com (Don Stewart) Date: Mon Dec 7 12:03:41 2009 Subject: [Haskell-cafe] The Haskell Web News: December 2009 Edition In-Reply-To: <7b501d5c0912070925t20723b90o7ce5b5eec87e1e33@mail.gmail.com> References: <20091207171625.GA5314@whirlpool.galois.com> <7b501d5c0912070925t20723b90o7ce5b5eec87e1e33@mail.gmail.com> Message-ID: <20091207172909.GC5314@whirlpool.galois.com> Deniz: > I think the correct URL should be: Oops, well spotted. The original link will work now. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ From deniz.a.m.dogan at gmail.com Mon Dec 7 12:30:27 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Mon Dec 7 12:05:18 2009 Subject: [Haskell-cafe] The Haskell Web News: December 2009 Edition In-Reply-To: References: <20091207171625.GA5314@whirlpool.galois.com> <7b501d5c0912070925t20723b90o7ce5b5eec87e1e33@mail.gmail.com> Message-ID: <7b501d5c0912070930i1fe4ac85rb33e09afe1b52782@mail.gmail.com> 2009/12/7 Tom Tobin : > On Mon, Dec 7, 2009 at 11:25 AM, Deniz Dogan wrote: >> 2009/12/7 Don Stewart : >>> The Haskell Web News is a monthly summary of the hottest news about the >>> Haskell programming language, as found in our online communities. If you >>> want to catch up with what?s been happening in Haskell, this might be >>> the journal for you. >>> >>> ? ?http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ >> >> I think the correct URL should be: >> http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ > > Actually, I think it's: > > http://haskellwebnews.wordpress.com/2009/12/06/whats-new-in-haskell-december-2009/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Of course, that's what I meant. :) -- Deniz Dogan From bulat.ziganshin at gmail.com Mon Dec 7 12:31:16 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 7 12:05:58 2009 Subject: [Haskell-cafe] The Haskell Web News: December 2009 Edition In-Reply-To: <20091207171625.GA5314@whirlpool.galois.com> References: <20091207171625.GA5314@whirlpool.galois.com> Message-ID: <1002344956.20091207203116@gmail.com> Hello Don, Monday, December 7, 2009, 8:16:25 PM, you wrote: > http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ can we make download counts for individual packages available? my own program (http://freearc.org) has about 10k downloads/month so i doubt what place it may have among all haskell applications :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From stephen.tetley at gmail.com Mon Dec 7 12:41:47 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Mon Dec 7 12:16:15 2009 Subject: [Haskell-cafe] A bug of groupBy implement In-Reply-To: <5fdc56d70912070911t79797d76j75558d0a8e99dce9@mail.gmail.com> References: <200912080045548287459@gmail.com> <5fdc56d70912070911t79797d76j75558d0a8e99dce9@mail.gmail.com> Message-ID: <5fdc56d70912070941x33c2ed3cn3afda877d9f7f9a3@mail.gmail.com> Hi L.Guo Brent has replied with the right answer. The definition of groupBy is below - the span in the where clause only compares with the first element of the current sub-list: -- | The 'groupBy' function is the non-overloaded version of 'group'. groupBy :: (a -> a -> Bool) -> [a] -> [[a]] groupBy _ [] = [] groupBy eq (x:xs) = (x:ys) : groupBy eq zs where (ys,zs) = span (eq x) xs -- list1 = [7,3,5,9,6,8,3,5,4::Int] Here are two more runs on your input with a wee bit less clutter. In both cases there are 'spans' where the numbers increase and decrease - this is because the operation is comparing the rest of the input against the first element in the 'span' not consecutive elements. *GroupBy Data.List> groupBy (<) list1 [[7],[3,5,9,6,8],[3,5,4]] *GroupBy Data.List> groupBy (<=) list1 [[7],[3,5,9,6,8,3,5,4]] Best wishes Stephen From mauricio.antunes at gmail.com Mon Dec 7 12:52:04 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Mon Dec 7 12:26:56 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> Message-ID: > To reply to an earlier point of Andrew's (I can't find the quote > now, sorry), one of the biggest difficulties developers face > on Windows is the lack of common install locations/practices. > Windows software is usually distributed as a binary, which may > or may not include header files. These files may be installed > in any of numerous locations, such as C:\Program Files\, the > user's home directory, the system directory, or directly off the > drive root. Defaults are not common among different programs or > even versions of programs, and install locations are frequently > changed by users anyway. Libraries and headers are usually > not located on the PATH environment variable, and there's no > standard INCDIR or LIBDIR variable either. If Windows lacks a sane environment, why not to provide one? I don't know how much of it mingw already provides. If it doesn't, that would be a nice Haskell project :) It could be called Windows SaneEnvironment, and include a few basic policies for packages and a package manager. When I needed Windows myself I would certainly help maintaining. It would not be hard to find others who still will. Maur?cio From michael at snoyman.com Mon Dec 7 13:47:09 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Dec 7 13:21:36 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <4B1CF14C.5090302@henning-thielemann.de> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> Message-ID: <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> On Mon, Dec 7, 2009 at 2:13 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > Michael Snoyman schrieb: > > > > > > On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen > > wrote: > > > > Michael Snoyman wrote: > > > > > On the other hand, what's so bad about treating errors as > exceptions? If > > > instead of the program crashing on an array-out-of-bound or > pattern-match > > > it throws an exception which can be caught, so what? > > > > The error gets hidden instead of fixed? > > > > Cheers > > Ben > > > > You're right; bad programmers could do this. A good programmer will know > > to do one of two things when it gets an exception it does not know how > > to handle: > > It is certainly not the task of a programming language or a library to > parent its users. Despite an interesting idea, it will not work, since > programmers will simply switch to a different language or library if > they feel pushed around. > How did you get from what I said that I have any desire to parent users of a language? I think my sentiment is clear: a bad programmer will do bad things with any tool. I don't care about how a bad programmer might screw things up. In fact, I think your ideas are much more likely to give the feeling of being "pushed around." The only opinion I've stated so far is that it's ridiculous to constantly demand that people follow your definition of error vs exception, since the line is incredibly blurry and it buys you very little. However, my opinion on what libraries should do is simple: Provide a simple, uniform interface for receiving both errors and exceptions, and let the library user decide what to do with them. If they are unhandable, then don't handle them; if a user *does* handle something which can't be dealt with, they fall into the over-defensive bad programmer category and I don't care. Otherwise, it gives people the flexibility that they need in all cases. I think under no circumstances* should a library simply terminate a runtime because it decides to. This is one of the great things of being able to catch all errors. * Of course, there are no absolutes. Ever. Not a single one. > > There is an important reason to not simply catch an error and proceed as > if it were only an exception: The error might have corrupted some data > and there is no general way to recover from that. Say, after detecting > an error you might want to close a file that you were working on. But > since you are coping with an error, something you did not foresee, you > cannot tell whether the file was already closed again or never opened. > So it is better to just abort the program. > > The next higher level, the shell calling your program or the browser > calling your plugin, might have registered what have opened and > allocated and can reliably free those resources. > > And what if you're calling a library in the same runtime? I think you are conflating the idea of "treating errors as exceptions", which I think is a good one, and "not letting there be any distinction between errors and exceptions," which is a bad one. The fact that I can use Control.Exception.catch to catch either errors or exceptions, but I can differentiate based on the data type, is IMO a great solution to this issue. I also believe that the failure package is a better** solution to the problem, because it makes it exceedingly clear which error/exception might have occurred. ** Of course, failure cannot handle a lot of what IO exceptions can, so it's a silly comparison in general. However, for the purpose of "good error/exception handling," I think it's a better solution. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/519c00dd/attachment.html From lemming at henning-thielemann.de Mon Dec 7 14:07:20 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 13:42:20 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <20091205174129.GA15215@soi.city.ac.uk> <29bf512f0912050952p3081e507x6588c02567febf02@mail.gmail.com> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> Message-ID: On Mon, 7 Dec 2009, Michael Snoyman wrote: > The only opinion I've stated so far is that it's ridiculous to constantly demand > that people follow your definition of error vs exception, since the line is incredibly > blurry and it buys you very little. If you have an example that is not contained in my article on the Haskell Wiki, where you think the error vs. exception distinction is not appropriate, please let me know and will think about it. http://www.haskell.org/haskellwiki/Error_vs._Exception From michael at snoyman.com Mon Dec 7 14:20:09 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Dec 7 13:54:37 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> Message-ID: <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> On Mon, Dec 7, 2009 at 9:07 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Mon, 7 Dec 2009, Michael Snoyman wrote: > > The only opinion I've stated so far is that it's ridiculous to constantly >> demand >> that people follow your definition of error vs exception, since the line >> is incredibly >> blurry and it buys you very little. >> > > If you have an example that is not contained in my article on the Haskell > Wiki, where you think the error vs. exception distinction is not > appropriate, please let me know and will think about it. > > > http://www.haskell.org/haskellwiki/Error_vs._Exception > I think it's a silly, unnecessary distinction. Sure, when you're teaching beginning programmers how to deal with out-of-bounds versus file not found, you can use the terminology. But as far as insisting that library authors have their programs die on an error, it's pointless. Having errors thrown as their own type of exception (like AssertionFailed, for example) is a much more resilient option, and for decent programmers who understand they shouldn't just catch every exception and return a default value, there is no downside. I don't care to make systems less resilient to deal with the sub-par programmer. I turn it around: give me an example where it's better for the runtime to exit than for some type of exception to be thrown, and *I'll* think about it ;). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/a69ddb10/attachment.html From lemming at henning-thielemann.de Mon Dec 7 14:23:07 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 13:57:34 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> Message-ID: > I turn it around: give me an example where it's better for the runtime to exit than for > some type of exception to be thrown, and *I'll* think about it ;). If you would have read my article, you had one ... From lemming at henning-thielemann.de Mon Dec 7 14:31:22 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 14:05:49 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? Message-ID: Somehow I missed this thread. I want to say that I have implemented a general way to add the information of an exception to the "end" of an arbitrary data structure. http://hackage.haskell.org/packages/archive/explicit-exception/0.1.4/doc/html/Control-Monad-Exception-Asynchronous.html Duncan already mentioned it: > data Exceptional e a = Exceptional { > exception :: Maybe e > result :: a > } > However it's pretty clear from the structure of this type that it cannot > cope with lazy error handling in sequences. If you try it you'll find > you cannot do it without space leaks. Actually you spotted the space leak - but how is it pretty clear, that it has the space leak? I wondered why 'unzip' does not have the space leak, although when I sequence a lot of Exceptional values using mconcat, I'm doing something pretty similar. I also agree with you, that the possibility to access the result directly, and thus easily ignore the exception is bad. I thought it could be improved by removing the field accessors and instead provide the function: switch :: (Maybe e -> c) -> (a -> c) -> Exceptional e a -> c From lemming at henning-thielemann.de Mon Dec 7 14:36:27 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 14:10:53 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: References: Message-ID: @Apfelmus: For practical purposes I think Train should have swapped type parameters in order to make Functor act on the type of the list elements. data Train b a = Wagon a (Train b a) | Loco b From lemming at henning-thielemann.de Mon Dec 7 14:53:16 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 14:28:00 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> Message-ID: On Mon, 7 Dec 2009, Michael Snoyman wrote: > I actually *did* read your article, and don't know what you are referring to. If this is true, sorry, I didn't had the impression. I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely. From nicolas.pouillard at gmail.com Mon Dec 7 14:55:52 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon Dec 7 14:30:19 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: References: Message-ID: <1260215701-sup-7631@peray> Excerpts from Henning Thielemann's message of Mon Dec 07 20:36:27 +0100 2009: > > @Apfelmus: > > For practical purposes I think Train should have swapped type parameters > in order to make Functor act on the type of the list elements. > > > data Train b a = Wagon a (Train b a) > | Loco b The functor on the Loco/Caboose makes sense too and swapping the arguments is less natural to read. -- Nicolas Pouillard http://nicolaspouillard.fr From michael at snoyman.com Mon Dec 7 14:59:56 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Dec 7 14:34:23 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> Message-ID: <29bf512f0912071159m78284e83v61a6d1b2fb0ebd93@mail.gmail.com> On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Mon, 7 Dec 2009, Michael Snoyman wrote: > > I actually *did* read your article, and don't know what you are referring >> to. >> > > If this is true, sorry, I didn't had the impression. > > I also think that in an earlier mail I answered, that errors can leave you > with corrupt data, say invalid file handles, memory pointers, or data > structures that violate invariants. You won't like to close files from > invalid file handles and free memory from corrupt pointers or run into > infinite loops by traversing the corrupt data structures. That's the reason > why it is better to stop execution of the program and hand over control to > the next higher level, say the shell or the web browser, that can free > resources safely. > Firstly: I'm really referring exclusively to non-FFI Haskell programs, to which most of the issues you mention don't really apply. Nonetheless, I think that for a language with exceptions, it still makes sense to use the exceptions in these cases. In all these cases, I think the correct thing is to have a specific exception type that is thrown that signals that it is such an unrecoverable error. This allows the programmer to do *whatever* they want. Perhaps they want to save some other data to a file before exiting? Perhaps they want to spawn a process to send in a bug report? Who knows. It doesn't matter. The point is, the user *might* want to do something, and exceptions let them do it if they wish, or they can completely ignore that specific exception type and let the program crash anyway. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/d29a938f/attachment.html From jason.dusek at gmail.com Mon Dec 7 15:39:10 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Dec 7 15:13:36 2009 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces In-Reply-To: <4B1D15E7.5040102@xiscosoft.es> References: <4AF02F06.2030105@henning-thielemann.de> <4AF4D352.1090107@xiscosoft.es> <7ca3f0160911061847k763c6073g4f055069b53c577d@mail.gmail.com> <4AF586CD.9010504@xiscosoft.es> <4B1CD90C.3040302@henning-thielemann.de> <4B1D15E7.5040102@xiscosoft.es> Message-ID: <42784f260912071239p12e0e690g8200eeb9e3aadacd@mail.gmail.com> 2009/12/07 klondike : > Well I got used to going back to the previous state without > crashing when I got a precondition violation due to user > input. Though I assume that was asking a bit too much of > Haskell. It's too much to ask of partial functions. If you want to state your preconditions and rollback in an appropriate monad, that's of a horse of a different color. > Of course crashing the whole program as default behaviour is a > better way to solve the problem. If you're not working in a side-effecting or sequential subset of the language, you can't really expect to have a consistent notion of the state "before" the crash. It's a declarative, lazy language, after all. Consider, also, that a crash is just one of the problems you get with bad input; another one is infinite loops. As Henning Thielemann points out in his wiki article, you can't expect to catch those as they don't throw exceptions or cause any errors! You need to validate the input or use a timer in that case. Relying on the program to crash in a timely manner if something is wrong with the input is not a strategy that is going to go the distance. -- Jason Dusek From fb at frank-buss.de Mon Dec 7 16:33:32 2009 From: fb at frank-buss.de (Frank Buss) Date: Mon Dec 7 16:07:44 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <1260215701-sup-7631@peray> References: <1260215701-sup-7631@peray> Message-ID: <100d01ca7784$ecd968e0$c68c3aa0$@de> Anyone interested in writing some lines of Haskell code for generating the Zumkeller numbers? http://www.luschny.de/math/seq/ZumkellerNumbers.html My C/C# solutions looks clumsy (but is fast). I think this can be done much more elegant in Haskell with lazy evaluation. Not related to Haskell, but do you think semi-Zumkeller numbers are semi-perfect numbers? Maybe some Haskell code for testing it for some numbers? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de From andrewcoppin at btinternet.com Mon Dec 7 16:37:28 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Dec 7 16:11:47 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> Message-ID: <4B1D7598.1020403@btinternet.com> Jeffrey Scofield wrote: > I think the real cultural difference is that you aren't a user, you're > a prospective Haskell developer, as others have said. Developers > pretty much have to install tools (like compilers and preprocessors) > and have to work with source code. > And I have no problem with needing to install a Haskell compiler. If I had to install a seperate C compiler to make FFI to C work, that wouldn't seem unreasonable either. (As it happens, GHC has a C backend, so the C compiler just happens to be there already.) What does seem very weird is having to turn my Windows box into a psuedo-Unix system in order to write native Windows programs. > Traditionally, Unix *comes with* thousands of tools that are useful > to developers. Windows traditionally came with none, at least > none that I was ever able to find. > True. By default, Windows assumes you are a clueless user, not an expert developer. > Since many of the traditional Unix tools are available free, it > makes sense that somebody would want to port them to Windows > *for doing development*. It's not so much a Unix emulation as > a solution to the lack of native Windows tools. Of course this > makes sense especially to somebody who has gotten used to > the Unix tools (such as myself). I would never try to *develop* > seriously under Windows using just what comes preinstalled. > You can't develop anything with just what's preinstalled. (Well, unless you could writing batch scripts...) Generally, if you want to develop C or C++ applications on Windows, you install MS Visual Studio. It gives you the compiler, linker, dependency management, and a whole bunch of other stuff. You typically wouldn't install gcc, ld and Automake. (Unless of course you were specifically trying to port existing Unix code, obviously.) The thing is, if you're a C programmer on Windows, and you want to write (say) a program that talks to an Oracle database, typically what you'd do is install Visual Studio, download the Net8 client DLLs and header files, compile your application against the Net8 client header files, link everything, and when your program runs, it dynamically loads the Net8 DLLs and does its work. But it seems that if I want to talk to Oracle from Haskell, I'm expected to find the *source code* to the Net8 client and *compile it from source*. This is highly unusual for Windows. (I wouldn't be surprised if Oracle haven't even released the source code for their Net8 libraries...) It just isn't the way Windows usually works. Even without VS, if I'm working in C, all I really need is a compiler and a linker, and I can build an executable program that talks to Oracle. But with Haskell, it seems I need to be able to actually build the Net8 client from source - which, depending on how those sources are written, is likely to require an entire build system (Automake, a VS project, whatever). It's a much bigger undertaking than just compiling the few source file I personally wrote and linking a few bits together. > This is not to say that on a given day it isn't frustrating > when you can't get something to compile, especially > if it's just a tool you need to compile something else. > Oh, hey, I understand why things are like this. You make something work properly on Linux, and with not that much effort you can make it also work for BSD, Mac OS, Solaris, HP UX... even certain embedded devices can potentially run it. You want to make something work on Windows? You have to do everything totally differently. (No wonder people thought that things like Cygwin and MinGW were a good idea.) One of the things that has impressed me about GHC is that it takes Windows seriously. The compiler and interpretter both work flawlessly on Windows. They don't try to teraform Windows into just another Unix, they actually try to do things The Windows Way. I like that. And it's not like all of Hackage is useless to me; anything that's 100% Haskell compiles and installs first time, almost every time. It's just frastrating that all the cool multimedia stuff I'd like to be doing requires access to C, and that's still currently very difficult. I understand not many Haskell people use Windows, so it's not so easy for people to test, and not so many people have a detailed knowledge of Windows. And with this latest discussion, I'm beginning to understand why binding to C is so hard. But, yeah, it *is* still frustrating. ;-) And, unfortunately, I lack the knowledge or skill to be able to improve the situation... > But this is why developers are so wealthy, they have the > fortitude to work through these problems. (Ha ha.) > Heh, good one. ;-) From andrewcoppin at btinternet.com Mon Dec 7 17:00:53 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Dec 7 16:35:11 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> Message-ID: <4B1D7B15.2070208@btinternet.com> John Lato wrote: > To reply to an earlier point of Andrew's (I can't find the quote now, > sorry), one of the biggest difficulties developers face on Windows is > the lack of common install locations/practices. Windows software is > usually distributed as a binary, which may or may not include header > files. These files may be installed in any of numerous locations, > Libraries and > headers are usually not located on the PATH environment variable, and > there's no standard INCDIR or LIBDIR variable either. > Agreed. > While it is Cabal's job to find the location of necessary libraries, > header files, and tools, there simply is no feasible way to do so on > Windows without searching most of the hard drive. > Also agreed. > The only workable approach is to have users specify the > locations of these files, which unfortunately requires more > sophistication than can be expected of most Windows users (and even > some Windows developers). > Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry), or possibly the *developer* package comes as a simple Zip file that you just unzip to wherever you fancy. Just tell the user the URL to grab the Zip file from, unzip it and tell Cabal where the root is now. Shouldn't be too hard. (Famous last words...) The problem, of course, is that, especially if the file layout differs significantly in the Windows version of the library, this is going to absolutely _require_ somebody with a real Windows box and familiarity with Windows to work on the Cabal packaging. (In extreme cases you might even end up needing a completely seperate, Windows-only Cabal file.) Presumably nobody will ever have the time or inclination to construct this. > On a related matter, many packagers resort to using configure-style > configuration setups to assist with binding to C libraries. Cabal is > now sophisticated enough to handle many of these steps (although not > all), however packagers may not have had an opportunity to update > their build process to remove the dependency on "configure". These > packages will continue to require cygwin or mingw for the "configure" > step. > Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it. I gather it's supposed to be Cabal's job to figure this stuff out in Haskell land? > One last wrinkle: many distributors of C libraries do not have Windows > machines available to test, and (understandably) have little interest > in supporting a platform they don't have and aren't familiar with. As > a result, many C libraries are not well supported on Windows and > require somebody familiar with gnu build tools (i.e. gcc, make, and > autoconf) to be usable on Windows *at all*. This means that, as a > Haskell developer wanting to use these libs, you need to use gnu build > tools because you're not just binding to the library, you're > maintaining a Windows port of it. > This seems to be kind of the catch-22. Nobody uses Windows, so there isn't much support for Windows, so we don't attract many Windows users... QED. :-} > C and unix are pretty much designed to work together, and have been > for decades, so I think it's reasonable to expect that Windows is the > side that needs to adapt to support their model. In other words, "Windows needs to become just like Unix". Not going to happen. ;-) Argue about whether this is good or bad amoungst yourselves. But it's not happening. > MS hasn't done so, > which means that C developers would need to unacceptably compromise > unix support in their packages in order to better support Windows. > I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though. > Cross-platform support precludes windows-native solutions, so you're > left making the best of it with Linux tools (mingw and cygwin) on > Windows. > Yeah, it seems for the time being any Haskellers wanting to work on Windows have to choose either to not use external C libraries or to install the entire GNU toolchain. *sigh* From jfredett at gmail.com Mon Dec 7 17:13:59 2009 From: jfredett at gmail.com (Joe Fredette) Date: Mon Dec 7 16:48:27 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <100d01ca7784$ecd968e0$c68c3aa0$@de> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> Message-ID: <87B929E3-6A37-4652-9E5E-E961BFF094C7@gmail.com> Here's a completely naive implementation, it's slow as cold molasses going uphill during a blizzard, but it doesn't seem to be wrong. I let it run in the interpreter for the last 3 minutes or so and it's reproduced the given list up to 126 (and hasn't crapped out yet). I imagine there's probably a less naive algorithm that could be done, but I rather like the straightforwardness of this one... /Joe ---------------------------- module Main where import Control.Monad(filterM) import Data.List(sort) divisors :: Int -> [Int] divisors n = [d | d <- [1..n], n `mod` d == 0] powerset = filterM (const [True, False]) (><) :: Eq a => [a] -> [a] -> [(a,a)] x >< y = [(x', y') | x' <- x, y' <- y, x' /= y'] (/\) :: Eq a => [a] -> [a] -> Bool x /\ y = null $ filter (`elem` x) y prod m n = filter (uncurry (/\)) (m >< n) eqSum :: ([Int], [Int]) -> Bool eqSum (m, n) = sum m == sum n containsAllDivisors i l = filter (\x -> (sort . uncurry (++) $ x) == divisors i) l zumkeller :: Int -> [([Int], [Int])] zumkeller n = containsAllDivisors n . filter eqSum . (\x -> prod x x) $ allParts where divs = divisors n allParts = powerset divs zumkellerP :: Int -> Bool zumkellerP = not . null . zumkeller --------------------------------------- On Dec 7, 2009, at 4:33 PM, Frank Buss wrote: > Anyone interested in writing some lines of Haskell code for > generating the Zumkeller numbers? > > http://www.luschny.de/math/seq/ZumkellerNumbers.html > > My C/C# solutions looks clumsy (but is fast). I think this can be > done much more elegant in Haskell with lazy evaluation. > > Not related to Haskell, but do you think semi-Zumkeller numbers are > semi-perfect numbers? Maybe some Haskell code for testing it for > some numbers? > > -- > Frank Buss, fb@frank-buss.de > http://www.frank-buss.de, http://www.it4-systems.de > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mle+hs at mega-nerd.com Mon Dec 7 17:21:54 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon Dec 7 16:56:23 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4B1D7B15.2070208@btinternet.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> <4B1D7B15.2070208@btinternet.com> Message-ID: <20091208092154.5cbfdcc0.mle+hs@mega-nerd.com> Andrew Coppin wrote: > Well, I don't know. It's going to vary from package to package, but most > things that have a semi-official Windows version either come as a > Windows Installer package (which, one presumes records where it put > everything *somewhere* in the Windows registry) Is that done automatically or does the installer have to explicity set it? What does it look like? The reason I ask is that I release a binary windows installer for libsndfile. The binaries are generated using a Linux to Windows cross-compiler and for the win32 version I run the testsuite under Wine (windows API emulator). I then run INNO Setup under wine to generate the installer executable. > > On a related matter, many packagers resort to using configure-style > > configuration setups to assist with binding to C libraries. Cabal is > > now sophisticated enough to handle many of these steps (although not > > all), however packagers may not have had an opportunity to update > > their build process to remove the dependency on "configure". These > > packages will continue to require cygwin or mingw for the "configure" > > step. > > > > Ah yes, this is pretty much guaranteed to make stuff not work on > Windows. :-) Still, all Unix systems have Automake, configure, etc., so > I guess most people don't even think twice before using it. There are bigger problems than that. The Microsoft compiler still doesn't support large chunks of the 1999 ISO C Standard. There is stuff in that standard that makes my life easier so I use it in libsndfile. Its also why I much prefer to cross compiler from Linux to Windows with a GNU compiler that supports the vast majority of the 1999 ISO C Standard. I would be possible to make libsndfile compile with Microsofts compiler but it would add a whole bunch of #ifdefs all over the place making the code base fragile and in the long term less maintainable and reliable. > > MS hasn't done so, > > which means that C developers would need to unacceptably compromise > > unix support in their packages in order to better support Windows. > > I don't know about that... Lots of commercial and open-source products > are available for Windows and Unix, seemingly without any problem. (GTK, > for example...) I don't deny that adding Windows support is _a lot more > work_ than adding support for just another Unix, though. Ignoring bugs and features that are common across all platforms in libsndfile I have spent at least an order of magnitude more time and effort getting things working with windows that I have with all of the Unixes (including OSX) summed together. This for a platform I don't use. > Yeah, it seems for the time being any Haskellers wanting to work on > Windows have to choose either to not use external C libraries or to > install the entire GNU toolchain. *sigh* If those libraries use parts of the C99 standard then yes. Microsoft has had 10 years to make their compilers compliant. Ask them why they haven't. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From lemming at henning-thielemann.de Mon Dec 7 17:30:01 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 17:04:29 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <100d01ca7784$ecd968e0$c68c3aa0$@de> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> Message-ID: On Mon, 7 Dec 2009, Frank Buss wrote: > Anyone interested in writing some lines of Haskell code for generating > the Zumkeller numbers? > > http://www.luschny.de/math/seq/ZumkellerNumbers.html > > My C/C# solutions looks clumsy (but is fast). I think this can be done > much more elegant in Haskell with lazy evaluation. http://darcs.haskell.org/htam/src/Example/Zumkeller.hs From duane.johnson at gmail.com Mon Dec 7 17:33:26 2009 From: duane.johnson at gmail.com (Duane Johnson) Date: Mon Dec 7 17:07:40 2009 Subject: [Haskell-cafe] Is anyone reading Pattern Calculus by Barry Jay? In-Reply-To: <4d8ad03a0912062241h2c0e8a04y1a71fe25185a52f3@mail.gmail.com> References: <1A26D96F-E122-41F1-A0A8-83945BB1C0A1@gmail.com> <4d8ad03a0912062241h2c0e8a04y1a71fe25185a52f3@mail.gmail.com> Message-ID: <3CF6D47F-426E-4FAC-ACFF-5142B973CB18@gmail.com> Thanks Bernie, I've applied for membership in the forum. I'm grateful that technology can connect me with so distant but interesting a group! Duane On Dec 7, 2009, at 12:41 AM, Bernie Pope wrote: > 2009/12/7 Duane Johnson : >> I just bought a copy of Pattern Calculus [1] by Barry Jay and I >> would like >> to discuss the lambda- and pattern-calculus with anyone who is >> interested. >> Is there anyone else here who is reading the book and would like >> to discuss >> here (if it is appropriate) or take the discussion elsewhere? My >> knowledge >> of types has come primarily through reading this Haskell Cafe list, >> so I am >> by no means an expert. Just a tinkerer :) >> Regards, >> Duane Johnson >> >> [1] http://lambda-the-ultimate.org/node/3695 > > Hi Duane, > > The Melbourne FPU (functional programming union) is interested in > topics like this, and some of us have a copy, or are about to get a > copy of the book. > > http://groups.google.com.au/group/fpunion > > There's already a short thread on the topic - please feel free to sign > up to the group. > > We welcome stimulating discussion. > > Cheers, > Bernie. From ok at cs.otago.ac.nz Mon Dec 7 17:45:33 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 7 17:20:02 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> Message-ID: <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> When I was working at Quintus, I came up with a classification which I can simplify something like this: operating system fault Something bad happened (like a remote node going down) that was entirely out of your control. There is nothing you can do to your program to prevent this. Example: power failure. It's still your problem to clean up on your way out. resource faults your program tried to do something possibly meaningful but the system ran out of some kind of resource (cpu limit, memory limit, disc quota, &c) You might respond to this by increasing the limit and trying again. representation faults your program tried to do something meaningful but the system was unable to represent the result (integer overflow, upper case of ? in a Latin 1 system, floating point overflow on a non-IEEE system, &c) Your program isn't *wrong* but you will still have to change it. existence errors Your program tried to do something with a (typically external) resource that doesn't exist (missing file) Your program could be wrong but probably isn't. You will have to create the resource or provide a different name. permission errors Your program tried to do something to a (typically external but not always) resource that you do not have permission to do (typically writing to a read-only file) You may have named the wrong resource. If not, you may have to get the permissions for the resource changed, or ask someone else to run the program. domain errors A precondition on the input arguments of an operation was not satisfied (e.g., X/0, sqrt(-1), malformed file name, head []). Your program is definitely wrong. postcondition errors Your program invoked some operation and the precondition for the operation was satisfied, but when it completed, the postcondition was not. The operation you invoked is broken. If it's yours, you will have to fix it. If the precondition was not strong enough, it may be your program at fault. Otherwise, until you can get a fix from someone, you will have to program around it. I didn't find a simple error/exception distinction helpful, and still don't. Take the case of trying to write to "/dev/nul". This is a permission error. If the program is responsible for the name being what it is, it's a mistake in the program. If the user typed the name in, it's the user's mistake. You really can't tell without tracing each value to its origin. I dare From chak at cse.unsw.edu.au Mon Dec 7 18:18:40 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Dec 7 17:53:12 2009 Subject: [Haskell-cafe] OpenCL target for DPH? In-Reply-To: <56780.130.55.132.67.1260159059.squirrel@webmail.lanl.gov> References: <56780.130.55.132.67.1260159059.squirrel@webmail.lanl.gov> Message-ID: Marcus Daniels wrote, > I'm wondering if anyone has looked at OpenCL as target for Data Parallel > Haskell? Specifically, having Haskell generate CL kernels, i.e. SIMD > vector type aware C language backend, as opposed to just a Haskell > language binding. The short answer is that there is currently no plan to directly target OpenCL from DPH. (That is the DPH team doesn't have any such plans, but if anybody else wants to give it a shot, the latest, bleeding edge DPH code is always available in the GHC HEAD repository.) The long answer is that we are currently working on two separate data-parallel extensions for Haskell. Data Parallel Haskell ~~~~~~~~~~~~~~~~~~~~~ Here the focus is *expressiveness*. In particular, we support arbitrarily deep, dynamic nesting of dataparallel computations with full support of higher-order functions (ie, parallel arrays of functions are fine). However, to keep the work manageable, we only target multicore CPUs for the moment (using the multi-threading support in GHC's RTS). Data.Array.Accelerate ~~~~~~~~~~~~~~~~~~~~~ Here the focus is on targeting *exotic, high-performance hardware*. We are currently working on a CUDA backend targeting CUDA-capable NVIDIA GPUs, but it shouldn't be too hard to re-target that to OpenCL. Support for the Cell BE and FPGAs appears feasible, too (but we lack local expertise and hardware to write such backends ourselves). However, to keep the work manageable, we only consider regular, multi-dimensional array codes encoded in an embedded DSL where functions are not first-class (ie, we use Haskell's first-class functions to implement the EDSL, but the embedded language is first-order). Longer term future ~~~~~~~~~~~~~~~~~~ At some point, we would of course like to bring the above two projects together, but at the moment, each is already rather challenging just by itself. Manuel From daniel.is.fischer at web.de Mon Dec 7 18:19:31 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Dec 7 17:56:26 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <100d01ca7784$ecd968e0$c68c3aa0$@de> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> Message-ID: <200912080019.31967.daniel.is.fischer@web.de> Am Montag 07 Dezember 2009 22:33:32 schrieb Frank Buss: > Anyone interested in writing some lines of Haskell code for generating the > Zumkeller numbers? > > http://www.luschny.de/math/seq/ZumkellerNumbers.html > > My C/C# solutions looks clumsy (but is fast). I think this can be done much > more elegant in Haskell with lazy evaluation. A fairly naive but not too slow version: --------------------------------------------------------------------------------- module Main (main) where import Data.List (sort) import Control.Monad (liftM2) import System.Environment (getArgs) main = do args <- getArgs let bd = case args of (a:_) -> read a _ -> 1000 mapM_ print $ filter isZumkeller [2 .. bd] trialDivPrime :: [Int] -> Int -> Bool trialDivPrime (p:ps) n = (p*p > n) || (n `mod` p /= 0) && trialDivPrime ps n oprs = 5:7:filter (trialDivPrime oprs) (scanl (+) 11 $ cycle [2,4]) primes :: [Int] primes = 2:3:oprs factors :: Int -> [(Int,Int)] factors n | n < 0 = factors (-n) | n == 0 = [(0,1)] | otherwise = go n primes where go 1 _ = [] go m (p:ps) | p*p > m = [(m,1)] | otherwise = case m `quotRem` p of (q,0) -> case countFactors q p of (m',k) -> (p,k+1):go m' ps _ -> go m ps countFactors :: Int -> Int -> (Int,Int) countFactors n p = go n 0 where go m k = case m `quotRem` p of (q,0) -> go q (k+1) _ -> (m,k) divisors :: Int -> [Int] divisors n = sort $ foldr (liftM2 (*)) [1] ppds where ppds = map (\(p,k) -> take (k+1) $ iterate (*p) 1) $ factors n partition :: Int -> [Int] -> [[Int]] partition 0 _ = [[]] partition n [] = [] partition n (p:ps) | n < p = partition n ps | otherwise = [p:parts | parts <- partition (n-p) ps] ++ partition n ps isZumkeller :: Int -> Bool isZumkeller n | sigma < 2*n = False | odd sigma = False | otherwise = not . null $ partition target candidates where divs = divisors n sigma = sum divs target = (sigma-n) `quot` 2 candidates = reverse $ takeWhile (<= target) divs ---------------------------------------------------------------------------------------------------- Of course, with sieving, you'd be much faster. > > Not related to Haskell, but do you think semi-Zumkeller numbers are > semi-perfect numbers? The site you linked to says so. I've not investigated. > Maybe some Haskell code for testing it for some numbers? From waldmann at imn.htwk-leipzig.de Mon Dec 7 18:23:18 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Dec 7 17:57:46 2009 Subject: [Haskell-cafe] SmallCheck design question Message-ID: <4B1D8E66.4040202@imn.htwk-leipzig.de> referring to the Serial instances in http://hackage.haskell.org/package/smallcheck : the idea is that series d gives all objects of depth <= d. depth of a term from an algebraic data type is the standard "depth" concept for trees (maximum nesting of constructors = longest path from root to node) 1. why are the tuple constructors treated differently? I'd expect depth (x,y) = succ $ max (depth x) (depth y) but the succ is missing. 2. why depth and not size (= total number of constructors)? it seems that the number of objects (trees) of given depth rises much more drastically than number of trees of given size. just wondering - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/191a5185/signature.bin From ben.franksen at online.de Mon Dec 7 18:25:34 2009 From: ben.franksen at online.de (Ben Franksen) Date: Mon Dec 7 18:00:27 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> <29bf512f0912071159m78284e83v61a6d1b2fb0ebd93@mail.gmail.com> Message-ID: Michael Snoyman wrote: > On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < > lemming@henning-thielemann.de> wrote: >> On Mon, 7 Dec 2009, Michael Snoyman wrote: >> I also think that in an earlier mail I answered, that errors can leave >> you with corrupt data, say invalid file handles, memory pointers, or data >> structures that violate invariants. You won't like to close files from >> invalid file handles and free memory from corrupt pointers or run into >> infinite loops by traversing the corrupt data structures. That's the >> reason why it is better to stop execution of the program and hand over >> control to the next higher level, say the shell or the web browser, that >> can free resources safely. >> > Firstly: I'm really referring exclusively to non-FFI Haskell programs, to > which most of the issues you mention don't really apply. Nonetheless, I > think that for a language with exceptions, it still makes sense to use the > exceptions in these cases. > > In all these cases, I think the correct thing is to have a specific > exception type that is thrown that signals that it is such an > unrecoverable error. This allows the programmer to do *whatever* they > want. Perhaps they want to save some other data to a file before exiting? > Perhaps they want to spawn a process to send in a bug report? Who knows. > It doesn't matter. The point is, the user *might* want to do something, > and exceptions let them do it if they wish, or they can completely ignore > that specific exception type and let the program crash anyway. Michael, Henning There are two meanings to the word 'exception' in this context; both of you tend to conflate these different meanings. One meaning is about a *mechanism* for non-local control flow; the other is about certain classes of un-desired program conditions. Michael, you are above arguing that it is ok to use the same /mechanism/ to signal errors and exceptions. That is ok with me. There are certainly good use cases, you have presented a few. However, that does not mean it is 'silly' or 'unnecessary' to distinguish between program(-mer) errors and other kinds of expected exceptional conditions in general, as you claimed in a previous message. I agree with Henning insofar as I think it is important to make the *conceptual* distinction -- regardless of whether we use the same mechanism to signal (and, perhaps, after serious consideration, handle) them. So, maybe it would help if we could agree to use different terms for those two meanings of the word 'exception'. I think 'exception' is too strongly associated with the non-local control flow mechanism to introduce a new word for it. Henning, what about calling an undesired but expected condition a 'failure' instead of an exception, so we could reserve this word for the language mechanism? Calling something a 'failure' in this sense (i.e. in contrast to 'error') would always include some judgement, as it needs to take the different program levels into account. Cheers Ben From lemming at henning-thielemann.de Mon Dec 7 18:28:40 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 18:03:08 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> Message-ID: On Tue, 8 Dec 2009, Richard O'Keefe wrote: > When I was working at Quintus, I came up with a classification > which I can simplify something like this: It's certainly possible to classify errors and exceptions in other (also more fine grained) ways ... > operating system fault > Something bad happened (like a remote node going down) that was > entirely out of your control. There is nothing you can do to > your program to prevent this. Example: power failure. It's > still your problem to clean up on your way out. This is an exception. Of course, if the machine your program runs on goes out of power, then neither exception handling nor debugging will help. > resource faults > your program tried to do something possibly meaningful but > the system ran out of some kind of resource (cpu limit, > memory limit, disc quota, &c) > > You might respond to this by increasing the limit and trying > again. An exception. > representation faults > your program tried to do something meaningful but the system > was unable to represent the result (integer overflow, upper > case of ? in a Latin 1 system, floating point overflow on a > non-IEEE system, &c) > > Your program isn't *wrong* but you will still have to change it. It is the responsibility of the programmer to choose number types that are appropriate for the application. If I address pixels on a todays screen I will have to choose at least Word16. On 8-bit computers bytes were enough. Thus, this sounds like an error. > existence errors > Your program tried to do something with a (typically external) > resource that doesn't exist (missing file) > > Your program could be wrong but probably isn't. > You will have to create the resource or provide a different name. Exception > permission errors > Your program tried to do something to a (typically external but > not always) resource that you do not have permission to do > (typically writing to a read-only file) > > You may have named the wrong resource. If not, you may have to > get the permissions for the resource changed, or ask someone > else to run the program. Exception > domain errors > A precondition on the input arguments of an operation was not > satisfied (e.g., X/0, sqrt(-1), malformed file name, head []). > > Your program is definitely wrong. X/0, sqrt(-1), head [] are errors Malformed constant file name in your program is an error but it will raise an exception. The fix is to correct the filename, but you will still need the exception handling, since also the file with the correct name might not exist. > postcondition errors > Your program invoked some operation and the precondition for > the operation was satisfied, but when it completed, the > postcondition was not. > > The operation you invoked is broken. If it's yours, you will > have to fix it. If the precondition was not strong enough, > it may be your program at fault. Otherwise, until you can > get a fix from someone, you will have to program around it. This is an error. > Take the case of trying to write to "/dev/nul". This is a permission > error. If the program is responsible for the name being what it is, > it's a mistake in the program. If the user typed the name in, it's > the user's mistake. You really can't tell without tracing each value > to its origin. Sure, the distinction exception/error depends on the source of the data that causes problems. From ok at cs.otago.ac.nz Mon Dec 7 18:33:48 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 7 18:08:20 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <100d01ca7784$ecd968e0$c68c3aa0$@de> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> Message-ID: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> On Dec 8, 2009, at 10:33 AM, Frank Buss wrote: > Anyone interested in writing some lines of Haskell code for > generating the Zumkeller numbers? > > http://www.luschny.de/math/seq/ZumkellerNumbers.html These lines of Haskell code find the Zumkeller numbers up to 5000 in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took 1.1 seconds. Note that this just finds whether a suitable partition exists; it does not report the partition. factors :: Int -> [Int] factors n = [m | m <- [1..n], mod n m == 0] can_part :: [Int] -> Int -> Bool can_part _ 0 = True can_part xs t = loop xs [] where loop [] _ = False loop (x:xs) ys = x <= t && can_part (xs++ys) (t-x) || loop xs ys is_Zumkeller :: Int -> Bool is_Zumkeller n = let facs = factors n fsum = sum facs in mod fsum 2 == 0 && can_part facs (div fsum 2) main = print (filter is_Zumkeller [1..5000]) From robgreayer at gmail.com Mon Dec 7 18:44:16 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Mon Dec 7 18:18:43 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4B1D7598.1020403@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> <4B1D7598.1020403@btinternet.com> Message-ID: <4ec472cb0912071544t21df549aj7e3c15d70377f49@mail.gmail.com> On Mon, Dec 7, 2009 at 4:37 PM, Andrew Coppin wrote: > > And I have no problem with needing to install a Haskell compiler. If I had > to install a seperate C compiler to make FFI to C work, that wouldn't seem > unreasonable either. (As it happens, GHC has a C backend, so the C compiler > just happens to be there already.) What does seem very weird is having to > turn my Windows box into a psuedo-Unix system in order to write native > Windows programs. > > > > You can't develop anything with just what's preinstalled. (Well, unless you > could writing batch scripts...) > > Generally, if you want to develop C or C++ applications on Windows, you > install MS Visual Studio. It gives you the compiler, linker, dependency > management, and a whole bunch of other stuff. You typically wouldn't install > gcc, ld and Automake. (Unless of course you were specifically trying to port > existing Unix code, obviously.) > > It helps, I believe, if you stop thinking of MinGW with MSYS as 'a pseudo-Unix system'. They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix). The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio. I think that it makes sense that open source software developers targeting multiple platforms would want to pick a tool suite that works across all those platforms, and the GNU tools fit that description. Cygwin truly is a Unix emulation, but MinGW/MSYS is just a packaging of useful open source (GNU) tools for Windows (including a shell). Many programs that work well as native Windows apps, such as the GIMP, are built with them. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091207/868c7ae5/attachment.html From fb at frank-buss.de Mon Dec 7 18:45:11 2009 From: fb at frank-buss.de (Frank Buss) Date: Mon Dec 7 18:19:23 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <200912080019.31967.daniel.is.fischer@web.de> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> <200912080019.31967.daniel.is.fischer@web.de> Message-ID: <10b201ca7797$51397ed0$f3ac7c70$@de> > From: daniel.is.fischer@web.de [mailto:daniel.is.fischer@web.de] > > Not related to Haskell, but do you think semi-Zumkeller numbers are > > semi-perfect numbers? > > The site you linked to says so. I've not investigated. Peter Luschny posted the link in a discussion in a German newsgroup: http://tinyurl.com/y9kfdpf Currently it is a conjecture and needs a proof before posting it to Sloane's integer sequences archive. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de From fb at frank-buss.de Mon Dec 7 18:45:22 2009 From: fb at frank-buss.de (Frank Buss) Date: Mon Dec 7 18:19:42 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> Message-ID: <10b301ca7797$578bfec0$06a3fc40$@de> > From: Richard O'Keefe [mailto:ok@cs.otago.ac.nz] > > These lines of Haskell code find the Zumkeller numbers up to 5000 > in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took > 1.1 seconds. Note that this just finds whether a suitable > partition exists; it does not report the partition. > > factors :: Int -> [Int] > > factors n = [m | m <- [1..n], mod n m == 0] > > can_part :: [Int] -> Int -> Bool > > can_part _ 0 = True > can_part xs t = loop xs [] > where loop [] _ = False > loop (x:xs) ys = x <= t && can_part (xs++ys) (t-x) > || loop xs ys > > is_Zumkeller :: Int -> Bool > is_Zumkeller n = > let facs = factors n > fsum = sum facs > in mod fsum 2 == 0 && > can_part facs (div fsum 2) > > main = print (filter is_Zumkeller [1..5000]) Thanks, I like this solution! Pure functional, easy to understand, no monads and fast :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de From ok at cs.otago.ac.nz Mon Dec 7 18:50:07 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 7 18:24:39 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4B1D7B15.2070208@btinternet.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> <4B1D7B15.2070208@btinternet.com> Message-ID: <52A0B1DB-9DF5-49C6-A81D-E74F83ACB7D3@cs.otago.ac.nz> On Dec 8, 2009, at 11:00 AM, Andrew Coppin wrote: >> > > In other words, "Windows needs to become just like Unix". Not going > to happen. I have the use of a dual-boot MacOS/Vista laptop. "Subsystem for Unix-based applications" is a Microsoft download. It means I can compile C programs using 'cc' or 'c89', and yep, it's VS behind that curtain. It's an alternative to MinGW or CygWin that might be worth exploring. Visual Studio remains a separate product, but SUA is free. From ok at cs.otago.ac.nz Mon Dec 7 18:59:18 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 7 18:33:45 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> Message-ID: <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote: >> representation faults >> your program tried to do something meaningful but the system >> was unable to represent the result (integer overflow, upper >> case of ? in a Latin 1 system, floating point overflow on a >> non-IEEE system, &c) >> >> Your program isn't *wrong* but you will still have to change it. > > It is the responsibility of the programmer to choose number types > that are appropriate for the application. If I address pixels on a > todays screen I will have to choose at least Word16. On 8-bit > computers bytes were enough. Thus, this sounds like an error. That kind of attitude might have done very well in the 1960s. In an age when Intel have demonstrated 48 full x86 cores on a single chip, when it's possible to get a single-chip "DSP" with >240 cores that's fast enough to *calculate* MHz radio signals in real time, typical machine-oriented integer sizes run out _really_ fast. For example, a simple counting loop runs out in well under a second using 32-bit integers. The programmer doesn't always have the information necessary to choose machine-oriented integer sizes. Or it might not offer a choice. Or the choice the programmer needs might not be available: if I want to compute sums of products of 64-bit integers, where are the 128-bit integers I need? > >> domain errors >> A precondition on the input arguments of an operation was not >> satisfied (e.g., X/0, sqrt(-1), malformed file name, head []). >> >> Your program is definitely wrong. > > X/0, sqrt(-1), head [] are errors It depends on WHERE THE DATA CAME FROM. >> > > Sure, the distinction exception/error depends on the source of the > data that causes problems. And sadly, the library does not know this, so the library cannot classify problems _that_ way. From lemming at henning-thielemann.de Mon Dec 7 19:00:54 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 18:35:21 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> <29bf512f0912071159m78284e83v61a6d1b2fb0ebd93@mail.gmail.com> Message-ID: On Tue, 8 Dec 2009, Ben Franksen wrote: > Michael, Henning > > There are two meanings to the word 'exception' in this context; both of you > tend to conflate these different meanings. One meaning is about a > *mechanism* for non-local control flow; the other is about certain classes > of un-desired program conditions. > > Michael, you are above arguing that it is ok to use the same /mechanism/ to > signal errors and exceptions. That is ok with me. I'm actually arguing that errors and exceptions (or failures) should not be treated the same way. This is my opinion because 1. You cannot catch all kinds of errors (infinite loops, memory corruption, and so on) at run-time 2. The program cannot help itself if it is buggy. The next higher level in the software hierarchy certainly can, but this requires obviously a different mechanism. The correct treatment of those things is in my opion: 1. Errors must be fixed by the programmer 2. Exceptions must be appreciated by the programmer and handled by the program at runtime > So, maybe it would help if we could agree to use different terms for those > two meanings of the word 'exception'. I think 'exception' is too strongly > associated with the non-local control flow mechanism to introduce a new > word for it. I used the term "exception" because this is the term used for the concept of handling "file not found", "could not allocate resource" in the introduction to modern languages that I have read. Thus my impression was that "exception" is the term for the concept, whereas there are different implementations and ways of handling them. For instance in Modula-3 the EXIT statement is called an exception that escapes the LOOP structure, but it cannot be catched with TRY, that is used for user defined exceptions. http://www.cs.purdue.edu/homes/hosking/m3/reference/exit.html In Modula-3 a detected error (range violation, NIL dereference, division by zero) terminates the program. An undetected error (which is restricted to UNSAFE modules) can cause memory corruption and all those bad things, and cannot be handled in any way. Before exceptions got a special handling in programming language, they still existed. In C for instance they were expressed by return codes. The Wikipedia author also seem to consider "exception" to be the term for the concept, not for the implementation: http://en.wikipedia.org/wiki/Exception_handling "Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution." From mle+hs at mega-nerd.com Mon Dec 7 19:01:10 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon Dec 7 18:35:39 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4ec472cb0912071544t21df549aj7e3c15d70377f49@mail.gmail.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> <4B1D7598.1020403@btinternet.com> <4ec472cb0912071544t21df549aj7e3c15d70377f49@mail.gmail.com> Message-ID: <20091208110110.6efc5dcd.mle+hs@mega-nerd.com> Robert Greayer wrote: > It helps, I believe, if you stop thinking of MinGW with MSYS as 'a > pseudo-Unix system'. They're billed as the minimal toolset required on > windows to use the GNU compilers and build system (and, as everybody knows, > Gnu's not Unix). The great thing about these compilers is that they're > cross-platform and freely available, unlike MS Visual Studio. These compilers are mostly C99 compliant, also unlike MS Visual Studio. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From lemming at henning-thielemann.de Mon Dec 7 19:07:30 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 18:41:56 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> Message-ID: On Tue, 8 Dec 2009, Richard O'Keefe wrote: > is_Zumkeller :: Int -> Bool > is_Zumkeller n = > let facs = factors n > fsum = sum facs > in mod fsum 2 == 0 && I see this test is essential. I didn't do it and thus my program did not find that 1800 is not a Zumkeller number within an hour. With this check my program becomes dramatically faster. > can_part facs (div fsum 2) > > main = print (filter is_Zumkeller [1..5000]) From lemming at henning-thielemann.de Mon Dec 7 19:15:50 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 18:52:43 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> Message-ID: On Tue, 8 Dec 2009, Richard O'Keefe wrote: >> X/0, sqrt(-1), head [] are errors > > It depends on WHERE THE DATA CAME FROM. If your program actually computes X/0 or sqrt(-1) or head [] your program is buggy, independent from where the zero, the minus one or the empty list comes. >> Sure, the distinction exception/error depends on the source of the data >> that causes problems. > > And sadly, the library does not know this, so the library cannot classify > problems _that_ way. To this end the library documentation says: "Precondition: This function must only be called on non-empty lists." If the programmer calls it with an empty list anyway, it's his fault. The library user made the error then. Of course it would be better, if types or contracts could force such restrictions: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068877.html From lemming at henning-thielemann.de Mon Dec 7 19:27:13 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 7 19:01:41 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> Message-ID: On Tue, 8 Dec 2009, Richard O'Keefe wrote: > On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote: >> >> It is the responsibility of the programmer to choose number types that are >> appropriate for the application. If I address pixels on a todays screen I >> will have to choose at least Word16. On 8-bit computers bytes were enough. >> Thus, this sounds like an error. > > That kind of attitude might have done very well in the 1960s. I don't quite understand. If it is not the responsibility of the programmer to choose numbers of the right size, who else? If the operating system uses Int32 for describing files sizes and Int16 for screen coordinates, I'm safe to do so as well. The interface to the operating system could use type synonyms FileSize and ScreenCoordinate that scale with future sizes. But the programmer remains responsible for using ScreenCoordinate actually for coordinates and not for file sizes. > In an age when Intel have demonstrated 48 full x86 cores on a single > chip, when it's possible to get a single-chip "DSP" with >240 cores > that's fast enough to *calculate* MHz radio signals in real time, > typical machine-oriented integer sizes run out _really_ fast. > For example, a simple counting loop runs out in well under a second > using 32-bit integers. > > The programmer doesn't always have the information necessary to > choose machine-oriented integer sizes. Or it might not offer a choice. > Or the choice the programmer needs might not be available: if I want > to compute sums of products of 64-bit integers, where are the 128-bit > integers I need? And the consequence is to ship a program that raises an exception about problems with the size of integers? I'm afraid I don't understand what you are arguing for. From ajb at spamcop.net Mon Dec 7 19:54:12 2009 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon Dec 7 19:28:44 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> Message-ID: <20091207195412.l6abiz7nk0woos48-nwo@webmail.spamcop.net> G'day all. Quoting Richard O'Keefe : > These lines of Haskell code find the Zumkeller numbers up to 5000 > in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took > 1.1 seconds. Note that this just finds whether a suitable > partition exists; it does not report the partition. This takes 0.1 seconds on a 2GHz Dell running Linux: module Main where import Control.Monad import qualified Data.List as L primesUpTo :: Integer -> [Integer] primesUpTo n | n < 13 = takeWhile (<= n) [2,3,5,11] | otherwise = takeWhile (<= n) primes where primes = 2 : 3 : sieve 0 (tail primes) 5 sieve k (p:ps) x = let fs = take k (tail primes) in [x | x<-[x,x+2..p*p-2], and [x `rem` p /= 0 | p<-fs] ] ++ sieve (k+1) ps (p*p+2) pseudoPrimesUpTo :: Integer -> [Integer] pseudoPrimesUpTo n | n <= wheelModulus = takeWhile (<= n) smallPrimes | otherwise = smallPrimes ++ pseudoPrimesUpTo' wheelModulus where largestSmallPrime = 11 verySmallPrimes = primesUpTo largestSmallPrime wheelModulus = product verySmallPrimes smallPrimes = primesUpTo wheelModulus wheel = mkWheel 1 [1] verySmallPrimes mkWheel _ rs [] = rs mkWheel n rs (p:ps) = mkWheel (p*n) (do k <- [0..p-1] r <- rs let r' = n*k + r guard (r' `mod` p /= 0) return r') ps pseudoPrimesUpTo' base | n <= base + wheelModulus = takeWhile (<= n) . map (+base) $ wheel | otherwise = map (+base) wheel ++ pseudoPrimesUpTo' (base + wheelModulus) -- Integer square root. isqrt :: Integer -> Integer isqrt n | n < 0 = error "isqrt" | otherwise = isqrt' ((n+1) `div` 2) where isqrt' s | s*s <= n && n < (s+1)*(s+1) = s | otherwise = isqrt' ((s + (n `div` s)) `div` 2) -- Compute the prime factorisation of an integer. factor :: Integer -> [Integer] factor n | n <= 0 = error "factor" | n <= primeCutoff = factor' n (primesUpTo primeCutoff) | otherwise = factor' n (pseudoPrimesUpTo (isqrt n)) where primeCutoff = 1000000 factor' 1 _ = [] factor' n [] = [n] factor' n (p:ps) | n `mod` p == 0 = p : factor' (n `div` p) (p:ps) | otherwise = factor' n ps -- The only function used from above is "factor". zumkeller :: Integer -> Bool zumkeller n | isPrime = False | isPrime = False | sigma `mod` 2 == 1 = False | sigma < 2*n = False | otherwise = sigmaTest ((sigma - 2*n) `div` 2) (factors n) where isPrime = case factorn of [_] -> True _ -> False factorn = factor n sigma = product . map (sum . scanl (*) 1) . L.group $ factorn factors n = reverse [ f | f <- [1..n `div` 2], n `mod` f == 0 ] sigmaTest 0 _ = True sigmaTest _ [] = False sigmaTest n (f:fs) | f > n = sigmaTest n fs | otherwise = sigmaTest (n-f) fs || sigmaTest n fs main = print (filter zumkeller [1..5000]) Yes, I cheated by using a different algorithm. Cheers, Andrew Bromage From ok at cs.otago.ac.nz Mon Dec 7 20:09:40 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 7 19:44:12 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> Message-ID: <67536F5D-677A-4D4C-A40A-64A266EB6755@cs.otago.ac.nz> On Dec 8, 2009, at 1:27 PM, Henning Thielemann wrote: > > On Tue, 8 Dec 2009, Richard O'Keefe wrote: > >> On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote: >>> It is the responsibility of the programmer to choose number types >>> that are appropriate for the application. If I address pixels on a >>> todays screen I will have to choose at least Word16. On 8-bit >>> computers bytes were enough. Thus, this sounds like an error. >> >> That kind of attitude might have done very well in the 1960s. > > I don't quite understand. If it is not the responsibility of the > programmer to choose numbers of the right size, who else? It is the responsibility of the computer to support the numbers that the programmer needs. It is the responsibility of the computer to compute CORRECTLY with the numbers that it claims to support. I repeat: the programmer might not KNOW what the integer sizes are. In Classic C and C89, the size of an 'int' was whatever the compiler chose to give you. In c89, limits.h means that the program can find out at run time what range it got, but that's too late. > > > If the operating system uses Int32 for describing files sizes and > Int16 for screen coordinates, I'm safe to do so as well. In a very trivial sense, this is true. In any less trivial sense, not hardly. Suppose I am calculating screen coordinates using / x \ / a11 a12 a13 \ / u \ | y | = | a21 a22 a23 | | v | \ 1 / \ 0 0 1 / \ 1 / which is a fairly standard kind of transformation, it is not in general sufficient that u, v, x, and y should all fit into Int16. The intermediate results must _also_ fit. (Assume for the moment that overflow is checked.) If I need to represent *differences* of Int32 pairs, I know perfectly well what type I need: Int33. But there is no such type. > The interface to the operating system could use type synonyms > FileSize and ScreenCoordinate that scale with future sizes. But the > programmer remains responsible for using ScreenCoordinate actually > for coordinates and not for file sizes. Consider this problem: We are given a whole bunch of files, and want to determine the total space used by all of them. Smalltalk: fileNames detectSum: [:each | (FileStatus fromFile: each) size] The answer is correct, however many file names there are in the collection. But if we're using C, or Pascal, or something like that, we want to do FileCollectionSize fcs = 0; for (i = 0; i < n; i++) { fcs += OS_File_System_Size(filename[i]); } and how on earth do we compute the type FileCollectionSize? Remember, it has to be big enough to hold the sum of the sizes of an *unknown* and quite possibly large number of quite possibly extremely large files, not necessarily confined to a single disc, so the total could well exceed what will fit in FileSize. This is especially so when you realise that there might be many repetitions of the same file names. I can _easily_ set this up to overflow 64 bits on a modern machine. In Haskell, you'd want to switch straight over to Integer and stay there. >> In an age when Intel have demonstrated 48 full x86 cores on a single >> chip, when it's possible to get a single-chip "DSP" with >240 cores >> that's fast enough to *calculate* MHz radio signals in real time, >> typical machine-oriented integer sizes run out _really_ fast. >> For example, a simple counting loop runs out in well under a second >> using 32-bit integers. >> >> The programmer doesn't always have the information necessary to >> choose machine-oriented integer sizes. Or it might not offer a >> choice. >> Or the choice the programmer needs might not be available: if I want >> to compute sums of products of 64-bit integers, where are the 128-bit >> integers I need? > > And the consequence is to ship a program that raises an exception > about problems with the size of integers? Yes. Just because the programmer has TRIED to ensure that all the numbers will fit into the computer's arbitrary and application- irrelevant limits doesn't mean s/he succeeded. For that matter, it doesn't mean that the compiler won't use an optimisation that breaks the program. (Yes, I have known this happen, with integer arithmetic, and recently.) > I'm afraid I don't understand what you are arguing for. I'm arguing for three things. (1) If you look at the CERT web site, you'll discover that there have been enough security breaches due to integer overflow that they recommend working very hard to prevent it, and there's an "As If Ranged" project to enable writing C _as if_ it could be trusted to raise exceptions about problems with the size of integers. It is better to raise an exception than to let organised crime take over your computer. (2) In a language like Ada where the programmer can *say* exactly what range they need, and the bounds can be computed at compile time, and the compiler either does it right or admits right away that it can't, it's the programmer's fault if it's wrong. Otherwise it isn't. (3) Be very worried any time you multiply or divide integers. (INT_MIN / (-1) is an overflow, C is allowed to treat INT_MIN % (-1) as undefined even though it is mathematically 0.) No, make that "be terrified". If you cannot formally verify that results will be in range, use Haskell's Integer type. From ml.nwgreen at gmail.com Mon Dec 7 20:11:45 2009 From: ml.nwgreen at gmail.com (drostin77) Date: Mon Dec 7 19:46:10 2009 Subject: [Haskell-cafe] Hayoo and Hoogle (beginner question) In-Reply-To: <404396ef0912070431m51f5daecn275385716ef7444@mail.gmail.com> References: <26669924.post@talk.nabble.com> <404396ef0912070431m51f5daecn275385716ef7444@mail.gmail.com> Message-ID: <26687210.post@talk.nabble.com> Thanks for all the answers, in particular the history (quoted) was informative! So for now the answer is indeed probably to use both, starting with Hoogle if I am searching by type. And if you do find that old hayoo command line search script yes please :P (esp the offline one, I do so much studying on airplanes that even if I couldn't download the package knowing I didn't need to build it myself would be great)! If I get irked enough at the browser to hack together a wget/cut/grep (or-dare-i-say-ruby) script to search hayoo from bash I will post it somewhere haskelly! Neil Mitchell wrote: > > Hi, > > It probably helps to know some of the history, as it explains a lot of > what you see today. Hoogle was written first (about 5 years ago now), > before there was hackage (so it doesn't search hackage), and with an > emphasis on type search (as that's cool). Hayoo came a lot later > (about 2 years ago at most). Hoogle will be gaining the ability to do > a full search of Hackage - I'm just waiting to get some bits sorted > out first. There isn't really a technical obstacle, I've just not had > the time to finish the implementation. > > Use whichever you choose, but if you use Hayoo for some reason other > than Hoogle not searching all packages, I'd love to know. > > Thanks, Neil > > 2009/12/7 drostin77 : >> >> Hello Hopefully Helpful Haskell Community! >> >> (I really wanted that to be alliteration... couldn't come up with an h >> word >> for community) >> >> ?I've just started learning Haskell (working my way through "Real World >> Haskell" and really liking it)! ?I have started to appreciate that there >> are >> a lot of Haskell libraries I will want to search and access quite >> regularly >> when I work on Haskell projects, so I had the following questions: >> >> 1. ?Hoogle and Hayoo: ?I'm a bit confused by the difference here. ?From >> initial impressions it seems that Hayoo is linked to Hackage, but Hoogle >> is >> not? ?And it seems that Hayoo is, well, "Similar to Hoogle, but with less >> focus on type search." ?Should I check both of these when I want a >> library, >> or choose one and go with it...? ?Or is it indeed better to search Hayoo >> when I'm thinking of a named library and Hoogle when I think I know the >> type >> signature for just the function I need? >> >> 2. ?I much prefer a command line search interface to a browser, I see >> Hoogle >> offers such a tool, does Hayoo? >> >> P.S. ?If these questions are in the wrong place, or if they are already >> answered in detail somewhere that my Googling didn't find please feel >> free >> to paste a link and tell me to search better next time! >> -- >> View this message in context: >> http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26669924.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > > -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26687210.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From daniel.is.fischer at web.de Mon Dec 7 20:22:59 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Dec 7 19:58:55 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <20091207195412.l6abiz7nk0woos48-nwo@webmail.spamcop.net> References: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> <20091207195412.l6abiz7nk0woos48-nwo@webmail.spamcop.net> Message-ID: <200912080222.59345.daniel.is.fischer@web.de> Am Dienstag 08 Dezember 2009 01:54:12 schrieb ajb@spamcop.net: > G'day all. > > Quoting Richard O'Keefe : > > These lines of Haskell code find the Zumkeller numbers up to 5000 > > in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took > > 1.1 seconds. Note that this just finds whether a suitable > > partition exists; it does not report the partition. > > This takes 0.1 seconds on a 2GHz Dell running Linux: > > Yes, I cheated by using a different algorithm. > > Cheers, > Andrew Bromage Yes, what I do (after fixing an embarrassing typo from the first post). Using Int, it's a little faster, with Integer the same time. I've now added the printout of one partition. module Main (main) where import Data.List (sort) import Control.Monad (liftM2) import System.Environment (getArgs) main = do args <- getArgs let bd = case args of (a:_) -> read a _ -> 4000 mapM_ (\n -> case zumParts n of [] -> return () ((l,r):_) -> putStrLn (show n ++ " " ++ show l ++ " " ++ show r)) [1 .. bd] trialDivPrime :: [Int] -> Int -> Bool trialDivPrime (p:ps) n = (p*p > n) || (n `mod` p /= 0) && trialDivPrime ps n oprs = 5:7:filter (trialDivPrime oprs) (scanl (+) 11 $ cycle [2,4]) primes :: [Int] primes = 2:3:oprs factors :: Int -> [(Int,Int)] factors n | n < 0 = factors (-n) | n == 0 = [(0,1)] | otherwise = go n primes where go 1 _ = [] go m (p:ps) | p*p > m = [(m,1)] | otherwise = case m `quotRem` p of (q,0) -> case countFactors q p of (m',k) -> (p,k+1):go m' ps _ -> go m ps countFactors :: Int -> Int -> (Int,Int) countFactors n p = go n 0 where go m k = case m `quotRem` p of (q,0) -> go q (k+1) _ -> (m,k) divisors :: Int -> [Int] divisors n = sort $ foldr (liftM2 (*)) [1] ppds where ppds = map (\(p,k) -> take (k+1) $ iterate (*p) 1) $ factors n partition :: Int -> [Int] -> [[Int]] partition 0 _ = [[]] partition n [] = [] partition n (p:ps) | n < p = partition n ps | otherwise = [p:parts | parts <- partition (n-p) ps] ++ partition n ps zumParts :: Int -> [([Int],[Int])] zumParts n | sigma < 2*n = [] | odd sigma = [] | otherwise = [(prt ++ [n],init divs `without` prt) | prt <- prts] where divs = divisors n sigma = sum divs target = (sigma-2*n) `quot` 2 sml = takeWhile (<= target) $ init divs prts = map reverse $ partition target (reverse sml) xxs@(x:xs) `without` yys@(y:ys) | x < y = x:xs `without` yys | x == y = xs `without` ys | otherwise = xxs `without` ys xs `without` _ = xs From donn at avvanta.com Mon Dec 7 20:33:59 2009 From: donn at avvanta.com (Donn Cave) Date: Mon Dec 7 20:08:24 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912051423safd7842ka39c8b8b6dee1ac0@mail.gmail.com> <29bf512f0912051500h2199ee0ds8e6a3947353fab46@mail.gmail.com> <29bf512f0912062104p2ce37d03i98adee1c144aeacc@mail.gmail.com> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <71B9F60A-D4AA-4D1C-A631-191922A14691@cs.otago.ac.nz> <354D93D1-2AAB-4E7B-97A9-2571AD485785@cs.otago.ac.nz> Message-ID: <20091208013359.7374E276C50@mail.avvanta.com> I'm wondering, what are we talking about here? - the meaning of "error" and "exception"? - personal responsibility when writing programs? - language features - library functions, runtime implementation etc.? The first two, I think could serve as the basis for an entertaining discussion. Where the third applies, if there are real disagreements it would be helpful to frame the discussion at least partly in those terms, so anyone who has a practical interest in the matter may understand what's being discussed. In my view, the discussion so far has shown that while everyone has interesting and valuable opinions about how various contingencies ought to be handled, in the end it no doubt it must be up to the programmer writing the code ... right? Donn Cave, donn@avvanta.com From magicloud.magiclouds at gmail.com Mon Dec 7 21:22:44 2009 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon Dec 7 20:57:11 2009 Subject: [Haskell-cafe] How to deal with C buf in Haskell? Message-ID: <3bd412d40912071822v52562a01u563def2aa744bf6b@mail.gmail.com> Hi, I am warping some C libs. In one function, I do this: 183 allocaBytes bufLen $ \buf -> do 184 ret <- {# call buf_read #} 185 bluh 186 bala 187 buf 188 bufLen 189 if ret < 0 190 then userError "bufRead error" 191 else -- what should I do here? I am thinking about bytestring, to pass the content of the buf to the outside of the function. But I am not sure. What should I do? -- ??????? ??????? From v.dijk.bas at gmail.com Mon Dec 7 22:41:44 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon Dec 7 22:16:10 2009 Subject: [Haskell-cafe] How to deal with C buf in Haskell? In-Reply-To: <3bd412d40912071822v52562a01u563def2aa744bf6b@mail.gmail.com> References: <3bd412d40912071822v52562a01u563def2aa744bf6b@mail.gmail.com> Message-ID: On Tue, Dec 8, 2009 at 3:22 AM, Magicloud Magiclouds wrote: > Hi, > ?I am warping some C libs. In one function, I do this: > 183 ?allocaBytes bufLen $ \buf -> do > 184 ? ?ret <- {# call buf_read #} > 185 ? ? ?bluh > 186 ? ? ?bala > 187 ? ? ?buf > 188 ? ? ?bufLen > 189 ? ?if ret < 0 > 190 ? ? ?then userError "bufRead error" > 191 ? ? ?else -- what should I do here? > > ?I am thinking about bytestring, to pass the content of the buf to > the outside of the function. But I am not sure. > ?What should I do? See: Data.ByteString.Internal.createAndTrim: http://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString-Internal.html#v:createAndTrim With that your program becomes something like: createAndTrim bufLen $ \buf -> ret <- {# call buf_read #} bluh bala buf bufLen if ret < 0 then userError "bufRead error" else return ret -- if ret indicates the number of bytes read regards, Bas From v.dijk.bas at gmail.com Mon Dec 7 22:54:44 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon Dec 7 22:29:10 2009 Subject: [Haskell-cafe] Handles with their IOMode in their type Message-ID: Could not get to sleep tonight so I got up and hacked this together: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 Does something like this already exist on hackage: If not, I may turn this into a package and upload it tomorrow. Comments, criticism and patches are welcome. regards, Bas From wren at freegeek.org Mon Dec 7 23:49:45 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Dec 7 23:18:43 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: <1260215701-sup-7631@peray> References: <1260215701-sup-7631@peray> Message-ID: <4B1DDAE9.1090605@freegeek.org> Nicolas Pouillard wrote: > Excerpts from Henning Thielemann's message of Mon Dec 07 20:36:27 +0100 2009: >> @Apfelmus: >> >> For practical purposes I think Train should have swapped type parameters >> in order to make Functor act on the type of the list elements. >> >> >> data Train b a = Wagon a (Train b a) >> | Loco b > > The functor on the Loco/Caboose makes sense too and swapping the arguments > is less natural to read. Indeed, Train is a bifunctor. Choosing one over the other is as arbitrary as choosing one over the other for (,) or Either. The only difference here is that the two functors aren't "the same". There are reasons for wanting both instances depending on how the structure is being used. It's times like this that I wish Haskell had real type-level functions, at least for swap and compose, without the need for newtype wrappers or type-family peculiarities. -- Live well, ~wren From korpios at korpios.com Tue Dec 8 00:30:23 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 00:04:49 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: References: Message-ID: On Sat, Dec 5, 2009 at 6:35 AM, Jasper van der Jeugt wrote: > Hakyll is a simple static site generator library, mostly aimed at blogs. It > supports markdown, tex and html templates. > > It is inspired by the ruby Jekyll program. It has a very small codebase > because it makes extensive use of the excellent pandoc and Text.Template > libraries. > > More information can be found on: > http://hackage.haskell.org/package/hakyll-0.1 > http://github.com/jaspervdj/Hakyll I hate to say this, but it looks like you're violating the GPL by not releasing Hakyll under the GPL, since Pandoc is GPL'd. I don't think you're alone in this ? IIRC I've seen several Hackage libraries doing the same thing. I *really* wish Pandoc would switch to a non-copyleft license. (Pretty please, with sugar and cherries on top?) I know that GPL authors are trying to enforce contributions, but the opposite can very well happen: if you have an "essential" copyleft library, someone's eventually going to write a non-copyleft replacement for it (e.g., witness the replacements for Readline) rather than continue to allow it to restrict the licensing options of the community. Great libraries should be able to be embraced without reservations. From michael at snoyman.com Tue Dec 8 00:40:20 2009 From: michael at snoyman.com (Michael Snoyman) Date: Tue Dec 8 00:14:46 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <4B1CF14C.5090302@henning-thielemann.de> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> <29bf512f0912071159m78284e83v61a6d1b2fb0ebd93@mail.gmail.com> Message-ID: <29bf512f0912072140u5a92db48ya7e61918d46fcc8d@mail.gmail.com> On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen wrote: > Michael Snoyman wrote: > > On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < > > lemming@henning-thielemann.de> wrote: > >> On Mon, 7 Dec 2009, Michael Snoyman wrote: > >> I also think that in an earlier mail I answered, that errors can leave > >> you with corrupt data, say invalid file handles, memory pointers, or > data > >> structures that violate invariants. You won't like to close files from > >> invalid file handles and free memory from corrupt pointers or run into > >> infinite loops by traversing the corrupt data structures. That's the > >> reason why it is better to stop execution of the program and hand over > >> control to the next higher level, say the shell or the web browser, that > >> can free resources safely. > >> > > Firstly: I'm really referring exclusively to non-FFI Haskell programs, to > > which most of the issues you mention don't really apply. Nonetheless, I > > think that for a language with exceptions, it still makes sense to use > the > > exceptions in these cases. > > > > In all these cases, I think the correct thing is to have a specific > > exception type that is thrown that signals that it is such an > > unrecoverable error. This allows the programmer to do *whatever* they > > want. Perhaps they want to save some other data to a file before exiting? > > Perhaps they want to spawn a process to send in a bug report? Who knows. > > It doesn't matter. The point is, the user *might* want to do something, > > and exceptions let them do it if they wish, or they can completely ignore > > that specific exception type and let the program crash anyway. > > Michael, Henning > > There are two meanings to the word 'exception' in this context; both of you > tend to conflate these different meanings. One meaning is about a > *mechanism* for non-local control flow; the other is about certain classes > of un-desired program conditions. > > Actually, I think you'll find the we are *not* conflating the terms. Henning makes it clear later on. > Michael, you are above arguing that it is ok to use the same /mechanism/ to > signal errors and exceptions. That is ok with me. There are certainly good > use cases, you have presented a few. However, that does not mean it > is 'silly' or 'unnecessary' to distinguish between program(-mer) errors and > other kinds of expected exceptional conditions in general, as you claimed > in a previous message. > > I agree with Henning insofar as I think it is important to make the > *conceptual* distinction -- regardless of whether we use the same mechanism > to signal (and, perhaps, after serious consideration, handle) them. > > So, maybe it would help if we could agree to use different terms for those > two meanings of the word 'exception'. I think 'exception' is too strongly > associated with the non-local control flow mechanism to introduce a new > word for it. > > Henning, what about calling an undesired but expected condition a > 'failure' > instead of an exception, so we could reserve this word for the language > mechanism? Calling something a 'failure' in this sense (i.e. in contrast > to 'error') would always include some judgement, as it needs to take the > different program levels into account. > > Please do *not* call them failures; a few of us have been working on a failure package and associated helper packages, and called it failure specifically because it was an unused term and thus incurred none of the wrath which rains down upon those unfortunate souls who conflate the terms error and exception in the descriptions of their issues. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/b516259a/attachment.html From jv at informatik.uni-bonn.de Tue Dec 8 00:55:18 2009 From: jv at informatik.uni-bonn.de (=?ISO-8859-15?Q?Janis_Voigtl=E4nder?=) Date: Tue Dec 8 00:29:40 2009 Subject: [Haskell-cafe] Lots of Haskell at PEPM 2010 - Call for Participation Message-ID: <4B1DEA46.7020807@informatik.uni-bonn.de> Hi all, If you are planning to go to Madrid in January, for POPL, don't forget registering for PEPM as well! If you haven't yet been planning to go, maybe you want to reconsider, for PEPM if not for POPL. Why, you ask? Well, the PEPM program has *lots* of Haskell this year. Indeed, no fewer than 10 of the 21 presentations are directly related to Haskell. And the other papers are great, too, and many of them will be interesting to Haskell folk as well. Scan the speakers and titles below, and you will know why I think you won't want to miss out on that one. Best regards, Janis. =============================================================== CALL FOR PARTICIPATION ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 =============================================================== Abstracts of all papers and presentations are available from the above web site. INVITED TALKS: * Lennart Augustsson (Standard Chartered Bank, UK) Title: O, Partial Evaluator, Where Art Thou? * Jeremy Siek (University of Colorado at Boulder, USA) Title: General Purpose Languages Should be Metalanguages. CONTRIBUTED TALKS: * Nabil el Boustani and Jurriaan Hage. Corrective Hints for Type Incorrect Generic Java Programs. * Johannes Rudolph and Peter Thiemann. Mnemonics: Type-safe Bytecode Generation at Run Time. * Elvira Albert, Miguel Gomez-Zamalloa and German Puebla. PET: A Partial Evaluation-based Test Case Generation Tool for Java Bytecode. * Martin Hofmann. Igor2 - an Analytical Inductive Functional Programming System. * Jos? Pedro Magalh?es, Stefan Holdermans, Johan Jeuring and Andres L?h. Optimizing Generics Is Easy! * Michele Baggi, Mar?a Alpuente, Demis Ballis and Moreno Falaschi. A Fold/Unfold Transformation Framework for Rewrite Theories extended to CCT. * Hugh Anderson and Siau-Cheng KHOO. Regular Approximation and Bounded Domains for Size-Change Termination. * ?velyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich, Olivier Pons and Xavier Urbain. A3PAT, an Approach for Certified Automated Termination Proofs. * Fritz Henglein. Optimizing Relational Algebra Operations Using Generic Equivalence Discriminators and Lazy Products. * Adrian Riesco and Juan Rodriguez-Hortala. Programming with Singular and Plural Non-deterministic Functions. * Martin Hofmann and Emanuel Kitzelmann. I/O Guided Detection of List Catamorphisms. * Andrew Moss and Dan Page. Bridging the Gap Between Symbolic and Efficient AES Implementations. * Christopher Brown and Simon Thompson. Clone Detection and Elimination for Haskell. * Stefan Holdermans and Jurriaan Hage. Making Stricterness More Relevant. * Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero J?nior. Context-Sensitive Analysis of Obfuscated x86 Executables. * Xin Li and Mizuhito Ogawa. Conditional Weighted Pushdown Systems and Applications. * Ivan Lazar Miljenovic. The SourceGraph Program. * Florian Haftmann. From Higher-Order Logic to Haskell: There and Back Again. SPECIAL FEATURE: * Andy Gill, Garrin Kimmell and Kevin Matlage. Capturing Functions and Catching Satellites. IMPORTANT DATES: * Early registration deadline: December 22, 2009 * Hotel registration deadline: December 28, 2009 From michael at snoyman.com Tue Dec 8 01:05:12 2009 From: michael at snoyman.com (Michael Snoyman) Date: Tue Dec 8 00:39:37 2009 Subject: [Haskell-cafe] Re: New Hackage category: Error Handling In-Reply-To: <29bf512f0912072140u5a92db48ya7e61918d46fcc8d@mail.gmail.com> References: <3CB22109-1166-4DE4-89CE-7DB0119BD29C@phys.washington.edu> <29bf512f0912071047u202d9798q58d367494ba5714d@mail.gmail.com> <29bf512f0912071120u9f35b9dvd6cebaf8c77347f0@mail.gmail.com> <29bf512f0912071145m30bddcd5p7a3d34cb832a06a@mail.gmail.com> <29bf512f0912071159m78284e83v61a6d1b2fb0ebd93@mail.gmail.com> <29bf512f0912072140u5a92db48ya7e61918d46fcc8d@mail.gmail.com> Message-ID: <29bf512f0912072205t10e3cf39w5827b77a8e462033@mail.gmail.com> On Tue, Dec 8, 2009 at 7:40 AM, Michael Snoyman wrote: > > > On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen wrote: > >> Michael Snoyman wrote: >> > On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann < >> > lemming@henning-thielemann.de> wrote: >> >> On Mon, 7 Dec 2009, Michael Snoyman wrote: >> >> I also think that in an earlier mail I answered, that errors can leave >> >> you with corrupt data, say invalid file handles, memory pointers, or >> data >> >> structures that violate invariants. You won't like to close files from >> >> invalid file handles and free memory from corrupt pointers or run into >> >> infinite loops by traversing the corrupt data structures. That's the >> >> reason why it is better to stop execution of the program and hand over >> >> control to the next higher level, say the shell or the web browser, >> that >> >> can free resources safely. >> >> >> > Firstly: I'm really referring exclusively to non-FFI Haskell programs, >> to >> > which most of the issues you mention don't really apply. Nonetheless, I >> > think that for a language with exceptions, it still makes sense to use >> the >> > exceptions in these cases. >> > >> > In all these cases, I think the correct thing is to have a specific >> > exception type that is thrown that signals that it is such an >> > unrecoverable error. This allows the programmer to do *whatever* they >> > want. Perhaps they want to save some other data to a file before >> exiting? >> > Perhaps they want to spawn a process to send in a bug report? Who knows. >> > It doesn't matter. The point is, the user *might* want to do something, >> > and exceptions let them do it if they wish, or they can completely >> ignore >> > that specific exception type and let the program crash anyway. >> >> Michael, Henning >> >> There are two meanings to the word 'exception' in this context; both of >> you >> tend to conflate these different meanings. One meaning is about a >> *mechanism* for non-local control flow; the other is about certain classes >> of un-desired program conditions. >> >> Actually, I think you'll find the we are *not* conflating the terms. > Henning makes it clear later on. > > Let me rephrase that: we both agree that there is at least a theoretical difference between the two. I believe the distinction in practice is difficult, if not possible, to determine, while Henning disagrees (I believe). Since I believe the two cannot in general be distinguished by name, they should not be distinguished by mechanism, and thus individual types of errors/exceptions/failures should be distinguished by type. I believe Henning thinks that "errors" should cause a program to abort, while "exceptions" should be handled by the exception mechanism. So you're right: we do conflate the terms a bit. I *think* the conflation in terminology, however, is directly correlated to the conflation in mechanism. > Michael, you are above arguing that it is ok to use the same /mechanism/ to >> signal errors and exceptions. That is ok with me. There are certainly good >> use cases, you have presented a few. However, that does not mean it >> is 'silly' or 'unnecessary' to distinguish between program(-mer) errors >> and >> other kinds of expected exceptional conditions in general, as you claimed >> in a previous message. >> >> I agree with Henning insofar as I think it is important to make the >> *conceptual* distinction -- regardless of whether we use the same >> mechanism >> to signal (and, perhaps, after serious consideration, handle) them. >> >> So, maybe it would help if we could agree to use different terms for those >> two meanings of the word 'exception'. I think 'exception' is too strongly >> associated with the non-local control flow mechanism to introduce a new >> word for it. >> >> Henning, what about calling an undesired but expected condition a >> 'failure' >> instead of an exception, so we could reserve this word for the language >> mechanism? Calling something a 'failure' in this sense (i.e. in contrast >> to 'error') would always include some judgement, as it needs to take the >> different program levels into account. >> >> Please do *not* call them failures; a few of us have been working on a > failure package and associated helper packages, and called it failure > specifically because it was an unused term and thus incurred none of the > wrath which rains down upon those unfortunate souls who conflate the terms > error and exception in the descriptions of their issues. > > Michael > Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/119fcf4e/attachment.html From jaspervdj at gmail.com Tue Dec 8 02:05:53 2009 From: jaspervdj at gmail.com (Jasper Van der Jeugt) Date: Tue Dec 8 01:40:20 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: References: Message-ID: Okay, You're right. I will change the license info as soon as possible. Kind regards, Jasper Van der Jeugt On Dec 8, 2009 6:30 AM, "Tom Tobin" wrote: On Sat, Dec 5, 2009 at 6:35 AM, Jasper van der Jeugt wrote: > Hakyll is a simp... I hate to say this, but it looks like you're violating the GPL by not releasing Hakyll under the GPL, since Pandoc is GPL'd. I don't think you're alone in this ? IIRC I've seen several Hackage libraries doing the same thing. I *really* wish Pandoc would switch to a non-copyleft license. (Pretty please, with sugar and cherries on top?) I know that GPL authors are trying to enforce contributions, but the opposite can very well happen: if you have an "essential" copyleft library, someone's eventually going to write a non-copyleft replacement for it (e.g., witness the replacements for Readline) rather than continue to allow it to restrict the licensing options of the community. Great libraries should be able to be embraced without reservations. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/70161361/attachment.html From mle+hs at mega-nerd.com Tue Dec 8 02:09:30 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue Dec 8 01:43:55 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: References: Message-ID: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> Tom Tobin wrote: > I hate to say this, but it looks like you're violating the GPL by not > releasing Hakyll under the GPL, since Pandoc is GPL'd. Not necessarily. The 3 clause BSD license is officially a GPL compatible license. See: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license. Hakyll would only run into trouble if it was used as a library that linked to code which was not under a GPL compatible license. > I *really* wish Pandoc would switch to a non-copyleft license. The LGPL is still a copyleft license. Do you still have a problem with that? > (Pretty please, with sugar and cherries on top?) Most chunks of code can't switch license because they have dozens of contributions from dozens of people many of whom they no longer have contact with. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ketil at malde.org Tue Dec 8 02:44:52 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Dec 8 02:19:16 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> (Richard O'Keefe's message of "Tue, 8 Dec 2009 12:33:48 +1300") References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> Message-ID: <873a3lewp7.fsf@malde.org> "Richard O'Keefe" writes: > factors n = [m | m <- [1..n], mod n m == 0] -- saves about 10% time, seems to give the same result: factors n = [m | m <- [1..n `div` 2], mod n m == 0]++[n] (But checking against primes is even faster, it seems) -k -- If I haven't seen further, it is by standing in the footprints of giants From jeanchristophe.mincke at gmail.com Tue Dec 8 03:21:14 2009 From: jeanchristophe.mincke at gmail.com (jean-christophe mincke) Date: Tue Dec 8 02:55:40 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell Message-ID: Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/494bd71b/attachment.html From gcross at phys.washington.edu Tue Dec 8 03:22:45 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Tue Dec 8 02:58:26 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> Message-ID: > Tom Tobin wrote: > > The 3 clause BSD license is officially a GPL compatible license. See: > > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses > > It is within the terms of the GPL to link GPL code to a bunch of BSD3 code > as long as you abide by both the GPL and the BSD3 license. That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. Having said that... >> I *really* wish Pandoc would switch to a non-copyleft license. > > The LGPL is still a copyleft license. Do you still have a problem > with that? If Pandoc is LGPL, then I think that means we are dealing with an entirely different situation, one in which the library user can choose whatever license he or she likes for his or her own code as long as any modifications to the LGPL'd library itself are released under the LGPL. Cheers, Greg From valgarv at gmx.net Tue Dec 8 03:34:39 2009 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Tue Dec 8 03:09:05 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: References: Message-ID: <1260261279.4027.9.camel@lnx-arielb> On Tue, 2009-12-08 at 09:21 +0100, jean-christophe mincke wrote: > Hello, > > Has there already been attempts to introduce lisp like symbols in > haskell? I'm not sure if this answers your question, but there is an attempt to mix Lisp syntax with Haskell semantics, called Liskell. Description: http://clemens.endorphin.org/ILC07-Liskell-draft.pdf Latest news: http://blog.clemens.endorphin.org/2009/01/liskell-standalone.html Have fun, -- Ariel J. Birnbaum From mle+hs at mega-nerd.com Tue Dec 8 03:38:03 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue Dec 8 03:12:28 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> Message-ID: <20091208193803.2b2fc5e0.mle+hs@mega-nerd.com> Gregory Crosswhite wrote: > >> I *really* wish Pandoc would switch to a non-copyleft license. > > > > The LGPL is still a copyleft license. Do you still have a problem > > with that? > > If Pandoc is LGPL, I wasn't suggesting that pandoc was LGPL, I was probing the other posters attitudes to copyleft licenses other than the GPL. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From stephen.tetley at gmail.com Tue Dec 8 03:43:08 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Tue Dec 8 03:17:33 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: References: Message-ID: <5fdc56d70912080043t14614d04k4cec317423cf9fbb@mail.gmail.com> Hi Jean-Christophe There is no mention in the 'History of Haskell' which is probably the most authoritative published reference http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm If someone wanted to introduce symbols, they would presumably have to propose an extension to the type system to handle them - don't symbols in Lisp and Scheme rely on lists being dynamically typed? Best wishes Stephen 2009/12/8 jean-christophe mincke : > Hello, > > Has there already been attempts to introduce lisp like symbols in haskell? > > > Thank you > > Regards > > J-C > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ganesh.sittampalam at credit-suisse.com Tue Dec 8 03:47:21 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Dec 8 03:22:02 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FD62@ELON17P32001A.csfb.cs-group.com> Gregory Crosswhite wrote: >> Tom Tobin wrote: >> >> The 3 clause BSD license is officially a GPL compatible license. >> See: >> >> >> http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses >> >> It is within the terms of the GPL to link GPL code to a bunch of BSD3 >> code as long as you abide by both the GPL and the BSD3 license. > > That really just means that BSD3 code can be used in GPL code; you > still have to release your own code as GPL if you are including any > GPL code. The main licence of darcs is GPL, but I've licensed all my contributions to it as BSD3. My view of this is that while darcs as a whole is obviously still GPL, any of my contributions that can be extracted independently can be used in other projects under BSD3. I'd say that with hakyll, the library itself can be under BSD3 but any executable you produce from it at the moment will necessarily be GPL. Not sure if there's any good way to communicate this fact in the metadata, though. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From mvanier42 at gmail.com Tue Dec 8 03:48:09 2009 From: mvanier42 at gmail.com (Michael Vanier) Date: Tue Dec 8 03:22:35 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: References: Message-ID: <4B1E12C9.9000308@cs.caltech.edu> jean-christophe mincke wrote: > Hello, > > Has there already been attempts to introduce lisp like symbols in haskell? > > > Thank you > > Regards > > J-C > J-C, Do you mean symbols as in "interned strings with an O(1) string comparison method"? I would love to have those, but I don't see an easy way to get it without being in the IO or ST monad. Mike From maydwell at gmail.com Tue Dec 8 03:55:18 2009 From: maydwell at gmail.com (Lyndon Maydwell) Date: Tue Dec 8 03:29:42 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: <4B1E12C9.9000308@cs.caltech.edu> References: <4B1E12C9.9000308@cs.caltech.edu> Message-ID: Aren't symbols made redundant by algebraic data types? On Tue, Dec 8, 2009 at 4:48 PM, Michael Vanier wrote: > jean-christophe mincke wrote: >> >> Hello, >> >> Has there already been attempts to introduce lisp like symbols in haskell? >> >> >> Thank you >> >> Regards >> >> J-C >> > > J-C, > > Do you mean symbols as in "interned strings with an O(1) string comparison > method"? ?I would love to have those, but I don't see an easy way to get it > without being in the IO or ST monad. > > Mike > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From vlado at dikini.net Tue Dec 8 03:58:18 2009 From: vlado at dikini.net (Vladimir Zlatanov) Date: Tue Dec 8 03:32:43 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: <4B1E12C9.9000308@cs.caltech.edu> References: <4B1E12C9.9000308@cs.caltech.edu> Message-ID: <4d197d970912080058h684bbdb4hc3fd543e5a96dc8e@mail.gmail.com> I think stable names can be used where symbols are used in scheme. I think there are better alternatives for different use cases in haskell. For example, symbols are often used to tag values - haskell has pattern matching on constructors. From noteed at gmail.com Tue Dec 8 03:58:51 2009 From: noteed at gmail.com (minh thu) Date: Tue Dec 8 03:33:36 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: References: <4B1E12C9.9000308@cs.caltech.edu> Message-ID: <40a414c20912080058t11a0d0a2g2410c531f36ac758@mail.gmail.com> Probably in the same way integers are made redundant : data Integer = 0 | 1 | 2 | .... Cheers, Thu 2009/12/8 Lyndon Maydwell : > Aren't symbols made redundant by algebraic data types? > > On Tue, Dec 8, 2009 at 4:48 PM, Michael Vanier wrote: >> jean-christophe mincke wrote: >>> >>> Hello, >>> >>> Has there already been attempts to introduce lisp like symbols in haskell? >>> >>> >>> Thank you >>> >>> Regards >>> >>> J-C >>> >> >> J-C, >> >> Do you mean symbols as in "interned strings with an O(1) string comparison >> method"? I would love to have those, but I don't see an easy way to get it >> without being in the IO or ST monad. >> >> Mike >> >> >> _______________________________________________ >> 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 > From bulat.ziganshin at gmail.com Tue Dec 8 03:59:53 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Dec 8 03:34:25 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: <4B1E12C9.9000308@cs.caltech.edu> References: <4B1E12C9.9000308@cs.caltech.edu> Message-ID: <1776901241.20091208115953@gmail.com> Hello Michael, Tuesday, December 8, 2009, 11:48:09 AM, you wrote: > Do you mean symbols as in "interned strings with an O(1) string > comparison method"? I would love to have those, but I don't see an easy > way to get it without being in the IO or ST monad. you could intern IO usage with unsafePerformIO. it's implemented in GHC sources, afair it's FastString type or so -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lrpalmer at gmail.com Tue Dec 8 04:01:25 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Dec 8 03:35:49 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: <4B1E12C9.9000308@cs.caltech.edu> References: <4B1E12C9.9000308@cs.caltech.edu> Message-ID: <7ca3f0160912080101q1b371767ya877ba7a6e401224@mail.gmail.com> On Tue, Dec 8, 2009 at 1:48 AM, Michael Vanier wrote: > Do you mean symbols as in "interned strings with an O(1) string comparison > method"? ?I would love to have those, but I don't see an easy way to get it > without being in the IO or ST monad. data Sym = Sym String Hash fromString :: String -> Sym fromString s = Sym s (hash s) instance Eq Sym where Sym _ h == Sym _ h' = h == h' Much as I am uncomfortable with hash-based equality. 1/2^256, despite being very small, is not zero. It is begging for a mysterious failure someday. Luke From magnus at therning.org Tue Dec 8 04:25:47 2009 From: magnus at therning.org (Magnus Therning) Date: Tue Dec 8 04:00:11 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> Message-ID: On Tue, Dec 8, 2009 at 8:22 AM, Gregory Crosswhite [..] > If Pandoc is LGPL, then I think that means we are dealing with an entirely different situation, one in which the library user can choose whatever license he or she likes for his or her own code as long as any modifications to the LGPL'd library itself are released under the LGPL. As has been discussed a few times before on this list, using LGPL for Haskell modules has its own set of problems when using GHC, due to the current state of linking in that compiler. From what I've read we're on a path to salvation with 6.12, but we're still not at the destination. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus identi.ca|twitter: magthe From gcross at phys.washington.edu Tue Dec 8 04:51:42 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Tue Dec 8 04:26:27 2009 Subject: [Haskell-cafe] ANNOUNCE: new installment of failure framework In-Reply-To: <29bf512f0912062058m4076b4dcvae3a38cf71bae54f@mail.gmail.com> References: <29bf512f0912062058m4076b4dcvae3a38cf71bae54f@mail.gmail.com> Message-ID: <73F577DF-35A4-44AB-A028-9CA56E3E5604@phys.washington.edu> Michael, Although I like the idea of improving the way that failures are handled in Haskell, I am having trouble seeing any reason to use your framework. If a function is always assumed to succeed given certain pre-conditions, and somewhere along the lines my code discovers that one of these had been violated, then I throw an exception in order to communicate to myself the manner in which I screwed up. If a function might either succeed or fail for a very specific reason, then I use a Maybe because the caller will know exactly what problem is being signaled by Nothing. If a function might fail for one of many reasons and the caller might care about learning more about the problem, then I use an Either so that I can report the details of the problem. In each of the latter two cases, I can already use monads to handle the errors in a relatively convenient manner. In the first case I usually want the program to die right away and let me know where I screwed up, but if for some reason I wanted to continue even given arbitrary unanticipated problems in a particular computation the I use an exception handler. Given that all of the scenarios that I encounter are already handled by the functionality the standard libraries, it is not clear to me what your framework actually offers. I am not writing this to shoot your framework down, but rather to voice my thoughts aloud in order to hear your response to them, since if there is a use scenario that I am missing in which your framework would be ideal then I would be interested in hearing about it. Cheers, Greg On Dec 6, 2009, at 8:58 PM, Michael Snoyman wrote: > We'd like to announce the next installment of the Failure Framework. Based on feedback, our main goals in this release is to reduce the number of external dependencies and avoid complications with monad transformer libraries at the core of the framework. We have made the following changes: > > * Failure is not tied directly to monads anymore. The main typeclass is Failure, which provides the failure function. MonadFailure, ApplicativeFailure and FunctorFailure are provided for convenience. > * The Failure typeclass is now located in the failure package, which has no dependencies. All code dealing with transformers and mtl has been factored into control-monad-failure and control-monad-failure-mtl, respectively. > > In addition, we are simultaneously releasing the following packages: > * safe-failure provides safe versions of dangerous, non total functions, such as head, by returning failures. It depends exclusively on failure. > * attempt provides a concrete data type for handling extensible exceptions as failures. It depends exclusively on failure. > * control-monad-attempt provides a monad transformer for attempt using the transformers library. We do not provide currently an mtl version of this package, but can provide one if there is demand. > * control-monad-exception, explicitly typed, checked exceptions with monadic stack traces. > > Below are the links to the packages just released. Enjoy! > > http://hackage.haskell.org/package/failure-0.0.0 > http://hackage.haskell.org/package/control-monad-failure-0.6.0 > http://hackage.haskell.org/package/control-monad-failure-mtl-0.6.0 > http://hackage.haskell.org/package/safe-failure-0.4.0 > http://hackage.haskell.org/package/attempt-0.2.0 > http://hackage.haskell.org/package/control-monad-attempt-0.0.0 > http://hackage.haskell.org/package/control-monad-exception-0.8.0 > http://hackage.haskell.org/package/control-monad-exception-mtl-0.8.0 > http://hackage.haskell.org/package/control-monad-exception-monadsfd-0.8.0 > http://hackage.haskell.org/package/control-monad-exception-monadstf-0.8.0 > > Michael Snoyman, Pepe Iborra, Nicolas Pouillard > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/90ad52b7/attachment.html From deniz.a.m.dogan at gmail.com Tue Dec 8 04:56:38 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Tue Dec 8 04:31:23 2009 Subject: [Haskell-cafe] Allowing hyphens in identifiers Message-ID: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. -- Deniz Dogan From ketil at malde.org Tue Dec 8 05:06:01 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Dec 8 04:40:27 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: <7ca3f0160912080101q1b371767ya877ba7a6e401224@mail.gmail.com> (Luke Palmer's message of "Tue, 8 Dec 2009 02:01:25 -0700") References: <4B1E12C9.9000308@cs.caltech.edu> <7ca3f0160912080101q1b371767ya877ba7a6e401224@mail.gmail.com> Message-ID: <87y6lddbli.fsf@malde.org> Luke Palmer writes: > data Sym = Sym String Hash > > fromString :: String -> Sym > fromString s = Sym s (hash s) > > instance Eq Sym where > Sym _ h == Sym _ h' = h == h' > Much as I am uncomfortable with hash-based equality. 1/2^256, despite > being very small, is not zero. It is begging for a mysterious failure > someday. How about: instance Eq Sym where Sym s h == Sym s' h' = h == h' && s == s' So, very fast if the hashes fail to match, only marginally slower than just the string comparison if they are equal. -k -- If I haven't seen further, it is by standing in the footprints of giants From jon.fairbairn at cl.cam.ac.uk Tue Dec 8 05:19:14 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Dec 8 04:54:03 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> Message-ID: Deniz Dogan writes: > Has there been any serious suggestion or attempt to change the syntax > of Haskell to allow hyphens in identifiers, much like in Lisp > languages? E.g. hello-world would be a valid function name. I (among others) suggested it right at the beginning when we were first defining the lexical syntax, and have raised the possibility again a couple of times now that unicode hyphens are available, but it wasn't liked at the beginning and hasn't excited much interest since. Why do you want them? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) From jeanchristophe.mincke at gmail.com Tue Dec 8 05:28:02 2009 From: jeanchristophe.mincke at gmail.com (jean-christophe mincke) Date: Tue Dec 8 05:02:29 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: <87y6lddbli.fsf@malde.org> References: <4B1E12C9.9000308@cs.caltech.edu> <7ca3f0160912080101q1b371767ya877ba7a6e401224@mail.gmail.com> <87y6lddbli.fsf@malde.org> Message-ID: I think lisp like symbols could be quite useful in the context of embedded DSL to create ... well... symbols that can be interpreted as variables in that DSL. I can imagine something such as a small relational DSL i.e Without symbols we have several alternatives: 1. Symbols are written as strings (and possibly automatically lifted to Symbol string if necessary, It is possible for nums I do not know for strings). Moreover the system should be able to tell the difference between a string representing a symbol and a string representing a string value "Table_A" 'where' "Att_Name" = "Smith" 'and' "Att_Age" > 10 2. Using algebraic data type: the syntax looks better but the data type must be declared before. In this case we must know in advance all the attributes and table names (including all the names used in 'rename' relational op?ration - the 'as' in sql). Table_A 'where' Att_Name = "Smith" 'and' Att_Age > 10 3 If we had symbols. Note lisp like symbols might well be values of some predefined type "Symbol". Just like 2,3, 56 are values of the predefined type Integer. Table_A 'where' Att_Name = "Smith" 'and' Att_Age > 10 Here the problem is that the compiler should be able to tell the difference between a symbol and an undefined variable. Lisp solves it by prefixing the symbol with a little '. Smalltalk prefixes it with #. So with unambiguous symbols: 'Table_A 'where' 'Att_Name = "Smith" 'and' 'Att_Age > 10 or #Table_A 'where' #Att_Name = "Smith" 'and' #Att_Age > 10 Regards J-C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/65e2180c/attachment.html From ivan.miljenovic at gmail.com Tue Dec 8 05:34:48 2009 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue Dec 8 05:09:17 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: (Gregory Crosswhite's message of "Tue, 8 Dec 2009 00:22:45 -0800") References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> Message-ID: <87ws0xn48n.fsf@gmail.com> Gregory Crosswhite writes: > That really just means that BSD3 code can be used in GPL code; you > still have to release your own code as GPL if you are including any > GPL code. Not quite true: it means that any code your BSD3 library gets used in has to have a GPL-compatible license: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL (this is the approach I've used for Graphalyze since I use Pandoc as a default library for document generation; later on I'm planning on re-doing the document part in which case it will _have_ to use Pandoc and thus I'll re-license the library). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com From noteed at gmail.com Tue Dec 8 05:42:11 2009 From: noteed at gmail.com (minh thu) Date: Tue Dec 8 05:16:56 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: <87ws0xn48n.fsf@gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> Message-ID: <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> 2009/12/8 Ivan Lazar Miljenovic : > Gregory Crosswhite writes: >> That really just means that BSD3 code can be used in GPL code; you >> still have to release your own code as GPL if you are including any >> GPL code. > > Not quite true: it means that any code your BSD3 library gets used in > has to have a GPL-compatible license: > > http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL > > (this is the approach I've used for Graphalyze since I use Pandoc as a > default library for document generation; later on I'm planning on > re-doing the document part in which case it will _have_ to use Pandoc > and thus I'll re-license the library). I wonder how APIs are covered. If your code use an API implemented by Pandoc (GPL) and also by another library licensed under, say, BSD3. Why should your code be licensed under GPL ? The only difference would be a build-depends in the .cabal. Has anyone an idea about this ? Cheers, Thu From deniz.a.m.dogan at gmail.com Tue Dec 8 05:53:54 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Tue Dec 8 05:28:38 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> Message-ID: <7b501d5c0912080253o3b98fec0rf8a508d56d4c5610@mail.gmail.com> 2009/12/8 Jon Fairbairn : > Deniz Dogan writes: > >> Has there been any serious suggestion or attempt to change the syntax >> of Haskell to allow hyphens in identifiers, much like in Lisp >> languages? E.g. hello-world would be a valid function name. > > I (among others) suggested it right at the beginning when we > were first defining the lexical syntax, and have raised the > possibility again a couple of times now that unicode hyphens are > available, but it wasn't liked at the beginning and hasn't > excited much interest since. ?Why do you want them? > I just like the standard Lisp naming convention better than camel casing and saw someone on #haskell mentioning it the other day. No biggie though. -- Deniz Dogan From ketil at malde.org Tue Dec 8 06:10:21 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Dec 8 05:44:45 2009 Subject: [Haskell-cafe] ANN: hakyll-0.1 In-Reply-To: <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> (minh thu's message of "Tue, 8 Dec 2009 11:42:11 +0100") References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> Message-ID: <87r5r5d8ma.fsf@malde.org> minh thu writes: > I wonder how APIs are covered. I don't think an API would be covered. The API is the standard way to use something, if copyright licenses cover usage like this, any executable will be a derivative of the operating system and (possibly) the compiler. > Why should your code be licensed under GPL? I think your code is covered by whatever license you wish. An aggregate work, on the other hand, would need to be covered by the GPL, and all source code would have to be available under GPL terms. So if you distribute your code linked to or incorporating the GPL library, the whole must conform to the GPL license (source availability and redistributatbility, etc). Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. -k -- If I haven't seen further, it is by standing in the footprints of giants From vlado at dikini.net Tue Dec 8 06:13:48 2009 From: vlado at dikini.net (Vladimir Zlatanov) Date: Tue Dec 8 05:48:13 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: References: <4B1E12C9.9000308@cs.caltech.edu> <7ca3f0160912080101q1b371767ya877ba7a6e401224@mail.gmail.com> <87y6lddbli.fsf@malde.org> Message-ID: <4d197d970912080313k354a3b3ai6a980682a29d25de@mail.gmail.com> wrote: > I think lisp like symbols could be quite useful in the context of embedded > DSL to create ... well... symbols that can be interpreted as variables in > that DSL. Well for such use-case you could use either stable names, or recode them into a state monad- you will get either a global i.e. lisp like unique symbols, or their equivalent within a state context. Or some variation of the code posted previously in this thread. http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html From daniel.is.fischer at web.de Tue Dec 8 07:15:49 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 8 06:51:43 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <873a3lewp7.fsf@malde.org> References: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> <873a3lewp7.fsf@malde.org> Message-ID: <200912081315.49795.daniel.is.fischer@web.de> Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: > "Richard O'Keefe" writes: > > factors n = [m | m <- [1..n], mod n m == 0] > > -- saves about 10% time, seems to give the same result: > factors n = [m | m <- [1..n `div` 2], mod n m == 0]++[n] Even faster (for large enough n): factors n = mergeAll [if q == d then [d] else [d, q] | d <- [1 .. isqrt n] , let (q,r) = n `divMod` d, r == 0] > > (But checking against primes is even faster, it seems) That's peanuts, the important part is to partition smaller numbers (i.e. (sigma(n)-2*n) vs. sigma(n)). Still faster would be using the fact that if n is Zumkeller and gcd n m = 1, then n*m is Zumkeller, too. > > -k From jwlato at gmail.com Tue Dec 8 07:19:49 2009 From: jwlato at gmail.com (John Lato) Date: Tue Dec 8 06:54:13 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww Message-ID: <9979e72e0912080419u7bcfcc40odd4ee96d0a19acbc@mail.gmail.com> > From: Andrew Coppin > > John Lato wrote: > >> The only workable approach is to have users specify the >> locations of these files, which unfortunately requires more >> sophistication than can be expected of most Windows users (and even >> some Windows developers). >> > > Well, I don't know. It's going to vary from package to package, but most > things that have a semi-official Windows version either come as a > Windows Installer package (which, one presumes records where it put > everything *somewhere* in the Windows registry), or possibly the > *developer* package comes as a simple Zip file that you just unzip to > wherever you fancy. Just tell the user the URL to grab the Zip file > from, unzip it and tell Cabal where the root is now. Shouldn't be too > hard. (Famous last words...) Indeed, in theory it would work this way. In practice, not so much. > >> On a related matter, many packagers resort to using configure-style >> configuration setups to assist with binding to C libraries. ?Cabal is >> now sophisticated enough to handle many of these steps (although not >> all), however packagers may not have had an opportunity to update >> their build process to remove the dependency on "configure". ?These >> packages will continue to require cygwin or mingw for the "configure" >> step. >> > > Ah yes, this is pretty much guaranteed to make stuff not work on > Windows. :-) Still, all Unix systems have Automake, configure, etc., so > I guess most people don't even think twice before using it. > > I gather it's supposed to be Cabal's job to figure this stuff out in > Haskell land? > AFAIK, this is true to an extent. I think that someone like Duncan could explain the role of Cabal better than I can. Of course Cabal was missing much of the necessary functionality until only recently. As an example, the possibility of listing C library dependencies was only added in 1.6 IIRC. >> One last wrinkle: many distributors of C libraries do not have Windows >> machines available to test, and (understandably) have little interest >> in supporting a platform they don't have and aren't familiar with. ?As >> a result, many C libraries are not well supported on Windows and >> require somebody familiar with gnu build tools (i.e. gcc, make, and >> autoconf) to be usable on Windows *at all*. ?This means that, as a >> Haskell developer wanting to use these libs, you need to use gnu build >> tools because you're not just binding to the library, you're >> maintaining a Windows port of it. >> > > This seems to be kind of the catch-22. Nobody uses Windows, so there > isn't much support for Windows, so we don't attract many Windows > users... QED. :-} > Agreed (by users I presume you mean Haskell developers). I remember that many readers of this list were shocked by the download numbers for the HP, particularly the high number of Windows downloads. I think it goes to show that there is interest among Windows developers, as long as they have the sense that their platform is equally-supported compared to Linux. There are many more potential windows developers than linux developers due to the size of the Windows install base, so good Windows support is one of the easiest ways to expand the audience. >> C and unix are pretty much designed to work together, and have been >> for decades, so I think it's reasonable to expect that Windows is the >> side that needs to adapt to support their model. > > In other words, "Windows needs to become just like Unix". Not going to > happen. ;-) Argue about whether this is good or bad amoungst yourselves. > But it's not happening. I don't mean that Windows needs to become just like Unix. I mean that if Windows supported a common installation location for .dll's and .h files (and binary packages regularly provided them), much of this difficulty would be easily resolved. It wouldn't be "becoming like Unix", it would mean adopting to a C distribution model that Unix happens to share. Regardless, I think I have a better chance of winning the lottery jackpot than seeing MS support this in my lifetime. > >> MS hasn't done so, >> which means that C developers would need to unacceptably compromise >> unix support in their packages in order to better support Windows. >> > > I don't know about that... Lots of commercial and open-source products > are available for Windows and Unix, seemingly without any problem. (GTK, > for example...) I don't deny that adding Windows support is _a lot more > work_ than adding support for just another Unix, though. > This goes back to the catch-22 you listed above, but I wouldn't say Windows support is "without any problem." First you need active Windows developers for this. Commercial products have a big advantage here. Second, Windows support means a host of platform-specific bugs to be dealt with in every part of the package. These are in addition to any other bugs that you'd have anyway. FWIW, I had great difficulty in building hCsound on Windows, and my primary development box at the time was WinXP. I did eventually make it work with the binary csound distribution, but not without a lot of pain derived from the specifics of the binaries in ways that cabal can't (and probably shouldn't) be expected to handle. John From agocorona at gmail.com Tue Dec 8 07:21:41 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Dec 8 06:56:07 2009 Subject: [Haskell-cafe] The Transient monad Message-ID: Hi haskell cafe: concerning Stable Names http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html makeStableName :: a -> IO (StableName a) I Did not test fully my proposal, and I?m thinking aloud, Just to inpire others and fish some ideas; The IO in makeStableName suggest more side effects than makeStableName really do. But still the call isn't pure. For calls such are makeStableName that gives a different result the FIRST time they are called but return the same result every time in the same session, I suggest to use a Transient monad: makeStableName :: a -> Transient (StableName a) The key here is to maintain the programmer aware that it is not pure, but there are no IO and that the results have no meaning from session to session. Instance Monad Transient where Transient x ? f = f x return x = Transient x We can Transient`ize IO calls by means of an implicit memoization: liftT:: IO a -> Transient a liftT= < whatever memoization code> liftT2=.... liftT3=.... Memorization then is embedded in the monad transformation This may be more elegant than IO plus unsafePerformIO and is more informative for the programmer. The transition form IO to pure can be done in two steps, see below Instead of unsafePerformIO, we can use: unsafePurifyTransient :: Transient a -> a unsafePurifyTransient (Transient x) = x for the inherently transient calls A safer version of unsafePerformIO using implicit memoization could be: unsafePerformIOT :: IO a -> a unsafePerformIOT = unsafePurifyTransient . liftT unsafePerformIOT guatantee that it returns the same value in the same session. 2009/12/8 Vladimir Zlatanov > wrote: > > I think lisp like symbols could be quite useful in the context of > embedded > > DSL to create ... well... symbols that can be interpreted as variables in > > that DSL. > > Well for such use-case you could use either stable names, or recode > them into a state monad- you will get either a global i.e. lisp like > unique symbols, or their equivalent within a state context. Or some > variation of the code posted previously in this thread. > > > http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/22d521b2/attachment.html From michael at snoyman.com Tue Dec 8 07:47:47 2009 From: michael at snoyman.com (Michael Snoyman) Date: Tue Dec 8 07:22:12 2009 Subject: [Haskell-cafe] ANNOUNCE: new installment of failure framework In-Reply-To: <73F577DF-35A4-44AB-A028-9CA56E3E5604@phys.washington.edu> References: <29bf512f0912062058m4076b4dcvae3a38cf71bae54f@mail.gmail.com> <73F577DF-35A4-44AB-A028-9CA56E3E5604@phys.washington.edu> Message-ID: <29bf512f0912080447j4c85dde0uc1d5e7b9c7921726@mail.gmail.com> On Tue, Dec 8, 2009 at 11:51 AM, Gregory Crosswhite < gcross@phys.washington.edu> wrote: > Michael, > > Although I like the idea of improving the way that failures are handled in > Haskell, I am having trouble seeing any reason to use your framework. > > If a function is always assumed to succeed given certain pre-conditions, > and somewhere along the lines my code discovers that one of these had been > violated, then I throw an exception in order to communicate to myself the > manner in which I screwed up. > > If a function might either succeed or fail for a very specific reason, then > I use a Maybe because the caller will know exactly what problem is being > signaled by Nothing. > > If a function might fail for one of many reasons and the caller might care > about learning more about the problem, then I use an Either so that I can > report the details of the problem. > > In each of the latter two cases, I can already use monads to handle the > errors in a relatively convenient manner. In the first case I usually want > the program to die right away and let me know where I screwed up, but if for > some reason I wanted to continue even given arbitrary unanticipated problems > in a particular computation the I use an exception handler. > > Given that all of the scenarios that I encounter are already handled by the > functionality the standard libraries, it is not clear to me what your > framework actually offers. > > I am not writing this to shoot your framework down, but rather to voice my > thoughts aloud in order to hear your response to them, since if there is a > use scenario that I am missing in which your framework would be ideal then I > would be interested in hearing about it. > > The failure wiki page addresses exactly why Maybe and Either are inadequate solutions in a number of circumstances. Maybe does not allow any information to be attached; that may be fine when you directly call a function, but what if you call a function, which calls another one, and so on and so forth? You would then have two choices: * Ultimately just receive a Nothing and not know why. * At each step of the why, check if it's a Nothing, and then produce some appropriate message to describe it. If you choose option 2, you're admitting that Maybe was not sufficient for your uses any. Regarding Either, there are a number of issues: * There *is* not Monad instance in the base library. Orphan instances lead to major issues, such as not being able to import two modules at the same time because each declares a Monad Either instance. * With Either, you are limited to a single error type (unless you use existential types). * There is no easy way to chain together different types of Eithers (see below). For example, let's say I want to write some code to authenticate a user via OpenID (see the authenticate package). It has to do at least two things: * Download pages by HTTP * Parse the resulting HTML page. I would like to ideally do the following: authenticate = do page <- getPage url parsed <- parseHtml page checkResult parsed In other words, easily chain things together, and simply let the error types propogate. If the given functions had these signatures: getPage :: (MonadFailure HttpException m, MonadIO m) => String -> m String parseHtml :: Failure ParseHtmlException m => String -> m HtmlTree checkResult :: Failure AuthenticationException m => HtmlTree -> m Identifier Then authenticate would simply subsume all these error types, making it explicit what a client of the libraries needs to be aware of. If clients instead want to look at it as a simple success/failure, I would recommend using the attempt package. If they want to deal with each failure type separately, they could use control-monad-exception. I hope that clears up why this package exists. It was not born of nothing; it is meant to solve real problems in an elegant manner. If you have any questions, please let me know. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/7c0d7c3b/attachment.html From pepeiborra at gmail.com Tue Dec 8 08:08:46 2009 From: pepeiborra at gmail.com (=?iso-8859-1?Q?Jos=E9_Iborra?=) Date: Tue Dec 8 07:43:15 2009 Subject: [Haskell-cafe] ANNOUNCE: new installment of failure framework In-Reply-To: <29bf512f0912080447j4c85dde0uc1d5e7b9c7921726@mail.gmail.com> References: <29bf512f0912062058m4076b4dcvae3a38cf71bae54f@mail.gmail.com> <73F577DF-35A4-44AB-A028-9CA56E3E5604@phys.washington.edu> <29bf512f0912080447j4c85dde0uc1d5e7b9c7921726@mail.gmail.com> Message-ID: <1DC4FCD4-7B19-4E20-9885-3AAAC0AE1D18@gmail.com> On Dec 8, 2009, at 1:47 PM, Michael Snoyman wrote: > For example, let's say I want to write some code to authenticate a user via OpenID (see the authenticate package). It has to do at least two things: > > * Download pages by HTTP > * Parse the resulting HTML page. > > I would like to ideally do the following: > > authenticate = do > page <- getPage url > parsed <- parseHtml page > checkResult parsed > > In other words, easily chain things together, and simply let the error types propogate. If the given functions had these signatures: > > getPage :: (MonadFailure HttpException m, MonadIO m) => String -> m String > parseHtml :: Failure ParseHtmlException m => String -> m HtmlTree > checkResult :: Failure AuthenticationException m => HtmlTree -> m Identifier > > Then authenticate would simply subsume all these error types, making it explicit what a client of the libraries needs to be aware of. Let me highlight this point. The Maybe, Either,Exception diversity can be a curse instead of a blessing when combining libraries which return errors in different ways. The main goal of the failure framework is to provide an abstract notion of failure, so that libraries can offer interfaces which fail in an abstract way, and the client of the libraries can make the choice of how to manage the failures. Using a similar example (from [1]), consider a program to download a web page and parse it: 1. Network.URI.parseURI returns (Maybe URI). 2. Network.HTTP.simpleHTTP returns (IO (Result Request)), which is basically a broken version of (IO (Either ConnError Request)). 3. Parsec returns (Either ParseError a) So there's no hope that I can write anything like: *> do uri <- parseURI uriStr *> doc <- evenSimplerHTTP uri *> parsed <- parse grammar uriStr doc The Failure package contains functions that help when dealing with this problem, so that we can write something very close: > do uri <- try <$> parseURI uriStr > doc <- try <$> evenSimplerHTTP uri > let parsed = try $ parse grammar uriStr doc But more importantly, the abstract notion of Failure enables library authors to write code that will easily combine with other failable code. Thanks, pepe [1] - http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors From Alistair.Bayley at invesco.com Tue Dec 8 09:20:00 2009 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Tue Dec 8 08:54:24 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: <87iqcjfbqk.fsf@malde.org> References: <20091206223855.GC920@whirlpool.galois.com> <87iqcjfbqk.fsf@malde.org> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9110264EF@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ketil Malde > > Don Stewart writes: > > > > http://hackage.haskell.org/package/Diff > > Wherein we can read: > > | This is an implementation of the O(ND) diff algorithm > [...]. It is O(mn) > | in space. > > At first I thought 'N' and 'M' would be the lengths of the lists, and > 'D' is the number of differences, but then the space bound > doesn't make > sense. I tried to find the reference, but Citeseer is down > (again. sigh). > > Anybody know what the bounds really are? I think the space bounds are O(M+N). Section "4b. A Linear Space Refinement" concludes with "Unfortunately, the input sequences A and B must be kept in memory, implying that a total of O(M+N) space is needed." BTW, there is a minor improvement to this algorithm (claims to be faster, same space usage): http://research.janelia.org/myers/Papers/np_diff.pdf found via: http://scholar.google.com/scholar?q=%22An+O(NP)+Sequence+Comparison+Algo rithm.%22 I thought this paper was easier to understand. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From adam.ciganek at gmail.com Tue Dec 8 10:10:53 2009 From: adam.ciganek at gmail.com (=?ISO-8859-1?Q?Adam_Cig=E1nek?=) Date: Tue Dec 8 09:45:19 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? Message-ID: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> Hello there, Is there some other parser library, with similar nice API than Parsec, but which somehow handles left-recursive grammars? Ideally if it has at least rudimentary documentation and/or tutorial :) From doaitse at swierstra.net Tue Dec 8 11:11:22 2009 From: doaitse at swierstra.net (S. Doaitse Swierstra) Date: Tue Dec 8 10:45:51 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? In-Reply-To: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> References: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> Message-ID: In principle it is not possible to parse left-recursive grammars, but you may follow the following route: 1 write your grammars using the constructors from the Christmastree package at: http://hackage.haskell.org/packages/archive/ChristmasTree/0.1.2/doc/html/Text-GRead-Grammar.html 2 if you want to parse Haskell values use the provided template haskell code to derive these descriptions 3 use the transformations to perform a left corner transform on your grammar, as done at: http://hackage.haskell.org/packages/archive/ChristmasTree/0.1.2/doc/html/src/Text-GRead.html#gread For a full documentation of the underlying techniques see: http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS and Arthur Baars thesis at: http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS If you do not want to explore this route you may use combinators like pChainl and pChainr, which can be useful in removing left recursion and even make your parsers look nicer and more intuitive, Doaitse Swierstra On 8 dec 2009, at 16:10, Adam Cig?nek wrote: > Hello there, > > Is there some other parser library, with similar nice API than Parsec, > but which somehow handles left-recursive grammars? Ideally if it has > at least rudimentary documentation and/or tutorial :) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From john at n-brain.net Tue Dec 8 11:16:04 2009 From: john at n-brain.net (John A. De Goes) Date: Tue Dec 8 10:50:39 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? In-Reply-To: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> References: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> Message-ID: <389B189B-FE16-4119-AA8B-530C5EBBA2B3@n-brain.net> X-Saiga. Regards, John On Dec 8, 2009, at 7:10 AM, Adam Cig?nek wrote: > Hello there, > > Is there some other parser library, with similar nice API than Parsec, > but which somehow handles left-recursive grammars? Ideally if it has > at least rudimentary documentation and/or tutorial :) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ndmitchell at gmail.com Tue Dec 8 11:38:40 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Dec 8 11:13:04 2009 Subject: [Haskell-cafe] SmallCheck design question In-Reply-To: <4B1D8E66.4040202@imn.htwk-leipzig.de> References: <4B1D8E66.4040202@imn.htwk-leipzig.de> Message-ID: <404396ef0912080838l28afce10qebe050db3df22bea@mail.gmail.com> Hi, I'm cc'ing the people behind smallcheck, who can give definitive answers. > 1. why are the tuple constructors treated differently? > I'd expect depth (x,y) = succ $ max (depth x) (depth y) > but the succ is missing. I think this was a design choice. Some people would consider: data Foo = Foo a b and data Foo = Foo (a,b) to be roughly the same - in some way the tuple is just to group things up, but it never is any structure by itself, since any structure it has is limited by the type system. But it could have been defined the other way. > 2. why depth and not size (= total number of constructors)? > it seems that the number of objects (trees) of given depth > rises much more drastically than number of trees of given size. That seems harder to generate terms compositionally. To create all terms of depth n+1 you just glue together all terms of depth n, but to create terms of size n+1 you need to glue 1 with n, 2 with n-1 etc. Thanks, Neil From gabor at karamaan.com Tue Dec 8 12:09:10 2009 From: gabor at karamaan.com (siki) Date: Tue Dec 8 11:43:34 2009 Subject: [Haskell-cafe] Haskell job opportunity Message-ID: <26697169.post@talk.nabble.com> I've posted this before but did not get a whole lot of responses, so here it is again: Principal investment firm based in Manhattan is looking for an outstanding software developer to develop and maintain the firm's proprietary valuation models as well as accounting and portfolio management systems. You should have at least a bachelor?s degree in computer science from a top university and impeccable coding style. This is a high-impact, high-visibility job opportunity where successful candidates will be entrusted with a lot of responsibility for products that have a direct effect on the P&L of the firm and influences our workflow. This is a very small hedge fund with me being the only developer right now. The next hire will have a very direct say into how this side of our business progresses from here. We are a growth oriented firm that values people who take a craftsman?s pride in their work. We always like to take a contrarian view of things, value experimenting and using often overlooked technologies. That is one of the main reasons why we currently started using Haskell in developing our quantitative models. We are looking for a candidate who shows strong analytical, organizational, and communication skills. Attention to detail is essential, i.e. we fully document everything we do and pay a lot of attention to coding style. The majority of our existing code was written in Java, so you should have at least some experience with Java and related technologies, in order to be able to maintain the existing code. But as I mentioned above, Haskell has now become my choice of language and eventually all of the existing code will have to be re-written in Haskell. Background in accounting is not necessary but is definitely a plus. Please send your CV and cover letter to recruitment at karamaan.com, or reply to this post if you have any questions. Thanks -- View this message in context: http://old.nabble.com/Haskell-job-opportunity-tp26697169p26697169.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From korpios at korpios.com Tue Dec 8 12:54:55 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 12:29:19 2009 Subject: [Haskell-cafe] Haskell job opportunity In-Reply-To: <26697169.post@talk.nabble.com> References: <26697169.post@talk.nabble.com> Message-ID: On Tue, Dec 8, 2009 at 11:09 AM, siki wrote: > I've posted this before but did not get a whole lot of responses, so here it > is again: [...] > You should have at least a bachelor?s degree in computer science from a top > university Might I humbly suggest that this is going to severely limit your hiring options? You're looking for the intersection of sets of people who: - Have a BS in computer science (cuts out a fair number of people) - Graduated from a "top university" (cuts out a *lot* of people) - Is familiar with Java (cuts out some people) - Is skilled with Haskell (a fair bet for many on this mailing list, at least) - Can work in the Manhattan area (cuts out a *lot* of people) I'm not sure how many people *exist* who meet all these criteria. ;-) I'd probably start by dropping your "top university" requirement, since I don't think it's all that relevant if you find your candidate has the skills you're looking for. You might even find someone who fits yet doesn't have a CompSci BS degree; you can phrase it as "a BS in computer science or an equivalent strong background in theoretical computer science" or somesuch, as appropriate. From gmane at asztal.net Tue Dec 8 13:22:41 2009 From: gmane at asztal.net (Lee Houghton) Date: Tue Dec 8 13:00:07 2009 Subject: [Haskell-cafe] Re: Handles with their IOMode in their type In-Reply-To: References: Message-ID: On 08/12/2009 03:54, Bas van Dijk wrote: > Could not get to sleep tonight so I got up and hacked this together: > > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 > > Does something like this already exist on hackage: > > If not, I may turn this into a package and upload it tomorrow. > > Comments, criticism and patches are welcome. > > regards, > > Bas I like this idea. A small observation, though: > stdin :: ReadModes ioMode => Handle ioMode > stdin = Handle SIO.stdin This allows writing to stdin by choosing ReadWriteMode as the ioMode. I think it would be better to have just > stdin :: Handle ReadMode *HandleExplicitIOMode> hPutStrLn (stdin :: Handle ReadWriteMode) "This shouldn't typecheck!" *** Exception: : hPutStr: illegal operation (handle is not open for writing) This also shows another reason for stdin, stdout and stderr to be monomorphic: > hGetLine stdin :1:0: Ambiguous type variable `ioMode' in the constraint: `ReadModes ioMode' arising from a use of `hGetLine' at :1:0-13 Probable fix: add a type signature that fixes these type variable(s) From vanenkj at gmail.com Tue Dec 8 14:37:19 2009 From: vanenkj at gmail.com (John Van Enk) Date: Tue Dec 8 14:11:42 2009 Subject: [Haskell-cafe] "Rebox Package" or "To Hackage or not to Hackage" Message-ID: Hi List, I've recently had a situation where I used the same pattern quite a bit while reducing and evaluating an AST. I quickly wrapped the operation in a package and stuck it on github. http://github.com/sw17ch/rebox/blob/master/src/Data/Rebox.hs I'm wondering two things: 1) Does any one recognize the pattern I'm using here as something with a different name? 2) Is this worth sticking on Hackage? It's trivial, but we have plenty of trivial concepts on Hackage (and it's not a bad thing). Any feedback would be great. /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/7fdf4866/attachment.html From jon at ffconsultancy.com Tue Dec 8 16:41:37 2009 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue Dec 8 15:02:20 2009 Subject: [Haskell-cafe] Re: can there be (hash-table using) O(n) version of this (I think currently) n log n algo? In-Reply-To: References: <910ddf450907171524x2720c0deya1d524b22698a558@mail.gmail.com> Message-ID: <200912082141.37279.jon@ffconsultancy.com> On Sunday 19 July 2009 09:26:14 Heinrich Apfelmus wrote: > Thomas Hartman wrote: > > The code below is, I think, n log n, a few seconds on a million + element > > list. > > > > I wonder if it's possible to get this down to O(N) by using a > > hashtable implemementation, or other better data structure. > > > > -- findsums locates pairs of integers in a list > > that add up to a wanted sum. > > > > findsums :: [Int] -> Int -> S.Set (Int,Int) > > findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs > > where f (candidates,successes) next = > > if S.member (wanted-next) candidates > > then (candidates, S.insert (next,wanted-next) successes) > > else (S.insert next candidates,successes) > > Remember that hash tables are actually O(key length) instead of O(1), so > I don't think you can break the log n for really large lists this > way since the key length increases as well (unless most elements are > equal anyway). Use a trie of hash tables with ~word-sized pieces of key. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From ok at cs.otago.ac.nz Tue Dec 8 16:09:02 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Tue Dec 8 15:43:27 2009 Subject: [Haskell-cafe] A new form of newtype Message-ID: <02681695-2679-4D71-A359-F1D40E80BD2A@cs.otago.ac.nz> Haskell is very nearly a high level language. One rather unpleasant way in which it lets the the underlying machine show through is integral types. Aside from the unbounded Integer type, which is fine, there are integral types bounded by machine sizes: Int, size unspecified, Data.Int.Int{8,16,32,64}, and Data.Word.Word{8,16,32,64}. There are a number of problems with these. The principal one is that in order to figure out which size is needed, a programmer must do arithmetic. I still remember a student's bitter complaint about being required to find the base 2 logarithm of 32 in an examination where calculators were forbidden... I propose a small addition to 'newtype' syntax: 'newtype' id '=' '[' expr {',' expr}... ']' [deriving-part] The expressions are Integral expressions made from constants and suitable Prelude functions. Each Haskell implementation supports some sublist of the types [Int1,Word1,Int2,Word2,Int3,Word3,...,Int64,Word64, ...,Int256,Word256,...,Integral, _except (It's almost interesting that the Natural type missing from Haskell would go after Integral in this list, and so would never be used.) The effect of the declaration would be to make "id" a copy of the first type in the list of supported types that is big enough to include the value of every expression on the right hand side, except that minBound = the smallest value on the right hand side maxBound = the largest value on the right hand side rather than being the bounds for the underlying type. The instances that could be derived would include Bits, Bounded, Data, Enum, Eq, Integral, Ix, Num, Ord, PrintfArg, Read, Real, Show, Storable, Typable. I'd actually prefer that the default list of derived instances be short, but it's hard to draw an arbitrary line, so the default instances should be the same as the default instances for Int in the same Haskell system. Suppose I knew that I had a 2TB disc (I don't, and wish I did) and wanted to be able to hold not only any file size but the sums and differences of up to 10,000,000 file sizes. (There could be one giant file, and all the file sizes could be the size of that file.) newtype FileSize = [-10000000*2^41,10000000*2^41] I don't see any simple way to get named values into the expressions defining a new integral type, but the use of cpp with Haskell has been common practice for a long time, so #define Tera 2^40 #define Many 10000000 newtype FileSize = [-Many*2*Tera,Many*2*Tera] In this case, FileSize would be a copy of Integer. From ok at cs.otago.ac.nz Tue Dec 8 16:13:57 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Tue Dec 8 15:48:30 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <873a3lewp7.fsf@malde.org> References: <1260215701-sup-7631@peray> <100d01ca7784$ecd968e0$c68c3aa0$@de> <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> <873a3lewp7.fsf@malde.org> Message-ID: <7C2459C7-58C9-4E0C-818B-2020B74704F3@cs.otago.ac.nz> On Dec 8, 2009, at 8:44 PM, Ketil Malde wrote: > "Richard O'Keefe" writes: > >> factors n = [m | m <- [1..n], mod n m == 0] I should remark that I wasn't *trying* to write fast code. I was trying to code as directly as I could, fully expecting to have to rewrite later. I was pleasantly surprised that it was fast enough for my purposes. The focus of my attention was actually on "can this list of numbers be divided into two parts with the same sum", which was to me the novel part. From fw at deneb.enyo.de Tue Dec 8 16:18:20 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue Dec 8 15:52:44 2009 Subject: [Haskell-cafe] Lisp like symbols in haskell In-Reply-To: (jean-christophe mincke's message of "Tue, 8 Dec 2009 09:21:14 +0100") References: Message-ID: <87tyw1w4f7.fsf@mid.deneb.enyo.de> * jean-christophe mincke: > Has there already been attempts to introduce lisp like symbols in haskell? Do you mean something like Objective Caml's polymorphic variants? From vitaliy.akimov at gmail.com Tue Dec 8 16:25:03 2009 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Tue Dec 8 15:59:25 2009 Subject: [Haskell-cafe] "Rebox Package" or "To Hackage or not to Hackage" In-Reply-To: References: Message-ID: Hi John, I don't know if this is useful for you, but these are instances of Cofunctor's comap. For example if we use TypeCompose package we have: rebox f = unFlip . cofmap f . Flip The rest are also Cofunctors. There are a few options. You can either specify instances or use type combinators from category-extras or TypeCompose packages. Basically (a -> a -> b) is curried composition of diagonal Functor from Bifunctor (,) and Cofunctor (Flip (->) a) etc. It's interesting to know more about usage of the pattern for AST reduction. Vitaliy On Tue, Dec 8, 2009 at 9:37 PM, John Van Enk wrote: > Hi List, > I've recently had a situation where I used the same pattern quite a bit > ?while reducing and evaluating an AST. I quickly wrapped the operation in a > package and stuck it on github. > http://github.com/sw17ch/rebox/blob/master/src/Data/Rebox.hs > I'm wondering two things: > 1) Does any one recognize the pattern I'm using here as something with a > different name? > 2) Is this worth sticking on Hackage? It's trivial, but we have plenty of > trivial concepts on Hackage (and it's not a bad thing). > Any feedback would be great. > /jve > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From agocorona at gmail.com Tue Dec 8 16:28:29 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Dec 8 16:02:53 2009 Subject: [Haskell-cafe] can there be (hash-table using) O(n) version of this (I think currently) n log n algo? In-Reply-To: <1887698464.20090718195704@gmail.com> References: <910ddf450907171524x2720c0deya1d524b22698a558@mail.gmail.com> <565557226.20090718141649@gmail.com> <910ddf450907180823s68902889i758489ec80bb5bb1@mail.gmail.com> <1887698464.20090718195704@gmail.com> Message-ID: Any application where multiple updates are done in multiple threads . gain by using a hashTable 2009/7/18 Bulat Ziganshin > Hello Thomas, > > Saturday, July 18, 2009, 7:23:10 PM, you wrote: > > > Going back to my original question, I am now looking for a dead simple > > motivating example for showing the example of using a (good) hashtable > > over Data.Map > > spell checking? > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/f4974ffd/attachment.html From ben.franksen at online.de Tue Dec 8 16:30:40 2009 From: ben.franksen at online.de (Ben Franksen) Date: Tue Dec 8 16:05:28 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: Ketil Malde wrote: > minh thu writes: >> Why should your code be licensed under GPL? > > I think your code is covered by whatever license you wish. > > An aggregate work, on the other hand, would need to be covered by the > GPL, and all source code would have to be available under GPL terms. So > if you distribute your code linked to or incorporating the GPL library, > the whole must conform to the GPL license (source availability and > redistributatbility, etc). > > Your contributions could still be licensed under a different license > (e.g. BSD), as long as the licensing doesn't prevent somebody else to > pick it up and relicense it under GPL. > > At least, that's how I understand things. Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Cheers Ben From ben.franksen at online.de Tue Dec 8 16:36:25 2009 From: ben.franksen at online.de (Ben Franksen) Date: Tue Dec 8 16:11:16 2009 Subject: [Haskell-cafe] Re: Lisp like symbols in haskell References: <4B1E12C9.9000308@cs.caltech.edu> <4d197d970912080058h684bbdb4hc3fd543e5a96dc8e@mail.gmail.com> Message-ID: Vladimir Zlatanov wrote: > I think stable names can be used where symbols are used in scheme. I > think there are better alternatives for different use cases in > haskell. > > For example, symbols are often used to tag values - haskell has > pattern matching on constructors. Here is a link: http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html Cheers Ben From ben.franksen at online.de Tue Dec 8 16:42:56 2009 From: ben.franksen at online.de (Ben Franksen) Date: Tue Dec 8 16:17:43 2009 Subject: [Haskell-cafe] Re: The Transient monad References: Message-ID: +1 Alberto G. Corona wrote: > Hi haskell cafe: > > concerning Stable Names > > http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html > > > makeStableName :: a -> IO (StableName a) > > I Did not test fully my proposal, and I?m thinking aloud, Just to inpire > others and fish some ideas; > > The IO in makeStableName suggest more side effects than makeStableName > really do. But still the call isn't pure. > > For calls such are makeStableName that gives a different result the FIRST > time they are called but return the same result every time in the same > session, I suggest to use a Transient monad: > > > makeStableName :: a -> Transient (StableName a) > > The key here is to maintain the programmer aware that it is not pure, but > there are no IO and that the results have no meaning from session to > session. > > Instance Monad Transient where > Transient x ? f = f x > return x = Transient x > > We can Transient`ize IO calls by means of an implicit memoization: > > liftT:: IO a -> Transient a > liftT= < whatever memoization code> > liftT2=.... > liftT3=.... > > Memorization then is embedded in the monad transformation > This may be more elegant than IO plus unsafePerformIO and is more > informative for the programmer. The transition form IO to pure can be done > in two steps, see below > > Instead of unsafePerformIO, we can use: > > unsafePurifyTransient :: Transient a -> a > unsafePurifyTransient (Transient x) = x > > for the inherently transient calls > > A safer version of unsafePerformIO using implicit memoization could be: > unsafePerformIOT :: IO a -> a > unsafePerformIOT = unsafePurifyTransient . liftT > > unsafePerformIOT guatantee that it returns the same value in the same > session. > > > > > 2009/12/8 Vladimir Zlatanov > >> wrote: >> > I think lisp like symbols could be quite useful in the context of >> embedded >> > DSL to create ... well... symbols that can be interpreted as variables >> > in that DSL. >> >> Well for such use-case you could use either stable names, or recode >> them into a state monad- you will get either a global i.e. lisp like >> unique symbols, or their equivalent within a state context. Or some >> variation of the code posted previously in this thread. From korpios at korpios.com Tue Dec 8 16:46:00 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 16:20:23 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen wrote: > Ketil Malde wrote: >> Your contributions could still be licensed under a different license >> (e.g. BSD), as long as the licensing doesn't prevent somebody else to >> pick it up and relicense it under GPL. >> >> At least, that's how I understand things. > > Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term "GPL-compatible license". GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*. If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. If you don't believe me, ask the people at the Software Freedom Law Center: help@softwarefreedom.org They've answered legal questions for me before. Please note that I'm not raising this issue because I like the GPL (I don't); I'm raising it because I don't think many people understand the consequences of using a GPL'd library. I think there would be more pressure on library authors to not GPL their works if everyone understood how restrictive the GPL was. From holgersiegel74 at yahoo.de Tue Dec 8 16:55:11 2009 From: holgersiegel74 at yahoo.de (Holger Siegel) Date: Tue Dec 8 16:29:38 2009 Subject: [Haskell-cafe] "Rebox Package" or "To Hackage or not to Hackage" In-Reply-To: References: Message-ID: <1260309311.8393.10.camel@cornfed> Am Dienstag, den 08.12.2009, 23:25 +0200 schrieb Vitaliy Akimov: > Hi John, > > I don't know if this is useful for you, but these are instances of > Cofunctor's comap. For example if we use TypeCompose package we have: > > rebox f = unFlip . cofmap f . Flip > > The rest are also Cofunctors. There are a few options. You can either > specify instances or use type combinators from category-extras or > TypeCompose packages. Basically (a -> a -> b) is curried composition > of diagonal Functor from Bifunctor (,) and Cofunctor (Flip (->) a) > etc. You can also define them recursively: rebox0 :: (a -> b) -> c -> c rebox0 _ x = x reboxN :: ((a -> b) -> d -> e) -> (a -> b) -> (b -> d) -> a -> e reboxN reboxM un re = reboxM un . re . un rebox1 :: (a -> b) -> (b -> c) -> a -> c rebox1 = reboxN rebox0 rebox2 :: (a -> b) -> (b -> b -> c) -> a -> a -> c rebox2 = reboxN rebox1 rebox3 :: (a -> b) -> (b -> b -> b -> c) -> a -> a -> a -> c rebox3 = reboxN rebox2 rebox4 = reboxN rebox3 rebox5 = reboxN rebox4 From ganesh at earth.li Tue Dec 8 16:57:50 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue Dec 8 16:32:14 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: On Tue, 8 Dec 2009, Tom Tobin wrote: > On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen wrote: >> Ketil Malde wrote: >>> Your contributions could still be licensed under a different license >>> (e.g. BSD), as long as the licensing doesn't prevent somebody else to >>> pick it up and relicense it under GPL. >>> >>> At least, that's how I understand things. >> >> Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. > > Seriously, no, this is *totally* wrong reading of the GPL, probably > fostered by a misunderstanding of the term "GPL-compatible license". > GPL-compatible means the compatibly-licensed work can be incorporated > into the GPL'd work (the whole of which is GPL'd), *not the other way > around*. If you are forming a derivative work based on the GPL'd > work, and thus you have to release that derivative work under the GPL. The combination of haykll and pandoc clearly must be GPL. I don't think it automatically follows from that that hakyll taken alone must be GPL. One might argue that the hakyll itself must be a derivative work as it builds on pandoc, but equally there may well be at least some pieces of hakyll that have independent uses; in addition someone might write a API-compatible replacement for pandoc that was BSD3. I would therefore argue for clearly marking the hakyll source as BSD3, so long as there is some way to clearly signal that anything compiled from it will necessarily be GPL. Ganesh From twanvl at gmail.com Tue Dec 8 17:05:04 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Dec 8 16:39:27 2009 Subject: [Haskell-cafe] The Transient monad In-Reply-To: References: Message-ID: <4B1ECD90.2060108@gmail.com> Alberto G. Corona wrote: > Hi haskell cafe: > > concerning Stable Names > > The IO in makeStableName suggest more side effects than makeStableName > really do. But still the call isn't pure. > > For calls such are makeStableName that gives a different result the > FIRST time they are called but return the same result every time in the > same session, I suggest to use a Transient monad: makeStableName doesn't really give 'the same result every time', though. For example: *> let sn x = hashStableName <$> makeStableName x *> let x = replicate 3 'x' in (,) <$> sn x <* evaluate x <*> sn x (18,17) After x is evaluated in this example, its stable name changes. Perhaps instead of Transient we could use a name that makes it more clear what is going on, perhaps "ObservingEvaluation". That could also include exception handling, by the way. > makeStableName :: a -> Transient (StableName a) Why not wrap it up in a class? class Monad m => MonadObservingEvaluation m where -- what should go here? perhaps: liftOE :: ObservingEvaluation a -> m a Then we can have makeStableName :: MonadObservingEvaluation m => a -> m (StableName a) Which works both in IO and the new monad. Twan From korpios at korpios.com Tue Dec 8 17:05:17 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 16:39:45 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: On Tue, Dec 8, 2009 at 3:46 PM, Tom Tobin wrote: > If you are forming a derivative work based on the GPL'd > work, and thus you have to release that derivative work under the GPL. Wow, I mangled the syntax on that last sentence. That should read: "If you are forming a derivative work based on the GPL'd work, you thus have to release that derivative work under the GPL." From robgreayer at gmail.com Tue Dec 8 17:13:35 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Tue Dec 8 16:47:59 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote: > On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen > wrote: > > Ketil Malde wrote: > >> Your contributions could still be licensed under a different license > >> (e.g. BSD), as long as the licensing doesn't prevent somebody else to > >> pick it up and relicense it under GPL. > >> > >> At least, that's how I understand things. > > > > Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. > > Seriously, no, this is *totally* wrong reading of the GPL, probably > fostered by a misunderstanding of the term "GPL-compatible license". > GPL-compatible means the compatibly-licensed work can be incorporated > into the GPL'd work (the whole of which is GPL'd), *not the other way > around*. If you are forming a derivative work based on the GPL'd > work, and thus you have to release that derivative work under the GPL. > The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/aa3aaf9e/attachment.html From warren.henning at gmail.com Tue Dec 8 17:17:18 2009 From: warren.henning at gmail.com (Warren Henning) Date: Tue Dec 8 16:51:42 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: <9e5767b0912081417m210d5567mb5b6fa1e1a1a2615@mail.gmail.com> Am I the only one who finds this stuff confusing as hell? On Tue, Dec 8, 2009 at 2:13 PM, Robert Greayer wrote: > The crux here is that the source code of hakyll, released on hackage, is not > a derivative of Pandoc (it contains, as far as I understand it, no Pandoc > source code).? A compiled executable *is* a derivative of Pandoc, so anyone > who *distributes* a compiled executable would need to make *all* the source > available under the GPL (including the hakyll source).? Since the hakyll > package is released under BSD3, this would be allowed (AIUI, IANAL). From ok at cs.otago.ac.nz Tue Dec 8 17:19:17 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Tue Dec 8 16:53:42 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <200912081315.49795.daniel.is.fischer@web.de> References: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> <873a3lewp7.fsf@malde.org> <200912081315.49795.daniel.is.fischer@web.de> Message-ID: On Dec 9, 2009, at 1:15 AM, Daniel Fischer wrote: > Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: >> "Richard O'Keefe" writes: >>> factors n = [m | m <- [1..n], mod n m == 0] >> >> -- saves about 10% time, seems to give the same result: >> factors n = [m | m <- [1..n `div` 2], mod n m == 0]++[n] > > Even faster (for large enough n): > > factors n = > mergeAll [if q == d then [d] else [d, q] | d <- [1 .. isqrt n] > , let (q,r) = n `divMod` > d, r == 0] We can improve on that somewhat: factors 1 = [1] factors n = 1 : candidates 2 4 n [n] where candidates d d2 n hi = if d2 < n then let (q,r) = divMod n d in if r == 0 then d : candidates (d+1) (d2+d+d+1) n (q:hi) else candidates (d+1) (d2+d+d+1) n hi else if d2 == n then d:hi else hi This never constructs a cons cell it doesn't mean to keep. > From korpios at korpios.com Tue Dec 8 17:19:35 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 16:54:00 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: On Tue, Dec 8, 2009 at 4:13 PM, Robert Greayer wrote: > On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote: >> >> On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen >> wrote: >> > Ketil Malde wrote: >> >> Your contributions could still be licensed under a different license >> >> (e.g. BSD), as long as the licensing doesn't prevent somebody else to >> >> pick it up and relicense it under GPL. >> >> >> >> At least, that's how I understand things. >> > >> > Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. >> >> Seriously, no, this is *totally* wrong reading of the GPL, probably >> fostered by a misunderstanding of the term "GPL-compatible license". >> GPL-compatible means the compatibly-licensed work can be incorporated >> into the GPL'd work (the whole of which is GPL'd), *not the other way >> around*. ?If you are forming a derivative work based on the GPL'd >> work, and thus you have to release that derivative work under the GPL. > > The crux here is that the source code of hakyll, released on hackage, is not > a derivative of Pandoc (it contains, as far as I understand it, no Pandoc > source code).? A compiled executable *is* a derivative of Pandoc, so anyone > who *distributes* a compiled executable would need to make *all* the source > available under the GPL (including the hakyll source).? Since the hakyll > package is released under BSD3, this would be allowed (AIUI, IANAL). IANAL either, but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license. If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary. I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested. From korpios at korpios.com Tue Dec 8 17:22:25 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 16:56:50 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <9e5767b0912081417m210d5567mb5b6fa1e1a1a2615@mail.gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <9e5767b0912081417m210d5567mb5b6fa1e1a1a2615@mail.gmail.com> Message-ID: On Tue, Dec 8, 2009 at 4:17 PM, Warren Henning wrote: > Am I the only one who finds this stuff confusing as hell? It *is* confusing as hell, because law is confusing as hell, because it's an "interpreted language" of sorts ? what matters is how judges rule on the law, not just the law as written. Copyleft licenses, contributor license agreements, and other such icky stuff makes me crazy, but it's stuff that has to be at least somewhat understood if you're contributing to open source, IMHO. From robgreayer at gmail.com Tue Dec 8 17:38:02 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Tue Dec 8 17:12:26 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: <4ec472cb0912081438m393f6bdarfe1672633ab4ed6@mail.gmail.com> On Tue, Dec 8, 2009 at 5:13 PM, Robert Greayer wrote: > > The crux here is that the source code of hakyll, released on hackage, is > not a derivative of Pandoc (it contains, as far as I understand it, no > Pandoc source code). A compiled executable *is* a derivative of Pandoc, so > anyone who *distributes* a compiled executable would need to make *all* the > source available under the GPL (including the hakyll source). Since the > hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). > Not to belabor the point (I hope), but consider the following situation -- if the current version of Pandoc, 1.2.1, were released under BSD3, not GPL, it would be obvious that the current version of hakyll could be released as BSD3 as well. After said hakyll release, the Pandoc maintainer would be perfectly within his rights to release an API compatible 1.2.2 version of Pandoc, this time licensed under the GPL. People installing hakyll with cabal might now be building a version of hakyll containing both GPL and BSD3 code. This is not under either author's control, and is perfectly allowable. If the person downloading chooses to redistribute the hakyll executable he's built, he must be aware of and comply with his responsibilities under the GPL, but those would be his responsibilities, not those of the original author of hakyll. (AIUI -- IANAL). (If hakyll had been released under a GPL-incompatible license -- EPL, for example -- then the person downloading hakyll and building the executable could *not* distribute the executable he built. He could use it for his own purposes, but not distribute it. This is the implication of GPL incompatibility. As I Understand It.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/0513645c/attachment.html From t-otto-news at gmx.de Tue Dec 8 17:47:33 2009 From: t-otto-news at gmx.de (Torsten Otto) Date: Tue Dec 8 17:21:57 2009 Subject: [Haskell-cafe] Interactive chatbot In-Reply-To: References: <497D4F71-8839-40C6-8521-9806CA666438@gmx.de> Message-ID: <0B94E63B-FED9-4B91-88F8-17E5D794CA78@gmx.de> No worries, I'd rather have it twice than not at all :-) Thank you all for the helpful tipps. We ended up knowing a lot more about Haskell. The easiest solution however, was to compile it all into an application - tadaa, deleting works as wished for. Regards, Torsten Am 05.11.2009 um 02:00 schrieb Ben Millwood: > Oops, I clicked "reply" instead of "reply to all". Duplicating the > message below. > I suppose this means someone is going to get two copies of this. Sorry someone! > > On Thu, Nov 5, 2009 at 12:56 AM, Ben Millwood wrote: >> On Wed, Nov 4, 2009 at 10:21 PM, Torsten Otto wrote: >>> >>> When we read the user's input through >>>> t <- getLine >>> it is not possible to delete typos before hitting enter and thereby sending >>> the input off to the system (at least in OS X, bash). I didn't find that >>> terribly problematic, but of course it is a bit of a show stopper from their >>> point of view. >>> >> >> As people have said it's worth checking what buffering settings you >> are using (especially note that ghci changes some interesting settings >> in relation to how input is handled, and compiled code may behave >> differently), but it might also be worth checking the terminal >> application's preferences to see if there are settings related to the >> interpretation of the backspace key that you need to twiddle one way >> or the other. In particular, if you are finding that pressing delete >> makes ^H appear on the input line instead of deleting things, or if >> pressing ctrl-H deletes stuff where the delete key fails to do so, it >> might be a problem with your terminal rather than with your program. >> This is only based on what I vaguely remember from faffing with the >> Mac Terminal application some time ago when it wouldn't co-operate >> with screen, but it may be worth a look. >> >> yours, >> Ben Millwood >> From ben.franksen at online.de Tue Dec 8 17:56:20 2009 From: ben.franksen at online.de (Ben Franksen) Date: Tue Dec 8 17:31:09 2009 Subject: [Haskell-cafe] Re: Re: ANN: hakyll-0.1 References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: Ganesh Sittampalam wrote: > On Tue, 8 Dec 2009, Tom Tobin wrote: >> On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen >> wrote: >>> Ketil Malde wrote: >>>> Your contributions could still be licensed under a different license >>>> (e.g. BSD), as long as the licensing doesn't prevent somebody else to >>>> pick it up and relicense it under GPL. >>>> >>>> At least, that's how I understand things. >>> >>> Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. >> >> Seriously, no, this is *totally* wrong reading of the GPL, probably >> fostered by a misunderstanding of the term "GPL-compatible license". >> GPL-compatible means the compatibly-licensed work can be incorporated >> into the GPL'd work (the whole of which is GPL'd), *not the other way >> around*. No. See http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatIsCompatible Quote: "What does it mean to say that two licenses are compatible? In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.[...]" and http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatDoesCompatMean "What does it mean to say a license is compatible with the GPL? It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program." >> If you are forming a derivative work based on the GPL'd >> work, and thus you have to release that derivative work under the GPL. Maybe, but I doubt very much that publishing a library that merely calls functions from some other (GPL'ed) library makes your library a "derivative work" of the former. It is something different if you /combine/ those two libraries into e.g. an application. > The combination of haykll and pandoc clearly must be GPL. I don't think it > automatically follows from that that hakyll taken alone must be GPL. Right that was the point I wanted to make. It is the responsibility of the programmer who uses hakyll (and thus, presumably, pandoc) in order to produce a complete program to make sure that his work complies with /both/ licenses. This is possible if the two licences are compatible, see quotes above. > One > might argue that the hakyll itself must be a derivative work as it builds > on pandoc, If this were so, then /all/ of Linux (including all the thousands of programs found on linux distributions) would have to be licensed under GPL, which is clearly not the case. It would also mean that MS could require fees from people who program against the windows API. Cheers Ben From ben.franksen at online.de Tue Dec 8 17:59:24 2009 From: ben.franksen at online.de (Ben Franksen) Date: Tue Dec 8 17:35:05 2009 Subject: [Haskell-cafe] Re: Re: ANN: hakyll-0.1 References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: Tom Tobin wrote: > On Tue, Dec 8, 2009 at 4:13 PM, Robert Greayer > wrote: >> On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote: >>> >>> On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen >>> wrote: >>> > Ketil Malde wrote: >>> >> Your contributions could still be licensed under a different license >>> >> (e.g. BSD), as long as the licensing doesn't prevent somebody else to >>> >> pick it up and relicense it under GPL. >>> >> >>> >> At least, that's how I understand things. >>> > >>> > Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. >>> >>> Seriously, no, this is *totally* wrong reading of the GPL, probably >>> fostered by a misunderstanding of the term "GPL-compatible license". >>> GPL-compatible means the compatibly-licensed work can be incorporated >>> into the GPL'd work (the whole of which is GPL'd), *not the other way >>> around*. ?If you are forming a derivative work based on the GPL'd >>> work, and thus you have to release that derivative work under the GPL. >> >> The crux here is that the source code of hakyll, released on hackage, is >> not a derivative of Pandoc (it contains, as far as I understand it, no >> Pandoc source code).? A compiled executable *is* a derivative of Pandoc, >> so anyone who *distributes* a compiled executable would need to make >> *all* the source available under the GPL (including the hakyll source).? >> Since the hakyll package is released under BSD3, this would be allowed >> (AIUI, IANAL). > > IANAL either, but my understanding is that judges take a very dim view > of attempts like this to evade the requirements of a license. If a > piece of software is built on another piece of software, it doesn't > matter if you're looking at source code or a binary. > > I can write the SFLC and pose a hypothetical situation that captures > the gist of what we're talking about, and post the response here, if > anyone is interested. Yes, very much. (and IANAL, too, of course). Cheers Ben From lennart at augustsson.net Tue Dec 8 18:02:30 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Dec 8 17:36:53 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: References: <3BD2B0F4-13C4-4D66-AC9D-4658CD2C7783@cs.otago.ac.nz> <873a3lewp7.fsf@malde.org> <200912081315.49795.daniel.is.fischer@web.de> Message-ID: And if you use quotRem it's faster (unless you're running on some exotic hardware like NS32K). On Tue, Dec 8, 2009 at 10:19 PM, Richard O'Keefe wrote: > > On Dec 9, 2009, at 1:15 AM, Daniel Fischer wrote: > >> Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: >>> >>> "Richard O'Keefe" writes: >>>> >>>> factors n = [m | m <- [1..n], mod n m == 0] >>> >>> ?-- saves about 10% time, seems to give the same result: >>> ?factors n = [m | m <- [1..n `div` 2], mod n m == 0]++[n] >> >> Even faster (for large enough n): >> >> factors n = >> ? mergeAll [if q == d then [d] else [d, q] | d <- [1 .. isqrt n] >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?, let (q,r) = n `divMod` d, r >> == 0] > > We can improve on that somewhat: > > factors 1 = [1] > factors n = 1 : candidates 2 4 n [n] > ?where candidates d d2 n hi = > ? ? ? ? ?if d2 < n then > ? ? ? ? ? ? let (q,r) = divMod n d in > ? ? ? ? ? ? ? if r == 0 then d : candidates (d+1) (d2+d+d+1) n (q:hi) > ? ? ? ? ? ? ? ? ? ? ? ? else ? ? candidates (d+1) (d2+d+d+1) n ? ?hi > ? ? ? ? ?else if d2 == n then d:hi else hi > > This never constructs a cons cell it doesn't mean to keep. > >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mle+hs at mega-nerd.com Tue Dec 8 18:09:02 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue Dec 8 17:43:29 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: <20091209100902.6b76ff96.mle+hs@mega-nerd.com> Tom Tobin wrote: > IANAL either, Ditto! > but my understanding is that judges take a very dim view > of attempts like this to evade the requirements of a license. I can't see how any judge could possibly come to that conclusion in this case. Studying the terms of the GPL and the BSD3 a lawyer would come to the conclusion that the terms of the GPL are narrower than the terms of the BSD3 but that independently developed code under the BSD3 license can be linked to GPL code as long as the terms of the GPL are followed. For instance, there are many BSD licensed drivers in the GPL licensed Linux kernel. > If a > piece of software is built on another piece of software, it doesn't > matter if you're looking at source code or a binary. The GPL makes this distinction. The GPL says if you distribute a binary from GPL sources you must release the sources as well. It does not however say that if you release sources you must also release binaries. > I can write the SFLC and pose a hypothetical situation that captures > the gist of what we're talking about, and post the response here, if > anyone is interested. I suggest that you put together a question, post it here for comments and when there is some form of concensus pass the question on the the SFLC. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From daniel.is.fischer at web.de Tue Dec 8 18:09:03 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 8 17:44:55 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: References: Message-ID: <200912090009.04154.daniel.is.fischer@web.de> Am Mittwoch 09 Dezember 2009 00:02:30 schrieb Lennart Augustsson: > And if you use quotRem it's faster (unless you're running on some > exotic hardware like NS32K). Yes, but Henning Thielemann was busy in the exception vs. error thread, so I didn't want to distract him by using quotRem :D From gcross at phys.washington.edu Tue Dec 8 18:15:28 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Tue Dec 8 17:50:33 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: <3DEA31F8-6CB0-4167-A3B4-6C4AAC2F3EFA@phys.washington.edu> > On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote: > > The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe To add to this thought: if the author releases hakyll under the BSD3 license, then even though programs using it *presently* must be licensed under the GPL since Pandoc is, if the Pandoc license were one day changed to BSD3, or hakyll patched to use a different BSD3-compatable API, then at that point programs using it could be licensed under BSD3. Cheers, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/2fd8b7b9/attachment.html From sebastian.sylvan at gmail.com Tue Dec 8 18:33:02 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue Dec 8 18:07:25 2009 Subject: [Haskell-cafe] Haskell job opportunity In-Reply-To: References: <26697169.post@talk.nabble.com> Message-ID: <3d96ac180912081533w13d50738hbd96889e15f0667f@mail.gmail.com> On Tue, Dec 8, 2009 at 5:54 PM, Tom Tobin wrote: > On Tue, Dec 8, 2009 at 11:09 AM, siki wrote: > > I've posted this before but did not get a whole lot of responses, so here > it > > is again: > [...] > > You should have at least a bachelor?s degree in computer science from a > top > > university > > Might I humbly suggest that this is going to severely limit your > hiring options? You're looking for the intersection of sets of people > who: > > - Have a BS in computer science (cuts out a fair number of people) > - Graduated from a "top university" (cuts out a *lot* of people) > - Is familiar with Java (cuts out some people) > - Is skilled with Haskell (a fair bet for many on this mailing list, at > least) > - Can work in the Manhattan area (cuts out a *lot* of people) > - Is looking for a job. Haskell is still exotic enough that it has a disproportionate amount of Giant Brains among its practitioners. Companies tend to want to hang on to these, even in a recession. -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/ab1b94b4/attachment.html From dave at zednenem.com Tue Dec 8 18:34:16 2009 From: dave at zednenem.com (David Menendez) Date: Tue Dec 8 18:08:39 2009 Subject: [Haskell-cafe] "Rebox Package" or "To Hackage or not to Hackage" In-Reply-To: References: Message-ID: <49a77b7a0912081534g190a1b72q120ccadb83bdadac@mail.gmail.com> On Tue, Dec 8, 2009 at 4:25 PM, Vitaliy Akimov wrote: > Hi John, > > I don't know if this is useful for you, but these are instances of > Cofunctor's comap. For example if we use TypeCompose package we have: > > rebox f = unFlip . cofmap f . Flip Alternately, rebox = flip (.) -- Dave Menendez From korpios at korpios.com Tue Dec 8 18:38:24 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 18:12:50 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <3DEA31F8-6CB0-4167-A3B4-6C4AAC2F3EFA@phys.washington.edu> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <3DEA31F8-6CB0-4167-A3B4-6C4AAC2F3EFA@phys.washington.edu> Message-ID: On Tue, Dec 8, 2009 at 5:15 PM, Gregory Crosswhite wrote: > On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote: > > The crux here is that the source code of hakyll, released on hackage, is not > a derivative of Pandoc (it contains, as far as I understand it, no Pandoc > source code).? A compiled executable *is* a derivative of Pandoc, so anyone > who *distributes* a compiled executable would need to make *all* the source > available under the GPL (including the hakyll source).? Since the hakyll > package is released under BSD3, this would be allowed (AIUI, IANAL). Hm, I didn't write that; I think your quoting is off. ^_^ From korpios at korpios.com Tue Dec 8 18:40:04 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 18:14:28 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081438m393f6bdarfe1672633ab4ed6@mail.gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <4ec472cb0912081438m393f6bdarfe1672633ab4ed6@mail.gmail.com> Message-ID: On Tue, Dec 8, 2009 at 4:38 PM, Robert Greayer wrote: > Not to belabor the point (I hope), but consider the following situation -- > if the current version of Pandoc, 1.2.1, were released under BSD3, not GPL, > it would be obvious that the current version of hakyll could be released as > BSD3 as well.? After said hakyll release, the Pandoc maintainer would be > perfectly within his rights to release an API compatible 1.2.2 version of > Pandoc, this time licensed under the GPL.? People installing hakyll with > cabal might now be building a version of hakyll containing both GPL and BSD3 > code.? This is not under either author's control, and is perfectly > allowable.? If the person downloading chooses to redistribute the hakyll > executable he's built, he must be aware of and comply with his > responsibilities under the GPL, but those would be his responsibilities, not > those of the original author of hakyll.? (AIUI -- IANAL). The compatible-API issue is very murky ??it does indeed seem weird that creating an API-compatible BSD'd library would magically "release" users. I've seen other discussions regarding this, and about the sanest conclusion I've drawn is "ask your lawyer". :-/ From ketil at malde.org Tue Dec 8 18:41:02 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Dec 8 18:15:24 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: (Tom Tobin's message of "Tue, 8 Dec 2009 16:19:35 -0600") References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: <87hbs16nld.fsf@malde.org> Tom Tobin writes: >>>>> Your contributions could still be licensed under a different license >>>>> (e.g. BSD), as long as the licensing doesn't prevent somebody else to >>>>> pick it up and relicense it under GPL. >>>> Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. >>> Seriously, no, this is *totally* wrong reading of the GPL, probably >>> fostered by a misunderstanding of the term "GPL-compatible license". >>> GPL-compatible means the compatibly-licensed work can be incorporated >>> into the GPL'd work You can incorporate all you want, as long as you don't distribute the result. >>> If you are forming a derivative work based on the GPL'd >>> work, and thus you have to release that derivative work under the GPL. Yes, but I understood the situation to be that Hakyll is using Pandoc as a library, accessing its API. If this makes Hakyll a derivative of Pandoc, then anything running on your Linux box must be GPL, as it uses system calls (the API of the GPL'ed kernel). >> available under the GPL (including the hakyll source).? Since the hakyll >> package is released under BSD3, this would be allowed (AIUI, IANAL). > IANAL either, but my understanding is that judges take a very dim view > of attempts like this to evade the requirements of a license. I don't consider it an attempt to evade requirements. For all I know, the author of Hakyll wrote it using public documentation, and never even had Pandoc in his possession. Why should he be bound by its copyright license? I've used public specs to write software to parse files generated by proprietary software. My code is GPL, and I think it would be incredibly unreasonable to force me to abide by whatever license the generating software uses. > If a piece of software is built on another piece of software, it doesn't > matter if you're looking at source code or a binary. The question is if using an API is sufficient to make it a derived work. > I can write the SFLC and pose a hypothetical situation that captures > the gist of what we're talking about, and post the response here, if > anyone is interested. I'm curious, at least. If nobody else wants it, feel free to email me privately. -k -- If I haven't seen further, it is by standing in the footprints of giants From korpios at korpios.com Tue Dec 8 18:45:10 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 18:19:33 2009 Subject: [Haskell-cafe] Re: Re: ANN: hakyll-0.1 In-Reply-To: References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> Message-ID: On Tue, Dec 8, 2009 at 4:56 PM, Ben Franksen wrote: >> On Tue, 8 Dec 2009, Tom Tobin wrote: >>> Seriously, no, this is *totally* wrong reading of the GPL, probably >>> fostered by a misunderstanding of the term "GPL-compatible license". >>> GPL-compatible means the compatibly-licensed work can be incorporated >>> into the GPL'd work (the whole of which is GPL'd), *not the other way >>> around*. > > No. See http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatIsCompatible > > Quote: > > "What does it mean to say that two licenses are compatible? > > In order to combine two programs (or substantial parts of them) into a > larger work, you need to have permission to use both programs in this way. > If the two programs' licenses permit this, they are compatible. If there is > no way to satisfy both licenses at once, they are incompatible.[...]" That's what compatibility means in general for any set of licenses, yes. > and http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatDoesCompatMean > > "What does it mean to say a license is compatible with the GPL? > > It means that the other license and the GNU GPL are compatible; you can > combine code released under the other license with code released under the > GNU GPL in one larger program." And, yes ? this is what I said. ^_^ > Ganesh Sittampalam wrote: >> One >> might argue that the hakyll itself must be a derivative work as it builds >> on pandoc, > > If this were so, then /all/ of Linux (including all the thousands of > programs found on linux distributions) would have to be licensed under GPL, > which is clearly not the case. No, it doesn't work that way; merely running a program under GPL'd Linux isn't the same thing. From korpios at korpios.com Tue Dec 8 18:55:55 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 18:30:19 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <20091209100902.6b76ff96.mle+hs@mega-nerd.com> References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> Message-ID: On Tue, Dec 8, 2009 at 5:09 PM, Erik de Castro Lopo wrote: > Tom Tobin wrote: >> I can write the SFLC and pose a hypothetical situation that captures >> the gist of what we're talking about, and post the response here, if >> anyone is interested. > > I suggest that you put together a question, post it here for comments > and when there is some form of concensus pass the question on the the > SFLC. This sounds good to me; I don't think any of us are lawyers, but if we have lawyers available to ask questions for free, let's take advantage of it. I'm thinking something along these lines: Myself and several other members of a mailing list for a particular programming language were recently discussing a situation where a BSD-licensed work required a GPL'd library. The ensuing discussion led to much confusion all around, as we've all read various (different!) things regarding honoring the GPL, and even where we've read the same thing, we took away different conclusions. We came up with a list of questions that would help us understand the matter better, and we were hoping you could help us answer them. The background situation: X is a library distributed under the GPL. Y is another library that uses that library and requires it in order to compile and function. 1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)? 2) If so, what would Y's author need to do (or *not* do)? 3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD? (Feel free to add more questions, and/or suggest tweaks.) From will at willthompson.co.uk Tue Dec 8 19:00:36 2009 From: will at willthompson.co.uk (Will Thompson) Date: Tue Dec 8 18:35:03 2009 Subject: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2 In-Reply-To: <3283f7fe0911112057r7f18567bk536627046b6865ca@mail.gmail.com> References: <3283f7fe0911112057r7f18567bk536627046b6865ca@mail.gmail.com> Message-ID: <4B1EE8A4.1060301@willthompson.co.uk> Hi John, Very nice work! As it happens, Dafydd Harries and I wrote another native implementation of the D-Bus protocol, but yours is much more complete, and the documentation/commentary is ace. A refreshing change from the daily pain of libdbus and dbus-glib... :-) I'm looking at modifying Bustle (which draws sequence diagrams of D-Bus traffic; ) to log raw D-Bus messages to a pcap file, rather than the current custom text format that includes just the information from the message the UI needs alongside a timestamp. Then the UI would read the pcap file, and feed the data through a D-Bus parser before processing it further. Now that there's a decent D-Bus implementation available, it seems like a good time to have a crack at this. However, I can't find a way to feed a bytestring to dbus-core and get back a ReceivedMessage. Is this deliberately not exposed? While it's obviously not useful in general, it would be very useful for Bustle. (The alternative is to construct a fake connection to myself and feed messages down it, I guess.) Also, the Haskell bit of Bustle is licensed under the LGPL (v2.1 or later), but dbus-{core,client} are under the GPL v3. Could you be convinced to reconsider the licensing of your packages? D-Bus is often used to allow free and non-free applications to play nicely together, letting free software be used in situations where it would otherwise be passed over; while I for one don't plan to write any non-free D-Bus applications in Haskell any time soon, it'd be nice not to write Haskell off for such applications. -- Will From ketil at malde.org Tue Dec 8 19:08:18 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Dec 8 18:42:39 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: (Tom Tobin's message of "Tue, 8 Dec 2009 17:55:55 -0600") References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> Message-ID: <878wdd6mbx.fsf@malde.org> Tom Tobin writes: > 1) Is there any scenario where Y can be distributed under a non-GPL > license (e.g., the BSD)? > 2) If so, what would Y's author need to do (or *not* do)? > 3) If Y must be released under the GPL under the above scenario, and > someone subsequently wrote library Z, an API compatible replacement > for X, and released it under the BSD license, would Y's author now be > permitted to release Y under the BSD? I wonder: if *using* an API makes a work derived, wouldn't replicating it be equally problematic? (The question stands anyhow, since 'someone' might be the author of the original library, who is clearly not limited by his licensing...) -k -- If I haven't seen further, it is by standing in the footprints of giants From mle+hs at mega-nerd.com Tue Dec 8 19:10:43 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue Dec 8 18:45:06 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> Message-ID: <20091209111043.781cfbf3.mle+hs@mega-nerd.com> Tom Tobin wrote: > The background situation: X is a library distributed under the GPL. Y > is another library that uses that library and requires it in order to > compile and function. You probably also need to bring in application Z which uses library X via library Y, because library Y is not usable by itself. > 1) Is there any scenario where Y can be distributed under a non-GPL > license (e.g., the BSD)? You need to make sure they know that your are talking about the 3 clause BSD license, the one the FSF calls the Modified BSD license. > 2) If so, what would Y's author need to do (or *not* do)? > > 3) If Y must be released under the GPL under the above scenario, and > someone subsequently wrote library Z, an API compatible replacement > for X, and released it under the BSD license, would Y's author now be > permitted to release Y under the BSD? The author is always allowed to relicense their own work under whatever license they choose. For instance there are libraries released under the GPL which are also available under a commercial use license for use in closed source products. The requirement here is that the library is soley written by the person doing the dual licensing and/or all other contributors have assigned their rights. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From korpios at korpios.com Tue Dec 8 19:21:20 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 18:55:43 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <20091209111043.781cfbf3.mle+hs@mega-nerd.com> References: <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <20091209111043.781cfbf3.mle+hs@mega-nerd.com> Message-ID: On Tue, Dec 8, 2009 at 6:10 PM, Erik de Castro Lopo wrote: > Tom Tobin wrote: > >> The background situation: X is a library distributed under the GPL. ?Y >> is another library that uses that library and requires it in order to >> compile and function. > > You probably also need to bring in application Z which uses library > X via library Y, because library Y is not usable by itself. I think this is implicit in calling something a library; are there any questions where it would come up? >> 1) Is there any scenario where Y can be distributed under a non-GPL >> license (e.g., the BSD)? > > You need to make sure they know that your are talking about the 3 clause > BSD license, the one the FSF calls the Modified BSD license. Good point. >> 3) If Y must be released under the GPL under the above scenario, and >> someone subsequently wrote library Z, an API compatible replacement >> for X, and released it under the BSD license, would Y's author now be >> permitted to release Y under the BSD? > > The author is always allowed to relicense their own work under whatever > license they choose. Well I think that's actually what we're wondering here ??under what circumstances is Y's author permitted to choose his license at will? > For instance there are libraries released under > the GPL which are also available under a commercial use license for > use in closed source products. The requirement here is that the library > is soley written by the person doing the dual licensing and/or all other > contributors have assigned their rights. But those libraries don't, in turn, depend on GPL'd libraries written by different authors. I think the answer to the "can Y's author choose the BSD3 for Y" question will also answer this for cases where there's a further, different-author GPL dependency involved. From korpios at korpios.com Tue Dec 8 19:22:56 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 18:57:20 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <20091209111043.781cfbf3.mle+hs@mega-nerd.com> Message-ID: On Tue, Dec 8, 2009 at 6:21 PM, Tom Tobin wrote: > Well I think that's actually what we're wondering here ??under what > circumstances is Y's author permitted to choose his license at will? I think I phrased this poorly; it's more "under what circumstances is Y's author permitted to distribute Y under the terms of a non-GPL license?" From matthew at brecknell.net Tue Dec 8 19:25:02 2009 From: matthew at brecknell.net (Matthew Brecknell) Date: Tue Dec 8 18:59:28 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> Message-ID: <1260318302.7272.59.camel@localhost> Tom Tobin wrote: > I'm thinking something along these lines: > > The background situation: X is a library distributed under the GPL. Y > is another library that uses that library and requires it in order to > compile and function. > > 1) Is there any scenario where Y can be distributed under a non-GPL > license (e.g., the BSD)? > > 2) If so, what would Y's author need to do (or *not* do)? > > 3) If Y must be released under the GPL under the above scenario, and > someone subsequently wrote library Z, an API compatible replacement > for X, and released it under the BSD license, would Y's author now be > permitted to release Y under the BSD? > > (Feel free to add more questions, and/or suggest tweaks.) Based on the discussion so far, I think you need to distinguish between distributing source and distributing binaries. For example: Background: X is a library distributed under GPL. Y is another library which calls external functions in the API of X. Assume X and Y have different authors. 1. Can the author of Y legally distribute the *source* of Y under a non-GPL licence (BSD3, Modified BSD, etc), assuming such source is distributed without any binaries, and is distributed separately from X? 2. etc. Question 1 covers the situation at hand, and keeps the initial line of questioning simple and specific. From korpios at korpios.com Tue Dec 8 19:31:43 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 19:06:05 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <1260318302.7272.59.camel@localhost> References: <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> Message-ID: On Tue, Dec 8, 2009 at 6:25 PM, Matthew Brecknell wrote: > Based on the discussion so far, I think you need to distinguish between > distributing source and distributing binaries. For example: > > Background: X is a library distributed under GPL. Y is another library > which calls external functions in the API of X. Assume X and Y have > different authors. > > 1. Can the author of Y legally distribute the *source* of Y under a > non-GPL licence (BSD3, Modified BSD, etc), assuming such source is > distributed without any binaries, and is distributed separately from X? I think you're right ? this cuts right to the heart of the main difference in understanding so far. Question 2 can be "If the answer to 1 is no, is there *any* circumstance under which the author of Y can distribute the source of Y under a non-GPL license?" From ivan.miljenovic at gmail.com Tue Dec 8 19:38:42 2009 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue Dec 8 19:13:09 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> (Robert Greayer's message of "Tue, 8 Dec 2009 17:13:35 -0500") References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> Message-ID: <87my1tgewd.fsf@gmail.com> Apologies, Robert, for you getting this twice: I forgot to CC the list as well. Robert Greayer writes: > The crux here is that the source code of hakyll, released on hackage, is not > a derivative of Pandoc (it contains, as far as I understand it, no Pandoc > source code). A compiled executable *is* a derivative of Pandoc, so anyone > who *distributes* a compiled executable would need to make *all* the source > available under the GPL (including the hakyll source). Since the hakyll > package is released under BSD3, this would be allowed (AIUI, IANAL). That is my understanding as well: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL ,---- | If a library is released under the GPL (not the LGPL), does that mean | that any program which uses it has to be under the GPL or a | GPL-compatible license? | | Yes, because the program as it is actually run includes the library. `---- Thus, it means your program using Pandoc can be BSD3; but it can never be used in a proprietary program. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com From jmillikin at gmail.com Tue Dec 8 19:42:02 2009 From: jmillikin at gmail.com (John Millikin) Date: Tue Dec 8 19:16:25 2009 Subject: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2 In-Reply-To: <4B1EE8A4.1060301@willthompson.co.uk> References: <3283f7fe0911112057r7f18567bk536627046b6865ca@mail.gmail.com> <4B1EE8A4.1060301@willthompson.co.uk> Message-ID: <3283f7fe0912081642q36da0aafk1ac44ce81843751a@mail.gmail.com> On Tue, Dec 8, 2009 at 16:00, Will Thompson wrote: > However, I can't find a way to feed a bytestring to dbus-core and get > back a ReceivedMessage. Is this deliberately not exposed? While it's > obviously not useful in general, it would be very useful for Bustle. > (The alternative is to construct a fake connection to myself and feed > messages down it, I guess.) > It's not exposed at the moment, because I didn't want to commit to a public API until I knew it was going to work. When I get home tonight, I'll add it to the API. Aside from message marshal/unmarshal, are there any other bits of the protocol which would be helpful to expose? > Also, the Haskell bit of Bustle is licensed under the LGPL (v2.1 or > later), but dbus-{core,client} are under the GPL v3. Could you be > convinced to reconsider the licensing of your packages? D-Bus is often > used to allow free and non-free applications to play nicely together, > letting free software be used in situations where it would otherwise be > passed over; while I for one don't plan to write any non-free D-Bus > applications in Haskell any time soon, it'd be nice not to write Haskell > off for such applications. > The following bit is just me being a free-software hippy, so take it with a grain of salt, but: There's already a DBus package for Haskell under the BSD 3-clause license at . It's a bit awkward to use, because it's a binding to libdbus, but it exists. dbus-core and -client offer developers ease of use in exchange for the developers granting rights to their users. Additionally, as far as I know, the teams porting DBus to Windows and OS X haven't released anything stable / usable yet -- if somebody's using DBus, it's probably on Linux, FreeBSD, etc. If any developers want to develop proprietary software 1) for Linux/BSD 2) in Haskell 3) using D-Bus, I'm sure both of them will take a break from rolling that boulder uphill to ask about relicensing. If it really is an issue -- ie, you'd be willing to use a less-featured library to avoid the GPL -- then please reply and I'll re-license. I don't want to negatively impact anybody else working on free software. But I'd rather keep the license as strong as possible until somebody actually needs it to be weakened. From jmillikin at gmail.com Tue Dec 8 19:58:35 2009 From: jmillikin at gmail.com (John Millikin) Date: Tue Dec 8 19:32:58 2009 Subject: [Haskell-cafe] A new form of newtype In-Reply-To: <02681695-2679-4D71-A359-F1D40E80BD2A@cs.otago.ac.nz> References: <02681695-2679-4D71-A359-F1D40E80BD2A@cs.otago.ac.nz> Message-ID: <3283f7fe0912081658t335bf7a5qe9a3e2cef1766d97@mail.gmail.com> What would these types be used for? If your students are complaining about having to perform logarithms to store integers, inform them of the "Integer" type. The existing sized types -- Word/Int [8, 16, 32, 64] -- are useful primarily because they match up with "standard" integral data types in other languages. They're great for FFI, (un)marshaling via ByteString, and occasional low-level code. In contrast, there is (to my knowledge) no machine with 42-bit integers, so there's no point to defining such intermediate types. In your FileSize example, it would be much easier to simply use: newtype FileSize = FileSize Integer since then your code will cope nicely when everybody upgrades to PB disks in a few years. If you need particular bounds, create your own instance of Bounded. From z_axis at 163.com Tue Dec 8 19:59:21 2009 From: z_axis at 163.com (zaxis) Date: Tue Dec 8 19:33:45 2009 Subject: [Haskell-cafe] How to understand such a `case` ? Message-ID: <26703526.post@talk.nabble.com> findHelper (x:xs) = do -- not lazy, but that's not really important here filex <- fileExists (file x) filex' <- fileExists (file' x) case () of _ | filex -> return $ Just $ file x | filex' -> return $ Just $ file' x | otherwise -> findHelper xs file x = foldl1 joinFileName (x ++ [helper]) file' x = (file x) ++ (getConfig "exe_ext") Sincerely! ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703526.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From jmillikin at gmail.com Tue Dec 8 20:11:26 2009 From: jmillikin at gmail.com (John Millikin) Date: Tue Dec 8 19:45:49 2009 Subject: [Haskell-cafe] How to understand such a `case` ? In-Reply-To: <26703526.post@talk.nabble.com> References: <26703526.post@talk.nabble.com> Message-ID: <3283f7fe0912081711m4ef164e9o936380dc105f9603@mail.gmail.com> Sorry; forgot to CC the list That case is equivalent to: if filex then return $ Just $ file x else if filex' then return $ Just $ file' x else findHelper xs The specific syntax being used is called a "pattern guard": http://www.haskell.org/haskellwiki/Pattern_guard On Tue, Dec 8, 2009 at 16:59, zaxis wrote: > > findHelper (x:xs) = do -- not lazy, but that's not really important here > ? ? ? ?filex ?<- fileExists (file ?x) > ? ? ? ?filex' <- fileExists (file' x) > ? ? ? ?case () of > ? ? ? ? ? ?_ > ? ? ? ? ? ? ? ?| filex ? ? -> return $ Just $ file ?x > ? ? ? ? ? ? ? ?| filex' ? ?-> return $ Just $ file' x > ? ? ? ? ? ? ? ?| otherwise -> findHelper xs > ? ?file ?x = foldl1 joinFileName (x ++ [helper]) > ? ?file' x = (file x) ++ (getConfig "exe_ext") > > Sincerely! > > ----- > fac n = foldr (*) 1 [1..n] > -- > View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703526.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tomahawkins at gmail.com Tue Dec 8 20:23:38 2009 From: tomahawkins at gmail.com (Tom Hawkins) Date: Tue Dec 8 19:58:01 2009 Subject: [Haskell-cafe] Haskell job opportunity In-Reply-To: References: <26697169.post@talk.nabble.com> Message-ID: <594c1e830912081723y18e63ec6h23d096f273482048@mail.gmail.com> On Tue, Dec 8, 2009 at 6:54 PM, Tom Tobin wrote: > On Tue, Dec 8, 2009 at 11:09 AM, siki wrote: >> You should have at least a bachelor?s degree in computer science from a top >> university > > Might I humbly suggest that this is going to severely limit your > hiring options? ?You're looking for the intersection of sets of people > who: > > - Have a BS in computer science (cuts out a fair number of people) > - Graduated from a "top university" (cuts out a *lot* of people) > - Is familiar with Java (cuts out some people) > - Is skilled with Haskell (a fair bet for many on this mailing list, at least) We hired a technician by trade with no engineering or computer science degree, but who happened to show an unique aptitude and interest for learning a wide variety of programming languages. Though he had no prior experience with Haskell, or functional programming for that matter, in a few months he became a very proficient Haskell developer. I've also experienced many engineers with advanced degrees from prominent schools who have had tremendous difficulty understanding the language -- and the benefits -- of Haskell. I'm starting to believe people are either wired for it, or they are not. > - Can work in the Manhattan area (cuts out a *lot* of people) My boss has said that the relative time zone is just as good as co-location. So I'd like to put a call out for resumes, which would help me build a case for opening reqs in the US -- and Canada and Central and South America for that matter. We need people interest in: - hybrid vehicles - electro-hydraulics - feedback control systems - safety-critical, hard real-time embedded - compiler design - formal methods - and of course, functional languages We use Haskell for many tools and Atom for embedded code and verification (http://hackage.haskell.org/package/atom). http://www.eaton.com From z_axis at 163.com Tue Dec 8 20:26:11 2009 From: z_axis at 163.com (zaxis) Date: Tue Dec 8 20:00:34 2009 Subject: [Haskell-cafe] How to understand such a `case` ? In-Reply-To: <3283f7fe0912081711m4ef164e9o936380dc105f9603@mail.gmail.com> References: <26703526.post@talk.nabble.com> <3283f7fe0912081711m4ef164e9o936380dc105f9603@mail.gmail.com> Message-ID: <26703743.post@talk.nabble.com> thanks for your quick answer ! Then what's the advantage using such a `case` not using `if` statement given by you ? For me, the `if` statement is more clear . jmillikin wrote: > > Sorry; forgot to CC the list > > That case is equivalent to: > > if filex > then return $ Just $ file x > else if filex' > then return $ Just $ file' x > else findHelper xs > > > The specific syntax being used is called a "pattern guard": > http://www.haskell.org/haskellwiki/Pattern_guard > > On Tue, Dec 8, 2009 at 16:59, zaxis wrote: >> >> findHelper (x:xs) = do -- not lazy, but that's not really important here >> ? ? ? ?filex ?<- fileExists (file ?x) >> ? ? ? ?filex' <- fileExists (file' x) >> ? ? ? ?case () of >> ? ? ? ? ? ?_ >> ? ? ? ? ? ? ? ?| filex ? ? -> return $ Just $ file ?x >> ? ? ? ? ? ? ? ?| filex' ? ?-> return $ Just $ file' x >> ? ? ? ? ? ? ? ?| otherwise -> findHelper xs >> ? ?file ?x = foldl1 joinFileName (x ++ [helper]) >> ? ?file' x = (file x) ++ (getConfig "exe_ext") >> >> Sincerely! >> >> ----- >> fac n = foldr (*) 1 [1..n] >> -- >> View this message in context: >> http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703526.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > > ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703743.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From daniel.is.fischer at web.de Tue Dec 8 20:35:32 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 8 20:11:24 2009 Subject: [Haskell-cafe] How to understand such a `case` ? In-Reply-To: <26703526.post@talk.nabble.com> References: <26703526.post@talk.nabble.com> Message-ID: <200912090235.33133.daniel.is.fischer@web.de> Am Mittwoch 09 Dezember 2009 01:59:21 schrieb zaxis: > findHelper (x:xs) = do -- not lazy, but that's not really important here > filex <- fileExists (file x) > filex' <- fileExists (file' x) > case () of > _ > > | filex -> return $ Just $ file x > | filex' -> return $ Just $ file' x > | otherwise -> findHelper xs Such a 'case' is a typographically more pleasant way to test multiple alternatives than a nested if-then-else chain. With an if-then-else chain, the code would wander to the right and be less easily followed. Using a case () of _ | condition1 -> thing1 | condition2 -> thing2 | condition3 -> thing3 ... you can nicely align all possibilities. Since the 'case' here is extraneous to the code logic and serves only aesthetic ends, such a practice may be frowned upon. > > file x = foldl1 joinFileName (x ++ [helper]) > file' x = (file x) ++ (getConfig "exe_ext") > > Sincerely! > From daniel.is.fischer at web.de Tue Dec 8 21:07:51 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Dec 8 20:43:44 2009 Subject: [Haskell-cafe] How to understand such a `case` ? In-Reply-To: <26703743.post@talk.nabble.com> References: <26703526.post@talk.nabble.com> <3283f7fe0912081711m4ef164e9o936380dc105f9603@mail.gmail.com> <26703743.post@talk.nabble.com> Message-ID: <200912090307.51485.daniel.is.fischer@web.de> Am Mittwoch 09 Dezember 2009 02:26:11 schrieb zaxis: > thanks for your quick answer ! Then what's the advantage using such a > `case` not using `if` statement given by you ? ? For me, the `if` statement > is more clear . Once you have a lot of possibilities to check, if-then-else cascades become rather unreadable. However, it might then be advisable to rethink your code, perhaps introduce a choice combinator. From robgreayer at gmail.com Tue Dec 8 21:19:37 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Tue Dec 8 20:53:59 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <87my1tgewd.fsf@gmail.com> References: <20091208180930.15ccd76b.mle+hs@mega-nerd.com> <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <87my1tgewd.fsf@gmail.com> Message-ID: <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> On Tue, Dec 8, 2009 at 7:38 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote: > Apologies, Robert, for you getting this twice: I forgot to CC the list > as well. > > Robert Greayer writes: > > The crux here is that the source code of hakyll, released on hackage, is > not > > a derivative of Pandoc (it contains, as far as I understand it, no Pandoc > > source code). A compiled executable *is* a derivative of Pandoc, so > anyone > > who *distributes* a compiled executable would need to make *all* the > source > > available under the GPL (including the hakyll source). Since the hakyll > > package is released under BSD3, this would be allowed (AIUI, IANAL). > > > That is my understanding as well: > > http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL > > ,---- > | If a library is released under the GPL (not the LGPL), does that mean > | that any program which uses it has to be under the GPL or a > | GPL-compatible license? > | > | Yes, because the program as it is actually run includes the library. > `---- > > Thus, it means your program using Pandoc can be BSD3; but it can never > be used in a proprietary program. > > There's another FAQ on GNU site that, I think, addresses the Pandoc/Hakyll situation directly: http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL "You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions. " -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/e1f28a0b/attachment.html From jmillikin at gmail.com Tue Dec 8 21:54:32 2009 From: jmillikin at gmail.com (John Millikin) Date: Tue Dec 8 21:28:54 2009 Subject: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2 In-Reply-To: <3283f7fe0912081642q36da0aafk1ac44ce81843751a@mail.gmail.com> References: <3283f7fe0911112057r7f18567bk536627046b6865ca@mail.gmail.com> <4B1EE8A4.1060301@willthompson.co.uk> <3283f7fe0912081642q36da0aafk1ac44ce81843751a@mail.gmail.com> Message-ID: <3283f7fe0912081854k414a1adcxb60de5ce0e57e888@mail.gmail.com> 0.7 released -- exposes the DBus.Wire module, which contains functions for marshaling and unmarshaling messages. Also supports detecting invalid UTF-8 when parsing (previously, it'd just error out). No other significant changes. https://dl.dropbox.com/u/1947532/dbus-core_0.7/index.html https://dl.dropbox.com/u/1947532/dbus-core_0.7.pdf It's difficult to know in advance how many bytes will be needed from the socket, so unmarshalMessage is written to pull them from a monad. If you're using it within pure code, you'll want to use Data.Binary.Get (or similar) to implement your parser: ------------------------------------------------------------------------------------- import qualified Data.Binary.Get as G import qualified Data.ByteString.Lazy as BL bytes = BL.pack [1, 2, 3, 4, 5...] getBytes = G.getLazyByteString . fromIntegral received = G.runGet (unmarshalMessage getBytes) bytes ------------------------------------------------------------------------------------- From ok at cs.otago.ac.nz Tue Dec 8 23:22:46 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Tue Dec 8 22:57:12 2009 Subject: [Haskell-cafe] A new form of newtype In-Reply-To: <3283f7fe0912081658t335bf7a5qe9a3e2cef1766d97@mail.gmail.com> References: <02681695-2679-4D71-A359-F1D40E80BD2A@cs.otago.ac.nz> <3283f7fe0912081658t335bf7a5qe9a3e2cef1766d97@mail.gmail.com> Message-ID: <9D13DF62-7168-4687-B5A0-7AA0469988DF@cs.otago.ac.nz> On Dec 9, 2009, at 1:58 PM, John Millikin wrote: > What would these types be used for? If your students are complaining > about having to perform logarithms to store integers, inform them of > the "Integer" type. I mentioned one student who couldn't compute log 32 *himself* 2 to point out that >> people are bad at arithmetic <<. As my later example made clear, base 2 logarithms are not the only calculations one may need to perform. I would want to use these types practically any time that I want to choose bounded integer types for my own purposes. > The existing sized types -- Word/Int [8, 16, 32, 64] -- are useful > primarily because they match up with "standard" integral data types in > other languages. They're great for FFI, (un)marshaling via ByteString, > and occasional low-level code. Well, no. If you want to match up with Java's byte, short, int, or long, then yes, Int8, Int16, Int32, or Int64 are a good match. If you want to interface with C, you really really ought to be using Data.Foreign.{CChar,CSChar,CUChar,CShort,CUShort,CInt,CUInt,CLong, CULong,CPtrdiff,CSize,CWchar,CSigAomic,CLLong,CULLong,CIntPtr, CUintPtr,CIntMax,CUintMax,CTime} or Foreign.C.Error.Errno, or System.Posix.Types.{you can read the list yourself} and you may well find yourself wishing for others. _These_ are the '"standard" integral data types' in C, and they exist precisely because the programmer has no other portable way of specifying them. MacOS X gives me library support for integers up to 1024 bits; if I want to interface to those, what do I do? Never mind not getting what I ask for, as things standard I can't even _ask_. People are now writing EDSLs using Haskell to generate code for all sorts of interesting things. What if you want to use Haskell as a host for an EDSL targeted at a 24-bit DSP? > In contrast, there is (to my knowledge) no machine with 42-bit > integers, so there's no point to defining such intermediate types. There may not be MACHINES with 42-bit integers, but that doesn't mean there aren't PROBLEMS that need them. This whole idea of "let the machine dictate the sizes" is precisely what I'm complaining of. The Mac OS X library, as I noted above, has /System/Library/Frameworks/Accelerate.framework/Frameworks/\ vecLib.framework/Headers/vBigNum.h vS128 vS256 vS512 vS1024 signed vU128 vU256 vU512 vU1024 unsigned and I'm pretty sure the hardware doesn't do 1024 bit integers directly. > In your FileSize example, it would be much easier to simply use: > > newtype FileSize = FileSize Integer sure it would, BUT IT WOULDN'T BE BOUNDED. By this argument, the Haskell type 'Int' should not exist; except for using System.* and Foreign.* interface types we should not be using bounded integers at all. > since then your code will cope nicely when everybody upgrades to PB > disks in a few years. If you need particular bounds, create your own > instance of Bounded. Sorry, but creating instances of Bounded is what a compiler is for. If I don't write it, I won't wrong it. Put together Data.Int, Data.Word, Foreign.*, System.*, and Haskell _already_ has oodles of integral newtypes. All I'm asking for is a human-oriented way of doing more of the same. If wanting a human-oriented way of doing things were unreasonable, we would be unreasonable to use Haskell, wouldn't we? From korpios at korpios.com Wed Dec 9 00:19:47 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 23:54:10 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <87my1tgewd.fsf@gmail.com> <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> Message-ID: On Tue, Dec 8, 2009 at 8:19 PM, Robert Greayer wrote: > There's another FAQ on GNU site that, I think, addresses the Pandoc/Hakyll > situation directly: > > http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL > > "You have a GPL'ed program that I'd like to link with my code to build a > proprietary program. Does the fact that I link with your program mean I have > to GPL my program? > > ??? Not exactly. It means you must release your program under a license > compatible with the GPL (more precisely, compatible with one or more GPL > versions accepted by all the rest of the code in the combination that you > link). The combination itself is then available under those GPL versions. " I'll confess to not being sure what exactly this means; this seems to imply that if you never distribute the GPL'd code itself, you're fine. In temporary lieu of posing questions explicitly to the SFLC, I dug up a copy of _Intellectual Property and Open Source_ by Foobar (and published by O'Reilly), and found this (from an entire chapter ? Chapter 12 ? about the GPL): "Nevertheless, there is a persistent issue that won?t go away?whether linking programs together creates a derivative work. If linking creates a derivative work, the GPL applies to the linked program; otherwise, the GPL doesn?t apply." ... "In legal practice, this arises as a common concern of clients just getting into open source. This question is usually phrased as either, 'Can I load and use a GPL-licensed library without applying the GPL to my application?' or, 'Do I have to apply the GPL to my plug-in for a particular program if that program is licensed under the GPL?'" ... "I won?t keep you in suspense; the short answer is that we don?t know." It then goes on with the "long" answer, which is honestly confusing as hell. There's even a question in the FAQ that goes like this: "Q: That is different than the official GPL FAQ! Why?" "A: The GPL FAQ was written in inexact language, and gives the impression that the rules regarding derivative works may have greater reach than current copyright law allows. The FSF has repeatedly stated, however, that they believe in copyright minimalism and that the GPL should not be interpreted to extend beyond the reach of copyright." And the final answer is best: "Q: Can I depend on the answers in this Q&A to keep me out of trouble?" "A: No. This is our best understanding of copyright law as it stands right now, but it could change tomorrow?and nobody really knows until these questions are resolved in a court of law." Oh dear Ceiling Cat, I have *no* idea at this point. Much of the FAQ deals with distributing *binaries*, though, not source alone. I'd still like to get a (somewhat?) straight answer from the SFLC folks, though. If it turns out that Hakyll *is* okay to be BSD3 licensed so long as neither any binary nor the GPL'd work's source is distributed under non-GPL terms, well ... I'll say that the meaning of "BSD licensed" will have become much less reliable, since it means you actually have to trace the genealogy of the libraries you use *all* the way back in order to understand the situation for certain. From korpios at korpios.com Wed Dec 9 00:20:55 2009 From: korpios at korpios.com (Tom Tobin) Date: Tue Dec 8 23:55:16 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <87my1tgewd.fsf@gmail.com> <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> Message-ID: On Tue, Dec 8, 2009 at 11:19 PM, Tom Tobin wrote: > ?In temporary lieu of posing questions explicitly to the SFLC, I dug > up a copy of _Intellectual Property and Open Source_ by Foobar ::facepalm:: I wrote "Foobar" as a placeholder as I was typing, and never replaced it. The author's name is Van Lindberg. From jon.fairbairn at cl.cam.ac.uk Wed Dec 9 04:36:57 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Wed Dec 9 04:11:41 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <7b501d5c0912080253o3b98fec0rf8a508d56d4c5610@mail.gmail.com> Message-ID: Deniz Dogan writes: > 2009/12/8 Jon Fairbairn : >> Deniz Dogan writes: >> >>> [...] allow hyphens in identifiers, much like in Lisp >>> languages? E.g. hello-world would be a valid function name. >> >> I (among others) suggested it right at the beginning when we >> were first defining the lexical syntax > > I just like the standard Lisp naming convention better than camel > casing and saw someone on #haskell mentioning it the other day. No > biggie though. I prefer it too, but as far as Haskell is concerned, it's one of those things that's not really worth changing at this stage of its life. Changing the syntactic category of Unicode HYPHEN (U+2010) might still be possible, but someone (with more stamina than me) would have to advocate it. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From uzytkownik2 at gmail.com Wed Dec 9 04:54:15 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Wed Dec 9 04:28:58 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> Message-ID: <1260352455.2949.7.camel@picard> On Tue, 2009-12-08 at 10:56 +0100, Deniz Dogan wrote: > Has there been any serious suggestion or attempt to change the syntax > of Haskell to allow hyphens in identifiers, much like in Lisp > languages? E.g. hello-world would be a valid function name. > You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. About unicode - if something looks the same it should be parsed the same. I mean - we have already had problem historically with tab vs. spaces (vide Make). BTW. You can always use hello_world. Regards From apfelmus at quantentunnel.de Wed Dec 9 05:11:12 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Wed Dec 9 04:46:08 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: <1260215701-sup-7631@peray> References: <1260215701-sup-7631@peray> Message-ID: Nicolas Pouillard wrote: > Henning Thielemann wrote: >> @Apfelmus: >> >> For practical purposes I think Train should have swapped type parameters >> in order to make Functor act on the type of the list elements. >> >> >> data Train b a = Wagon a (Train b a) >> | Loco b > > The functor on the Loco/Caboose makes sense too and swapping the arguments > is less natural to read. It's a bifunctor! :D I don't really mind. The application "list that may end with an error" uses a fixed b , so putting the a at the end makes sense. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From dan.doel at gmail.com Wed Dec 9 05:14:10 2009 From: dan.doel at gmail.com (Dan Doel) Date: Wed Dec 9 04:48:35 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <1260352455.2949.7.camel@picard> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> Message-ID: <200912090514.11012.dan.doel@gmail.com> On Wednesday 09 December 2009 4:54:15 am Maciej Piechotka wrote: > You mean to parse a - b differently then a-b? You don't have the problem > in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. > > About unicode - if something looks the same it should be parsed the > same. I mean - we have already had problem historically with tab vs. > spaces (vide Make). > > BTW. You can always use hello_world. hello'world is also an option. I'm a fan of hyphens in names, as well (I use them in Agda, where there's no naming distinction for operators), but I don't really expect it to happen in Haskell. From deniz.a.m.dogan at gmail.com Wed Dec 9 05:40:18 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Wed Dec 9 05:14:59 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <1260352455.2949.7.camel@picard> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> Message-ID: <7b501d5c0912090240p60b1d1a6i744f15197ba569a0@mail.gmail.com> 2009/12/9 Maciej Piechotka : > On Tue, 2009-12-08 at 10:56 +0100, Deniz Dogan wrote: >> Has there been any serious suggestion or attempt to change the syntax >> of Haskell to allow hyphens in identifiers, much like in Lisp >> languages? E.g. hello-world would be a valid function name. >> > > You mean to parse a - b differently then a-b? You don't have the problem > in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. > I understand. How do GHC extensions work? Would a (hopefully tiny) GHC extension make it possible to use normal hyphens (i.e. those in ASCII) in identifiers? If so, is anyone interested in writing one? -- Deniz Dogan From lemming at henning-thielemann.de Wed Dec 9 05:47:49 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Dec 9 05:22:10 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <200912090009.04154.daniel.is.fischer@web.de> References: <200912090009.04154.daniel.is.fischer@web.de> Message-ID: On Wed, 9 Dec 2009, Daniel Fischer wrote: > Am Mittwoch 09 Dezember 2009 00:02:30 schrieb Lennart Augustsson: >> And if you use quotRem it's faster (unless you're running on some >> exotic hardware like NS32K). > > Yes, but Henning Thielemann was busy in the exception vs. error thread, so I didn't want > to distract him by using quotRem :D Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert. 8-] Is there an English translation of it? From ketil at malde.org Wed Dec 9 05:59:56 2009 From: ketil at malde.org (Ketil Malde) Date: Wed Dec 9 05:34:15 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: (Tom Tobin's message of "Tue, 8 Dec 2009 23:19:47 -0600") References: <87ws0xn48n.fsf@gmail.com> <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <87my1tgewd.fsf@gmail.com> <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> Message-ID: <874oo05s5v.fsf@malde.org> Tom Tobin writes: > In temporary lieu of posing questions explicitly to the SFLC, I dug > up a copy of _Intellectual Property and Open Source_ by Foobar (and > published by O'Reilly), and found this (from an entire chapter ? > Chapter 12 ? about the GPL): > "Nevertheless, there is a persistent issue that won?t go away?whether > linking programs together creates a derivative work. If linking > creates a derivative work, the GPL applies to the linked program; ^^^^^^^^^^^^^^^^^^^^^ > otherwise, the GPL doesn?t apply." According to this, application Z linking GPL library X and BSD library Y *may* be required to be GPL-redistributable. The is no such requirement on the source code of Y. > If it turns out that Hakyll *is* okay to be BSD3 licensed so > long as neither any binary nor the GPL'd work's source is distributed > under non-GPL terms, well ... I'll say that the meaning of "BSD > licensed" will have become much less reliable, since it means you > actually have to trace the genealogy of the libraries you use *all* > the way back in order to understand the situation for certain. How so? To me it's the exact converse: if the author of Hakyll may *not* distribute his work under the BSD license, just because it is intended to be linked with some GPL code, this complicates issues tremendously. I don't think the FAQs you cited is all that confusing: copyright covers the expression of an idea - i.e. actual source code. If my source code doesn't contain bits of somebody elses source code, I can license it as I wish. All my programs are "intended" to be linked with Linux's libc, and "intended" to call into to Linux kernel. That this should imply a particular licensing seems very counterintuitive, would be impossible to police, and would have a tremendous effect on the software ecosystem. -k -- If I haven't seen further, it is by standing in the footprints of giants From daniel.is.fischer at web.de Wed Dec 9 06:50:44 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Dec 9 06:26:35 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: References: <200912090009.04154.daniel.is.fischer@web.de> Message-ID: <200912091250.45090.daniel.is.fischer@web.de> Am Mittwoch 09 Dezember 2009 11:47:49 schrieb Henning Thielemann: > On Wed, 9 Dec 2009, Daniel Fischer wrote: > > Am Mittwoch 09 Dezember 2009 00:02:30 schrieb Lennart Augustsson: > >> And if you use quotRem it's faster (unless you're running on some > >> exotic hardware like NS32K). > > > > Yes, but Henning Thielemann was busy in the exception vs. error thread, > > so I didn't want to distract him by using quotRem :D > > Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert. 8-] If it were so easy. Not that I'd compare you to Serge Lang, but you also have a reputation besides the zealotism. > > Is there an English translation of it? None that I know of. From dav.vire+haskell at gmail.com Wed Dec 9 07:13:26 2009 From: dav.vire+haskell at gmail.com (David Virebayre) Date: Wed Dec 9 06:47:48 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: References: <200912090009.04154.daniel.is.fischer@web.de> Message-ID: <4c88418c0912090413h2f41fc2dq41dae57af9d456e6@mail.gmail.com> On Wed, Dec 9, 2009 at 11:47 AM, Henning Thielemann wrote: > Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert. 8-] > Is there an English translation of it? Google translate says : "If the reputation is ruined, one can live quite openly." David. From JohnDEarle at cox.net Wed Dec 9 06:36:30 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 07:08:16 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers Message-ID: <0206D53FBF18431C8A0C57CE96307168@JohnPC> A makeshift preprocessor written say in Perl could be used to replace the embedded hyphens with underscores thereby making them synonyms. A list of ways in which hyphens are used in the language will need to be developed so they may be distinguished. You don't want a single line comment sign being taken as containing an embedded hyphen. If done properly it shouldn't cause any problems. It will allow you to side step having to actually modify the language and may be portable across language implementations. I use the C language preprocessor to correct a number of features of the C language syntax that I find ugly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/a78332af/attachment.html From JohnDEarle at cox.net Wed Dec 9 06:42:31 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 07:08:29 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers Message-ID: <7F58B8C5671D48058881FE90B98BCB62@JohnPC> Oh yes I forgot. You will also need to map not merely those places where hyphens are used by the language, but also those circumstances where, wondering how to state it abstractly, anyway in string literals and such where substitutions should not occur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/6fe32f42/attachment.html From chris at eidhof.nl Wed Dec 9 07:41:22 2009 From: chris at eidhof.nl (Chris Eidhof) Date: Wed Dec 9 07:15:44 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9110264EF@GBLONXMB02.corp.amvescap.net> References: <20091206223855.GC920@whirlpool.galois.com> <87iqcjfbqk.fsf@malde.org> <125EACD0CAE4D24ABDB4D148C4593DA9110264EF@GBLONXMB02.corp.amvescap.net> Message-ID: Also, there is a paper about doing a type-safe diff in Agda, http://portal.acm.org/citation.cfm?id=1596614.1596624 I heard rumors that the library will be ported to Haskell. -chris On 8 dec 2009, at 15:20, Bayley, Alistair wrote: >> From: haskell-cafe-bounces@haskell.org >> [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ketil Malde >> >> Don Stewart writes: >> >> >>> http://hackage.haskell.org/package/Diff >> >> Wherein we can read: >> >> | This is an implementation of the O(ND) diff algorithm >> [...]. It is O(mn) >> | in space. >> >> At first I thought 'N' and 'M' would be the lengths of the lists, and >> 'D' is the number of differences, but then the space bound >> doesn't make >> sense. I tried to find the reference, but Citeseer is down >> (again. sigh). >> >> Anybody know what the bounds really are? > > > I think the space bounds are O(M+N). Section "4b. A Linear Space > Refinement" concludes with "Unfortunately, the input sequences A and B > must be kept in memory, implying that a total of O(M+N) space is > needed." > > BTW, there is a minor improvement to this algorithm (claims to be > faster, same space usage): > http://research.janelia.org/myers/Papers/np_diff.pdf > > found via: > > http://scholar.google.com/scholar?q=%22An+O(NP)+Sequence+Comparison+Algo > rithm.%22 > > I thought this paper was easier to understand. > > Alistair > ***************************************************************** > Confidentiality Note: The information contained in this message, > and any attachments, may contain confidential and/or privileged > material. It is intended solely for the person(s) or entity to > which it is addressed. Any review, retransmission, dissemination, > or taking of any action in reliance upon this information by > persons or entities other than the intended recipient(s) is > prohibited. If you received this in error, please contact the > sender and delete the material from any computer. > ***************************************************************** > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mauricio.antunes at gmail.com Wed Dec 9 08:19:21 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Wed Dec 9 07:54:13 2009 Subject: [Haskell-cafe] Checking dependencies from C packages in cabal Message-ID: Hi, all, When pkg-config info is not available for a library (when I could use pkgconfig-depends), what should I use to check if needed libraries are installed and to give the compiler all needed info about include files and library location? Also, is it possible to do that without configure and make files? I have no experience with them. I also tried reading the Distribution module, but wasn't able to recognize what could be a natural way to handle this problem. Thanks, Maur?cio From leather at cs.uu.nl Wed Dec 9 08:25:22 2009 From: leather at cs.uu.nl (Sean Leather) Date: Wed Dec 9 08:00:03 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: References: <20091206223855.GC920@whirlpool.galois.com> <87iqcjfbqk.fsf@malde.org> <125EACD0CAE4D24ABDB4D148C4593DA9110264EF@GBLONXMB02.corp.amvescap.net> Message-ID: <3c6288ab0912090525x1d521b9dmb40faf6fb82ad854@mail.gmail.com> On Wed, Dec 9, 2009 at 13:41, Chris Eidhof wrote: > Also, there is a paper about doing a type-safe diff in Agda, > http://portal.acm.org/citation.cfm?id=1596614.1596624 > Surprisingly, the paper also discusses a comparable implementation in Haskell. I heard rumors that the library will be ported to Haskell. > Yes, I heard that this library will be released at some point. Wonder how that's going... Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/abdb6f6f/attachment.html From v.dijk.bas at gmail.com Wed Dec 9 08:35:21 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Dec 9 08:09:43 2009 Subject: [Haskell-cafe] ANNOUNCE: bindings-libusb-1.4.2 Message-ID: Hello, I just uploaded a new release of Maur?cio C. Antunes' bindings-libusb to hackage. See: http://hackage.haskell.org/package/bindings-libusb-1.4.2 bindings-libusb is a bindings-DSL based, low-level binding to libusb. This release adds support for the recent libusb-1.0.5. BTW, there is work being done to create a Windows port for libusb. This means that in the near future libusb and therefor bindings-libusb and my usb packages will work on all major platforms, hooray! regards, Bas From v.dijk.bas at gmail.com Wed Dec 9 08:35:27 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Dec 9 08:09:51 2009 Subject: [Haskell-cafe] ANNOUNCE: usb-0.3 Message-ID: Hello I made a new release of my usb library for high-level communication with usb devices from Haskell. See: http://hackage.haskell.org/package/usb-0.3 I made the following changes compared to the previous 0.2.0.1: - Moved the enumeration of usb devices in its own module: System.USB.Enumeration - Moved the device descriptor inside the device type so that you can retrieve it without doing IO, e.g: deviceDesc :: Device -> DeviceDesc - Moved the configuration descriptors inside the device descriptor so you can retrieve them without doing IO, e.g: deviceConfigs :: DeviceDesc -> [ConfigDesc] - Implemented standard device requests that are missing from libusb. - Made the timeout of I/O operations explicit. Now all I/O operations return an additional Bool that indicates if the operation has timed out. If an operation timed out does not mean there is no result, it just means that the result may be incomplete. - Added experimental (and still untested) support for iteratees for doing predictable, high-performance, safe, and elegant input processing using the iteratee package. See module: System.USB.IO.Synchronous.Enumerator - Fixed some asynchronous exception related bugs (put a needed bracket, block and unblock here and there). - Finally some functions, constructors and types got renamed, documentation got updated and extended and some refactoring has taken place. As always: questions, comments and patches are more than welcome. darcs get http://code.haskell.org/~basvandijk/code/usb regards, Bas From v.dijk.bas at gmail.com Wed Dec 9 08:35:32 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Dec 9 08:09:59 2009 Subject: [Haskell-cafe] ANNOUNCE: usb-safe-0.1 Message-ID: Hello, My usb library provides a standard Haskell abstracting layer over bindings-libusb providing: abstract types instead of Ptrs, automatic marshalling and unmarshalling, automatic garbage collection, exceptions instead of integer return codes, etc.. While all that is very nice there are still some things that you can do wrong. For example doing I/O with a closed device or reading from or writing to an endpoint which doesn't belong to the claimed interface. Or reading from an Out endpoint or writing to an In endpoint. I released the usb-safe package to prevent you making these errors. See: http://hackage.haskell.org/package/usb-safe-0.1 usb-safe provides the following guarantees: - You can't reference handles to devices that are closed. In other words: no I/O with closed handles is possible. - The programmer specifies the region in which devices should remain open. On exit from the region the opened devices are automatically closed. - You can't reference handles to configurations that have not been set. - You can't reference handles to interfaces that have not been claimed. - You can't reference handles to alternates that have not been set. - You can't reference endpoints that don't belong to a setted alternate. - You can't read from an endpoint with an Out transfer direction. - You can't write to an endpoint with an In transfer direction. - You can't read from or write to endpoints with the unsupported transfer types Control and Isochronous. Only I/O with endpoints with the Bulk and Interrupt transfer types is allowed. The primary technique used in usb-safe is called "Lightweight monadic regions" which was invented by Oleg Kiselyov and Chung-chieh Shan. See: http://okmij.org/ftp/Haskell/regions.html#light-weight Note that I consider this a preview release. In fact, I haven't tested the package at all. I can only guarantee you that it will pass the type-checker. As always: questions, comments and patches are more than welcome. Please don't look at the hscolour generated source code from the haddock documentation because it screws up the nice unicode symbols I used. If you want to read the source download the package or go straight to the darcs repos: darcs get http://code.haskell.org/~basvandijk/code/usb-safe regards, Bas From vandijk.roel at gmail.com Wed Dec 9 08:37:35 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Wed Dec 9 08:11:57 2009 Subject: [Haskell-cafe] ANNOUNCE: ls-usb-0.1.0.2 Message-ID: Hello everyone, I have released a minor update of my ls-usb program: http://hackage.haskell.org/package/ls-usb This small utility lists USB devices connected to your system. It can also show you the device descriptors, interface descriptors, vendor and product identifiers and various other things. All in wonderful colours of course. The only major change is that it now depends on usb-0.3.* Regards, Roel van Dijk From adnorm at gmail.com Wed Dec 9 08:37:45 2009 From: adnorm at gmail.com (Matthew) Date: Wed Dec 9 08:12:15 2009 Subject: [Haskell-cafe] OpenAL and Hsndfile Message-ID: <24FCCE80-E822-4953-8E0A-671928047190@gmail.com> Yesterday, I set out to accomplish the challenge of loading and playing a sound from a file. So far, my attempts have resulted only in silence... rather disheartening after all the effort it took to get everything to build and run cleanly. I currently take the following steps: - Load samples from file into an IOCArray using hsndfile - Create an OpenAL buffer which points to the IOCArray - Play sound using OpenAL code is at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13836 I'm wondering if anyone who is familiar with these libraries can tell me if I'm using them sanely or not. Alternatively, if anyone has a favorite sound library and can help me get started with that, I'd be very grateful. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/cfe4b4c4/attachment.html From marco-oweber at gmx.de Wed Dec 9 08:46:53 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Dec 9 08:21:26 2009 Subject: [Haskell-cafe] Checking dependencies from C packages in cabal In-Reply-To: References: Message-ID: <1260366142-sup-2145@nixos> Hi Maur?cio, > When pkg-config info is not available for a library (when I could Until you get the perfect answer you may want to have a look at the cabal definitions of zlib digest OpenGLRaw GLUT readline GLFW wxcore terminfo berkeleydb BerkeleyDB hubris pcre-light HDBC-mysql HDBC-sqlite3 HDBC-odbc HDBC-postgresql They all require additional C libraries to built. Also make sure to search the Cabal mailinglist and maybe even move this thread to the Cabal mailinglist. Eg just typing pkg-config and cabal into google revealed: http://markmail.org/message/aumw5ustnyrishvw There is a also a bug tracker for Cabal. Marc Weber From duncan.coutts at googlemail.com Wed Dec 9 08:50:34 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed Dec 9 08:24:57 2009 Subject: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling? In-Reply-To: References: Message-ID: <1260366634.13548.5164.camel@localhost> On Mon, 2009-12-07 at 20:31 +0100, Henning Thielemann wrote: > Somehow I missed this thread. I want to say that I have implemented a general > way to add the information of an exception to the "end" of an arbitrary data > structure. > > http://hackage.haskell.org/packages/archive/explicit-exception/0.1.4/doc/html/Control-Monad-Exception-Asynchronous.html > > > Duncan already mentioned it: > > > data Exceptional e a = Exceptional { > > exception :: Maybe e > > result :: a > > } > > > However it's pretty clear from the structure of this type that it cannot > > cope with lazy error handling in sequences. If you try it you'll find > > you cannot do it without space leaks. > > Actually you spotted the space leak - but how is it pretty clear, that it > has the space leak? Yes you're right, it's not that clear. First time I saw the type my intuition was that would have a space leak but I had to do some work to demonstrate it. I was misremembering, it's only clear in retrospect :-) > I also agree with you, that the possibility to access the result directly, > and thus easily ignore the exception is bad. I thought it could be > improved by removing the field accessors and instead provide the function: > > switch :: (Maybe e -> c) -> (a -> c) -> Exceptional e a -> c True. As a general approach though, I think I rather like just making up extra algebraic types and handling them with their natural folds and unfolds. It's very much in the pure lazy FP tradition. Duncan From vandijk.roel at gmail.com Wed Dec 9 08:58:05 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Wed Dec 9 08:32:26 2009 Subject: [Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1 Message-ID: Hello, I would like the announce the release of my package unicode-symbols: http://hackage.haskell.org/package/unicode-symbols It offers alternative symbols for a number of common functions and operators from the base and containers packages. When used in combination with the language extension UnicodeSyntax you can write really nice code. The only thing missing is a nice ? symbol. The documentation on hackage should be pretty self explanatory. For each symbol the documentation gives its exact definition. The source code however, probably due to a bug in hscolour, is totally unreadable. To view the sources simply download the package and use a text editor. I tried to be conservative with the choice of unicode symbols. I have defined the division sign (?) to be (/). But it could just as well be defined as 'div'. I do not know what would be the logical choice. Another choice that could lead to some discussion is the definition of (?) to be 'Data.Set.isProperSubsetOf' and (?) to be 'Data.Set.isSubsetOf'. An alternative choice would be to have (?) for 'isProperSubsetOf' and (?) for 'isSubsetOf'. I choose the former because it is more symmetrical with (<) and (?). This package was inspired by unicode-prelude from P?ter Divi?nszky: http://hackage.haskell.org/package/unicode-prelude Regards, Roel van Dijk From korpios at korpios.com Wed Dec 9 09:16:27 2009 From: korpios at korpios.com (Tom Tobin) Date: Wed Dec 9 08:50:48 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <874oo05s5v.fsf@malde.org> References: <40a414c20912080242m2ce8f860vcf3f6a09b7fa7ce3@mail.gmail.com> <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <87my1tgewd.fsf@gmail.com> <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> <874oo05s5v.fsf@malde.org> Message-ID: On Wed, Dec 9, 2009 at 4:59 AM, Ketil Malde wrote: > Tom Tobin writes: >> If it turns out that Hakyll *is* okay to be BSD3 licensed so >> long as neither any binary nor the GPL'd work's source is distributed >> under non-GPL terms, well ... I'll say that the meaning of "BSD >> licensed" will have become much less reliable, since it means you >> actually have to trace the genealogy of the libraries you use *all* >> the way back in order to understand the situation for certain. > > How so? ?To me it's the exact converse: if the author of Hakyll may > *not* distribute his work under the BSD license, just because it is > intended to be linked with some GPL code, this complicates issues > tremendously. For instance, it would mean that businesses which may be writing proprietary software can't assume they can freely use a liberally licensed (e.g., BSD3) library ? which would *completely* go against the prevailing understanding of liberally licensed software. Tainting your software with a GPL dependency without realizing it is a terrifying prospect (and certainly one of the questions I'd now like to pose to the SFLC). From stephen.tetley at gmail.com Wed Dec 9 09:42:14 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Wed Dec 9 09:16:34 2009 Subject: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? Message-ID: <5fdc56d70912090642p585376efoe729274cc8a515ec@mail.gmail.com> Hi All, Would a pure Haskell version of pexports be useful to the Haskell community? For a Sunday afternoon hack that turned out to take a bit more effort (its now Wednesday), I thought I'd code up a tool that extracts function symbols from .dll's (also when I first looked at the C pexports it seemed somewhat unadopted, though checking today it appears to in MinGW, so my local MinGW must be out-of-date). If there are compelling uses that aren't covered by pexports and would ease Haskell C binding problems on Windows, I don't mind polishing up my tool, but otherwise I've exhausted my natural interest. Best wishes Stephen From v.dijk.bas at gmail.com Wed Dec 9 09:50:08 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Dec 9 09:24:29 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: usb-safe-0.1 In-Reply-To: References: Message-ID: On Wed, Dec 9, 2009 at 2:35 PM, Bas van Dijk wrote: > Hello, > > My usb library provides a standard Haskell abstracting layer over > bindings-libusb providing: abstract types instead of Ptrs, automatic > marshalling and unmarshalling, automatic garbage collection, > exceptions instead of integer return codes, etc.. > > While all that is very nice there are still some things that you can > do wrong. For example doing I/O with a closed device or reading from > or writing to an endpoint which doesn't belong to the claimed > interface. Or reading from an Out endpoint or writing to an In > endpoint. > > I released the usb-safe package to prevent you making these errors. See: > > http://hackage.haskell.org/package/usb-safe-0.1 > > usb-safe provides the following guarantees: > > - ?You can't reference handles to devices that are closed. In other > words: no I/O with closed handles is possible. > > - The programmer specifies the region in which devices should remain > open. On exit from the region the opened devices are automatically > closed. > > - You can't reference handles to configurations that have not been set. > > - You can't reference handles to interfaces that have not been claimed. > > - You can't reference handles to alternates that have not been set. > > - You can't reference endpoints that don't belong to a setted alternate. > > - You can't read from an endpoint with an Out transfer direction. > > - You can't write to an endpoint with an In transfer direction. > > - You can't read from or write to endpoints with the unsupported > transfer types Control and Isochronous. Only I/O with endpoints with > the Bulk and Interrupt transfer types is allowed. > > The primary technique used in usb-safe is called "Lightweight monadic > regions" which was invented by Oleg Kiselyov and Chung-chieh Shan. > See: > > http://okmij.org/ftp/Haskell/regions.html#light-weight > > Note that I consider this a preview release. In fact, I haven't tested > the package at all. I can only guarantee you that it will pass the > type-checker. > > As always: questions, comments and patches are more than welcome. > > Please don't look at the hscolour generated source code from the > haddock documentation because it screws up the nice unicode symbols I > used. If you want to read the source download the package or go > straight to the darcs repos: > > darcs get http://code.haskell.org/~basvandijk/code/usb-safe > > regards, > > Bas > I just released a new 0.2 version of usb-safe which adds the type synonym: type TopDeviceRegion s = DeviceRegionT s IO and the function: runTopDeviceRegion ? (? s. TopDeviceRegion s ?) ? IO ? I changed the name of 'forkDeviceRegionT' to 'forkTopDeviceRegion' and changed its type accordingly. Because these are API changes and additions I bumped the version from 0.1 to 0.2 following the PVP[1]. See: http://hackage.haskell.org/package/usb-safe-0.2 darcs get http://code.haskell.org/~basvandijk/code/usb-safe regards, Bas [1] http://haskell.org/haskellwiki/Package_versioning_policy From robgreayer at gmail.com Wed Dec 9 09:54:02 2009 From: robgreayer at gmail.com (Robert Greayer) Date: Wed Dec 9 09:28:24 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <4ec472cb0912090651i30e8d922v71576723d1b7318d@mail.gmail.com> References: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <87my1tgewd.fsf@gmail.com> <4ec472cb0912081819v23c043a2k4aa773e2e9181f81@mail.gmail.com> <874oo05s5v.fsf@malde.org> <4ec472cb0912090651i30e8d922v71576723d1b7318d@mail.gmail.com> Message-ID: <4ec472cb0912090654s125e8c72h64a748223f9706cb@mail.gmail.com> sigh -- to the list this time. On Wed, Dec 9, 2009 at 9:16 AM, Tom Tobin wrote: > On Wed, Dec 9, 2009 at 4:59 AM, Ketil Malde wrote: > > Tom Tobin writes: > >> If it turns out that Hakyll *is* okay to be BSD3 licensed so > >> long as neither any binary nor the GPL'd work's source is distributed > >> under non-GPL terms, well ... I'll say that the meaning of "BSD > >> licensed" will have become much less reliable, since it means you > >> actually have to trace the genealogy of the libraries you use *all* > >> the way back in order to understand the situation for certain. > > > > How so? To me it's the exact converse: if the author of Hakyll may > > *not* distribute his work under the BSD license, just because it is > > intended to be linked with some GPL code, this complicates issues > > tremendously. > > For instance, it would mean that businesses which may be writing > proprietary software can't assume they can freely use a liberally > licensed (e.g., BSD3) library ? which would *completely* go against > the prevailing understanding of liberally licensed software. Tainting > your software with a GPL dependency without realizing it is a > terrifying prospect (and certainly one of the questions I'd now like > to pose to the SFLC). > I don't think I follow your reasoning here: certainly, a business can use, freely, the Hakyll library (meaning that they can redistribute, in binary form, their executable built with it, without distributing the Hakyll source or their own source). They cannot freely use the Pandoc library in the same way, because it is GPL. Since the Hakyll library depends on the Pandoc library, they will of course have some trouble with *building* an executable that contains Hakyll but not Pandoc. Both there's no hidden dependency, no 'tainting' of Hakyll involved. There is a danger, of course, that when installing Hakyll (via cabal) the user won't realize they've also installed Pandoc, even though the dependency is clearly specified. The lesson here is that someone packaging an executable for distribution has to be aware of everything they are building into it. It's possible to make a mistake here, if one is not careful. But it doesn't require much diligence to get it right (if you use cabal to build your executable, you have to specify your dependencies. Check the licensing terms of each, and comply). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/48b59532/attachment.html From sk at k-hornz.de Wed Dec 9 10:17:05 2009 From: sk at k-hornz.de (stefan kersten) Date: Wed Dec 9 09:51:29 2009 Subject: [Haskell-cafe] OpenAL and Hsndfile In-Reply-To: <24FCCE80-E822-4953-8E0A-671928047190@gmail.com> References: <24FCCE80-E822-4953-8E0A-671928047190@gmail.com> Message-ID: <4B1FBF71.8020206@k-hornz.de> hi matthew, On 09.12.09 14:37, Matthew wrote: > Yesterday, I set out to accomplish the challenge of loading and playing > a sound from a file. > So far, my attempts have resulted only in silence... rather > disheartening after all the effort > it took to get everything to build and run cleanly. > > I currently take the following steps: > - Load samples from file into an IOCArray using hsndfile > - Create an OpenAL buffer which points to the IOCArray > - Play sound using OpenAL > code is at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13836 could you isolate the problem by checking if the array returned by hsndfile actually contains non-zero sample frames? e.g. by computing the maximum amplitude: (Data.List.foldl' (max) 0 . fmap abs) `fmap` Data.Array.MArray.getElems buffer you could also try to test OpenAL with a synthesized sound, e.g. sin(2*pi*f/fs*k); i'm not familiar with OpenAL, though. From sk at k-hornz.de Wed Dec 9 10:20:59 2009 From: sk at k-hornz.de (stefan kersten) Date: Wed Dec 9 09:55:21 2009 Subject: [Haskell-cafe] ANNOUNCE: usb-0.3 In-Reply-To: References: Message-ID: <4B1FC05B.9080403@k-hornz.de> On 09.12.09 14:35, Bas van Dijk wrote: > I made a new release of my usb library for high-level communication > with usb devices from Haskell. looks great, thanks! do you happen to have some example code for working with HID devices (mice, keyboards, etc.)? From vandijk.roel at gmail.com Wed Dec 9 10:50:08 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Wed Dec 9 10:24:31 2009 Subject: [Haskell-cafe] ANNOUNCE: usb-0.3 In-Reply-To: <4B1FC05B.9080403@k-hornz.de> References: <4B1FC05B.9080403@k-hornz.de> Message-ID: On Wed, Dec 9, 2009 at 4:20 PM, stefan kersten wrote: > looks great, thanks! do you happen to have some example code for working with > HID devices (mice, keyboards, etc.)? The usb package does not support the various device classes directly. You won't find a function like "isKeyPressed ? Device ? KeyCode ? IO Bool". But you could write it based solely on functions from the usb package. Enumerate the devices connected to your system, find your HID device, open a handle (or enter a safe region), choose an interface and an alternative and finally send some sort of control request encoded in a ByteString. The actual bytes you need to send in order to discover if some key on your USB keyboard is pressed is defined somewhere in the USB HID device class specification. If you really need that kind of functionality then you could create a package "usb-hid" that offers an abstraction over the HID device class. But if you just want to know if some key is pressed then a much simpler solution would be to use a library like SDL or GLUT. Keep in mind that all functions in the usb package run in *client side*. To actually use a device (communication) you need the proper permissions, which in practice implies super-user privileges. Libraries like SDL interface with the kernel drivers and do not need such permissions (correct me if I'm wrong). Regards, Roel From nad at Cs.Nott.AC.UK Wed Dec 9 10:51:02 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Wed Dec 9 10:29:25 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? In-Reply-To: References: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> Message-ID: <4B1FC766.1060202@cs.nott.ac.uk> On 2009-12-08 16:11, S. Doaitse Swierstra wrote: > In principle it is not possible to parse left-recursive grammars [...] I suspect that this statement is based on some hidden assumption. It /is/ possible to parse many left recursive grammars using parser combinators, without rewriting the grammars or representing the cycles in the grammars explicitly. See the following paper draft: Total Parser Combinators http://www.cs.nott.ac.uk/~nad/publications/danielsson-parser-combinators.html -- /NAD From leepike at gmail.com Wed Dec 9 11:49:02 2009 From: leepike at gmail.com (Lee Pike) Date: Wed Dec 9 11:23:54 2009 Subject: [Haskell-cafe] Announcing a summer internship for a NASA-sponsored project Message-ID: <47BC400B-BC7F-4647-BD84-7B70578D4088@gmail.com> ************************************************ * ANNOUNCING: * * SUMMER INTERNSHIP FOR NASA-SPONSORED PROJECT * ************************************************ The National Institute of Aerospace (NIA) and Galois, Inc. would like to announce a Summer Visitor position for a joint in the summer of 2010 (and the summer of 2011). The position will be located at the NIA, located in the historic Hampton Roads area of Virginia, U.S. The visitor will work with researchers at both the NIA and Galois. PROJECT OVERVIEW: We are looking for a summer visitor to work on a NASA-sponsored project investigating runtime monitoring applied to hard real-time distributed systems such as avionics. Runtime monitoring is an approach to check a system's conformance to safety specifications at runtime. The work is being directed by Dr. Alwyn Goodloe (NIA) and Dr. Lee Pike (Galois, Inc.)---contact below. The visitor's work will depend on the skills and interests of the student, but it will likely focus on the development and application of of a monitor synthesis tool, CoPilot. Copilot takes property specification and synthesizes monitors for the properties to embedded C. Copilot is a Haskell library built on top of the Haskell eDSL Atom . The work is expected to lead to one or more conference publications. QUALIFICATIONS: * MUST-HAVES: * The candidate should have significant experience in programming in modern typed functional programming languages such as Haskell, OCAML, or Clean (programming will be done mainly in Haskell). * Some experience and exposure to writing and debugging C programs. * Some experience with using and configuring *nix systems. * NICE-TO-HAVES: * Experience with real-time systems, RTOSes, scheduling, distributed systems, control theory, or avionics. * Experience or interest in in configuring a small distributed hardware-based system (e.g., using Arduinos). * Experience or interest in formal methods (e.g., model-checking, temporal logics, runtime monitoring). * Good writing skills/experience in writing technical papers. * Interest in continuing collaboration at his or her home institution during the remainder of the year. * Interest in an internship for the summers of 2010 *and* 2011. * Interest in NASA. * DO *NOT* NEED: * A degree (we're interested in hearing from post-docs, graduate students, and undergrads). * U.S. citizenship or work visa (all expenses are paid, but we anticipate this being an unpaid internship). ABOUT THE NIA: The National Institute of Aerospace is a nonprofit institution with both research and educational components. We have both full-time research staff members as well as faculty and graduate students from our six member universities. Research carried out at NIA includes fluid mechanics, space vehicle design, atmospheric science, material science, and computer science. Within computer science, the primary focus is in formal methods, and we work closely with the formal methods group at NASA's Langley Research Center, located less than one mile away. The visitor will have an opportunity for frequent interaction with the NASA Langley Formal Methods Group. The NIA is located in Hampton, Virginia. The cities of Norfolk and Virginia Beach are nearby as is historic Colonial Willamsburg. Numerous attractions and activities are available within an hour's drive. Within a couple of hours are the Outer Banks of North Carolina and Washington DC, which are popular weekend getaways for our summer visitors. NASA and NIA both host a large number of summer visitors (undergraduate and graduate students) from around the world. ABOUT GALOIS: Galois, Inc. is located in Portland, Oregon with a mission to create trustworthiness in critical systems. We?re in the business of taking blue-sky ideas and turning them into real-world technology solutions. We've been developing real-world systems for the past 10 years using Haskell. BENEFITS: This is anticipated to be an unpaid but internship in which all living expenses are covered. These include * travel expenses to and from the NIA and your home * housing allowance * food allowance * rental car and gas TO APPLY: Please email a C.V. (PDF or plain text) and a brief plain text note statting your interest and experience to Dr. Alwyn Goodloe at . There is flexibility regarding the dates of the visit. *************************************** * Application due date: Jan. 15, 2010 * *************************************** LEARN MORE: * NIA website: http://www.nianet.org/ * Galois website: http://www.galois.com/ * Hampton Roads: http://en.wikipedia.org/wiki/Hampton_Roads * NASA Langley Formal Methods Group: http://shemesh.larc.nasa.gov/fm/ Please email either Dr. Alwyn Goodloe and/ or Dr. Lee Pike with any questions. From sk at k-hornz.de Wed Dec 9 11:54:05 2009 From: sk at k-hornz.de (stefan kersten) Date: Wed Dec 9 11:28:28 2009 Subject: [Haskell-cafe] ANNOUNCE: usb-0.3 In-Reply-To: References: <4B1FC05B.9080403@k-hornz.de> Message-ID: <4B1FD62D.8070908@k-hornz.de> hi roel, On 09.12.09 16:50, Roel van Dijk wrote: > On Wed, Dec 9, 2009 at 4:20 PM, stefan kersten wrote: >> looks great, thanks! do you happen to have some example code for working with >> HID devices (mice, keyboards, etc.)? > > The usb package does not support the various device classes directly. > You won't find a function like "isKeyPressed ? Device ? KeyCode ? IO > Bool". But you could write it based solely on functions from the usb > package. Enumerate the devices connected to your system, find your HID > device, open a handle (or enter a safe region), choose an interface > and an alternative and finally send some sort of control request > encoded in a ByteString. The actual bytes you need to send in order to > discover if some key on your USB keyboard is pressed is defined > somewhere in the USB HID device class specification. ok, thanks. i just thought you might have something ready to use ;) > If you really need that kind of functionality then you could create a > package "usb-hid" that offers an abstraction over the HID device > class. But if you just want to know if some key is pressed then a much > simpler solution would be to use a library like SDL or GLUT. i'm interested in "headless" appliances, where no window system is actually running. on linux i could use the input device layer, but it would be nice to have something more portable ... From westondan at imageworks.com Wed Dec 9 12:31:30 2009 From: westondan at imageworks.com (Dan Weston) Date: Wed Dec 9 12:06:24 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <4c88418c0912090413h2f41fc2dq41dae57af9d456e6@mail.gmail.com> References: <200912090009.04154.daniel.is.fischer@web.de> <4c88418c0912090413h2f41fc2dq41dae57af9d456e6@mail.gmail.com> Message-ID: <4B1FDEF2.2010905@imageworks.com> Ouch. That's what happens when you let a machine do the translation. How about: "Once your good name is trashed, you can live unabashed." David Virebayre wrote: > On Wed, Dec 9, 2009 at 11:47 AM, Henning Thielemann > wrote: > >> Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert. 8-] > >> Is there an English translation of it? > > Google translate says : "If the reputation is ruined, one can live > quite openly." > > David. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mauricio.antunes at gmail.com Wed Dec 9 12:51:56 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Wed Dec 9 12:26:49 2009 Subject: [Haskell-cafe] Re: Checking dependencies from C packages in cabal In-Reply-To: <1260366142-sup-2145@nixos> References: <1260366142-sup-2145@nixos> Message-ID: > Until you get the perfect answer you may want to have a look at > the cabal definitions of > > zlib digest OpenGLRaw GLUT readline GLFW wxcore terminfo > berkeleydb BerkeleyDB hubris pcre-light HDBC-mysql HDBC-sqlite3 > HDBC-odbc HDBC-postgresql I do know them. But they just include needed .h and .c files with Haskell package, mark required libraries but do no version check, or delegate the task to configure scripts or external programs. HDBC-mysql Setup program gave me a start, thought. Thanks. > Also make sure to search the Cabal mailinglist and maybe even > move this thread to the Cabal mailinglist. Cabal page sugests Haskell libraries mailing list for questions. I should have used that. Thanks. Best, Maur?cio From jwlato at gmail.com Wed Dec 9 13:10:03 2009 From: jwlato at gmail.com (John Lato) Date: Wed Dec 9 12:44:25 2009 Subject: [Haskell-cafe] Re: A new form of newtype Message-ID: <9979e72e0912091010u6765de9cv73fda656c9d7e0f1@mail.gmail.com> > From: "Richard O'Keefe" > Subject: Re: [Haskell-cafe] A new form of newtype > > People are now writing EDSLs using Haskell to generate code for > all sorts of interesting things. ?What if you want to use Haskell > as a host for an EDSL targeted at a 24-bit DSP? *plug* for this specific case, I would use the word24 package, http://hackage.haskell.org/package/word24 which I wrote for a very similar problem. It was surprisingly difficult to get right (N.B. I have only tested the code, not proven it correct). I would have much preferred to let the compiler handle the details. > > There may not be MACHINES with 42-bit integers, > but that doesn't mean there aren't PROBLEMS that need them. > This whole idea of "let the machine dictate the sizes" is > precisely what I'm complaining of. > > > Sorry, but creating instances of Bounded is what a compiler is for. > If I don't write it, I won't wrong it. I'm pretty sure I don't understand the syntax of your proposal (which is my fault), but I definitely see the usefulness. I'll leave the syntax wrangling for the language lawyers, however. John From dan.doel at gmail.com Wed Dec 9 13:50:40 2009 From: dan.doel at gmail.com (Dan Doel) Date: Wed Dec 9 13:25:04 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? In-Reply-To: <4B1FC766.1060202@cs.nott.ac.uk> References: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> <4B1FC766.1060202@cs.nott.ac.uk> Message-ID: <200912091350.40309.dan.doel@gmail.com> On Wednesday 09 December 2009 10:51:02 am Nils Anders Danielsson wrote: > On 2009-12-08 16:11, S. Doaitse Swierstra wrote: > > In principle it is not possible to parse left-recursive grammars [...] > > I suspect that this statement is based on some hidden assumption. It > /is/ possible to parse many left recursive grammars using parser > combinators, without rewriting the grammars or representing the cycles > in the grammars explicitly. See the following paper draft: > > Total Parser Combinators > > http://www.cs.nott.ac.uk/~nad/publications/danielsson-parser-combinators.h > tml There's also parsing expression grammars, and the relevant paper "Packrat Parsers can Support Left Recursion." (Your parsers aren't PEGs, are they? If so, I apologize for the redundancy.) There's a PEG parser combinator library written by John Meacham (of jhc fame), named Frisby (there's also pappy, but it's a parser generator, not a combinator library). The parsers themselves aren't monadic, but there are some monadic combinators which are used together with recursive do to construct (mutually) recursively defined parsers such that the library can observe sharing (and thus perform optimizations with that information). On a side note, someone asked in a thread a while back about how (paraphrasing) 'performance problems always seem to be rectified by adding more strictness, and laziness always seems to be at best not-a-loss, and never a win.' But the Frisby docs state: (It is interesting to note that the memory efficiency of frisby depends vitally on being as lazy as possible, in contrast to traditional thoughts when it comes to memory consumption) So there. :) -- Dan From andrewcoppin at btinternet.com Wed Dec 9 13:59:59 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Dec 9 13:34:19 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windows In-Reply-To: <20091208092154.5cbfdcc0.mle+hs@mega-nerd.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> <4B1D7B15.2070208@btinternet.com> <20091208092154.5cbfdcc0.mle+hs@mega-nerd.com> Message-ID: <4B1FF3AF.5080208@btinternet.com> Erik de Castro Lopo wrote: > There are bigger problems than that. The Microsoft compiler still doesn't > support large chunks of the 1999 ISO C Standard. > Seriously? OK, well that's news to me. I was under the impression that practically all C compilers in existence support the same set of features. (Although I'm sure each one probably has a few non-standard additions too.) From andrewcoppin at btinternet.com Wed Dec 9 14:01:46 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Dec 9 13:36:06 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4ec472cb0912071544t21df549aj7e3c15d70377f49@mail.gmail.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1A7FE7.1080707@btinternet.com> <5fdc56d70912050914t293c8c28if636d51e067c40eb@mail.gmail.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> <4B1D7598.1020403@btinternet.com> <4ec472cb0912071544t21df549aj7e3c15d70377f49@mail.gmail.com> Message-ID: <4B1FF41A.4080800@btinternet.com> Robert Greayer wrote: > It helps, I believe, if you stop thinking of MinGW with MSYS as 'a > pseudo-Unix system'. They're billed as the minimal toolset required > on windows to use the GNU compilers and build system (and, as > everybody knows, Gnu's not Unix). The great thing about these > compilers is that they're cross-platform and freely available, unlike > MS Visual Studio. I think that it makes sense that open source > software developers targeting multiple platforms would want to pick a > tool suite that works across all those platforms, and the GNU tools > fit that description. Cygwin truly is a Unix emulation, but > MinGW/MSYS is just a packaging of useful open source (GNU) tools for > Windows (including a shell). Many programs that work well as native > Windows apps, such as the GIMP, are built with them. I see. So you're saying that while Cygwin is a Unix emulator, MinGW is just a set of Unix-style tools which run natively on Windows? From andrewcoppin at btinternet.com Wed Dec 9 14:06:00 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Dec 9 13:40:21 2009 Subject: [Haskell-cafe] Haskell job opportunity In-Reply-To: <26697169.post@talk.nabble.com> References: <26697169.post@talk.nabble.com> Message-ID: <4B1FF518.3060706@btinternet.com> siki wrote: > I've posted this before but did not get a whole lot of responses, so here it > is again: > > Principal investment firm based in Manhattan is looking for an outstanding > software developer to develop and maintain the firm's proprietary valuation > models as well as accounting and portfolio management systems. > Hey, if it was in the UK, I'd probably apply. (Even though I utterly fail to meet most of the criteria...) From JohnDEarle at cox.net Wed Dec 9 12:24:47 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 13:50:36 2009 Subject: [Haskell-cafe] fgetc and fputc equivalents Message-ID: Although much work has apparently gone into providing support for manipulation binary data I was unable to uncover a Haskell equivalent of the C fgetc and fputc functions. The Haskell equivalents work with Unicode character streams, not bytes words etcetera. I did find a library for handling arrays of bytes and such, but I did not find it to be convenient for the application I have in mind. I resolved myself to emitted Unicode 0s and 1s that are later converted to binary 0s and 1s by means of a C program. Is this functionality missing in Haskell? or did I miss something? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/2d2d3afa/attachment.html From JohnDEarle at cox.net Wed Dec 9 12:33:43 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 13:50:59 2009 Subject: [Haskell-cafe] Re: fgetc and fputc equivalents Message-ID: <1A81802297E3446883D1176D94A5EBB0@JohnPC> My interest isn't actually to push around characters. I do enough of that. What I really want to do is push bits and not bytes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/592b312a/attachment.html From JohnDEarle at cox.net Wed Dec 9 11:08:48 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 13:51:41 2009 Subject: [Haskell-cafe] Nano-Languages Message-ID: <55F43355F0AC40D18A005341A2EBE260@JohnPC> What I wrote under "Allowing hyphens in identifiers" and what Richard O'Keefe wrote earlier under "A new form of newtype" caused me to think. It was pointed out that hyphens are not permitted in Haskell identifiers much as they are in Lisp for good cause even though such a feature is regarded by some as especially desirable. It is technically feasible (or at least appears to be). It is a matter of what constitutes good language design. My suggestion was to whip up a makeshift preprocessor to make the necessary substitutions. It might be better to go about it in a fashion similar to how one would use Haskell to create a new language using Happy, but instead of making a full fledged language create a language that makes only minor adjustments to the official language where most of the original source code and command line options are copied verbatim with a handful of things caught such as the Richard O'Keefe newtype, a nano-language if you will. Actually I have known about this possibility for years. There is always something you would like to change about whatever language you are working with and so I have put thought into it. It would make prototyping of new ideas easier. It would furthermore make it possible to make changes that would be unacceptable for an official version of the language such as hyphens in place of underscores for those who feel the benefit of being able to use hyphens this way outweigh the problems it may cause. The official language remains intact. Broadly speaking I am talking about a preprocessor, but one tailored for the needs of Haskell. For related art see Ciao Prolog (see http://ciaohome.org). They are using their preprocessor to do some rather sophisticated things which include program analysis and optimization. Something so elaborate may not be necessary, however. Just some Happy code that has been cobbled together that address some of the issues involved that is reworked to satisfy a special need. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/12586b95/attachment.html From JohnDEarle at cox.net Wed Dec 9 11:24:54 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 13:51:45 2009 Subject: [Haskell-cafe] Re: Nano-Languages Message-ID: <8A5C7EDC107E43088FCC7C9CEDEB3995@JohnPC> To help clarify my meaning Haskell would be used as an assembler language or put in another way an intermediate language for those constructs that are caught by the preprocessor for special processing. Since Haskell is a functional language I would imagine that this would be unproblematic. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/1af31b0c/attachment.html From stephen.tetley at gmail.com Wed Dec 9 14:24:30 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Wed Dec 9 13:58:49 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windoww In-Reply-To: <4B1FF41A.4080800@btinternet.com> References: <619187.27009.qm@web113112.mail.gq1.yahoo.com> <4B1AC38B.7090507@btinternet.com> <5fdc56d70912051258u3f917f37xe11eb8540e370e1f@mail.gmail.com> <5fdc56d70912051514n7f58a9cclabae109a607676ca@mail.gmail.com> <4B1BB0C7.9050902@btinternet.com> <4B1D7598.1020403@btinternet.com> <4ec472cb0912071544t21df549aj7e3c15d70377f49@mail.gmail.com> <4B1FF41A.4080800@btinternet.com> Message-ID: <5fdc56d70912091124j6212e4a3m3048a9c92755ec23@mail.gmail.com> 2009/12/9 Andrew Coppin : > > I see. So you're saying that while Cygwin is a Unix emulator, MinGW is just > a set of Unix-style tools which run natively on Windows? > Yes, in a nutshell MinGW executables are native. Executables in Cygwin may or may not have dependencies on cygwin.dll the Unix emulation library (depending whether or not they actually use Unix calls of course). From JohnDEarle at cox.net Wed Dec 9 14:42:23 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 14:16:53 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windows In-Reply-To: <4B1FF3AF.5080208@btinternet.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> <4B1D7B15.2070208@btinternet.com><20091208092154.5cbfdcc0.mle+hs@mega-nerd.com> <4B1FF3AF.5080208@btinternet.com> Message-ID: There are several C standards by year of publication. There are also drafts of those standards. A C compiler may comply with a draft of the official standard before it became official, but not the official standard itself. Rarely does anyone seek full compliance with respect to any standard it seems and it can take years before everyone has bother themselves enough to bring themselves up to speed with whatever the current standard is supposed to be. I use the Microsoft CL compiler (aka Visual C++). It has some undocumented quirks/optimizations, but for the most part if you are doing native development it seems fine. It is the official compiler so you just have to learn to love it. The problem seems to be if you are coming from a POSIX environment and assuming that Windows is going to honor its conventions. I personally don't bother with the C library very much. I deliberately avoid it. Its Win32/64 programming all the way with me. That too has its undocumented quirks, but is better documented that the brief Java documentation for example. Windows programming can be quite difficult. It is just that I've been around it for so long. Windows and Mac are not designed for people who are not dedicated to working with these environments. I have experience in both of them. You may want to use Microsoft Visual C++ to access the Microsoft .NET Framework rather than bother with the C library. There is a Haskell library designed to help you access the Microsoft .NET Framework directly from Haskell on Windows. Even so, you may want to work with C++ to do this because the Microsoft documentation will not explain to you how to do this in Haskell. -------------------------------------------------- From: "Andrew Coppin" Sent: 09 Wednesday December 2009 1159 To: Subject: Re: [Haskell-cafe] Re: binding to C libraries on Windows > Erik de Castro Lopo wrote: >> There are bigger problems than that. The Microsoft compiler still doesn't >> support large chunks of the 1999 ISO C Standard. >> > > Seriously? OK, well that's news to me. I was under the impression that > practically all C compilers in existence support the same set of features. > (Although I'm sure each one probably has a few non-standard additions > too.) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From aslatter at gmail.com Wed Dec 9 14:54:09 2009 From: aslatter at gmail.com (Antoine Latter) Date: Wed Dec 9 14:28:30 2009 Subject: [Haskell-cafe] Re: fgetc and fputc equivalents In-Reply-To: <1A81802297E3446883D1176D94A5EBB0@JohnPC> References: <1A81802297E3446883D1176D94A5EBB0@JohnPC> Message-ID: <694519c50912091154r23eb31d9h5a88b4ab5ff264cd@mail.gmail.com> On Wed, Dec 9, 2009 at 11:33 AM, John D. Earle wrote: > My interest isn't actually to push around characters. I do enough of that. > What I really want to do is push bits and not bytes. I thought that fgetc and fputc worked on bytes, not bits? I've had great luck using the binary package to produce structured binary data. If it's overkill for what you're trying to do then I recommend the bytestring package. See: http://hackage.haskell.org/package/binary http://hackage.haskell.org/package/bytestring Antoine From mle+hs at mega-nerd.com Wed Dec 9 14:56:49 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed Dec 9 14:31:13 2009 Subject: [Haskell-cafe] diff implementation in haskell In-Reply-To: References: <20091206223855.GC920@whirlpool.galois.com> <87iqcjfbqk.fsf@malde.org> <125EACD0CAE4D24ABDB4D148C4593DA9110264EF@GBLONXMB02.corp.amvescap.net> Message-ID: <20091210065649.a419c3f7.mle+hs@mega-nerd.com> Chris Eidhof wrote: > Also, there is a paper about doing a type-safe diff in Agda, http://portal.acm.org/citation.cfm?id=1596614.1596624 That is locke dbehind some ridiculous paywall. It seems the same paper is available here: http://people.cs.uu.nl/andres/GDiff.html Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ben.franksen at online.de Wed Dec 9 14:56:55 2009 From: ben.franksen at online.de (Ben Franksen) Date: Wed Dec 9 14:31:41 2009 Subject: [Haskell-cafe] Re: fgetc and fputc equivalents References: Message-ID: John D. Earle wrote: > Although much work has apparently gone into providing support for > manipulation binary data I was unable to uncover a Haskell equivalent of > the C fgetc and fputc functions. The Haskell equivalents work with Unicode > character streams, not bytes words etcetera. I did find a library for > handling arrays of bytes and such, but I did not find it to be convenient > for the application I have in mind. I resolved myself to emitted Unicode > 0s and 1s that are later converted to binary 0s and 1s by means of a C > program. Is this functionality missing in Haskell? or did I miss > something? It is not in the Standard, but (at least) GHC has hPutBuf and hGetBuf (see http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html). Cheers Ben From mle+hs at mega-nerd.com Wed Dec 9 15:01:28 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed Dec 9 14:35:53 2009 Subject: [Haskell-cafe] Re: binding to C libraries on Windows In-Reply-To: <4B1FF3AF.5080208@btinternet.com> References: <9979e72e0912070441o2735f511xbd62269d21a73fe9@mail.gmail.com> <4B1D7B15.2070208@btinternet.com> <20091208092154.5cbfdcc0.mle+hs@mega-nerd.com> <4B1FF3AF.5080208@btinternet.com> Message-ID: <20091210070128.00114c42.mle+hs@mega-nerd.com> Andrew Coppin wrote: > Erik de Castro Lopo wrote: > > There are bigger problems than that. The Microsoft compiler still doesn't > > support large chunks of the 1999 ISO C Standard. > > > > Seriously? OK, well that's news to me. Yes, seriously: http://www.mega-nerd.com/erikd/Blog/Windiots/ms_c99.html That list is not complete, just what I felt was stuff that was hard to do without. The lack of a standards conforming snpirntf is particlularly painful. > I was under the impression that > practically all C compilers in existence support the same set of > features. (Although I'm sure each one probably has a few non-standard > additions too.) With the GNU compilers (and I suspect most other) the non-standard features can be switched off. For the GNU compilers -std=c99 or -std=c89 allows the user to pick which standard they are compiling to. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Wed Dec 9 15:05:53 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed Dec 9 14:40:17 2009 Subject: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? In-Reply-To: <5fdc56d70912090642p585376efoe729274cc8a515ec@mail.gmail.com> References: <5fdc56d70912090642p585376efoe729274cc8a515ec@mail.gmail.com> Message-ID: <20091210070553.c9bfe413.mle+hs@mega-nerd.com> Stephen Tetley wrote: > If there are compelling uses that aren't covered by pexports and would > ease Haskell C binding problems on Windows, I don't mind polishing up > my tool, but otherwise I've exhausted my natural interest. I think the main problem you'll face is that pexports is a windows only tool. If cabal can be made to use pexports on windows and something else on Unix then that should be ok. If you expect people writing Haskell bindings in Unix to jump though hoops to hook pexports into a windows specific build, you are heading for disappointment :-). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mblazevic at stilo.com Wed Dec 9 15:17:56 2009 From: mblazevic at stilo.com (Mario Blazevic) Date: Wed Dec 9 14:52:17 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize (was: Re: You are in a twisty maze of concurrency libraries, all different ...) In-Reply-To: <4B18F7AE.4090303@pessce.net> References: <4B18F7AE.4090303@pessce.net> Message-ID: <4B2005F4.2050905@stilo.com> It appears there are several implementations existing on Hackage of the following function, in various disguises: runPar :: [IO a] -> IO [a] the idea being that the IO computations are run in parallel, rather than sequentially. My own Streaming Component Combinators package contains a similar function, but somewhat generalized: class Monad m => ParallelizableMonad m where parallelize :: m a -> m b -> m (a, b) instance ParallelizableMonad IO -- implemented using forkIO instance ParallelizableMonad Identity -- implemented using par instance ParallelizableMonad Maybe -- implemented using par Would there be any interest in having this class packaged in a separate library? If so, can you sugest a better name or some additional functionality? From andrewcoppin at btinternet.com Wed Dec 9 15:38:14 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Dec 9 15:12:38 2009 Subject: [Haskell-cafe] Type system speculation Message-ID: <4B200AB6.8090806@btinternet.com> People in the Haskell community get awfully excited about Haskell's type system. When I was first learning Haskell, I found this rather odd. After all, a "type" is just a flat name that tells the compiler how many bits to allocate and which operations to allow, right? As I read further, I quickly discovered that in Haskell, the type system is something much more powerful. In a normal language, the type system prevents you from accidentally trying to multiply a string by a binary tree of integers, or pass a function an signed integer when it's expecting an unsigned integer. But in Haskell, the combination of parametric polymorphism, typeclasses and automatic type inference combine to form a potent mixture. Even without any exotic language extensions, in Haskell you can use the type system to *prove stuff about your programs*! And not necessary stuff that's anything to do with the usual notion of a "data type". You can prove that lists are non-empty or even of a specific size. You can prove that optional values get checked before they are used. And you can prove that user input is sanitised before being passed to sensitive functions. (Or rather, you can make your program simply not compile if the required properties are not guaranteed.) Let's take an example. Suppose you have some functions that obtain input from a user, and you have some other functions that do something with this data. What you can do is something like this: newtype Data x y = Data x data Checked data Unchecked check_string :: Data String Unchecked -> Data String Checked Now make it so that everything that obtains data from the user returns Data String Unchecked, and everything that uses a string to do something potentially hazardous demands Data String Checked. (And any functions that don't care whether the string is checked or not can just use Data String x.) Only one problem: Any functions that expect a plain String now won't work. Particularly, the entirity of Data.List will refuse to accept this stuff. Which is kind of galling, considering that a Data String Checked *is* a String! What we're really trying to do here is attach additional information to a value - information which exists only in the type checker's head, but has no effect on runtime behaviour (other than determining whether we *get* to runtime). As far as I can tell, Haskell does not provide any way to take an existing type and attach additional information to it in such a way that code which cares about the new information can make use of it, but existing code which doesn't care continues to work. Any comments on this one? On a rather unrelated note, I found myself thinking about the Type Families extension (or whatever the hell it's called). I found that I can do this: class Collection c where type Element c :: * empty :: c first :: c -> Maybe (Element c) ... This works for collections that can contain *anything*: instance Collection [x] where type Element [x] = x ... It works for collections that can only contain *one* type: instance Collection ByteString where type Element ByteString = Word8 ... And it works for collections that can handle more than one type, but less than *every* type: instance Ord x => Collection (Set x) where type Element (Set x) = x ... Something quite interesting is happening here: this "Element" thing is almost like a *function* which takes one type and returns another. A function that operates on types themselves. Now suppose I want to write a function that converts one kind of collection into another: convert :: (Collection c1, Collection c2) => c1 -> c2 Erm, no. That doesn't work AT ALL. What we want to say is that the element types are constrained (specifically, they're identical). I searched for quite some time looking for a way to say this. In the end, I gave up and let the compiler deduce the type signature automatically. Apparently the correct signature is convert :: (Collection c1, Collection c2, Element c1 ~ Element c2) => c1 -> c2 Apparently the bizare syntax "Element c1 ~ Element c2" means that these two types are supposed to be equal. (Why not just an equals sign?) This got me thinking... Maybe what we'd really like to say is something like convert :: (Collection c1 {Element = x}, Collection c2 {Element = x}) => c1 -> c2 In other words, make the assosiated type like a named field of the class, using syntax similar to the named fields that values can have. And then, if we can do it to classes, why not types? data Map {keys :: *, values :: *} = ... insert :: (Ord k) => k -> v -> Map {keys = k, values = v} -> Map {keys = k, values = v} Now, it seems reasonable that if one of the type fields is unconstrained, you do not need to mention it: keys :: (Ord k) => Map {keys = k} -> [k] values :: Map {values = v} -> [v] If we can have some mechanism for adding new type fields to an existing type, we are one step away from the problem at the beginning. You could take the existing String type, and add (by whatever the mechanism is) a new "safety" field to it. All of Data.List ignores this field, but any new code you write can choose to use it if required. At least, that's my vague idea. Anybody like it? (My first thought is that "Map {keys = k, values = v}" is going to start getting tedious to type very, very quickly. Perhaps we should do something like values :: (m :: Map {values = v}) => m -> [v], or even allow values :: (m :: Map {}) => m -> [values m] as an alternative? IDK.) So there you have it. Multiple paragraphs of semi-directed rambling about type systems. All written by somebody who doesn't even know what a Skolem variable is. :-} From tom.davie at gmail.com Wed Dec 9 15:42:30 2009 From: tom.davie at gmail.com (Tom Davie) Date: Wed Dec 9 15:16:51 2009 Subject: [Haskell-cafe] Haskell job opportunity In-Reply-To: References: <26697169.post@talk.nabble.com> Message-ID: <8b70a98a0912091242y2405475tcb963142858b6a71@mail.gmail.com> I have to admit, it's just one criterion too much for me. I can manage to satisfy all of them except for willing to work in Manhattan. Bob On Tue, Dec 8, 2009 at 5:54 PM, Tom Tobin wrote: > On Tue, Dec 8, 2009 at 11:09 AM, siki wrote: > > I've posted this before but did not get a whole lot of responses, so here > it > > is again: > [...] > > You should have at least a bachelor?s degree in computer science from a > top > > university > > Might I humbly suggest that this is going to severely limit your > hiring options? You're looking for the intersection of sets of people > who: > > - Have a BS in computer science (cuts out a fair number of people) > - Graduated from a "top university" (cuts out a *lot* of people) > - Is familiar with Java (cuts out some people) > - Is skilled with Haskell (a fair bet for many on this mailing list, at > least) > - Can work in the Manhattan area (cuts out a *lot* of people) > > I'm not sure how many people *exist* who meet all these criteria. ;-) > I'd probably start by dropping your "top university" requirement, > since I don't think it's all that relevant if you find your candidate > has the skills you're looking for. You might even find someone who > fits yet doesn't have a CompSci BS degree; you can phrase it as "a BS > in computer science or an equivalent strong background in theoretical > computer science" or somesuch, as appropriate. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/bf1f0df8/attachment.html From aslatter at gmail.com Wed Dec 9 15:43:37 2009 From: aslatter at gmail.com (Antoine Latter) Date: Wed Dec 9 15:17:58 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize (was: Re: You are in a twisty maze of concurrency libraries, all different ...) In-Reply-To: <4B2005F4.2050905@stilo.com> References: <4B18F7AE.4090303@pessce.net> <4B2005F4.2050905@stilo.com> Message-ID: <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> On Wed, Dec 9, 2009 at 2:17 PM, Mario Blazevic wrote: > ? ? ? ?It appears there are several implementations existing on Hackage of > the following function, in various disguises: > > ? runPar :: [IO a] -> IO [a] > > > the idea being that the IO computations are run in parallel, rather than > sequentially. My own Streaming Component Combinators package contains a > similar function, but somewhat generalized: > > > ? class Monad m => ParallelizableMonad m where > ? ? ?parallelize :: m a -> m b -> m (a, b) > > ? instance ParallelizableMonad IO ?-- implemented using forkIO > ? instance ParallelizableMonad Identity ?-- implemented using par > ? instance ParallelizableMonad Maybe ?-- implemented using par > > > ? ? ? ?Would there be any interest in having this class packaged in a > separate library? If so, can you sugest a better name or some additional > functionality? A similar function that I'm fond of: forkExec :: IO a -> IO (IO a) forkExec k = do result <- newEmptyMVar _ <- forkIO $ k >>= putMVar result return (takeMVar result) Although I don't think it can be generalized to non-IO monads. Antoine From stephen.tetley at gmail.com Wed Dec 9 15:47:21 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Wed Dec 9 15:21:42 2009 Subject: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? In-Reply-To: <20091210070553.c9bfe413.mle+hs@mega-nerd.com> References: <5fdc56d70912090642p585376efoe729274cc8a515ec@mail.gmail.com> <20091210070553.c9bfe413.mle+hs@mega-nerd.com> Message-ID: <5fdc56d70912091247k4f0f5cb1t6ec7de9a5d670a89@mail.gmail.com> Hi Erik I'm neither expecting nor obliging Unix users to do anything... pexports (the C tool) extracts function names from dlls. In one of the messages on the PortAudio thread [1], John Lask explained how to get from a standard Windows .dll to an .a file suitable for GHC (which is bundled with a MinGW gcc). Before John's explanation I thought you had to build the .a file yourself - or do some magic with GreenCard which is now quite antiquated, but with pexports you can do the missing step (I almost feel a commuting diagram coming on at this point...). When I looked for pexports on Sunday it seem rather abandoned (it didn't seem to be included in MinGW, M Xyz's tutorial points to a very old version...) so I thought I'd see if I could do the job myself in Haskell. Anyway it was a bit more work that I imagined and when I was web-searching for pexports today I found that it was included in MinGW. So my Haskell version is redundant - but pexports isn't quite the full story, seemingly people often have to hand-edit the .def file it produces. If someone else has a use compelling enough that it would benefit the Haskell community on Windows, I don't mind extending and polishing my version so it can do a bit more than pexports; but I get by with cygwin and MinGW myself, so I've no personal inclination to spend any more time on it (and of course it is no help whatsoever for includes files and related problems...). Best wishes Stephen [1] http://www.haskell.org/pipermail/haskell-cafe/2009-December/070293.html 2009/12/9 Erik de Castro Lopo : > Stephen Tetley wrote: > >> If there are compelling uses that aren't covered by pexports and would >> ease Haskell C binding problems on Windows, I don't mind polishing up >> my tool, but otherwise I've exhausted my natural interest. > > I think the main problem you'll face is that pexports is a windows > only tool. If cabal can be made to use pexports on windows and something > else on Unix then that should be ok. > > If you expect people writing Haskell bindings in Unix to jump though > hoops to hook pexports into a windows specific build, you are heading > for disappointment :-). > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From matthew at brecknell.net Wed Dec 9 16:41:16 2009 From: matthew at brecknell.net (Matthew Brecknell) Date: Wed Dec 9 16:15:40 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize (was: Re: You are in a twisty maze of concurrency libraries, all different ...) In-Reply-To: <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> References: <4B18F7AE.4090303@pessce.net> <4B2005F4.2050905@stilo.com> <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> Message-ID: <1260394876.6583.20.camel@localhost> Antoine Latter wrote: > A similar function that I'm fond of: > > forkExec :: IO a -> IO (IO a) It's cute that forkExec already has a dual operation with just the right name (specialised to IO): join :: IO (IO a) -> IO a From mblazevic at stilo.com Wed Dec 9 16:44:39 2009 From: mblazevic at stilo.com (Mario Blazevic) Date: Wed Dec 9 16:19:00 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize In-Reply-To: <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> References: <4B18F7AE.4090303@pessce.net> <4B2005F4.2050905@stilo.com> <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> Message-ID: <4B201A47.5090901@stilo.com> > A similar function that I'm fond of: > > forkExec :: IO a -> IO (IO a) > forkExec k > = do > result <- newEmptyMVar > _ <- forkIO $ k >>= putMVar result > return (takeMVar result) > > Although I don't think it can be generalized to non-IO monads. > > Antoine > I can't test it right now, but wouldn't the following do the job in the Identity monad? forkExec :: Identity a -> Identity (Identity a) forkExec k = let result = runIdentity k in result `par` return (Identity result) From jvlask at hotmail.com Wed Dec 9 16:46:29 2009 From: jvlask at hotmail.com (John Lask) Date: Wed Dec 9 16:21:05 2009 Subject: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card? In-Reply-To: <5fdc56d70912090642p585376efoe729274cc8a515ec@mail.gmail.com> References: <5fdc56d70912090642p585376efoe729274cc8a515ec@mail.gmail.com> Message-ID: I think it would be a usefull addition to the haskell windows tool chain, and help facilitate the creation of bindings to libraries on windows where no appropriate import library exists. I am sure if you put it "out there" in whatever form, someone will find a use for it and perhaps build upon it. jvl Stephen Tetley wrote: > Hi All, > > Would a pure Haskell version of pexports be useful to the Haskell community? > > For a Sunday afternoon hack that turned out to take a bit more effort > (its now Wednesday), I thought I'd code up a tool that extracts > function symbols from .dll's (also when I first looked at the C > pexports it seemed somewhat unadopted, though checking today it > appears to in MinGW, so my local MinGW must be out-of-date). > > If there are compelling uses that aren't covered by pexports and would > ease Haskell C binding problems on Windows, I don't mind polishing up > my tool, but otherwise I've exhausted my natural interest. > > Best wishes > > Stephen > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From v.dijk.bas at gmail.com Wed Dec 9 16:51:31 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Dec 9 16:25:51 2009 Subject: [Haskell-cafe] Re: Handles with their IOMode in their type In-Reply-To: References: Message-ID: On Tue, Dec 8, 2009 at 7:22 PM, Lee Houghton wrote: > I like this idea. Thanks > A small observation, though: > >> stdin :: ReadModes ioMode => Handle ioMode >> stdin = Handle SIO.stdin > > This allows writing to stdin by choosing ReadWriteMode as the ioMode. I > think it would be better to have just >> >> stdin :: Handle ReadMode > > *HandleExplicitIOMode> hPutStrLn (stdin :: Handle ReadWriteMode) "This > shouldn't typecheck!" > *** Exception: : hPutStr: illegal operation (handle is not open for > writing) > > This also shows another reason for stdin, stdout and stderr to be > monomorphic: > >> hGetLine stdin > > :1:0: > ? ?Ambiguous type variable `ioMode' in the constraint: > ? ? ?`ReadModes ioMode' > ? ? ? ?arising from a use of `hGetLine' at :1:0-13 > ? ?Probable fix: add a type signature that fixes these type variable(s) Rightly spotted, thanks! I will change the types to: stdin :: Handle ReadMode stdout :: Handle WriteMode stderr :: Handle WriteMode Or are there scenarios where people want to write to stdin or read from stdout or stderr? I think I will also rename the IOMode constructors to their System.IO.IOMode equivalents. Then I will also have to rename the ioMode types like so: data IOMode ioMode where ReadMode :: IOMode R WriteMode :: IOMode W AppendMode :: IOMode A ReadWriteMode :: IOMode RW Then there are two decisions I still have to make: 1) How to name the module? What about: System.IO.ExplicitIOModes? 2) What to export? Do I only need to export the changed functions and types like I have now: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 or do I need to export all the other things that System.IO exports. In the latter case users have the advantage that they can just swap their import of System.IO with System.IO.ExplicitIOModes When I have time I will put this in a package and upload it to hackage. Oh yes, final question: how to name this package? What about explicit-iomodes? regards, Bas From aslatter at gmail.com Wed Dec 9 17:07:19 2009 From: aslatter at gmail.com (Antoine Latter) Date: Wed Dec 9 16:41:39 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize In-Reply-To: <4B201A47.5090901@stilo.com> References: <4B18F7AE.4090303@pessce.net> <4B2005F4.2050905@stilo.com> <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> <4B201A47.5090901@stilo.com> Message-ID: <694519c50912091407y483c598btf3cf82825d5ae4b3@mail.gmail.com> On Wed, Dec 9, 2009 at 3:44 PM, Mario Blazevic wrote: > > ? ? ? ?I can't test it right now, but wouldn't the following do the job in > the Identity monad? > > forkExec :: Identity a -> Identity (Identity a) > forkExec k = let result = runIdentity k > ? ? ? ? ? ? in result `par` return (Identity result) > Since Identity is a newtype, would that be equivalent to "result `par` result"? The forkExec in the IO monad let's other computations keep going until I need the result from the forked computation. In a pure computation, I can already get the same result with `par` and laziness, right? Antoine From stefan at cs.uu.nl Wed Dec 9 17:36:54 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Dec 9 17:11:15 2009 Subject: [Haskell-cafe] Nano-Languages In-Reply-To: <55F43355F0AC40D18A005341A2EBE260@JohnPC> References: <55F43355F0AC40D18A005341A2EBE260@JohnPC> Message-ID: John, > It might be better to go about it in a fashion similar to how one > would use Haskell to create a new language using Happy, but instead > of making a full fledged language create a language that makes only > minor adjustments to the official language where most of the > original source code and command line options are copied verbatim > with a handful of things caught such as the Richard O'Keefe newtype, > a nano-language if you will. Actually I have known about this > possibility for years. There is always something you would like to > change about whatever language you are working with and so I have > put thought into it. What about?syntax macros? http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf Cheers, Stefan From ok at cs.otago.ac.nz Wed Dec 9 17:54:22 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Dec 9 17:28:46 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <1260352455.2949.7.camel@picard> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> Message-ID: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: > You mean to parse a - b differently then a-b? You don't have the > problem > in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. It's a problem that COBOL solved a long time ago: COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. Haskell already has this problem with ".", where we generally need to put spaces around "." with the meaning "composition" and not put spaces around other uses. This is something someone could easily try out by writing a trivial preprocessor to convert hyphens with letters on each side to underscores. See how it works. Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might be nice to have a wee preprocessor that turned _ into so that I could write take_while and Haskell could see takeWhile. [I'm writing this in MacOS X Mail. "takeWhile" is underlined in red as a spelling mistake, "take_while" is not. Maybe they know something...] Here is such a preprocessor. This is meant for people to try out. I don't claim that it's perfect, it's just a quick hack. -------------- next part -------------- A non-text attachment was scrubbed... Name: hspp.hs Type: application/octet-stream Size: 1994 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/e7a4b949/hspp.obj -------------- next part -------------- From v.dijk.bas at gmail.com Wed Dec 9 18:04:54 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Dec 9 17:39:15 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: usb-safe-0.1 In-Reply-To: References: Message-ID: On Wed, Dec 9, 2009 at 3:50 PM, Bas van Dijk wrote: > On Wed, Dec 9, 2009 at 2:35 PM, Bas van Dijk wrote: >> Hello, >> >> My usb library provides a standard Haskell abstracting layer over >> bindings-libusb providing: abstract types instead of Ptrs, automatic >> marshalling and unmarshalling, automatic garbage collection, >> exceptions instead of integer return codes, etc.. >> >> While all that is very nice there are still some things that you can >> do wrong. For example doing I/O with a closed device or reading from >> or writing to an endpoint which doesn't belong to the claimed >> interface. Or reading from an Out endpoint or writing to an In >> endpoint. >> >> I released the usb-safe package to prevent you making these errors. See: >> >> http://hackage.haskell.org/package/usb-safe-0.1 >> >> usb-safe provides the following guarantees: >> >> - ?You can't reference handles to devices that are closed. In other >> words: no I/O with closed handles is possible. >> >> - The programmer specifies the region in which devices should remain >> open. On exit from the region the opened devices are automatically >> closed. >> >> - You can't reference handles to configurations that have not been set. >> >> - You can't reference handles to interfaces that have not been claimed. >> >> - You can't reference handles to alternates that have not been set. >> >> - You can't reference endpoints that don't belong to a setted alternate. >> >> - You can't read from an endpoint with an Out transfer direction. >> >> - You can't write to an endpoint with an In transfer direction. >> >> - You can't read from or write to endpoints with the unsupported >> transfer types Control and Isochronous. Only I/O with endpoints with >> the Bulk and Interrupt transfer types is allowed. >> >> The primary technique used in usb-safe is called "Lightweight monadic >> regions" which was invented by Oleg Kiselyov and Chung-chieh Shan. >> See: >> >> http://okmij.org/ftp/Haskell/regions.html#light-weight >> >> Note that I consider this a preview release. In fact, I haven't tested >> the package at all. I can only guarantee you that it will pass the >> type-checker. >> >> As always: questions, comments and patches are more than welcome. >> >> Please don't look at the hscolour generated source code from the >> haddock documentation because it screws up the nice unicode symbols I >> used. If you want to read the source download the package or go >> straight to the darcs repos: >> >> darcs get http://code.haskell.org/~basvandijk/code/usb-safe >> >> regards, >> >> Bas >> > > I just released a new 0.2 version of usb-safe which adds the type synonym: > > type TopDeviceRegion s = DeviceRegionT s IO > > and the function: > > runTopDeviceRegion ? (? s. TopDeviceRegion s ?) ? IO ? > > I changed the name of 'forkDeviceRegionT' to 'forkTopDeviceRegion' and > changed its type accordingly. > > Because these are API changes and additions I bumped the version from > 0.1 to 0.2 following the PVP[1]. > > See: > > http://hackage.haskell.org/package/usb-safe-0.2 > > darcs get http://code.haskell.org/~basvandijk/code/usb-safe > > regards, > > Bas > > [1] http://haskell.org/haskellwiki/Package_versioning_policy > And yet another major release for usb-safe-0.3 * This time I renamed the type 'EndpointHandle' to 'FilteredEndpoint' because it's not really a handle to an endpoint but more of an endpoint which got filtered and therefor got some more type information. * I also renamed lots of type variables to better reflect their intended meaning. * Finally I added some documentation. See: http://hackage.haskell.org/package/usb-safe-0.3 or the darcs repos for details. Maybe one major 0.4 release will follow shortly where I remove the region variables from: ConfigHandle, Interface, InterfaceHandle, Alternate, AlternateHandle, Endpoint and FilteredEndpoint. I think these region variables are not strictly necessary in these types because they are already imprisoned (for lack of a better term) by all the respected 'with*' functions using their 's' type variables. However I have to think about if this is a wise change. regards, Bas From deniz.a.m.dogan at gmail.com Wed Dec 9 18:05:17 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Wed Dec 9 17:39:58 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> Message-ID: <7b501d5c0912091505y4f24177dwa2a588954912987b@mail.gmail.com> 2009/12/9 Richard O'Keefe : > > On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: >> >> You mean to parse a - b differently then a-b? You don't have the problem >> in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. > > It's a problem that COBOL solved a long time ago: > ? ? ? ?COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. > Haskell already has this problem with ".", where we generally need > to put spaces around "." with the meaning "composition" and not > put spaces around other uses. > > This is something someone could easily try out by writing a trivial > preprocessor to convert hyphens with letters on each side to > underscores. ?See how it works. > > Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might > be nice to have a wee preprocessor that turned > ? ? ? ? _ > into ? ? > > so that I could write take_while and Haskell could see takeWhile. > [I'm writing this in MacOS X Mail. ?"takeWhile" is underlined in > red as a spelling mistake, "take_while" is not. ?Maybe they know > something...] > > Here is such a preprocessor. ?This is meant for people to try out. > I don't claim that it's perfect, it's just a quick hack. > Is there any flag I can pass to e.g. GHC to make it use the preprocessor automagically or do I write my own little hack to apply the preprocessor? -- Deniz Dogan From moonpatio at gmail.com Wed Dec 9 18:06:31 2009 From: moonpatio at gmail.com (Matt Morrow) Date: Wed Dec 9 17:40:52 2009 Subject: [Haskell-cafe] Re: can there be (hash-table using) O(n) version of this (I think currently) n log n algo? In-Reply-To: <200912082141.37279.jon@ffconsultancy.com> References: <910ddf450907171524x2720c0deya1d524b22698a558@mail.gmail.com> <200912082141.37279.jon@ffconsultancy.com> Message-ID: <1bc51a990912091506l428a73d9xc73851f391621d98@mail.gmail.com> Never underestimate teh power of the Int{Set,Map}: {-# LANGUAGE BangPatterns #-} import Data.Set(Set) import Data.IntSet(IntSet) import qualified Data.Set as S import qualified Data.IntSet as IS import Control.Parallel.Strategies(rnf) import Data.Monoid(Monoid(..)) import Data.List findsumsIS :: [Int] -> Int -> IntSet findsumsIS xs wanted = snd . foldl' f mempty $ xs where f (!candidates,!successes) next = let x = wanted - next in case x `IS.member` candidates of True -> (candidates, IS.insert next successes) False -> (IS.insert next candidates,successes) -- (i had to add bangs in f since it was blowing the stack) findsums :: [Int] -> Int -> Set (Int,Int) findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs where f (!candidates,!successes) next = if S.member (wanted-next) candidates then (candidates, S.insert (next,wanted-next) successes) else (S.insert next candidates,successes) {- Note that the list has 10 million elements, (time is roughly 0.4s with 1 million with IntSet). -} {- main = do let s = findsums (take 10000000 (cycle [1..999])) 500 print (rnf s `seq` ()) [m@monire ~]$ time ./FindSums () real 0m8.793s user 0m8.762s sys 0m0.022s -} {- main = do let s = findsumsIS (take 10000000 (cycle [1..999])) 500 print (rnf s `seq` ()) [m@monire ~]$ time ./FindSumsIS () real 0m4.488s user 0m4.459s sys 0m0.023s -} Matt > On Sunday 19 July 2009 09:26:14 Heinrich Apfelmus wrote: >> Thomas Hartman wrote: >> > The code below is, I think, n log n, a few seconds on a million + >> > element >> > list. >> > >> > I wonder if it's possible to get this down to O(N) by using a >> > hashtable implemementation, or other better data structure. >> > >> > -- findsums locates pairs of integers in a list >> > that add up to a wanted sum. >> > >> > findsums :: [Int] -> Int -> S.Set (Int,Int) >> > findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs >> > where f (candidates,successes) next = >> > if S.member (wanted-next) candidates >> > then (candidates, S.insert (next,wanted-next) successes) >> > else (S.insert next candidates,successes) >> >> Remember that hash tables are actually O(key length) instead of O(1), so >> I don't think you can break the log n for really large lists this >> way since the key length increases as well (unless most elements are >> equal anyway). From ok at cs.otago.ac.nz Wed Dec 9 18:16:15 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Dec 9 17:50:37 2009 Subject: [Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1 In-Reply-To: References: Message-ID: <40FC7CF7-58EC-43BB-B07E-94AD040F193E@cs.otago.ac.nz> On Dec 10, 2009, at 2:58 AM, Roel van Dijk wrote: > I tried to be conservative with the choice of unicode symbols. I have > defined the division sign (?) to be (/). But it could just as well be > defined as 'div'. No it couldn't. One expects 3?2 to be 1?, not 1. You will, for example, find this text on the web: "Mathematically, the division sign is equivalent to the forward slash. Thus, for example, 4 ? 5 = 4/5 = 0.8" This is actually historically backwards. When I was a nipper, 1/6 meant "one and six" or "eighteen pence" or at least three loaves of good bread. As far as I'm aware, the use of "/" instead of "?" is a computerism introduced in the days of 6 bit character sets. > Another choice that could lead to some discussion is the definition of > (?) to be 'Data.Set.isProperSubsetOf' and (?) to be > 'Data.Set.isSubsetOf'. An alternative choice would be to have (?) > for > 'isProperSubsetOf' and (?) for 'isSubsetOf'. Mathematicians may use the plain horseshoe for either subset or proper subset, depending on the author. But I've never ever seen anyone use the horseshoe with an equals bar for proper subset; that would really make no sense. I suggest that you take the Z formal specification language as your guide (plain horseshoe is proper subset, horseshoe with equal bar is subset-or-equal). If you don't like Z, try B: same thing. From uzytkownik2 at gmail.com Wed Dec 9 18:24:15 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Wed Dec 9 17:58:55 2009 Subject: [Haskell-cafe] Re: Re: Allowing hyphens in identifiers In-Reply-To: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> Message-ID: <1260401055.2949.75.camel@picard> On Thu, 2009-12-10 at 11:54 +1300, Richard O'Keefe wrote: > On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: > > You mean to parse a - b differently then a-b? You don't have the > > problem > > in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. > > It's a problem that COBOL solved a long time ago: > COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. > Haskell already has this problem with ".", where we generally need > to put spaces around "." with the meaning "composition" and not > put spaces around other uses. > Well. http://en.wikipedia.org/wiki/Backward_compatibility About '.' - there are two contexts in which it is used: - Hierarchical modules: In which first letters (except maybe last one) are capitalized - Composition: In which first letters are not capitalized In combination of those I belive there is no disambiguoty since the lower case words functions as terminators. While it can be discussed as an error of the past it is not the problem that spaces creates problems: ghci> :t head . tail head . tail :: [a] -> a ghci> :t head .tail head .tail :: [a] -> a ghci> :t head.tail head.tail :: [a] -> a Or even: ghci> :t Data.IORef.readIORef.System.IO.Unsafe.unsafePerformIO.Data.IORef.newIORef Data.IORef.readIORef.System.IO.Unsafe.unsafePerformIO.Data.IORef.newIORef :: a -> IO a Even in hugs: Hugs> :t head.tail head . tail :: [a] -> a Hugs> :t head . tail head . tail :: [a] -> a Hugs> :t head .tail head . tail :: [a] -> a Hugs> :t head.tail head . tail :: [a] -> a Main> :t Data.IORef.readIORef.System.IO.Unsafe.unsafePerformIO.Data.IORef.newIORef readIORef . unsafePerformIO . newIORef :: a -> IO a I would question sanity of using . here but it is not the case that we get flood of posts why adding/removing space next to ./- causes any problems. People with practically any programmin backround would expect a-b be equivalent to a - b. Sometimes this 2 spaces are needed to fit in 72/80 columns. > This is something someone could easily try out by writing a trivial > preprocessor to convert hyphens with letters on each side to > underscores. See how it works. > > Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might > be nice to have a wee preprocessor that turned > _ > into > > so that I could write take_while and Haskell could see takeWhile. > [I'm writing this in MacOS X Mail. "takeWhile" is underlined in > red as a spelling mistake, "take_while" is not. Maybe they know > something...] > > Here is such a preprocessor. This is meant for people to try out. > I don't claim that it's perfect, it's just a quick hack. Personally I don't have any strong feelings about conventions as long as they are consistent within one language. Camel cases are no more uncommon then the underscore and they saved space in the past (ok. now it does not matter) and hyphen is very rarly used (to not have problem with minus). For example: - Java - camel cases both in classes and methods (convention very similar to Haskell) - .Net - the same (but first letter of method is capitalized) - Python - underscore - C/C++ - Veries Regards From JohnDEarle at cox.net Wed Dec 9 18:26:23 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 18:00:53 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com><1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> Message-ID: <0BBE58B88167495A878E2773C3DC6C96@JohnPC> The problem that I see with elision resulting in juxtaposition is that it would alter the layout. Each line would not have the same number of characters before and after the makeover. Visual appearance would also be altered. Replacing hyphens with underscores as I originally proposed would alleviate both of these problems. There is also the matter of canonicalization for the purposes of comparing identifiers. Would it be wise for the a version that lacks hyphens be regarded as equivalent to one that does? -------------------------------------------------- From: "Richard O'Keefe" Sent: 09 Wednesday December 2009 1554 To: "Maciej Piechotka" Cc: Subject: Re: [Haskell-cafe] Re: Allowing hyphens in identifiers > > On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: >> You mean to parse a - b differently then a-b? You don't have the >> problem >> in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. > > It's a problem that COBOL solved a long time ago: > COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. > Haskell already has this problem with ".", where we generally need > to put spaces around "." with the meaning "composition" and not > put spaces around other uses. > > This is something someone could easily try out by writing a trivial > preprocessor to convert hyphens with letters on each side to > underscores. See how it works. > > Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might > be nice to have a wee preprocessor that turned > _ > into > > so that I could write take_while and Haskell could see takeWhile. > [I'm writing this in MacOS X Mail. "takeWhile" is underlined in > red as a spelling mistake, "take_while" is not. Maybe they know > something...] > > Here is such a preprocessor. This is meant for people to try out. > I don't claim that it's perfect, it's just a quick hack. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From JohnDEarle at cox.net Wed Dec 9 18:43:58 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 18:18:28 2009 Subject: [Haskell-cafe] Nano-Languages In-Reply-To: References: <55F43355F0AC40D18A005341A2EBE260@JohnPC> Message-ID: Stefan, I managed to look at the paper and yeah you may be onto something. I am certainly open to ideas. Looks promising. There needs to be a standard way to extend the language without having to concern oneself with everything that goes under the hood. There is certainly an interest in this. It is like what everyone wants for Christmas. -------------------------------------------------- From: "Stefan Holdermans" Sent: 09 Wednesday December 2009 1536 To: "John D. Earle" Cc: "Haskell Cafe" Subject: Re: [Haskell-cafe] Nano-Languages > John, > >> It might be better to go about it in a fashion similar to how one would >> use Haskell to create a new language using Happy, but instead of making >> a full fledged language create a language that makes only minor >> adjustments to the official language where most of the original source >> code and command line options are copied verbatim with a handful of >> things caught such as the Richard O'Keefe newtype, a nano-language if >> you will. Actually I have known about this possibility for years. There >> is always something you would like to change about whatever language you >> are working with and so I have put thought into it. > > What about?syntax macros? > http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf > > Cheers, > > Stefan From gcross at phys.washington.edu Wed Dec 9 18:54:17 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Wed Dec 9 18:30:56 2009 Subject: [Haskell-cafe] Re: Re: Allowing hyphens in identifiers In-Reply-To: <1260401055.2949.75.camel@picard> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <1260401055.2949.75.camel@picard> Message-ID: <78A4CA0F-7112-47B4-B98A-CEE9BDB7769C@phys.washington.edu> On Dec 9, 2009, at 3:24 PM, Maciej Piechotka wrote: > On Thu, 2009-12-10 at 11:54 +1300, Richard O'Keefe wrote: > - Composition: In which first letters are not capitalized > > In combination of those I belive there is no disambiguoty since the > lower case words functions as terminators. Except for data constructors, which are a special class of functions that start with capital letters; this where an ambiguity can (and does) crop up that is resolved by the spacing rule. Cheers, Greg From westondan at imageworks.com Wed Dec 9 19:04:21 2009 From: westondan at imageworks.com (Dan Weston) Date: Wed Dec 9 18:38:46 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize In-Reply-To: <1260394876.6583.20.camel@localhost> References: <4B18F7AE.4090303@pessce.net> <4B2005F4.2050905@stilo.com> <694519c50912091243x7063bb7fv88aba83142106652@mail.gmail.com> <1260394876.6583.20.camel@localhost> Message-ID: <4B203B05.3000001@imageworks.com> It's a good thing then that forkExec and return are denotationally equal (though not operationally). Otherwise, I'd be worried. Matthew Brecknell wrote: > Antoine Latter wrote: >> A similar function that I'm fond of: >> >> forkExec :: IO a -> IO (IO a) > > It's cute that forkExec already has a dual operation with just the right > name (specialised to IO): > > join :: IO (IO a) -> IO a > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From james at slohall.com Wed Dec 9 19:08:39 2009 From: james at slohall.com (James Hall) Date: Wed Dec 9 18:42:58 2009 Subject: [Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1 In-Reply-To: <40FC7CF7-58EC-43BB-B07E-94AD040F193E@cs.otago.ac.nz> References: <40FC7CF7-58EC-43BB-B07E-94AD040F193E@cs.otago.ac.nz> Message-ID: <873b98860912091608w65953cc5hfed2f454db33adc3@mail.gmail.com> 2009/12/9 Richard O'Keefe > > On Dec 10, 2009, at 2:58 AM, Roel van Dijk wrote: > >> I tried to be conservative with the choice of unicode symbols. I have >> defined the division sign (?) to be (/). But it could just as well be >> defined as 'div'. >> > > No it couldn't. One expects 3?2 to be 1?, not 1. > You will, for example, find this text on the web: > "Mathematically, the division sign is equivalent to the forward slash. > Thus, for example, 4 ? 5 = 4/5 = 0.8" > This is actually historically backwards. When I was a nipper, > 1/6 meant "one and six" or "eighteen pence" or at least three > loaves of good bread. As far as I'm aware, the use of "/" > instead of "?" is a computerism introduced in the days of 6 bit > character sets. > > > Another choice that could lead to some discussion is the definition of >> (?) to be 'Data.Set.isProperSubsetOf' and (?) to be >> 'Data.Set.isSubsetOf'. An alternative choice would be to have (?) for >> 'isProperSubsetOf' and (?) for 'isSubsetOf'. >> > > Mathematicians may use the plain horseshoe for either subset or > proper subset, depending on the author. But I've never ever seen > anyone use the horseshoe with an equals bar for proper subset; > that would really make no sense. > The second notation uses a horseshoe with an equals bar and a _slash_ through it to indicate proper subset, and I have seen that several times before; however, I prefer the first notation style. > > I suggest that you take the Z formal specification language as your > guide (plain horseshoe is proper subset, horseshoe with equal bar is > subset-or-equal). If you don't like Z, try B: same thing. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- James Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/e1f8c1aa/attachment.html From mblazevic at stilo.com Wed Dec 9 19:12:03 2009 From: mblazevic at stilo.com (=?utf-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Wed Dec 9 18:46:23 2009 Subject: [Haskell-cafe] forkSequence, runPar, parallelize Message-ID: <.1260403923@magma.ca> > > > ? ? ? ?I can't test it right now, but wouldn't the > > following do the job in the Identity monad? > > > forkExec :: Identity a -> Identity (Identity a) > > forkExec k = let result = runIdentity k > > ? ? ? ? ? ? in result `par` return (Identity result) > > > Since Identity is a newtype, would that be equivalent to "result `par` > result"? The forkExec in the IO monad let's other computations keep > going until I need the result from the forked computation. You're right, it doesn't seem to work the way I hoped. The equivalent function on Maybe monad works, though, so it is possible to write forkExec in monads other than IO. > In a pure computation, I can already get the same result with `par` > and laziness, right? Yes. The goal is to enable writing monadic parallel computations which work under any parallelizable monad. For example, I'm using it to run two trampolining producer/consumer coroutines in parallel. A large majority of interesting coroutines I have are completely agnostic with respect to the underlying monad. From JohnDEarle at cox.net Wed Dec 9 19:16:50 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 18:51:20 2009 Subject: [Haskell-cafe] Nano-Languages In-Reply-To: References: <55F43355F0AC40D18A005341A2EBE260@JohnPC> Message-ID: <6A5DE7114E504B40B544D31436AA82D6@JohnPC> I delved a little more deeper into http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf. I'm uncertain if I am able to understand the value of what its authors are proposing. The emphasis appears to be on extending the syntax of the language at runtime, but like so what. My impression after skimming a portion of the paper is they are advocating a bottom up approach whereas I am advocating a top down approach. Our orientation appears to be different. From kkwweett at yahoo.fr Wed Dec 9 19:42:56 2009 From: kkwweett at yahoo.fr (jean legrand) Date: Wed Dec 9 19:17:15 2009 Subject: [Haskell-cafe] Re: OpenAL and Hsndfile Message-ID: <221790.53103.qm@web24507.mail.ird.yahoo.com> a while ago, I wrote a minimal and inefficient code to generate and play an audible 4-second-sine sound http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1538 Can you hear something with it ? From JohnDEarle at cox.net Wed Dec 9 20:11:04 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 19:45:43 2009 Subject: [Haskell-cafe] Natural Language Processing Message-ID: <1CE1DC965D46463A899924D4DD778178@JohnPC> Is Parsec capable of parsing a mildly context sensitive language? In particular does it parse a combinatory categorial grammar? Does Haskell have such tools in its shed? What sort of facilities does Haskell have for natural language processing? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/de5b5c6e/attachment.html From ok at cs.otago.ac.nz Wed Dec 9 20:21:57 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Dec 9 19:56:30 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <7b501d5c0912091505y4f24177dwa2a588954912987b@mail.gmail.com> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <7b501d5c0912091505y4f24177dwa2a588954912987b@mail.gmail.com> Message-ID: On Dec 10, 2009, at 12:05 PM, Deniz Dogan wrote: > 2009/12/9 Richard O'Keefe : >> >> Here is such a preprocessor. This is meant for people to try out. >> I don't claim that it's perfect, it's just a quick hack. >> > > Is there any flag I can pass to e.g. GHC to make it use the > preprocessor automagically or do I write my own little hack to apply > the preprocessor? It's amazing what you find in the manual: -F runs a custom preprocessor. Let the source file be $S. First, literate Haskell processing is done, producing $L. Then "$S" "$L" "$O" is run, where $O is where GHC wants your program to write its output. GHC then reads $O. -pgmF cmd tells GHC to use cmd as the custom preprocessor. My little hspp was written before I realised this could be done, so I had to whip up #!/bin/sh exec hspp <"$2" >"$3" and use that. Sample session: m% cat main.hs main = print (take-while (<10) [1..]) m% ghc -F -pgmF hspp.sh main.hs m% a.out [1,2,3,4,5,6,7,8,9] If there isn't a GHC option to count the dragons in the moon, there soon will be. One option that would be nice would be accepting -help as well as --help. From ok at cs.otago.ac.nz Wed Dec 9 20:30:12 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Dec 9 20:04:41 2009 Subject: [Haskell-cafe] Re: Re: Allowing hyphens in identifiers In-Reply-To: <1260401055.2949.75.camel@picard> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <1260401055.2949.75.camel@picard> Message-ID: <20C27875-4417-4FA5-A758-FA4CA6380139@cs.otago.ac.nz> On Dec 10, 2009, at 12:24 PM, Maciej Piechotka wrote: [it appears that I have been misinformed about "." vs " . "] > > Personally I don't have any strong feelings about conventions as > long as > they are consistent within one language. Camel cases are no more > uncommon then the underscore and they saved space in the past (ok. now > it does not matter) and hyphen is very rarly used (to not have problem > with minus). baStudlyCase was *never* about saving space. It was copied from Smalltalk by people who failed to realise that Smalltalk did it that way because the Smalltalk character set didn't _have_ an underscore. Nor is being "uncommon" the issue. > > > For example: > - Java - camel cases both in classes and methods (convention very > similar to Haskell) which is why I have something similar to my little hspp tool for reading and writing Java. The fact that other people do something ill-considered is no reason why we have to follow them. Your own list of languages shows that baStudlyCase is not universal. For that matter, the Interlisp and S convention was to separate words in an identifier with dots. (once again, every runTogetherWord inThisMessage is flagged as a spelling mistake...) Thanks to GHC's -F and -pgmF options, people can now choose whether to writeInAnUnreadableAndUglyStyle or not. Brilliant! From qdunkan at gmail.com Wed Dec 9 20:47:51 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Dec 9 20:22:11 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <0BBE58B88167495A878E2773C3DC6C96@JohnPC> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <0BBE58B88167495A878E2773C3DC6C96@JohnPC> Message-ID: <2518b95d0912091747v71bdd451ke6968cecebe5146@mail.gmail.com> On Wed, Dec 9, 2009 at 3:26 PM, John D. Earle wrote: > The problem that I see with elision resulting in juxtaposition is that it > would alter the layout. Each line would not have the same number of > characters before and after the makeover. Visual appearance would also be > altered. Replacing hyphens with underscores as I originally proposed As long as we're pushing pet peeves: don't line things up vertically then. If you use a newline and add a tab level you can still use layout and not have this problem. You wind up with less indentation too, though occasionally more vertical space. And you can use proportional fonts if you want. And you can use editor indent/dedent commands without the editor having to understand haskell. Etc. My pet peeve is having to lean on the space bar while squinting at the screen because someone wants to line things up vertically. From nad at Cs.Nott.AC.UK Wed Dec 9 20:49:56 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Wed Dec 9 20:29:32 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? In-Reply-To: <200912091350.40309.dan.doel@gmail.com> References: <798686260912080710p589a6c97h429fe71fc9e38a41@mail.gmail.com> <4B1FC766.1060202@cs.nott.ac.uk> <200912091350.40309.dan.doel@gmail.com> Message-ID: <4B2053C4.20004@cs.nott.ac.uk> On 2009-12-09 18:50, Dan Doel wrote: > (Your parsers aren't PEGs, are they? If so, I apologize for the > redundancy.) No, my parsers use Brzozowski derivatives. See the related work section of the paper I mentioned for some other parser combinator libraries which can handle (some) left recursive grammars. -- /NAD From allbery at ece.cmu.edu Wed Dec 9 21:00:00 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Dec 9 20:34:51 2009 Subject: [Haskell-cafe] Re: Handles with their IOMode in their type In-Reply-To: References: Message-ID: <0E16EDDF-C99D-4F8B-BF4F-7100A43FE098@ece.cmu.edu> On Dec 9, 2009, at 16:51 , Bas van Dijk wrote: > I will change the types to: > > stdin :: Handle ReadMode > stdout :: Handle WriteMode > stderr :: Handle WriteMode > > Or are there scenarios where people want to write to stdin or read > from stdout or stderr? These situations *do* come up; the controlling terminal for a program is open read/write on all 3 file descriptors initially, ands programs like more/less/pg rely on this and do their I/O on stdout. Additionally, on *BSD pipes are actually socketpairs and therefore bidirectional, and a small number of programs rely on this. But I would not do that by default, just expose a way for programs to make it so if they wish. (Hm, just discovered that the System.Posix.IO wrapper for fcntl() does *not* expose the part of the result of F_GETFL that reports the open mode. Boo hiss.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091209/082a52e1/PGP.bin From JohnDEarle at cox.net Wed Dec 9 21:04:28 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 20:39:00 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <2518b95d0912091747v71bdd451ke6968cecebe5146@mail.gmail.com> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <0BBE58B88167495A878E2773C3DC6C96@JohnPC> <2518b95d0912091747v71bdd451ke6968cecebe5146@mail.gmail.com> Message-ID: <86EC4BBFC2714166B95857514F303441@JohnPC> Interesting point. I'll have to try what you suggested. A proportional font would lessen the need to align things up vertically. It is annoying from a typographical stand point when things are almost aligned, but a tad off and so I must admit that I am guilty as charged. Monospaced fonts encourage this condition. -------------------------------------------------- From: "Evan Laforge" Sent: 09 Wednesday December 2009 1847 To: "John D. Earle" Cc: "Haskell Cafe" Subject: Re: [Haskell-cafe] Re: Allowing hyphens in identifiers > On Wed, Dec 9, 2009 at 3:26 PM, John D. Earle wrote: >> The problem that I see with elision resulting in juxtaposition is that it >> would alter the layout. Each line would not have the same number of >> characters before and after the makeover. Visual appearance would also be >> altered. Replacing hyphens with underscores as I originally proposed > > As long as we're pushing pet peeves: don't line things up vertically > then. If you use a newline and add a tab level you can still use > layout and not have this problem. You wind up with less indentation > too, though occasionally more vertical space. And you can use > proportional fonts if you want. And you can use editor indent/dedent > commands without the editor having to understand haskell. Etc. > > My pet peeve is having to lean on the space bar while squinting at the > screen because someone wants to line things up vertically. From uzytkownik2 at gmail.com Wed Dec 9 21:17:07 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Wed Dec 9 20:52:05 2009 Subject: [Haskell-cafe] Re: Re: Re: Allowing hyphens in identifiers In-Reply-To: <78A4CA0F-7112-47B4-B98A-CEE9BDB7769C@phys.washington.edu> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <1260401055.2949.75.camel@picard> <78A4CA0F-7112-47B4-B98A-CEE9BDB7769C@phys.washington.edu> Message-ID: <1260411427.2949.80.camel@picard> On Wed, 2009-12-09 at 15:54 -0800, Gregory Crosswhite wrote: > On Dec 9, 2009, at 3:24 PM, Maciej Piechotka wrote: > > > On Thu, 2009-12-10 at 11:54 +1300, Richard O'Keefe wrote: > > - Composition: In which first letters are not capitalized > > > > In combination of those I belive there is no disambiguoty since the > > lower case words functions as terminators. > > Except for data constructors, which are a special class of functions that start with capital letters; this where an ambiguity can (and does) crop up that is resolved by the spacing rule. > > Cheers, > Greg You're right. However it is still rather rare case comparing to the use of - I belive. Epsecially that with - we already have sufficiently complicated paring rules [($), ($a), (a$) where $ is any operator except - vs. -] Regards From john at repetae.net Wed Dec 9 21:19:43 2009 From: john at repetae.net (John Meacham) Date: Wed Dec 9 20:54:06 2009 Subject: [Haskell-cafe] Natural Language Processing In-Reply-To: <1CE1DC965D46463A899924D4DD778178@JohnPC> References: <1CE1DC965D46463A899924D4DD778178@JohnPC> Message-ID: <20091210021942.GB6668@sliver.repetae.net> On Wed, Dec 09, 2009 at 06:11:04PM -0700, John D. Earle wrote: > Is Parsec capable of parsing a mildly context sensitive language? In > particular does it parse a combinatory categorial grammar? Does > Haskell have such tools in its shed? What sort of facilities does > Haskell have for natural language processing? The happy parser generator now has a GLR mode, which allows parsing of ambiguous grammers such as occur in natural languages. It uses clever representation to avoid space issues with storing the large number of possible parse trees. I believe NLP was one of the main motivations of the feature but am not sure. I too am interested in lightweight NLP in haskell but have not had time to put into it. I'd be curious what you come up with. http://www.haskell.org/happy/doc/html/sec-glr.html John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From jvlask at hotmail.com Wed Dec 9 21:20:50 2009 From: jvlask at hotmail.com (John Lask) Date: Wed Dec 9 20:55:28 2009 Subject: [Haskell-cafe] Natural Language Processing In-Reply-To: <1CE1DC965D46463A899924D4DD778178@JohnPC> References: <1CE1DC965D46463A899924D4DD778178@JohnPC> Message-ID: maybe this helps ... see http://www.cs.chalmers.se/~aarne/GF/ I quote from the web site: GF is "a categorial grammar formalism, like ACG, CCG, but different and equipped with different tools" it compiles with at least GHC 6.8.2 > Is Parsec capable of parsing a mildly context sensitive language? In > particular does it parse a combinatory categorial grammar? Does Haskell > have such tools in its shed? What sort of facilities does Haskell have > for natural language processing? > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From JohnDEarle at cox.net Wed Dec 9 21:48:28 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Wed Dec 9 21:23:01 2009 Subject: [Haskell-cafe] Natural Language Processing In-Reply-To: References: <1CE1DC965D46463A899924D4DD778178@JohnPC> Message-ID: <47509E402F2241F4A55EBC8DD5A51080@JohnPC> Yes, I was referring to CCG. Thank you. -------------------------------------------------- From: "John Lask" Sent: 09 Wednesday December 2009 1920 To: "John D. Earle" Cc: "Haskell Cafe" Subject: Re: [Haskell-cafe] Natural Language Processing > maybe this helps ... > see http://www.cs.chalmers.se/~aarne/GF/ > > I quote from the web site: GF is > > "a categorial grammar formalism, like ACG, CCG, but different and > equipped with different tools" > > it compiles with at least GHC 6.8.2 > >> Is Parsec capable of parsing a mildly context sensitive language? In >> particular does it parse a combinatory categorial grammar? Does Haskell >> have such tools in its shed? What sort of facilities does Haskell have >> for natural language processing? >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > From ajb at spamcop.net Wed Dec 9 22:39:37 2009 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Dec 9 22:14:01 2009 Subject: [Haskell-cafe] Zumkeller numbers In-Reply-To: <4B1FDEF2.2010905@imageworks.com> References: <200912090009.04154.daniel.is.fischer@web.de> <4c88418c0912090413h2f41fc2dq41dae57af9d456e6@mail.gmail.com> <4B1FDEF2.2010905@imageworks.com> Message-ID: <20091209223937.vdl9bia1i8gs8wwk-nwo@webmail.spamcop.net> G'day all. Quoting Dan Weston : > Ouch. That's what happens when you let a machine do the translation. > How about: > > "Once your good name is trashed, you can live unabashed." "Until you've lost your reputation, you never realize what a burden it was." -- Margaret Mitchell Cheers, Andrew Bromage From wren at freegeek.org Wed Dec 9 22:47:56 2009 From: wren at freegeek.org (wren ng thornton) Date: Wed Dec 9 22:16:49 2009 Subject: [Haskell-cafe] Type system speculation In-Reply-To: <4B200AB6.8090806@btinternet.com> References: <4B200AB6.8090806@btinternet.com> Message-ID: <4B206F6C.5030807@freegeek.org> Andrew Coppin wrote: > What we're really trying to do here is attach additional information to > a value - information which exists only in the type checker's head, but > has no effect on runtime behaviour (other than determining whether we > *get* to runtime). As far as I can tell, Haskell does not provide any > way to take an existing type and attach additional information to it in > such a way that code which cares about the new information can make use > of it, but existing code which doesn't care continues to work. Any > comments on this one? In defense of Haskell, that's not what the semantics of newtype are. The semantics of newtype declare that the, er, new type is unrelated to the old type--- despite however they may be represented at runtime. Thus, allowing functions to ignore the newtype wrapper would defeat the intentions of using newtypes in the first place. I actually find this to be one of the most powerful things in the type system of H98, and I miss having them in every other language where I'm forced to sacrifice performance or correctness. As a stop-gap measure you can always make your newtype a functor and then use (<$>) for application instead of ($) or whitespace. That said, I've also considered the ability to have a "multi-type" system where types can be annotated with orthogonal information like Perl's taint flag (which your example resembles) or which subset of IO is used for some particular IO x (e.g., which exceptions can be thrown). There's some trickiness with getting multi-types to work right because we'd like to be able to restrict certain functions to only accept sanitized values, or values in a given format, or what have you. That is, just passing the information around at the type level isn't enough, we have to be able to restrict it too. It's certainly a worthy avenue of research to work the kinks out and get a nice workable system. -- Live well, ~wren From wren at freegeek.org Wed Dec 9 22:58:00 2009 From: wren at freegeek.org (wren ng thornton) Date: Wed Dec 9 22:26:48 2009 Subject: [Haskell-cafe] Natural Language Processing In-Reply-To: <1CE1DC965D46463A899924D4DD778178@JohnPC> References: <1CE1DC965D46463A899924D4DD778178@JohnPC> Message-ID: <4B2071C8.3060503@freegeek.org> John D. Earle wrote: > Is Parsec capable of parsing a mildly context sensitive language? In particular does it parse a combinatory categorial grammar? Does Haskell have such tools in its shed? What sort of facilities does Haskell have for natural language processing? If you come back at the end of spring term I should have an adaptive incremental CCG parser for on-line integration with speech recognition and semantic evaluation (i.e., the complete stack of NLP for a speech-understanding robot). Until then, you may want to join the (quiet) Haskell NLP list: http://projects.haskell.org/nlp/ And there's the NLP section of Hackage: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:natural%20language%20processing If you're just interested in mildly-context-sensitive grammars rather than CCG in particular, Eric Kow's thesis work on generation with FB-LTAG grammars is also online: http://projects.haskell.org/GenI/ -- Live well, ~wren From dagit at codersbase.com Thu Dec 10 02:08:53 2009 From: dagit at codersbase.com (Jason Dagit) Date: Thu Dec 10 01:43:12 2009 Subject: [Haskell-cafe] Type system speculation In-Reply-To: <4B206F6C.5030807@freegeek.org> References: <4B200AB6.8090806@btinternet.com> <4B206F6C.5030807@freegeek.org> Message-ID: On Wed, Dec 9, 2009 at 7:47 PM, wren ng thornton wrote: > Andrew Coppin wrote: > >> What we're really trying to do here is attach additional information to a >> value - information which exists only in the type checker's head, but has no >> effect on runtime behaviour (other than determining whether we *get* to >> runtime). As far as I can tell, Haskell does not provide any way to take an >> existing type and attach additional information to it in such a way that >> code which cares about the new information can make use of it, but existing >> code which doesn't care continues to work. Any comments on this one? >> > > In defense of Haskell, that's not what the semantics of newtype are. The > semantics of newtype declare that the, er, new type is unrelated to the old > type--- despite however they may be represented at runtime. Thus, allowing > functions to ignore the newtype wrapper would defeat the intentions of using > newtypes in the first place. I actually find this to be one of the most > powerful things in the type system of H98, and I miss having them in every > other language where I'm forced to sacrifice performance or correctness. > > What caught me about Andrew's idea is that it would allow for kind polymorphism in a useful way. Or at least, in a way that I tend to yearn for it. Do you have anyway to get kind polymorphism? Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/b98c7440/attachment.html From oleg at okmij.org Thu Dec 10 02:16:34 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Dec 10 01:51:49 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? Message-ID: <20091210071634.D2E8D17363@Adric.ern.nps.edu> There are at least two parser combinator libraries that can deal with *any* left-recursive grammars. That said, Prof. Swierstra's advice to try to get rid of left recursion is still well worth to follow. The first library is described in Frost, Richard, Hafiz, Rahmatullah, and Callaghan, Paul. Parser Combinators for Ambiguous Left-Recursive Grammars. PADL2008. http://cs.uwindsor.ca/~richard/PUBLICATIONS/PADL_08.pdf It handles arbitrary left-recursive grammars, including eps-cycles. It copes with highly ambiguous grammars. It can produce all parses of the input sequence. It parses the input in O(n^4) time with respect to the size of the input. I have tried dealing with left-recursive grammars and too wrote a parser combinator library: http://okmij.org/ftp/Haskell/LeftRecursion.hs It can handle eps-cycles, ambiguity and other pathology. Here is a sample bad grammar: S -> S A C | C A -> B | aCa B -> B C -> b | C A The library is pure and uses no state (monad). Strictly speaking, the library produces a recognizer rather than a parser, or a recognizer that yields a list of fired productions. There are standard ways however to `lift' a recognizer to produce a parse tree. The library is far simpler than than of Frost et al, and does not require explicit labeling of productions. Although the library can be faster than Frost's et al when a parse exists, it currently can be far slower when no parse exists. (It still assuredly terminates.) Both libraries require that the whole input be known in advance: neither library does on-line parsing. The reason has to do with memoization and with the cut-off for the recursion (a productive left-recursive rule shouldn't be applied more times than there are characters in the input). That is quite a disappointment. Therefore, it is well worth to convert the left recursion away, as was described in Doaitse Swierstra's earlier message. From oleg at okmij.org Thu Dec 10 02:40:27 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Dec 10 02:15:42 2009 Subject: [Haskell-cafe] Re: Type system speculation Message-ID: <20091210074027.6067417363@Adric.ern.nps.edu> Andrew Coppin wrote: > What we're really trying to do here is attach additional information to a > value - information which exists only in the type checker's head, but has no > effect on runtime behaviour (other than determining whether we *get* to > runtime). As far as I can tell, Haskell does not provide any way to take an > existing type and attach additional information to it in such a way that > code which cares about the new information can make use of it, but existing > code which doesn't care continues to work. Any comments on this one? Haskell has had the ability to attach arbitrary many pieces of (type-level) data to arbitrary types for a long time -- ever since multi-parameter type classes and functional dependencies have been introduced. Nowadays, type families accomplish the same with fewer keystrokes. One merely needs to define a type family type family Attrib n index :: * which maps the existing type n and the index to an arbitrary type. Chung-chieh Shan and I have explored the technique to annotate data types with attributes describing alignment of the corresponding data, location in ROM or RAM, etc. http://okmij.org/ftp/Haskell/types.html#ls-resources Here is a sample annotation, from http://okmij.org/ftp/Computation/resource-aware-prog/VideoRAM.hs -- A Screen on old PC type ScreenCharT = Pair AWord8 AWord8 -- attribute and char proper scrchar_attr r = afst r scrchar_char r = asnd r type ScreenT = Array N25 (Array N80 ScreenCharT) data Screen = Screen instance Property Screen APInHeap HTrue instance Property Screen APARef (ARef N8 ScreenT) instance Property Screen APReadOnly HFalse instance Property Screen APOverlayOK HTrue -- many more can be added, perhaps in other modules type SmallScreenT = Array N5 (Array N80 ScreenCharT) -- we can place the Screen area at a fixed absolute address data ScreenAbs = ScreenAbs instance Property ScreenAbs APInHeap HFalse instance Property ScreenAbs APARef (ARef N8 ScreenT) instance Property ScreenAbs APReadOnly HFalse instance Property ScreenAbs APFixedAddr HTrue If we forget to assign property APReadOnly=HFalse, an operation write_area that uses a pointer in the area raises a type error. From dagit at codersbase.com Thu Dec 10 02:51:06 2009 From: dagit at codersbase.com (Jason Dagit) Date: Thu Dec 10 02:25:24 2009 Subject: [Haskell-cafe] Re: Handles with their IOMode in their type In-Reply-To: <0E16EDDF-C99D-4F8B-BF4F-7100A43FE098@ece.cmu.edu> References: <0E16EDDF-C99D-4F8B-BF4F-7100A43FE098@ece.cmu.edu> Message-ID: On Wed, Dec 9, 2009 at 6:00 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > On Dec 9, 2009, at 16:51 , Bas van Dijk wrote: > >> I will change the types to: >> >> stdin :: Handle ReadMode >> stdout :: Handle WriteMode >> stderr :: Handle WriteMode >> >> Or are there scenarios where people want to write to stdin or read >> from stdout or stderr? >> > > > These situations *do* come up; the controlling terminal for a program is > open read/write on all 3 file descriptors initially, ands programs like > more/less/pg rely on this and do their I/O on stdout. Additionally, on *BSD > pipes are actually socketpairs and therefore bidirectional, and a small > number of programs rely on this. > I was surprised to hear this, so I did some fact checking: http://books.google.com/books?id=rHyMRyDEG3gC&pg=PA39&lpg=PA39&dq=posix+write+to+stdin&source=bl&ots=vHsgioIR8J&sig=PPXTzuwuuxyx_peCnuSNVmE220I&hl=en&ei=o6cgS-DxJ5S0sgPSl82kBQ&sa=X&oi=book_result&ct=result&resnum=3&ved=0CA8Q6AEwAjgK#v=onepage&q=&f=false Looks like you're telling the truth. Learn something new every time I read Haskell-Cafe :) Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/7511dd01/attachment.html From ketil at malde.org Thu Dec 10 05:34:39 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Dec 10 05:08:55 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> (Richard O'Keefe's message of "Thu, 10 Dec 2009 11:54:22 +1300") References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> Message-ID: <87zl5rungg.fsf@malde.org> "Richard O'Keefe" writes: >> You mean to parse a - b differently then a-b? You don't have the >> problem in LISP as AFAIR you use (- a b) but in Haskell it would be a >> problem. > Haskell already has this problem with ".", where we generally need (As somebody pointed out, this is usually unambigous) > to put spaces around "." with the meaning "composition" and not > put spaces around other uses. With implicit parameters, this also goes for (?). Is anybody using that extension still? > It's a problem that COBOL solved a long time ago: > COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. That we all program in COBOL these days shows how important this issue is :-) > Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that I prefer underscored_words myself, but just like periods for hierarchical modules, this is water under the bridge. In sum, perhaps the net effect of this convention is positive: it encourages short variable names. -k -- If I haven't seen further, it is by standing in the footprints of giants From JohnDEarle at cox.net Thu Dec 10 05:46:49 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 05:21:23 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <1AE7225B-A788-4E90-AA38-4BFAF05F4258@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com><1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <0BBE58B88167495A878E2773C3DC6C96@JohnPC> <1AE7225B-A788-4E90-AA38-4BFAF05F4258@cs.otago.ac.nz> Message-ID: To Underscore or Not to Underscore Richard O'Keefe and I were privately discussing the relative merits of his and my approach. We have come to an agreement. It concerns whether or not hyphens should be replaced with underscores. The following is my response to his most recent letter: I do not believe your approach given what you wrote here will create the sort of ambiguity I feared could be introduced. If an ambiguity results, it could be fixed. As I would put it, you hope to harmonize the word breaking styles by a process similar to though slightly more involved than what is done to remove case sensitivity in some languages. As layout is concerned only leading white space needs to be preserved. Anything else could be regarded as a superstition (not to say that computer scientists are superstitious). What you hope to do is kill two birds with one stone. If the only goal is to run everything through a preprocessor my approach seems to make the greatest sense, but if you also hope to harmonize the representation of word breaking styles, then what you are advocating seems to make greater sense. Your approach seems more consistent with Haskell traditions than mine. Therefore, I concede. You have successfully argued your point. From JohnDEarle at cox.net Thu Dec 10 07:01:23 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 06:35:57 2009 Subject: [Haskell-cafe] Why? Message-ID: <8C98544430C04B15872766E13F8CFD13@JohnPC> This is a matter that I genuinely at the present time do not grasp and I am hoping that some of you who are more familiar with the Haskell language may be able to help enlighten me. I feel the question to be an important one. What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction. The following is what I believe to be true at the present time. It seems to be that the decision was made because it was a matter of taste under the belief that computer scientists can and often are superstitious and their superstitions can and often do materially interfere with progress. What I am saying is that at the present time perhaps due to my ignorance I am unfamiliar with how this benefits the language in a material sense. It appears to be a philosophical matter, a matter of identity, what Haskell stands for. The sort of decision that Apple computer and Microsoft made not to go down the POSIX road seems relevant. Historically, Apple did not embrace POSIX. Windows continues to stand for Windows, that is the graphical user interface. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/3f32fdcc/attachment.html From magnus at therning.org Thu Dec 10 07:07:32 2009 From: magnus at therning.org (Magnus Therning) Date: Thu Dec 10 06:41:52 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <8C98544430C04B15872766E13F8CFD13@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle wrote: > This is a matter that I genuinely at the present time do not grasp and I am > hoping that some of you who are more familiar with the Haskell language may > be able to help enlighten me. I feel the question to be an important one. > What material benefit does Haskell derive from being a "pure" functional > language as opposed to an impure one? Please provide examples as I require > instruction. > > The following is what I believe to be true at the present time. It seems to > be that the decision was made because it was a matter of taste under the > belief that computer scientists can and often are superstitious and their > superstitions can and often do materially interfere with?progress. What I am > saying is that at the present time perhaps due to my ignorance I am > unfamiliar with how this benefits the language in a material sense. It > appears to be a philosophical matter, a matter of identity, what Haskell > stands for. > > The sort of decision that Apple computer and Microsoft made not to go down > the POSIX road seems relevant. Historically, Apple did not embrace POSIX. > Windows continues to stand for Windows, that is the graphical user > interface. As I understand it it all started with laziness. I don't know if laziness is impossible without purity, but talks and papers tend to say something like "laziness has kept Haskell pure". /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus identi.ca|twitter: magthe From johann.hoechtl at gmail.com Thu Dec 10 07:10:55 2009 From: johann.hoechtl at gmail.com (=?ISO-8859-1?Q?Johann_H=F6chtl?=) Date: Thu Dec 10 06:45:12 2009 Subject: [Haskell-cafe] Haskell and sockets Message-ID: <569fb061-9dbe-4626-949f-5be6059b5c36@9g2000yqa.googlegroups.com> Hello, How does Haskell handle sockets? Is it using select or epoll? I ask especially in regard to http://groups.google.com/group/erlang-programming/browse_frm/thread/a73efebabf352d19# Regards, Johann From JohnDEarle at cox.net Thu Dec 10 07:29:15 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 07:03:47 2009 Subject: [Haskell-cafe] Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: Magnus, thank you. It at least gives me a lead. I can focus on the significance of laziness and what role it may have on purity. That the language is lazy gives me no anxiety as I see laziness as natural. I see Haskell as having proven that laziness is viable; a language can be lazy and fast and memory efficient. I am trying to put the puzzle pieces together and from what I can gather purity may be a perceived outcome of combinatory logic with Occam's razor. So perhaps the motivation is scientific. Unless you absolutely must don't go there. Science is an evolutionary process. You go from Newtonian mechanics to Relativity. Relativity is more complicated than Newtonian mechanics, but it was proven that the additional complexity was needed. -------------------------------------------------- From: "Magnus Therning" Sent: 10 Thursday December 2009 0507 To: "John D. Earle" Cc: "Haskell Cafe" Subject: Re: [Haskell-cafe] Why? > On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle > wrote: >> This is a matter that I genuinely at the present time do not grasp and I >> am >> hoping that some of you who are more familiar with the Haskell language >> may >> be able to help enlighten me. I feel the question to be an important one. >> What material benefit does Haskell derive from being a "pure" functional >> language as opposed to an impure one? Please provide examples as I >> require >> instruction. >> >> The following is what I believe to be true at the present time. It seems >> to >> be that the decision was made because it was a matter of taste under the >> belief that computer scientists can and often are superstitious and their >> superstitions can and often do materially interfere with progress. What I >> am >> saying is that at the present time perhaps due to my ignorance I am >> unfamiliar with how this benefits the language in a material sense. It >> appears to be a philosophical matter, a matter of identity, what Haskell >> stands for. >> >> The sort of decision that Apple computer and Microsoft made not to go >> down >> the POSIX road seems relevant. Historically, Apple did not embrace POSIX. >> Windows continues to stand for Windows, that is the graphical user >> interface. > > As I understand it it all started with laziness. I don't know if > laziness is impossible without purity, but talks and papers tend to > say something like "laziness has kept Haskell pure". > > /M > > -- > Magnus Therning (OpenPGP: 0xAB4DFBA4) > magnus?therning?org Jabber: magnus?therning?org > http://therning.org/magnus identi.ca|twitter: magthe From JohnDEarle at cox.net Thu Dec 10 07:45:53 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 07:20:26 2009 Subject: [Haskell-cafe] Re: Nano-Languages Message-ID: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC> Earlier in this thread I wrote "... but like so what." In this letter I hope to address what I wrote more fully. The command line option that was found that allows for Haskell source code to be preprocessed accepts a Haskell source code file as an argument. This file defines a preprocessor. It seems to me that such a preprocessor would be undisciplined and capable of wrong doing because the Haskell language does not have all the facilities that a utility such as Happy possesses. Care is needed. It also lacks those facilities that are particular to preprocessors. The paper at http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf may provide a means to introduce this needed discipline. I do not see how the runtime verses compile time distinction is important, however. You can't really hand craft a preprocessor on the fly that is going to work. I do not believe the paper is explaining itself all that well. What they are referring to as syntax macros given a superficial examination of the paper seem to be the functional language equivalent of a definite clause grammar found in Prolog. So it seems that an effort to bring that goodness that Prolog programmers have enjoyed for years over to Haskell and perhaps to do one or two better. Their emphasis on runtime verses compile time seems like a distraction in that it is merely a necessary condition for inclusion into the Haskell language since Haskell is both compiled and interpreted. It is a problem that would need to be solved. They may have lost sight of what they were doing after having spent so much time working on just this one aspect. Haskell at the present time need external tools. The benefits of bringing in that sort of functionality into the language I would regard as self-evident. It is still a bottom up approach, but a bottom up approach would be easier to implement and it would be desirable for the two worlds to meet, the bottom up and the top down. An important question will be, Will syntax macros work out better than an existing tool such as Happy? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/5667f4be/attachment-0001.html From stephen.tetley at gmail.com Thu Dec 10 07:46:10 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Thu Dec 10 07:20:42 2009 Subject: [Haskell-cafe] Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <5fdc56d70912100446s3d5913c6u1006f239290c2d4b@mail.gmail.com> Hello All Paul Hudak's 'Conception, evolution, and application of functional programming languages' gives an account of the motivations, as its only available to ACM members, here are some lengthy quotes: "At least a dozen purely functional languages exist along with their implementations. The main property that is lost when side effects are introduced is referential transparency; this loss in turn impairs equational reasoning..." "Thus the analogy between goto-less programming and assignment-free programming runs deep. When Dijkstra first introduced structured programming, much of the programming community was aghast-how could one do without goto? But as people programmed in the new style, it was realized that what was being imposed was a discipline for good programming not a police state to inhibit expressiveness. Exactly the same can be said of side-effect free programming, and its advocates hope that as people become more comfortable programming in the functional style, they will appreciate the good sides of the discipline thus imposed. "When viewed in this way functional languages can be seen as a logical step in the evolution of imperative languages-thus, of course, rendering them nonimperative. On the other hand, it is exactly this purity to which some programmers object, and one could argue that just as a tasteful use of goto here or there is acceptable, so is a tasteful use of a side effect. Such small impurities certainly shouldn?t invalidate the functional programming style and thus may be acceptable." http://portal.acm.org/ft_gateway.cfm?id=72554&type=pdf The History of Haskell paper has less account of the motivations, but notes some drawbacks, and gives an advantage: "The purity of the language removed a significant technical obstacle to many type-system innovations, namely dealing with mutable state." http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm "Why purity?" / Why not? Best wishes Stephen From johann.hoechtl at gmail.com Thu Dec 10 08:01:37 2009 From: johann.hoechtl at gmail.com (=?ISO-8859-1?Q?Johann_H=F6chtl?=) Date: Thu Dec 10 07:35:54 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: ---------- Forwarded message ---------- From: "Bryan O'Sullivan" Date: Jan 2, 5:32?am Subject: Will GHC finally support epoll in 2009? To: Haskell-cafe On Wed, Dec 31, 2008 at 11:42 AM, Levi Greenspan wrote: >> Hence my question - is it likely that GHC will supportepollin 2009? > Yes. I'm working on a patch at the moment. Is there something planed to happen in 2010? _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/ haskell-cafe From 8mayday at gmail.com Thu Dec 10 08:01:41 2009 From: 8mayday at gmail.com (Andrey Popp) Date: Thu Dec 10 07:36:31 2009 Subject: [Haskell-cafe] Haskell and sockets In-Reply-To: <569fb061-9dbe-4626-949f-5be6059b5c36@9g2000yqa.googlegroups.com> References: <569fb061-9dbe-4626-949f-5be6059b5c36@9g2000yqa.googlegroups.com> Message-ID: GHC uses select() call in its I/O manager thread. There is ticket #635(http://hackage.haskell.org/trac/ghc/ticket/635) about replacing select() to more effective I/O multiplexer. On Thu, Dec 10, 2009 at 3:10 PM, Johann H?chtl wrote: > Hello, > > How does Haskell handle sockets? Is it using select or epoll? I ask > especially in regard to > http://groups.google.com/group/erlang-programming/browse_frm/thread/a73efebabf352d19# > > Regards, > > ? Johann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- ? ?????????, ?????? ????. +7 911 740 24 91 From johann.hoechtl at gmail.com Thu Dec 10 08:04:02 2009 From: johann.hoechtl at gmail.com (=?UTF-8?B?Sm9oYW5uIEjDtmNodGw=?=) Date: Thu Dec 10 07:38:24 2009 Subject: [Haskell-cafe] Haskell and sockets In-Reply-To: References: <569fb061-9dbe-4626-949f-5be6059b5c36@9g2000yqa.googlegroups.com> Message-ID: <4B20F1C2.8060507@gmail.com> Andrey Popp wrote: > GHC uses select() call in its I/O manager thread. There is ticket > #635(http://hackage.haskell.org/trac/ghc/ticket/635) about replacing > select() to more effective I/O multiplexer. > > Thank you, I found this ticket right back 10 minutes ago! > On Thu, Dec 10, 2009 at 3:10 PM, Johann H?chtl wrote: > >> Hello, >> >> How does Haskell handle sockets? Is it using select or epoll? I ask >> especially in regard to >> http://groups.google.com/group/erlang-programming/browse_frm/thread/a73efebabf352d19# >> >> Regards, >> >> Johann >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > > From JohnDEarle at cox.net Thu Dec 10 08:11:19 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 07:45:51 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: While going through the Haskell literature I uncovered a passage that said that, I'm paraphrasing: Complexity was at a premium. The task was very complex and what was needed to get Haskell to achieve its goals was extraordinary. This might explain how laziness kept Haskell pure. Everything was at a premium and this developed a discipline to keep everything streamlined. This suggests that purity had a material benefit, but the problem is it is conceivable that its material benefit was merely psychological. I do not have enough time to study what Stephen wrote at the moment so I will need to revisit it. He cited some references. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/34f6e847/attachment.html From nad at Cs.Nott.AC.UK Thu Dec 10 08:24:33 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Thu Dec 10 07:59:39 2009 Subject: [Haskell-cafe] Parsec-like parser combinator that handles left recursion? In-Reply-To: <20091210071634.D2E8D17363@Adric.ern.nps.edu> References: <20091210071634.D2E8D17363@Adric.ern.nps.edu> Message-ID: <4B20F691.2090909@cs.nott.ac.uk> On 2009-12-10 07:16, oleg@okmij.org wrote: > There are at least two parser combinator libraries that can deal with > *any* left-recursive grammars. Parser combinators are often used to describe infinite grammars (with a finite number of parametrised non-terminals). The library described by Frost et al. cannot handle all such grammars. For instance, it fails to terminate on p n = memoize n (p (1 + n)). (I don't think they claim that their library can handle such grammars.) Your library seems to handle infinite grammars better, as long as you can find a way to insert the incs correctly. I like the definition of Stream; I read Inc as being coinductive, and Plus as being inductive, and then it is easy to see that run is terminating (assuming that its arguments are well-behaved). However, it seems as if one has to be very careful in the placement of incs. Consider the following grammar: S -> A A -> S | B B -> A | eps The easiest implementation is incorrect: g1 = s where s = inc $ a a = inc $ s <+> b b = inc $ a <+> eps run "" g1 = Nothing The following one, where I have been more careful to only insert incs where absolutely necessary, works: g2 = s where s = a a = inc s <+> b b = inc a <+> eps run "" g2 = Just "" If I move the incs around it stops working again, though: g3 = s where s = inc a a = s <+> inc b b = a <+> eps run "" g3 = Nothing Have you proved that it is always possible to place the incs correctly? -- /NAD From sebastian.sylvan at gmail.com Thu Dec 10 08:27:49 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Dec 10 08:02:08 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <8C98544430C04B15872766E13F8CFD13@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle wrote: > This is a matter that I genuinely at the present time do not grasp and I > am hoping that some of you who are more familiar with the Haskell language > may be able to help enlighten me. I feel the question to be an important > one. What material benefit does Haskell derive from being a "pure" > functional language as opposed to an impure one? Please provide examples as > I require instruction. > The killer app for that, IMO, is parallelism these days.In large applications it's very hard to know for sure that a function truly has no side effects, so if the language can actually guarantee it for you then that certainly has immense value if you're trying to run things in parallel. Of course, various forms of lazy processing is becoming popular even in mainstream languages (especially with LINQ etc.), which also requires that the expressions to be pure. Currently mainstream languages rely on programmers being Very Careful, but again these kinds of assumptions aren't scalable. -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/cef79b7a/attachment.html From bulat.ziganshin at gmail.com Thu Dec 10 08:38:21 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Dec 10 08:12:48 2009 Subject: [Haskell-cafe] killer app, again In-Reply-To: <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> Message-ID: <1662913285.20091210163821@gmail.com> Hello Sebastian, Thursday, December 10, 2009, 4:27:49 PM, you wrote: > The killer app for that, IMO, is parallelism these days btw, are you seen Google App Engine? it's python/java ATM, but i think that haskell will be ideal fit there. it's all about computations-in-cloud, or more precisely hosting-in-a-cloud, like Amazon EC2 so, both individual cpus and largest servers now are multi-threaded, it just need some time so EC2/GAP developers will realize Haskell potential -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From agocorona at gmail.com Thu Dec 10 08:50:29 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu Dec 10 08:24:49 2009 Subject: Fwd: [Haskell-cafe] Re: Why? In-Reply-To: References: Message-ID: What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Here is my list of benefits of purity (some of them are enhanced by other features like the type system). Purity means referential transparency. that means that the programmer has no way to modify pure data. That cut the tree of possible programmer errors.In particular, since there are no variables, every state change must be in the form o a call to a function with new parameters. each function has no state change (except when needed and then the type system labels the stateful code as such)( This enforcement goes in the righ direction for clarity and readability, maintainability, modularity xxxxxbility. Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors. Purity permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed. Lazy evaluation eases mathematical reasoning,because mathematics has no notion of eager evaluation, but to make use of mathematical equations when the calculation is needed. . Mathematical reasoning permits the full use of a long tradition of mathematical knowledge. This makes code more simple, understandable, general, proof guarantted and elegant (for those that know the mathematical domain). This also permits high level optimization of code, both by the programmer and the compiler. for sure there are a few more We are superstitious and guided by "nonrational" ideas such is beauty. but: bauauty -> (simplicity -> (less effort to master, less errors) , utility ->, solve more problems, solve greater problems ) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/d59127c4/attachment.html From sebastian.sylvan at gmail.com Thu Dec 10 08:53:45 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Dec 10 08:28:03 2009 Subject: [Haskell-cafe] Re: killer app, again In-Reply-To: <1662913285.20091210163821@gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> <1662913285.20091210163821@gmail.com> Message-ID: <3d96ac180912100553p6b371ffbq62813d3bfa973dc2@mail.gmail.com> On Thu, Dec 10, 2009 at 1:38 PM, Bulat Ziganshin wrote: > Hello Sebastian, > > Thursday, December 10, 2009, 4:27:49 PM, you wrote: > > The killer app for that, IMO, is parallelism these days > > btw, are you seen Google App Engine? it's python/java ATM, but i think > that haskell will be ideal fit there. it's all about > computations-in-cloud, or more precisely hosting-in-a-cloud, like > Amazon EC2 > > so, both individual cpus and largest servers now are multi-threaded, > it just need some time so EC2/GAP developers will realize Haskell > potential Indeed. Something like Windows Azure could be a good fit too (as it more directly supports native code than GAE does). -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/82cc6483/attachment.html From agocorona at gmail.com Thu Dec 10 08:57:27 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu Dec 10 08:31:44 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: Message-ID: One more advantage that is not frequently cited Purity permits to pass every parameter of a procedure by reference (giving the pointer) rather that by value giving a copy, and still be sure that the data has not been modified. Besides the safety. this is great language optimization itself. 2009/12/10 Alberto G. Corona > > > > What material benefit does Haskell derive from being a "pure" functional > language as opposed to an impure one? > > > > Here is my list of benefits of purity (some of them are enhanced by other > features like the type system). > > Purity means referential transparency. that means that the programmer has > no way to modify pure data. That cut the tree of possible programmer > errors.In particular, since there are no variables, every state change must > be in the form o a call to a function with new parameters. each function has > no state change (except when needed and then the type system labels the > stateful code as such)( This enforcement goes in the righ direction for > clarity and readability, maintainability, modularity xxxxxbility. > > Purity also eases paralel processing, since no data is modified, each > process is isolated better. Less opportunities for errors. > > Purity permits lazines because since the execution tree of > an expression has pure, data, can be evaluated later, since it will not be > changed. > > Lazy evaluation eases mathematical reasoning,because mathematics has no > notion of eager evaluation, but to make use of mathematical equations when > the calculation is needed. . > > Mathematical reasoning permits the full use of a long tradition of > mathematical knowledge. This makes code more simple, understandable, > general, proof guarantted and elegant (for those that know the mathematical > domain). This also permits high level optimization of code, both by the > programmer and the compiler. > > for sure there are a few more > > We are superstitious and guided by "nonrational" ideas such is beauty. > but: > > bauauty -> (simplicity -> (less effort to master, less errors) > , utility ->, solve more problems, solve greater > problems > ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/919e214d/attachment.html From daniel.is.fischer at web.de Thu Dec 10 09:00:41 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Dec 10 08:36:29 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> Message-ID: <200912101500.42070.daniel.is.fischer@web.de> Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: > Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? 'Tis a matter of personal preference. From stephen.tetley at gmail.com Thu Dec 10 09:04:00 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Thu Dec 10 08:38:20 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> Message-ID: <5fdc56d70912100604n7e1e6360o49201a30d4f03137@mail.gmail.com> 2009/12/10 Sebastian Sylvan : > > > The killer app for that, IMO, is parallelism these days. Parallelism has been a killer app for quite a long time: Darlington's ALICE running Hope: http://www.chilton-computing.org.uk/acd/dcs/projects/p011.htm Clean was originally targeted to parallel machines: http://wiki.clean.cs.ru.nl/FAQ Many, many more: http://www.di.unipi.it/didadoc/lfc/OtherPapers/parallelism/parallel-introduction.pdf http://www.risc.uni-linz.ac.at/people/schreine/papers/pfpbib.ps.gz Best wishes Stephen From miguelimo38 at yandex.ru Thu Dec 10 09:05:21 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Dec 10 08:41:21 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <200912101500.42070.daniel.is.fischer@web.de> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <200912101500.42070.daniel.is.fischer@web.de> Message-ID: <4B210021.2060206@yandex.ru> Not to mention that in Emacs with glasses-mode enabled camelCase can be made even more readable (my personal favorite is highlighting internal capital letters with bold). Daniel Fischer wrote: > Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: >> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that >> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, > > mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others (granted, > underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? > 'Tis a matter of personal preference. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From leimy2k at gmail.com Thu Dec 10 09:11:29 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Dec 10 08:45:47 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: Message-ID: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> And that would be true if everything were strict and not partially evaluated sometimes :-) My understanding is the following... (and I could be way off) Remember that a function of arity N is really N functions of arity 1 with their arguments bound one at a time to create a new function along the way. At least you *can* write your code that way if you really want to, but the laziness might make it such that all the parameters are not bound, due to not being "needed" at that moment. Instead a thunk or what some other languages might call a "Future" is put in the argument's place, to be evaluated when needed. If Haskell were strict by default, I think your claim of passing references around could be true, but my experience with Haskell has been that sometimes it's too lazy for me to write the code that I first thought would be efficient without a lot f study and refactoring of that code. I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was. Dave On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona wrote: > One more advantage that is not frequently cited > > Purity permits to pass every parameter of a procedure by reference (giving > the pointer) rather that by value giving a copy, and still be sure that the > data has not been modified. Besides the safety. this is great language > optimization itself. > > 2009/12/10 Alberto G. Corona > > >> >> >> What material benefit does Haskell derive from being a "pure" functional >> language as opposed to an impure one? >> >> >> >> Here is my list of benefits of purity (some of them are enhanced by other >> features like the type system). >> >> Purity means referential transparency. that means that the programmer has >> no way to modify pure data. That cut the tree of possible programmer >> errors.In particular, since there are no variables, every state change must >> be in the form o a call to a function with new parameters. each function has >> no state change (except when needed and then the type system labels the >> stateful code as such)( This enforcement goes in the righ direction for >> clarity and readability, maintainability, modularity xxxxxbility. >> >> Purity also eases paralel processing, since no data is modified, each >> process is isolated better. Less opportunities for errors. >> >> Purity permits lazines because since the execution tree of >> an expression has pure, data, can be evaluated later, since it will not be >> changed. >> >> Lazy evaluation eases mathematical reasoning,because mathematics has no >> notion of eager evaluation, but to make use of mathematical equations when >> the calculation is needed. . >> >> Mathematical reasoning permits the full use of a long tradition of >> mathematical knowledge. This makes code more simple, understandable, >> general, proof guarantted and elegant (for those that know the mathematical >> domain). This also permits high level optimization of code, both by the >> programmer and the compiler. >> >> for sure there are a few more >> >> We are superstitious and guided by "nonrational" ideas such is beauty. >> but: >> >> bauauty -> (simplicity -> (less effort to master, less errors) >> , utility ->, solve more problems, solve greater >> problems >> ) >> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/abe092b6/attachment.html From wren at freegeek.org Thu Dec 10 09:22:50 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Dec 10 08:51:36 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <8C98544430C04B15872766E13F8CFD13@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <4B21043A.1040409@freegeek.org> John D. Earle wrote: > This is a matter that I genuinely at the present time do not grasp and I am hoping that some of you who are more familiar with the Haskell language may be able to help enlighten me. I feel the question to be an important one. What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction. > > The following is what I believe to be true at the present time. It seems to be that the decision was made because it was a matter of taste under the belief that computer scientists can and often are superstitious and their superstitions can and often do materially interfere with progress. What I am saying is that at the present time perhaps due to my ignorance I am unfamiliar with how this benefits the language in a material sense. It appears to be a philosophical matter, a matter of identity, what Haskell stands for. > > The sort of decision that Apple computer and Microsoft made not to go down the POSIX road seems relevant. Historically, Apple did not embrace POSIX. Windows continues to stand for Windows, that is the graphical user interface. Laziness, referential transparency, equational reasoning,... They're excellent things, but how about a pragmatic example? I was working recently on a metaprogramming framework to automate the generation of a bunch of shell scripts for wiring programs together. To ensure bug-free scripts we want to maintain a few invariants. One invariant is that the names of files to be generated should not be accessible prior to the file actually being generated (to avoid the file equivalent of a null-pointer dereference). Another invariant is that if someone wants to run a particular generated script then we should ensure that all prerequisite scripts are run first (a la any other build system). After some familiarity with Haskell it's easy to see that what we want here is a monad. This particular monad keeps track for each value (i.e., script) the prerequisite values necessary for it to be valid (i.e., tracking all other values used in constructing this one). The monad laws ensure that no values can escape--- but only with purity. If we could, for example, make global assignments without altering the type signatures then it would be possible to smuggle a file name out of the monadic scope, and thus to violate our invariant about names only being accessible when they're valid. These sorts of issues were painfully apparent because I was writing this framework in an impure language for non-Haskellites to use. There are many other examples along these lines as well. In general, purity means we can actually use mathematical notions in a rigorous way to ensure the program behaves appropriately and are not susceptible to various logic bugs. Referential transparency and equational reasoning are just two special-case examples of this general benefit. Having monads actually be monads is another less recognized one. -- Live well, ~wren From agocorona at gmail.com Thu Dec 10 09:37:53 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu Dec 10 09:12:12 2009 Subject: Fwd: [Haskell-cafe] Re: Why? In-Reply-To: References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> Message-ID: My understanding is that a pointer to the lazy expression tree for the calcualtion of the parameter is put it the corresponding location of the function expression tree. But at any time you can force the evauation before the call. or the compiler itself. Optimization is possible depending on the knowledge. What happens if the parameter is a large list and the function handles a few elements?. All of these consideration pales when a programmer has to call a procedure in a library made by others with no documentation, and no clue about what the procedure does inside. The purity and the type system removes many concerns. 2009/12/10 David Leimbach And that would be true if everything were strict and not partially evaluated > sometimes :-) > > My understanding is the following... (and I could be way off) > > Remember that a function of arity N is really N functions of arity 1 with > their arguments bound one at a time to create a new function along the way. > At least you *can* write your code that way if you really want to, but the > laziness might make it such that all the parameters are not bound, due to > not being "needed" at that moment. Instead a thunk or what some other > languages might call a "Future" is put in the argument's place, to be > evaluated when needed. > > If Haskell were strict by default, I think your claim of passing references > around could be true, but my experience with Haskell has been that sometimes > it's too lazy for me to write the code that I first thought would be > efficient without a lot f study and refactoring of that code. > > I'm sure this gets easier with practice, but it's not something I was > expecting to be as difficult as it all was. > > Dave > > On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona wrote: > >> One more advantage that is not frequently cited >> >> Purity permits to pass every parameter of a procedure by reference >> (giving the pointer) rather that by value giving a copy, and still be sure >> that the data has not been modified. Besides the safety. this is great >> language optimization itself. >> >> 2009/12/10 Alberto G. Corona >> >> >>> >>> >>> What material benefit does Haskell derive from being a "pure" functional >>> language as opposed to an impure one? >>> >>> >>> >>> Here is my list of benefits of purity (some of them are enhanced by other >>> features like the type system). >>> >>> Purity means referential transparency. that means that the programmer >>> has no way to modify pure data. That cut the tree of possible programmer >>> errors.In particular, since there are no variables, every state change must >>> be in the form o a call to a function with new parameters. each function has >>> no state change (except when needed and then the type system labels the >>> stateful code as such)( This enforcement goes in the righ direction for >>> clarity and readability, maintainability, modularity xxxxxbility. >>> >>> Purity also eases paralel processing, since no data is modified, each >>> process is isolated better. Less opportunities for errors. >>> >>> Purity permits lazines because since the execution tree of >>> an expression has pure, data, can be evaluated later, since it will not be >>> changed. >>> >>> Lazy evaluation eases mathematical reasoning,because mathematics has no >>> notion of eager evaluation, but to make use of mathematical equations when >>> the calculation is needed. . >>> >>> Mathematical reasoning permits the full use of a long tradition of >>> mathematical knowledge. This makes code more simple, understandable, >>> general, proof guarantted and elegant (for those that know the mathematical >>> domain). This also permits high level optimization of code, both by the >>> programmer and the compiler. >>> >>> for sure there are a few more >>> >>> We are superstitious and guided by "nonrational" ideas such is beauty. >>> but: >>> >>> bauauty -> (simplicity -> (less effort to master, less errors) >>> , utility ->, solve more problems, solve greater >>> problems >>> ) >>> >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/041aad04/attachment.html From greenrd at greenrd.org Tue Dec 8 10:00:43 2009 From: greenrd at greenrd.org (Robin Green) Date: Thu Dec 10 09:18:40 2009 Subject: [Haskell-cafe] Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: At Thu, 10 Dec 2009 12:07:32 +0000, Magnus Therning wrote: > As I understand it it all started with laziness. I don't know if > laziness is impossible without purity More or less. Haskell is a language where anything can be evaluated lazily by default. Unlike say Scheme, where if you want something to be evaluated lazily you have to be explicit about it, in Haskell it's the opposite - if you want something to be evaluated _strictly_ you have to be explicit about it. If you write an impure expression in Haskell (e.g. using unsafePerformIO) the side-effects of it might be executed once, twice, or never, depending on the Haskell implementation in use, the optimisation flags, or even other Haskell code in the system. And the side-effects might be executed at unpredictable times, in an unpredictable order, and only some of them might occur. Now, this might be fine for debugging purposes, where you want to see what is being done under the hood - but for most other side-effects, you really want them to occur in a more controllable way. Hence, to answer John's question, a lazy language _has_ to be pure (apart from the unsafe functions) because laziness (or, to be more technically correct, non-strict evaluation) is incompatible with good control of the side-effects arising from impure code. Both Clean and Haskell deal with side-effects by allowing the programmer to write imperative code in a pure way - in Haskell, by using monads or FRP, and in Clean by using world-passing and uniqueness types. Now, that answer probably suffices for a Haskell beginner. Of course eventually you realise time and space usage is a side-effect, and _that_ needs to be controlled as well... but despite this, I think my answer is basically right. However, that's not the _only_ reason why you might want purity. Even in a strict language, purity makes it easier to reason about code, because you don't have to consider the environment, only the parameters that are passed in. Of course, it gets more complicated with monads, because the Environment monad and the IO monad both give you implicit environments at the level of "running the monadic actions". But even then, it's supposed to be easier to reason about (once you get the hang of it), and I'd broadly agree with this. -- Robin From vlado at dikini.net Thu Dec 10 09:45:06 2009 From: vlado at dikini.net (Vladimir Zlatanov) Date: Thu Dec 10 09:19:25 2009 Subject: [Haskell-cafe] Re: Nano-Languages In-Reply-To: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC> References: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC> Message-ID: <4d197d970912100645i374987d3jb8a88306894e00b@mail.gmail.com> > An important question will be, Will syntax macros work out better than an > existing tool such as Happy? They work in scheme, and typed scheme http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf and a different hygienic mscheme is used in dylan http://people.csail.mit.edu/jrb/Projects/dexprs.pdf Both are based on pattern matching rewrite rules. Integrating a similar macro system in haskell should be possible, but definitely not trivial - how will it interact with the type system? Haskell is already halfway there, Template Haskell provides a platform to base them on http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/template-haskell.html From JohnDEarle at cox.net Thu Dec 10 09:50:19 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 09:24:51 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> Message-ID: David, think of the machine as being the earth and laziness is in the clouds. Strict evaluation is closer to the machine. The relationship between a lazy algorithm and the earth is abstract; hence, it will make creating algorithms especially efficient ones difficult. All of this is still a work in progress. The Haskell creed appears to be, This is the way so stick to it! The idea appears to be that by sticking to the program the problems will be overcome in time and we will be left with all the glorious goodness. At one time it was not possible to achieve the sort of efficiency that Haskell achieves as a matter of course. From leimy2k at gmail.com Thu Dec 10 10:06:06 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Dec 10 09:40:25 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> Message-ID: <3e1162e60912100706v6e9a66a3nad8bbb9b243f3394@mail.gmail.com> On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona wrote: > My understanding is that a pointer to the lazy expression tree for the > calcualtion of the parameter is put it the corresponding location of the > function expression tree. But at any time you can force the evauation before > the call. or the compiler itself. Optimization is possible depending on the > knowledge. What happens if the parameter is an infinite list and the > function handles a few items of it?. > > All of these consideration pales when a programmer has to call a procdure > in a library made by others with no documentation, and no clue about what > the procedure does inside. The purity and the type system removes many > concerns. > That's not a "safe" way to think of 3rd party libraries. It is a convenient claim for promoting the language, and is probably more often than not the case though it does not quite capture the whole truth. unsafePerformIO can exist in any library you import, and while you may think it's pure, you still have to implicitly trust the library writers (unless you bother to look at the source). Take Debug.Trace.trace for example, it's a pure computation, yet causes side effects. Yes, it's a controlled side effect, but a polluted version of the same function signature could "launch the missles" while looking like the function is synonymous with "id". In short unsafePerformIO, while it's "supposed to be" avoided, may not be avoided as much as the advice given to do so :-). Might be interesting to see how many occurrences of unsafePerformIO exist in hackage. I fully realize that someone will probably claim I'm taking this position to the extreme, but I think we're tempted to pretend that all functions with pure signatures are always safe which is another kind of extreme when you consider the existence of backdoors to the Monads that provide the guarantees we're clinging to to talk about how great Haskell is. I think the existence of unsafePerformIO is a bit of an admission that there's some things yet to be figured out to make this system 100% consistent with where we want pure functional programming to be. Dave > > 2009/12/10 David Leimbach > > And that would be true if everything were strict and not partially >> evaluated sometimes :-) >> >> My understanding is the following... (and I could be way off) >> >> Remember that a function of arity N is really N functions of arity 1 with >> their arguments bound one at a time to create a new function along the way. >> At least you *can* write your code that way if you really want to, but the >> laziness might make it such that all the parameters are not bound, due to >> not being "needed" at that moment. Instead a thunk or what some other >> languages might call a "Future" is put in the argument's place, to be >> evaluated when needed. >> >> If Haskell were strict by default, I think your claim of passing >> references around could be true, but my experience with Haskell has been >> that sometimes it's too lazy for me to write the code that I first thought >> would be efficient without a lot f study and refactoring of that code. >> >> I'm sure this gets easier with practice, but it's not something I was >> expecting to be as difficult as it all was. >> >> Dave >> >> On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona wrote: >> >>> One more advantage that is not frequently cited >>> >>> Purity permits to pass every parameter of a procedure by reference >>> (giving the pointer) rather that by value giving a copy, and still be sure >>> that the data has not been modified. Besides the safety. this is great >>> language optimization itself. >>> >>> 2009/12/10 Alberto G. Corona >>> >>> >>>> >>>> >>>> What material benefit does Haskell derive from being a "pure" >>>> functional language as opposed to an impure one? >>>> >>>> >>>> >>>> Here is my list of benefits of purity (some of them are enhanced by >>>> other features like the type system). >>>> >>>> Purity means referential transparency. that means that the programmer >>>> has no way to modify pure data. That cut the tree of possible programmer >>>> errors.In particular, since there are no variables, every state change must >>>> be in the form o a call to a function with new parameters. each function has >>>> no state change (except when needed and then the type system labels the >>>> stateful code as such)( This enforcement goes in the righ direction for >>>> clarity and readability, maintainability, modularity xxxxxbility. >>>> >>>> Purity also eases paralel processing, since no data is modified, each >>>> process is isolated better. Less opportunities for errors. >>>> >>>> Purity permits lazines because since the execution tree of >>>> an expression has pure, data, can be evaluated later, since it will not be >>>> changed. >>>> >>>> Lazy evaluation eases mathematical reasoning,because mathematics has no >>>> notion of eager evaluation, but to make use of mathematical equations when >>>> the calculation is needed. . >>>> >>>> Mathematical reasoning permits the full use of a long tradition of >>>> mathematical knowledge. This makes code more simple, understandable, >>>> general, proof guarantted and elegant (for those that know the mathematical >>>> domain). This also permits high level optimization of code, both by the >>>> programmer and the compiler. >>>> >>>> for sure there are a few more >>>> >>>> We are superstitious and guided by "nonrational" ideas such is beauty. >>>> but: >>>> >>>> bauauty -> (simplicity -> (less effort to master, less errors) >>>> , utility ->, solve more problems, solve greater >>>> problems >>>> ) >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/201b5ccf/attachment-0001.html From JohnDEarle at cox.net Thu Dec 10 10:07:17 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 09:41:49 2009 Subject: [Haskell-cafe] Re: Nano-Languages In-Reply-To: <4d197d970912100645i374987d3jb8a88306894e00b@mail.gmail.com> References: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC> <4d197d970912100645i374987d3jb8a88306894e00b@mail.gmail.com> Message-ID: <769BC90341874829B2CB33628A70D63D@JohnPC> If one were to think of this as a project, the initial project goal might be a proof of concept, that such an undertaking though non-trivial may be worth while. It would be desirable to act on the abstract syntax trees that result from the compiler parsing the source code and not the source code itself. -------------------------------------------------- From: "Vladimir Zlatanov" Sent: 10 Thursday December 2009 0745 To: "Haskell Cafe" Subject: Re: [Haskell-cafe] Re: Nano-Languages >> An important question will be, Will syntax macros work out better than an >> existing tool such as Happy? > > They work in scheme, and typed scheme > http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf > and a different hygienic mscheme is used in dylan > http://people.csail.mit.edu/jrb/Projects/dexprs.pdf > Both are based on pattern matching rewrite rules. Integrating a > similar macro system in haskell should be possible, but definitely not > trivial - how will it interact with the type system? > > Haskell is already halfway there, Template Haskell provides a platform > to base them on > http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/template-haskell.html > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From nad at Cs.Nott.AC.UK Thu Dec 10 10:06:34 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Thu Dec 10 09:43:30 2009 Subject: [Haskell-cafe] Natural Language Processing In-Reply-To: <1CE1DC965D46463A899924D4DD778178@JohnPC> References: <1CE1DC965D46463A899924D4DD778178@JohnPC> Message-ID: <4B210E7A.50908@cs.nott.ac.uk> On 2009-12-10 01:11, John D. Earle wrote: > Is Parsec capable of parsing a mildly context sensitive language? I expect that one can parse any decidable language using Parsec. Whether it is convenient to do so is another question. -- /NAD From JohnDEarle at cox.net Thu Dec 10 10:13:09 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 09:47:42 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <5E5AF0A75EB043A2AEB1C20DD70DEABD@JohnPC> Most of the discussion centers on the benefits of functional programming and laziness. Haskell is not merely a lazy functional language. It is a pure lazy functional language. I may need to explain what laziness is. Laziness is where you work through the logic in its entirely before acting on the result. In strict evaluation the logic is worked out in parallel with execution which doesn't make complete sense, but it does allow for an architecture that is close to the machine. From leimy2k at gmail.com Thu Dec 10 10:14:38 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Dec 10 09:48:55 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> Message-ID: <3e1162e60912100714nb34f6f5nbc36bdfaeb713653@mail.gmail.com> I understand that this is very much a work-in-progress. But we have to also come to the realization that there's people forming "industrial groups" and such around Haskell, and trying very earnestly to show that it's worth looking into for serious practical applications. I do believe that it's important to point out where there is work that needs to be done to meet all the goals that Haskell wants to achieve such that the selling points aren't possibly construed by the audience as disingenuous claims. Now having said that, this is *not* meant to be a slap in the face of those who want Haskell to be used in a practical way *now*. I am in fact one of them, having created code that has shipped and will continue to ship (at least until I'm forced to rewrite it... let's hope not) in Haskell in management systems that may, if our plans work out, be deployed potentially all over the world. Dave On Thu, Dec 10, 2009 at 6:50 AM, John D. Earle wrote: > David, think of the machine as being the earth and laziness is in the > clouds. Strict evaluation is closer to the machine. The relationship between > a lazy algorithm and the earth is abstract; hence, it will make creating > algorithms especially efficient ones difficult. All of this is still a work > in progress. The Haskell creed appears to be, This is the way so stick to > it! The idea appears to be that by sticking to the program the problems will > be overcome in time and we will be left with all the glorious goodness. At > one time it was not possible to achieve the sort of efficiency that Haskell > achieves as a matter of course. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/5a7ff5db/attachment.html From mightybyte at gmail.com Thu Dec 10 10:23:47 2009 From: mightybyte at gmail.com (MightyByte) Date: Thu Dec 10 09:58:03 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 9:50 AM, John D. Earle wrote: > in progress. The Haskell creed appears to be, This is the way so stick to > it! The idea appears to be that by sticking to the program the problems will > be overcome in time and we will be left with all the glorious goodness. At I think this is a bit of a misnomer. My perception of a "Haskell creed", if there really is one, is something more along the lines of: "Purity (also laziness, amongst other things) gives us some desirable properties. Let's see how far we can go with these ideas and if we can use them to solve practical problems." The Haskell community is not trying to shove these ideas down your throat. We're just interested in exploring them. Before monadic I/O was introduced, the absence of side effects made practical applications clumsy if not impossible [1]. But the Haskell researchers persisted. It just so happens that now the industry seems to be taking note of what the Haskell community has accomplished with careful adherence to these ideas. [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf From JohnDEarle at cox.net Thu Dec 10 10:30:48 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 10:05:21 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> My intuition says that laziness and purity are distinct whereas yours says that purity is a necessary condition. This is what needs to be reconciled. I believe that everyone is thinking that lazy evaluation and strict evaluation are similar activities whereas they are profoundly different. From JohnDEarle at cox.net Thu Dec 10 10:36:53 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 10:11:25 2009 Subject: [Haskell-cafe] Re: Why Message-ID: Laziness is on the logic front end and purity is on the execution back end. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/f05c4c37/attachment.html From ekirpichov at gmail.com Thu Dec 10 10:38:52 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Dec 10 10:13:13 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> Message-ID: <5e0214850912100738r4d912f02p32b4ff5707fabd15@mail.gmail.com> 2009/12/10 John D. Earle : > My intuition says that laziness and purity are distinct whereas yours says > that purity is a necessary condition. This is what needs to be reconciled. > Mixing impurity and laziness makes code whose behavior is too hard to understand. So, there is no theoretical reason not to mix them, but there is a practical one. > I believe that everyone is thinking that lazy evaluation and strict > evaluation are similar activities whereas they are profoundly different. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru From vlado at dikini.net Thu Dec 10 10:54:14 2009 From: vlado at dikini.net (Vladimir Zlatanov) Date: Thu Dec 10 10:28:32 2009 Subject: [Haskell-cafe] Re: Nano-Languages In-Reply-To: <769BC90341874829B2CB33628A70D63D@JohnPC> References: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC> <4d197d970912100645i374987d3jb8a88306894e00b@mail.gmail.com> <769BC90341874829B2CB33628A70D63D@JohnPC> Message-ID: <4d197d970912100754n41da795fhe8f1d7af7f838fe@mail.gmail.com> > If one were to think of this as a project, the initial project goal might be > a proof of concept, that such an undertaking though non-trivial may be worth > while. for me it is currently quite tough, since I don't know the internals at all > It would be desirable to act on the abstract syntax trees that result from > the compiler parsing the source code and not the source code itself. Template Haskell does that - it provides quotations, quasi-quotations and splicing, along with other utilities. I would guess that a simple design would be to add an import_syntax clause, similar to import, but importing only declarations with type ...-> Q ... and splicing automatically their appearances. This is a back of the envelope design, and I haven't considered any potential side-effects, but sounds like a reasonable approach From tom.davie at gmail.com Thu Dec 10 10:55:20 2009 From: tom.davie at gmail.com (Tom Davie) Date: Thu Dec 10 10:29:38 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> Message-ID: <8b70a98a0912100755p164e9839n58d2cef46275399e@mail.gmail.com> Non-strictness is not necessary for purity, but it sure gives you some nice properties... Take for example const x y = x It would be really nice for this function to have the property "always results in x no matter what you give it as it's second argument". But for a language which is strict, all instances where computing y non-terminates also non-terminate. So yes, non-strictness is very much a property you want in a language. Bob On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle wrote: > My intuition says that laziness and purity are distinct whereas yours says > that purity is a necessary condition. This is what needs to be reconciled. > > I believe that everyone is thinking that lazy evaluation and strict > evaluation are similar activities whereas they are profoundly different. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/3f258fe1/attachment.html From bugfact at gmail.com Thu Dec 10 11:00:58 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Dec 10 10:35:15 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <5e0214850912100738r4d912f02p32b4ff5707fabd15@mail.gmail.com> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> <5e0214850912100738r4d912f02p32b4ff5707fabd15@mail.gmail.com> Message-ID: Yes I remember when watching Erik Meijer's videos on Channel9 he said a similar thing: "laziness in the presence of side effects makes your head explode"... I guess the recent Microsoft Rx framework for .NET (that permits impure push-based functional reactive programming with LINQ) will soon show if the average software engineer can successfully combine side effects with laziness... Imperative/OO programming is full of guidelines to help the programmer avoid side effects: "use local state as much as possible", "never use mutable globals", "use single point of definition to avoid double out of sync data", "encapsulate encapsulate encapsulate", etc On Thu, Dec 10, 2009 at 4:38 PM, Eugene Kirpichov wrote: > 2009/12/10 John D. Earle : >> My intuition says that laziness and purity are distinct whereas yours says >> that purity is a necessary condition. This is what needs to be reconciled. >> > > Mixing impurity and laziness makes code whose behavior is too hard to > understand. So, there is no theoretical reason not to mix them, but > there is a practical one. > >> I believe that everyone is thinking that lazy evaluation and strict >> evaluation are similar activities whereas they are profoundly different. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Eugene Kirpichov > Web IR developer, market.yandex.ru > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From JohnDEarle at cox.net Thu Dec 10 11:02:08 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 10:36:41 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <5e0214850912100738r4d912f02p32b4ff5707fabd15@mail.gmail.com> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> <5e0214850912100738r4d912f02p32b4ff5707fabd15@mail.gmail.com> Message-ID: Eugene, by purity do you mean effect free? There is a subtle difference. The lack of effects makes a language functional, but this does not imply that the language is pure. -------------------------------------------------- From: "Eugene Kirpichov" Sent: 10 Thursday December 2009 0838 To: "John D. Earle" Cc: "Haskell Cafe" Subject: Re: [Haskell-cafe] Re: Why? > 2009/12/10 John D. Earle : >> My intuition says that laziness and purity are distinct whereas yours >> says >> that purity is a necessary condition. This is what needs to be >> reconciled. >> > > Mixing impurity and laziness makes code whose behavior is too hard to > understand. So, there is no theoretical reason not to mix them, but > there is a practical one. > >> I believe that everyone is thinking that lazy evaluation and strict >> evaluation are similar activities whereas they are profoundly different. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Eugene Kirpichov > Web IR developer, market.yandex.ru From ekirpichov at gmail.com Thu Dec 10 11:08:04 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Dec 10 10:42:22 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> <5e0214850912100738r4d912f02p32b4ff5707fabd15@mail.gmail.com> Message-ID: <5e0214850912100808h7c3baeaagefc2ee55f16a478a@mail.gmail.com> You're right. I mean referential transparency. 2009/12/10 John D. Earle : > Eugene, by purity do you mean effect free? There is a subtle difference. The > lack of effects makes a language functional, but this does not imply that > the language is pure. > > -------------------------------------------------- > From: "Eugene Kirpichov" > Sent: 10 Thursday December 2009 0838 > To: "John D. Earle" > Cc: "Haskell Cafe" > Subject: Re: [Haskell-cafe] Re: Why? > >> 2009/12/10 John D. Earle : >>> >>> My intuition says that laziness and purity are distinct whereas yours >>> says >>> that purity is a necessary condition. This is what needs to be >>> reconciled. >>> >> >> Mixing impurity and laziness makes code whose behavior is too hard to >> understand. So, there is no theoretical reason not to mix them, but >> there is a practical one. >> >>> I believe that everyone is thinking that lazy evaluation and strict >>> evaluation are similar activities whereas they are profoundly different. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> >> -- >> Eugene Kirpichov >> Web IR developer, market.yandex.ru > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru From JohnDEarle at cox.net Thu Dec 10 11:09:08 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 10:43:41 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: Laziness is on the logic front end and purity is on the execution back end. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/7da8bb77/attachment.html From vanenkj at gmail.com Thu Dec 10 11:13:22 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu Dec 10 10:47:42 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: Message-ID: If anything, I'd flip those two... On the backend, things are anything but pure but it helps us reason about the program on the front end. Laziness also isn't nearly as prevalent on the backend as it is on the front end. Even though we can reason about things using purity and laziness on the front, the compiler often times makes an identical situation that runs a lot faster using strictness and mutation on the back. /jve On Thu, Dec 10, 2009 at 11:09 AM, John D. Earle wrote: > Laziness is on the logic front end and purity is on the execution back > end. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/24218fb1/attachment.html From JohnDEarle at cox.net Thu Dec 10 11:15:25 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 10:49:57 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: <057BE731D23843E898964E7B2F1621B1@JohnPC> To elaborate there is another language that is also a functional language. I won't mention the name so as not to offend anyone. It too is effect free, that is what makes it functional and it is a functional language in the true sense of the term, but it is not effect free in the sense that Haskell is effect free. This other language is effect free in every practical sense whereas Haskell is effect free in a strict sense. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/977b67ee/attachment.html From JohnDEarle at cox.net Thu Dec 10 11:20:47 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 10:55:20 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: <8C19DAA93ACB42979F792DA3D1906108@JohnPC> So my question is, Did the leap from effect free for all practical purposes to effect free in a strict sense yield any material benefits? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/cd8b8da2/attachment.html From JohnDEarle at cox.net Thu Dec 10 11:30:53 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 11:05:25 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: <6B97EC4782AD47DEAB50CFB35BE361D2@JohnPC> What I think might be confusing the situation partially is that there is a difference between the language and its implementation. Any side effect would have been accounted for even though there is a means to side step it and its inclusion may have been perceived as a undesirable and perhaps unnecessary complication. To put it bluntly, it is like how division by zero can be inconvenient. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/4dfe5585/attachment.html From dev at mobileink.com Thu Dec 10 11:39:50 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Dec 10 11:14:08 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <5E5AF0A75EB043A2AEB1C20DD70DEABD@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <5E5AF0A75EB043A2AEB1C20DD70DEABD@JohnPC> Message-ID: <75cc17ac0912100839v6f43598cjb4a9b63e0efecd33@mail.gmail.com> On Thu, Dec 10, 2009 at 9:13 AM, John D. Earle wrote: > Most of the discussion centers on the benefits of functional programming > and laziness. Haskell is not merely a lazy functional language. It is a pure > lazy functional language. I may need to explain what laziness is. Laziness > is where you work through the logic in its entirely before acting on the > result. In strict evaluation the logic is worked out in parallel with > execution which doesn't make complete sense, but it does allow for an > architecture that is close to the machine. > > Just to roil the waters a bit: no programming language can ever hope to be "purely functional", for the simple reason that real computation (i.e. computation involving IO, interactivity) cannot be functional. "Functional programming" is an unfortunate misnomer. On the other hand, languages can be algebraic. The whole point is provability, not function-ness. More generally: judging by the many competing proposals addressing the issue of how to think formally about real computation (just google stuff like hypercomputation, interactive computation, etc.; Jack Copelandhas lots of interesting stuff on this) is still an open question. Soare has three essential papers on the subject. I guess the moral of the story is that the concepts and the terminology are both still unstable, so lots of terms in common use are rather ill-defined and misleading (e.g. functional programming). Lazyness is just a matter of how one attaches an actual computation to an expression; a better term would be something like "delayed evaluation" or "just-in-time computation". You don't have to work through any logic to have laziness. Just think about how one reads a mathematical text - you need not actually compute subformulae or even analyze them logically in order to work with them. This applies right down to expressions like "2+3" - one probably would compute "5" on reading that, but what about "12324/8353"? You'd leave the computation until you absolutely had to do it - i.e. one would probably try to eliminate it algebraically first. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/3108a00c/attachment.html From sebastian.sylvan at gmail.com Thu Dec 10 11:47:32 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Dec 10 11:21:50 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <057BE731D23843E898964E7B2F1621B1@JohnPC> References: <057BE731D23843E898964E7B2F1621B1@JohnPC> Message-ID: <3d96ac180912100847l6f5827e1q1e3bee7ee066a213@mail.gmail.com> On Thu, Dec 10, 2009 at 4:15 PM, John D. Earle wrote: > To elaborate there is another language that is also a functional > language. I won't mention the name so as not to offend anyone. It too is > effect free, that is what makes it functional and it is a functional > language in the true sense of the term, but it is not effect free in the > sense that Haskell is effect free. This other language is effect free in > every practical sense whereas Haskell is effect free in a strict sense. > Why would anyone be offended? I'd prefer if you tried to be clear about what you mean, rather than intentionally obscure your points to avoid causing offence. Be specific. What language? How is it different than Haskell w.r.t. purity? -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/d7383b7f/attachment.html From sebastian.sylvan at gmail.com Thu Dec 10 11:56:09 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Dec 10 11:30:26 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> Message-ID: <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle wrote: > My intuition says that laziness and purity are distinct whereas yours says > that purity is a necessary condition. This is what needs to be reconciled. > I think laziness requires purity to make sense. Laziness implies that the order of evaluation is highly unpredictable and depends strongly on the implementation details of libraries and such (which you may not have access to). So it's fickle. Someone adds an if statement somewhere and all of a sudden a variable gets evaluated earlier than it used to. It would be madness to write any code which depends on this unpredictable behaviour. In other words, the expressions that get evaluated lazily must not have side effects. -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/ce7ae284/attachment.html From JohnDEarle at cox.net Thu Dec 10 11:59:59 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 11:34:36 2009 Subject: [Haskell-cafe] Re: Nano-Languages In-Reply-To: <4d197d970912100754n41da795fhe8f1d7af7f838fe@mail.gmail.com> References: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC><4d197d970912100645i374987d3jb8a88306894e00b@mail.gmail.com><769BC90341874829B2CB33628A70D63D@JohnPC> <4d197d970912100754n41da795fhe8f1d7af7f838fe@mail.gmail.com> Message-ID: <83CC05FAED9B4343B1758E0B6719FB6D@JohnPC> Vladimir, I do not mind becoming more familiar with the internals, but as you pointed out that Template Haskell may provided much of the needed functionality. I tend to doubt that it will provide all the needed functionality, however. The new syntax created by the syntax macros will either reinterpret a preexisting production in the language or will create a new one which may be based on a preexisting production, a variant. In the latter case, the compiler will have a knee jerk reaction. It will feel that the structure is grammatically illegal! This knee jerk would need to be intercepted and assigned an interpretation. We would then need to calm the compiler down and say its ok. -------------------------------------------------- From: "Vladimir Zlatanov" Sent: 10 Thursday December 2009 0854 To: "Haskell Cafe" Subject: Re: [Haskell-cafe] Re: Nano-Languages >> If one were to think of this as a project, the initial project goal might >> be >> a proof of concept, that such an undertaking though non-trivial may be >> worth >> while. > > for me it is currently quite tough, since I don't know the internals at > all > >> It would be desirable to act on the abstract syntax trees that result >> from >> the compiler parsing the source code and not the source code itself. > > Template Haskell does that - it provides quotations, quasi-quotations > and splicing, along with other utilities. > > I would guess that a simple design would be to add an import_syntax > clause, similar to import, but importing only declarations with type > ...-> Q ... and splicing automatically their appearances. > > This is a back of the envelope design, and I haven't considered any > potential side-effects, but sounds like a reasonable approach > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mightybyte at gmail.com Thu Dec 10 12:03:50 2009 From: mightybyte at gmail.com (MightyByte) Date: Thu Dec 10 11:38:08 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 11:56 AM, Sebastian Sylvan wrote: > > > On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle wrote: >> >> My intuition says that laziness and purity are distinct whereas yours says >> that purity is a necessary condition. This is what needs to be reconciled. > > I think laziness requires purity to make sense. Laziness implies that the > order of evaluation is highly unpredictable and depends strongly on the > implementation details of libraries and such (which you may not have access > to). So it's fickle. Someone adds an if statement somewhere and all of a > sudden a variable gets evaluated earlier than it used to. It would be > madness to write any code which depends on this unpredictable behaviour. In > other words, the expressions that get evaluated lazily must not have side > effects. Yes, this is discussed in section 3.2 of the paper I cited earlier (http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf). That paper gives some nice insight into the history of Haskell. From leimy2k at gmail.com Thu Dec 10 12:04:48 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Dec 10 11:39:07 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <057BE731D23843E898964E7B2F1621B1@JohnPC> References: <057BE731D23843E898964E7B2F1621B1@JohnPC> Message-ID: <3e1162e60912100904g30063619pf14239f62c97c419@mail.gmail.com> My understanding of functional programming is that nearly everything is a function, and that evaluation of those functions is how programs are written. Functional programming languages treat functions as first class values, allowing them to be passed to other functions and returned from functions. In this sense Scheme qualifies as a functional language. However Scheme will fail your definition because you're saying it must be effect free, which is not the case with Scheme. It becomes difficult to have a discussion when the fundamental terms are not agreed upon :-) Dave On Thu, Dec 10, 2009 at 8:15 AM, John D. Earle wrote: > To elaborate there is another language that is also a functional > language. I won't mention the name so as not to offend anyone. It too is > effect free, that is what makes it functional and it is a functional > language in the true sense of the term, but it is not effect free in the > sense that Haskell is effect free. This other language is effect free in > every practical sense whereas Haskell is effect free in a strict sense. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/acae4bf0/attachment.html From jvranish at gmail.com Thu Dec 10 12:05:19 2009 From: jvranish at gmail.com (Job Vranish) Date: Thu Dec 10 11:39:38 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <057BE731D23843E898964E7B2F1621B1@JohnPC> References: <057BE731D23843E898964E7B2F1621B1@JohnPC> Message-ID: > > I won't mention the name so as not to offend anyone. Oh I'm sure we can handle it ;) Though I'm curious as to how a language could be effect free in a practical sense, but not a strict one? could you give an example? To answer your original question, there are many benefits haskell gains from being a pure language. (And by pure I mean that functions have no side effects, they can only give data to their environment via their return value). I think the my biggest reason (though there are probably others) is as follows: Pure code is easier to reason about than impure code: When I program for work (we use ada, ick) and I find that a function is returning a bad result it is very difficult to figure out where the malfunction is. Is the function itself the problem? incorrect parameters? some global flags setup incorrectly? Did I need to call another function to setup state before I called this one? In a pure language I can just check the function inputs. Are they good? if yes, then the problem is in the function, if no, then follow the value up the chain, etc... A simpler case would be a single variable in a large function. Say I trace a bug down to a bad value in a particular variable in a big function. I have to look at every place that the variable is modified in the function as well as any places where the variable is passed to other functions by reference _as well as_ the control flow from those mutations to the usage of the variable in question. In a pure language If a variable doesn't have the correct value I check the definition (there can only be one) Data flow in a pure language is so much easier to follow/understand and you never have to worry about the order of execution (which is what makes it easy to implement lazy evaluation). I have literally debugged _hundreds_ of errors in our codebase at work that would _not have even been possible_ in a pure language. The downside to purity is that sometimes it's slower (though this is becoming less and less of an issue, sometimes it's even faster) and sometimes it's much easier to mutate some state than pass a value back up a big chain. But overall I much prefer purity, it make my life so much easier. - Job On Thu, Dec 10, 2009 at 11:15 AM, John D. Earle wrote: > To elaborate there is another language that is also a functional > language. I won't mention the name so as not to offend anyone. It too is > effect free, that is what makes it functional and it is a functional > language in the true sense of the term, but it is not effect free in the > sense that Haskell is effect free. This other language is effect free in > every practical sense whereas Haskell is effect free in a strict sense. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/232beac0/attachment-0001.html From deniz.a.m.dogan at gmail.com Thu Dec 10 12:07:19 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Thu Dec 10 11:41:57 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> Message-ID: <7b501d5c0912100907r3dd6d6c3ia214f828f93703bc@mail.gmail.com> 2009/12/10 Sebastian Sylvan : > I think laziness requires purity to make sense. Laziness implies that the > order of evaluation is highly unpredictable and depends strongly on the > implementation details of libraries and such (which you may not have access > to). So it's fickle. Someone adds an if statement somewhere and all of a > sudden a variable gets evaluated earlier than it used to. It would be > madness to write any code which depends on this unpredictable behaviour. In > other words, the expressions that get evaluated lazily must not have side > effects. > -- > Sebastian Sylvan > +1 This unpredictability has bit me a few times when using LINQ (which is awesome and has lazy evaluation) with C#. -- Deniz Dogan From JohnDEarle at cox.net Thu Dec 10 12:16:40 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 11:51:13 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <75cc17ac0912100839v6f43598cjb4a9b63e0efecd33@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <5E5AF0A75EB043A2AEB1C20DD70DEABD@JohnPC> <75cc17ac0912100839v6f43598cjb4a9b63e0efecd33@mail.gmail.com> Message-ID: <060C5602B55A45848F6B2F2AF6D4C90E@JohnPC> Dear Gregg, You wrote, "Just think about how one reads a mathematical text - you need not actually compute subformulae or even analyze them logically in order to work with them." I hate to have to say this, but do you realize that algebra is concerned with functions among other things and it is the fact that these expressions are functions and not that they are algebraic that gives them this property? Functional programming is not a misnomer. It is called functional programming because you are quite literally working with functions. Functions have a profound simplifying effect. The truth is as Haskell has demonstrated that much of the complexity in computer programming is artificial and doesn't need to be there. It makes having to prove correctness a lot easier, but that is not the only motivation behind Haskell and other functional programming languages. The push has been getting performance up to a point where the language may be regarded as respectable. This has been a problem that has dogged artificial intelligence languages. It is easier to get a functional language to be efficient compared to a logic language. This reason for this is that you get the opportunity to work out more of the details as compared to a logic language. In assembler you get to work out every blessed detail to your hearts content or until you drop. That is why assembler has a reputation for being fast. It is the same reason why functional languages are fast comparatively speaking. From: Gregg Reynolds Sent: 10 Thursday December 2009 0939 To: John D. Earle Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Re: Why? On Thu, Dec 10, 2009 at 9:13 AM, John D. Earle wrote: Most of the discussion centers on the benefits of functional programming and laziness. Haskell is not merely a lazy functional language. It is a pure lazy functional language. I may need to explain what laziness is. Laziness is where you work through the logic in its entirely before acting on the result. In strict evaluation the logic is worked out in parallel with execution which doesn't make complete sense, but it does allow for an architecture that is close to the machine. Just to roil the waters a bit: no programming language can ever hope to be "purely functional", for the simple reason that real computation (i.e. computation involving IO, interactivity) cannot be functional. "Functional programming" is an unfortunate misnomer. On the other hand, languages can be algebraic. The whole point is provability, not function-ness. More generally: judging by the many competing proposals addressing the issue of how to think formally about real computation (just google stuff like hypercomputation, interactive computation, etc.; Jack Copeland has lots of interesting stuff on this) is still an open question. Soare has three essential papers on the subject. I guess the moral of the story is that the concepts and the terminology are both still unstable, so lots of terms in common use are rather ill-defined and misleading (e.g. functional programming). Lazyness is just a matter of how one attaches an actual computation to an expression; a better term would be something like "delayed evaluation" or "just-in-time computation". You don't have to work through any logic to have laziness. Just think about how one reads a mathematical text - you need not actually compute subformulae or even analyze them logically in order to work with them. This applies right down to expressions like "2+3" - one probably would compute "5" on reading that, but what about "12324/8353"? You'd leave the computation until you absolutely had to do it - i.e. one would probably try to eliminate it algebraically first. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/d42a208e/attachment.html From gcross at phys.washington.edu Thu Dec 10 12:17:22 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Thu Dec 10 11:55:14 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3d96ac180912100847l6f5827e1q1e3bee7ee066a213@mail.gmail.com> References: <057BE731D23843E898964E7B2F1621B1@JohnPC> <3d96ac180912100847l6f5827e1q1e3bee7ee066a213@mail.gmail.com> Message-ID: <28433BFC-C735-4275-815F-DCA348699C3E@phys.washington.edu> In fairness to John, his trying really hard to avoid causing offense might having something to do with the fact that he just had a couple dozen or so e-mails attacking him personally the last time he tried asking questions about Haskell and comparing it to O'Caml. I have to confess that I myself had thought at the time that he was being a troll --- i.e., in this case a person who shows up on a mailing list of fans of a language and attacks it just to create a fuss --- since he had not only pointed out reasons why the language is flawed (which is not in itself unreasonable, as long as it is being done in a constructive manner), but asked us to prove that it *wasn't* flawed, and said things that implied that we only liked it because we had never seriously looked at any other language. However, his recent e-mails on this have shown a serious willingness to really try to understand more about Haskell. Thus, perhaps there may have simply been a miscommunication/misunderstanding earlier. Cheers, Greg On Dec 10, 2009, at 8:47 AM, Sebastian Sylvan wrote: > > > On Thu, Dec 10, 2009 at 4:15 PM, John D. Earle wrote: > To elaborate there is another language that is also a functional language. I won't mention the name so as not to offend anyone. It too is effect free, that is what makes it functional and it is a functional language in the true sense of the term, but it is not effect free in the sense that Haskell is effect free. This other language is effect free in every practical sense whereas Haskell is effect free in a strict sense. > > Why would anyone be offended? I'd prefer if you tried to be clear about what you mean, rather than intentionally obscure your points to avoid causing offence. Be specific. What language? How is it different than Haskell w.r.t. purity? > > -- > Sebastian Sylvan > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/2c2f3e54/attachment.html From stephen.tetley at gmail.com Thu Dec 10 12:45:46 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Thu Dec 10 12:20:03 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3e1162e60912100706v6e9a66a3nad8bbb9b243f3394@mail.gmail.com> References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> <3e1162e60912100706v6e9a66a3nad8bbb9b243f3394@mail.gmail.com> Message-ID: <5fdc56d70912100945y18bf0091k3573690fe4d88ae9@mail.gmail.com> Hello David Apropos the (unfortunately) frosty exchanges that greeted the first release of UHC a couple of months ago, which argued that UHC wasn't Haskell because it didn't implement n+k patterns, one could argue (at least for rhetorical effect) that Haskell plus unsafePerformIO isn't Haskell, I don't think you'll be able to find unsafePerformIO in the report... Best wishes Stephen 2009/12/10 David Leimbach : > > That's not a "safe" way to think of 3rd party libraries. ?It is a convenient > claim for promoting the language, and is probably more often than not the > case though it does not quite capture the whole truth. ?unsafePerformIO can > exist in any library you import, [snip] > In short unsafePerformIO, while it's "supposed to be" avoided, may not be > avoided as much as the advice given to do so :-). From bos at serpentine.com Thu Dec 10 12:48:31 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Dec 10 12:22:48 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 5:01 AM, Johann H?chtl wrote: > > > Yes. I'm working on a patch at the moment. > > Is there something planed to happen in 2010? > Retooling the I/O manager isn't a huge job, but it requires the equivalent of several weeks of work. I tossed out my initial attempt at a patch because I didn't have time to work on it, so I'm back to square one. Johan Tibell and I have had occasional discussions about picking up the thread again, but we've had a busy year and it's moderately demanding work, so nothing has actually happened. If I develop the time and energy to take a serious crack at it, I will post here to let people know. This would be an effort where having multiple people work on different implementations concurrently would be a shame. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/09d4c05a/attachment.html From vlado at dikini.net Thu Dec 10 13:04:34 2009 From: vlado at dikini.net (Vladimir Zlatanov) Date: Thu Dec 10 12:38:51 2009 Subject: [Haskell-cafe] Re: Nano-Languages In-Reply-To: <83CC05FAED9B4343B1758E0B6719FB6D@JohnPC> References: <3557EBBB66D64DB48C1F3430BA9BE11B@JohnPC> <4d197d970912100645i374987d3jb8a88306894e00b@mail.gmail.com> <769BC90341874829B2CB33628A70D63D@JohnPC> <4d197d970912100754n41da795fhe8f1d7af7f838fe@mail.gmail.com> <83CC05FAED9B4343B1758E0B6719FB6D@JohnPC> Message-ID: <4d197d970912101004r172d331ete2b32337bd6c9d12@mail.gmail.com> I'll try to paraphrase you, to see if I understand you correctly. The composition splice . quote can have one 'hard' error source. Grammatically incorrect quote. I think that will be caught by the type checker. Of a bigger concern are logical errors, introduced by buggy macros. But it is template haskell, so the same rules and tools apply. What I suggest is replacing the $x of template haskell, with S.x, where S is a module imported for syntax. What I'm not sure is how to deal with matching$(...). I'm not sure that the parenthesis can be avoided in all cases. On Thu, Dec 10, 2009 at 4:59 PM, John D. Earle wrote: > Vladimir, I do not mind becoming more familiar with the internals, but as > you pointed out that Template Haskell may provided much of the needed > functionality. I tend to doubt that it will provide all the needed > functionality, however. The new syntax created by the syntax macros will > either reinterpret a preexisting production in the language or will create a > new one which may be based on a preexisting production, a variant. In the > latter case, the compiler will have a knee jerk reaction. It will feel that > the structure is grammatically illegal! This knee jerk would need to be > intercepted and assigned an interpretation. We would then need to calm the > compiler down and say its ok. > > -------------------------------------------------- > From: "Vladimir Zlatanov" > Sent: 10 Thursday December 2009 0854 > To: "Haskell Cafe" > Subject: Re: [Haskell-cafe] Re: Nano-Languages > >>> If one were to think of this as a project, the initial project goal might >>> be >>> a proof of concept, that such an undertaking though non-trivial may be >>> worth >>> while. >> >> for me it is currently quite tough, since I don't know the internals at >> all >> >>> It would be desirable to act on the abstract syntax trees that result >>> from >>> the compiler parsing the source code and not the source code itself. >> >> Template Haskell does that - it provides quotations, quasi-quotations >> and splicing, along with other utilities. >> >> I would guess that a simple design would be to add an import_syntax >> clause, similar to import, but importing only declarations with type >> ...-> Q ... and splicing automatically their appearances. >> >> This is a back of the envelope design, and I haven't considered any >> potential side-effects, but sounds like a reasonable approach >> _______________________________________________ >> 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 > From JohnDEarle at cox.net Thu Dec 10 13:19:40 2009 From: JohnDEarle at cox.net (John D. Earle) Date: Thu Dec 10 12:54:20 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: <86ED31DDEF0640B8BB4531C417016032@JohnPC> I'm going to try to respond to your letters later on when I have more time. This break may also be useful in that it may help the conversation from becoming overheated. I stopped in the middle of a letter and put it in the draft folder so that I could give it greater attention. I was writing it out too quickly. I was responding to Job Vranish. I was responding to his "Though I'm curious as to how a language could be effect free in a practical sense, but not a strict one? could you give an example?" query. My response is already fleshed out. I just have to polish it. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/6392221d/attachment.html From dev at mobileink.com Thu Dec 10 13:36:58 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Dec 10 13:11:15 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <060C5602B55A45848F6B2F2AF6D4C90E@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <5E5AF0A75EB043A2AEB1C20DD70DEABD@JohnPC> <75cc17ac0912100839v6f43598cjb4a9b63e0efecd33@mail.gmail.com> <060C5602B55A45848F6B2F2AF6D4C90E@JohnPC> Message-ID: <75cc17ac0912101036i5f552ec8q6121c682f4e77adc@mail.gmail.com> On Thu, Dec 10, 2009 at 11:16 AM, John D. Earle wrote: > Dear Gregg, > > You wrote, "Just think about how one reads a mathematical text - you need > not actually compute subformulae or even analyze them logically in order to > work with them." I hate to have to say this, but do you realize that algebra > is concerned with functions among other things and it is the fact that these > expressions are functions and not that they are algebraic that gives them > this property? > Hi John, I'd say algebra is mostly concerned with equalities and substitutions and doesn't much care about functions. The equation for a circle is not a function but that doesn't mean we can't use algebra to manipulate it. Algebras might use the concept of function but they are not necessarily _about_ functions. One could even argue that the lambda calculus isn't "about" functions - it's just a calculus, after all. Haskell goes by the rules of that calculus; whether the expressions involved denote functions is not relevant. The computer is just performs symbol calculus. Generally all formal semantics can be reduced to syntactic calculus as far as I can see. > Functional programming is not a misnomer. It is called functional > programming because you are quite literally working with functions. > Except when you're not. IO operations are never functions, for example, so IO expressions never denote functions. FP languages do not (and cannot) eliminate the side effectful nature of such operations; the best they can do is what Haskell does, namely circumscribe them so that they are well-behaved and thus can be properly managed (algebraically). But that doesn't make them functions. So for me at least "algebraic" better describes how Haskell works; what you're working with is expressions and you reason about them algebraically. You can do this reliably not because everything is a function but because non-functions are well-behaved. > Functions have a profound simplifying effect. > No argument there. But the expressive power that comes with first-class functions is not what distinguishes Haskell et al. - lots of non-FP languages support them these days. > The truth is as Haskell has demonstrated that much of the complexity in > computer programming is artificial and doesn't need to be there. It makes > having to prove correctness a lot easier, but that is not the only > motivation behind Haskell and other functional programming languages. The > push has been getting performance up to a point where the language may be > regarded as respectable. > Sure, but that's only possible because the properties of programs are provable, which is what makes it possible to reliably transform a program into an equivalent but more efficient form. -Gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/c00e6fd8/attachment.html From ketil at malde.org Thu Dec 10 13:43:07 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Dec 10 13:17:22 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> (Sebastian Sylvan's message of "Thu, 10 Dec 2009 16:56:09 +0000") References: <8B6EF47011EF4C77B2801FDE5CB465A6@JohnPC> <3d96ac180912100856x69fff628uc7bdf574301a0b2f@mail.gmail.com> Message-ID: <87ocm6llfo.fsf@malde.org> Sebastian Sylvan writes: > I think laziness requires purity to make sense. Laziness implies that the > order of evaluation is highly unpredictable and depends strongly on the > implementation details of libraries and such Laziness is like single-threaded concurrency. > So it's fickle. Someone adds an if statement somewhere and all of a > sudden a variable gets evaluated earlier than it used to. It would be > madness to write any code which depends on this unpredictable behaviour. I'm always amazed that shared-address space multi-threaded programs work at all. -k -- If I haven't seen further, it is by standing in the footprints of giants From leimy2k at gmail.com Thu Dec 10 14:28:06 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Dec 10 14:02:22 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <5fdc56d70912100945y18bf0091k3573690fe4d88ae9@mail.gmail.com> References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> <3e1162e60912100706v6e9a66a3nad8bbb9b243f3394@mail.gmail.com> <5fdc56d70912100945y18bf0091k3573690fe4d88ae9@mail.gmail.com> Message-ID: <3e1162e60912101128g3b0a3d27uc0dbbdeff2f8e56d@mail.gmail.com> Hi Stephen, While it's fair to mention that unsafePerformIO is not in the report for the reasons you give, it is present in some libraries. The practical reality of the situation is you can not in general trust that because a function's signature is pure, that the implementation of that function is. I mean you can, and you can pay the price for when you're wrong, as can the other people affected by that choice to trust that nothing fishy is going on behind the scenes, but it'd be a bad idea. Here's a really contrived example. Let's say you use a library, maybe one of the soon to be supported shared libraries for GHC, and that you use some pure functions of that library. Now let's say the system is compromised, and a modified version of said library is installed on the system which during the pure computation, has the effect of sending data that's being computed to some other internet connected machine. Now let's say you're a financial institution and the haskell code is running part of a webserver with people's account data in it. Now do you want to trust all pure functions implicitly? I realize this might be a bit too much of a straw man, but some people actually have to consider these possibilities. Dave On Thu, Dec 10, 2009 at 9:45 AM, Stephen Tetley wrote: > Hello David > > Apropos the (unfortunately) frosty exchanges that greeted the first > release of UHC a couple of months ago, which argued that UHC wasn't > Haskell because it didn't implement n+k patterns, one could argue (at > least for rhetorical effect) that Haskell plus unsafePerformIO isn't > Haskell, I don't think you'll be able to find unsafePerformIO in the > report... > > Best wishes > > Stephen > > 2009/12/10 David Leimbach : > > > > That's not a "safe" way to think of 3rd party libraries. It is a > convenient > > claim for promoting the language, and is probably more often than not the > > case though it does not quite capture the whole truth. unsafePerformIO > can > > exist in any library you import, > [snip] > > In short unsafePerformIO, while it's "supposed to be" avoided, may not be > > avoided as much as the advice given to do so :-). > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/d375442b/attachment.html From stephen.tetley at gmail.com Thu Dec 10 14:32:48 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Thu Dec 10 14:07:06 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <3e1162e60912101128g3b0a3d27uc0dbbdeff2f8e56d@mail.gmail.com> References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> <3e1162e60912100706v6e9a66a3nad8bbb9b243f3394@mail.gmail.com> <5fdc56d70912100945y18bf0091k3573690fe4d88ae9@mail.gmail.com> <3e1162e60912101128g3b0a3d27uc0dbbdeff2f8e56d@mail.gmail.com> Message-ID: <5fdc56d70912101132q43f880d9s9ab63df075b21159@mail.gmail.com> 2009/12/10 David Leimbach : > While it's fair to mention that unsafePerformIO is not in the report ... Colin Paul Adams called me out off list and its in the FFI appendum and in Haskell 2010 - "I've still got 21 days!". Best wishes Stephen From rodrigo.bonifacio at uol.com.br Thu Dec 10 14:33:42 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Thu Dec 10 14:08:06 2009 Subject: [Haskell-cafe] lhs2tex + pretty print Message-ID: <4b214d16dd9cb_732c3135be818b@weasel4.tmail> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/d23b839d/attachment.html From caseyh at istar.ca Thu Dec 10 14:45:43 2009 From: caseyh at istar.ca (Casey Hawthorne) Date: Thu Dec 10 14:20:07 2009 Subject: [Haskell-cafe] Re: Why? Message-ID: I have not read all/most of the replies. >What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction. A pure functional lanugage allows lazy evaluation, which adds another tool to your modularity toolbox, since it separates control from computation. In a pure functional language state is very carefully isolated from the rest of your program. This makes all sorts of optimizations trivial that are very hard to do in other languages. Optimizations are done in "code algebra", which is very easy to do in Haskell (for pure functions), for example optimizations are harder to do in the "code algebra" of Java. For a better discussion of "code algbra" please see the following book: "Practical Formal Software Engineering: Wanting the Software You Get" Bruce Mills, 2009 -- Regards, Casey From vandijk.roel at gmail.com Thu Dec 10 14:50:56 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Dec 10 14:25:12 2009 Subject: [Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1 In-Reply-To: <40FC7CF7-58EC-43BB-B07E-94AD040F193E@cs.otago.ac.nz> References: <40FC7CF7-58EC-43BB-B07E-94AD040F193E@cs.otago.ac.nz> Message-ID: 2009/12/10 Richard O'Keefe : > On Dec 10, 2009, at 2:58 AM, Roel van Dijk wrote: >> I tried to be conservative with the choice of unicode symbols. I have >> defined the division sign (?) to be (/). But it could just as well be >> defined as 'div'. > > No it couldn't. ?One expects 3?2 to be 1?, not 1. > You will, for example, find this text on the web: > "Mathematically, the division sign is equivalent to the forward slash. > Thus, for example, 4 ? 5 = 4/5 = 0.8" > This is actually historically backwards. ?When I was a nipper, > 1/6 meant "one and six" or "eighteen pence" or at least three > loaves of good bread. ?As far as I'm aware, the use of "/" > instead of "?" is a computerism introduced in the days of 6 bit > character sets. Ok, this makes me happy I choose (/) instead of 'div'. >> Another choice that could lead to some discussion is the definition of >> (?) to be 'Data.Set.isProperSubsetOf' and (?) to be >> 'Data.Set.isSubsetOf'. An alternative choice would be to have (?) for >> 'isProperSubsetOf' and (?) for 'isSubsetOf'. > > Mathematicians may use the plain horseshoe for either subset or > proper subset, depending on the author. ?But I've never ever seen > anyone use the horseshoe with an equals bar for proper subset; > that would really make no sense. As James Hall pointed out there is actually a tiny slash trough the equal bar underneath the horseshoe. The fact that this is hard to see is another reason why I choose the first option. > I suggest that you take the Z formal specification language as your > guide (plain horseshoe is proper subset, horseshoe with equal bar is > subset-or-equal). ?If you don't like Z, try B: ?same thing. Yes, this is how I have defined things in the current version. Thank you for your comments, Roel From andrewcoppin at btinternet.com Thu Dec 10 15:46:59 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Dec 10 15:21:16 2009 Subject: [Haskell-cafe] Re: Type system speculation In-Reply-To: <20091210074027.6067417363@Adric.ern.nps.edu> References: <20091210074027.6067417363@Adric.ern.nps.edu> Message-ID: <4B215E43.5080808@btinternet.com> oleg@okmij.org wrote: > Andrew Coppin wrote: > >> What we're really trying to do here is attach additional information to a >> value - information which exists only in the type checker's head, but has no >> effect on runtime behaviour. >> > > Haskell has had the ability to attach arbitrary many pieces of > (type-level) data to arbitrary types for a long time -- ever since > multi-parameter type classes and functional dependencies have been > introduced. Nowadays, type families accomplish the same with fewer > keystrokes. One merely needs to define a type family > type family Attrib n index :: * > which maps the existing type n and the index to an arbitrary type. > Ah, good point. I hadn't thought of that! So it seems you can indeed attach arbitrary attributes to any type, any time. However, I don't immediately see a way to construct a "safe" string type and an "unsafe" string type, so that you can write code which distinguishes between them, but that existing code that just expects a plain ordinary string still works. You could newtype string as two new types and attach whatever attributes you want to these types, but then normal string functions wouldn't work. Any ideas? From andrewcoppin at btinternet.com Thu Dec 10 15:49:05 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Dec 10 15:23:23 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <8C98544430C04B15872766E13F8CFD13@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <4B215EC1.6010706@btinternet.com> John D. Earle wrote: > What material benefit does Haskell derive from being a "pure" > functional language as opposed to an impure one? 1. Code optimisation becomes radically easier. The compiler can make very drastic alterations to your program, and not chance its meaning. (For that matter, the programmer can more easily chop the code around too...) 2. Purity leads more or less directly to laziness, which has several benefits: 2a. Unecessary work can potentially be avoided. (E.g., instead of a function for getting the first solution to an equation and a seperate function to generate *all* the solutions, you can just write the latter and laziness gives you the former by magic.) 2b. You can define brand new flow control constructs *inside* the language itself. (E.g., in Java, a "for" loop is a built-in language construct. In Haskell, "for" is a function in Control.Monad. Just a plain ordinary function that anybody could write.) 2c. The algorithms for generating data, selecting data and processing data can be seperated. (Normally you'd have to hard-wire the stopping condition into the function that generates the data, but with lazy "infinite" data structures, you can seperate it out.) 2d. Parallel computation. This turns out to be more tricky than you'd think, but it's leaps and bounds easier than in most imperative languages. 3. It's much harder to accidentally screw things up by modifying a piece of data from one part of the program which another part is still actually using. (This is somewhat similar to how garbage collection makes it harder to free data that's still in use.) That's at least 6 really huge reasons why purity is a massive win. From stephen.tetley at gmail.com Thu Dec 10 16:42:39 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Thu Dec 10 16:16:59 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <4B215EC1.6010706@btinternet.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> Message-ID: <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> C'mon Andrew - how about some facts, references? 2009/12/10 Andrew Coppin : > 1. Code optimisation becomes radically easier. The compiler can make very > drastic alterations to your program, and not chance its meaning. (For that > matter, the programmer can more easily chop the code around too...) Which code optimizations? >From a different point of view, whole program compilation gives plenty of opportunity for re-ordering transformations / optimization - Stalin (now Stalinvlad) and MLton often generated the fastest code for their respective (strict, impure) languages Scheme and Standard ML. Feel free to check the last page of the report here before replying with the Shootout - (GHC still does pretty well though easily beating Gambit and Bigloo): http://docs.lib.purdue.edu/ecetr/367/ > 2. Purity leads more or less directly to laziness, which has several > benefits: Other way round, no? > 2a. Unecessary work can potentially be avoided. (E.g., instead of a function > for getting the first solution to an equation and a seperate function to > generate *all* the solutions, you can just write the latter and laziness > gives you the former by magic.) > Didn't someone quote Heinrich Apfelmus in this list in the last week or so: http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html "Well, it's highly unlikely that algorithms get faster by introducing laziness. I mean, lazy evaluation means to evaluate only those things that are really needed and any good algorithm will be formulated in a way such that the unnecessary things have already been stripped off." http://apfelmus.nfshost.com/quicksearch.html > 2b. You can define brand new flow control constructs *inside* the language > itself. (E.g., in Java, a "for" loop is a built-in language construct. In > Haskell, "for" is a function in Control.Monad. Just a plain ordinary > function that anybody could write.) > Psst, heard about Scheme & call/cc? > 2c. The algorithms for generating data, selecting data and processing data > can be seperated. (Normally you'd have to hard-wire the stopping condition > into the function that generates the data, but with lazy "infinite" data > structures, you can seperate it out.) Granted. But some people have gone quite some way in the strict world, e.g.: http://users.info.unicaen.fr/~karczma/arpap/FDPE05/f20-karczmarczuk.pdf > 2d. Parallel computation. This turns out to be more tricky than you'd think, > but it's leaps and bounds easier than in most imperative languages. Plenty of lazy and strict, pure and impure languages in this survey: http://www.risc.uni-linz.ac.at/people/schreine/papers/pfpbib.ps.gz > 3. It's much harder to accidentally screw things up by modifying a piece of > data from one part of the program which another part is still actually > using. (This is somewhat similar to how garbage collection makes it harder > to free data that's still in use.) In a pure language I'd like to think its impossible... Best wishes Stephen From jstrait at moonloop.net Thu Dec 10 17:27:50 2009 From: jstrait at moonloop.net (Jon Strait) Date: Thu Dec 10 17:02:08 2009 Subject: [Haskell-cafe] Finding substantial examples of Cabal Setup files Message-ID: <4B2175E6.9070105@moonloop.net> Hi all, I was looking through some of the Hackage packages to find examples of how developers are extending UserHooks in their Setup files, but it wasn't easy, since the great majority of Cabal Setup files in Hackage simply require only the standard line of 'main = defaultMain' or 'defaultMainWithHooks' with a standard UserHooks value. So, I started hacking together a little Emacs Lisp script to walk through all the packages in the Hackage archive and report on the Setup files that looked interesting enough to serve as non-trivial examples. Here is the latest result: http://www.moonloop.net/haskell/docs/cbs-custom.html Jon From andres at cs.uu.nl Thu Dec 10 17:45:01 2009 From: andres at cs.uu.nl (Andres Loeh) Date: Thu Dec 10 17:19:19 2009 Subject: [Haskell-cafe] lhs2tex + pretty print In-Reply-To: <4b214d16dd9cb_732c3135be818b@weasel4.tmail> References: <4b214d16dd9cb_732c3135be818b@weasel4.tmail> Message-ID: <20091210224501.GT18397@cs.uu.nl> The attached document works for me. HTH, Andres -- Andres Loeh, Universiteit Utrecht mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de http://www.andres-loeh.de -------------- next part -------------- \documentclass{article} %include polycode.fmt %options ghci \begin{document} \section{Test} > test = putStrLn "\\section{Result}\n\nIt works!" \perform{test} \end{document} From lrpalmer at gmail.com Thu Dec 10 18:02:30 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Dec 10 17:36:46 2009 Subject: [Haskell-cafe] Re: Type system speculation In-Reply-To: <4B215E43.5080808@btinternet.com> References: <20091210074027.6067417363@Adric.ern.nps.edu> <4B215E43.5080808@btinternet.com> Message-ID: <7ca3f0160912101502q51eaff6ew1c28552a8cf13624@mail.gmail.com> On Thu, Dec 10, 2009 at 1:46 PM, Andrew Coppin wrote: > oleg@okmij.org wrote: >> >> Andrew Coppin wrote: >> >>> >>> What we're really trying to do here is attach additional information to a >>> value - information which exists only in the type checker's head, but has >>> no >>> effect on runtime behaviour. >>> >> >> Haskell has had the ability to attach arbitrary many pieces of >> (type-level) data to arbitrary types for a long time -- ever since >> multi-parameter type classes and functional dependencies have been >> introduced. Nowadays, type families accomplish the same with fewer >> keystrokes. One merely needs to define a type family >> ? ? ? ?type family Attrib n index :: * >> which maps the existing type n and the index to an arbitrary type. >> > > Ah, good point. I hadn't thought of that! > > So it seems you can indeed attach arbitrary attributes to any type, any > time. However, I don't immediately see a way to construct a "safe" string > type and an "unsafe" string type, so that you can write code which > distinguishes between them, but that existing code that just expects a plain > ordinary string still works. Well, what does existing code which just returns a plain ordinary string return? Presumably unsafe, so there would have to be a way to bias. > You could newtype string as two new types and > attach whatever attributes you want to these types, but then normal string > functions wouldn't work. Any ideas? That is the way I do it, with explicit conversion functions to indicate what I think is going on. As I pointed out, while passing a specialized version to ordinary functions might work (a common technique in OO), getting them back is another matter. module SafeString (String, fromSafe, safe) import Prelude hiding (String) newtype String = String { fromSafe :: Prelude.String } safe :: Prelude.String -> Maybe String safe s | verify s = Just (String s) | otherwise = Nothing And put in calls to safe and fromSafe explicitly. You might see this as a pain, but half of them (the safe calls) are adding value by forcing you to deal with it if your transformations are not safety-preserving. The fromSafe calls could technically be omitted, though you could argue that they are providing a nice abstraction barrier too: SafeStrings, being a subtype, might have a better representation[1] than ordinary Strings, which you may later decide, so fromSafe is providing you with the opportunity to change that later without affecting the client code. [1] For example (1) a bit-packed representation to save a little space, or (2) allowing the SafeString module to be reproduced in a proof assistant where the String type contains proof of its safety, so that you can verify the client code verbatim (This is currently not possible, but it is something I imagine being possible :-). Luke From lrpalmer at gmail.com Thu Dec 10 18:13:20 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Dec 10 17:47:37 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> Message-ID: <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> On Thu, Dec 10, 2009 at 2:42 PM, Stephen Tetley wrote: > C'mon Andrew - how about some facts, references? Filling in :-) > 2009/12/10 Andrew Coppin : > > >> 1. Code optimisation becomes radically easier. The compiler can make very >> drastic alterations to your program, and not chance its meaning. (For that >> matter, the programmer can more easily chop the code around too...) > > Which code optimizations? As a very potent example: stream fusion. Here is a talk demonstrating how it works. http://unlines.wordpress.com/2009/10/22/talk-on-loop-fusion-in-haskell/ >> 2a. Unecessary work can potentially be avoided. (E.g., instead of a function >> for getting the first solution to an equation and a seperate function to >> generate *all* the solutions, you can just write the latter and laziness >> gives you the former by magic.) >> > > Didn't someone quote Heinrich Apfelmus in this list in the last week or so: > > http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html > > "Well, it's highly unlikely that algorithms get faster by introducing > laziness. I mean, lazy evaluation means to evaluate only those things > that are really needed and any good algorithm will be formulated in a > way such that the unnecessary things have already been stripped off." That was me. I love that quote. The half that you omitted is another point on Andrew's list: "But laziness allows to simplify and compose algorithms. Sometimes, seemingly different algorithms turn out to be two sides of the same coin when formulated with lazy evaluation. Isn't it great that finding the k-th minimum is not only an adaption of quicksort but can readily be obtained from it by composing it with (!! k)?" > http://apfelmus.nfshost.com/quicksearch.html > >> 2b. You can define brand new flow control constructs *inside* the language >> itself. (E.g., in Java, a "for" loop is a built-in language construct. In >> Haskell, "for" is a function in Control.Monad. Just a plain ordinary >> function that anybody could write.) >> > > Psst, heard about Scheme & call/cc? But, very importantly, purity allows you to *restrict* the flow constructs that client code has available. If you have continuations + mutable state you can do anything, but the more code can *do*, the less you *know* about it. For example, providing parser combinators as an applicative functor offers more power than a traditional parser generator, but not enough that we can no longer parse efficiently. Luke From ok at cs.otago.ac.nz Thu Dec 10 19:03:43 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Thu Dec 10 18:38:05 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <8C98544430C04B15872766E13F8CFD13@JohnPC> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <868EB8A7-C098-4471-9F9E-6264CEE21D30@cs.otago.ac.nz> On Dec 11, 2009, at 1:01 AM, John D. Earle wrote: > This is a matter that I genuinely at the present time do not grasp > and I am hoping that some of you who are more familiar with the > Haskell language may be able to help enlighten me. I feel the > question to be an important one. What material benefit does Haskell > derive from being a "pure" functional language as opposed to an > impure one? Please provide examples as I require instruction. It sounds as though you think the Haskell designers wanted a language for some other reason, then cast around and said "what kind of language will it be?" and decided to make it a pure lazy functional one. It's the other way around. The programming language world was full of people trying all sorts of things. It so happened that several groups were exploring techniques for implementing pure lazy functional languages. In a fit of sanity that gives one hope for humanity, they said "why don't we all work on a *common* language?" The big outsider was Clean, which, however, adopted quite a lot of things from Haskell, and now has or is aquiring a Haskell98 front end. (It was already close enough to Haskell that the biggest pain in converting was that 'if' is just a plain function in Clean, not special syntax.) The question to ask, then, is "what material benefit did the pure lazy functional language community get from adopting a common language". Here's one hint: there are several Haskell implementations, numerous Haskell books, and a bulging library of reusable Haskell code. There's basically one out of date Clean book and an unfinished one available on the web. As for why anyone should care about pure functional languages, read "Why Functional Programming Matters". Oddly enough, the W3C language for transforming XML (XSLT) is a pure functional language, and so is the C++ type system. > The sort of decision that Apple computer and Microsoft made not to > go down the POSIX road seems relevant. (1) When the Mac was designed, POSIX did not exist. They _couldn't_ go down the POSIX road. (2) Apple computer *did* go down the POSIX road, or very nearly. MacOS X is as good a UNIX as ever came down the street. It's also a lot *more* than POSIX, but I routinely expect to have no more trouble moving code from say Solaris to MacOS than to Linux; sometimes less. (3) Since the release of Windows NT, Microsoft *have* gone down the POSIX road. I have Microsoft's "Services for Unix Applications" installed on a laptop. What Microsoft don't seem to be very interested in is going down the C99 road. Like Mac OS X, Windows is a lot *more* than POSIX. I suggest that one reason for functional language implementation researchers to concentrate on a *pure* functional language is to keep themselves honest: whenever a performance problem comes up it's no good saying "oh we'll do this the old fashioned imperative way" (as SML and O'Caml do), they have to find a way to do it well _functionally_. From ok at cs.otago.ac.nz Thu Dec 10 19:20:55 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Thu Dec 10 18:55:14 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <200912101500.42070.daniel.is.fischer@web.de> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <200912101500.42070.daniel.is.fischer@web.de> Message-ID: <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: > Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: >> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that >> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, > > mb_t's_bcs the ndrscr_stl is considered far uglier and less readable > by others Come ON. Argue honestly! The problem with that text is *NOT* the underscores but the insanely heavy abbreviation. We all agree that insanely heavy abbreviation is bad, but do you *really* want to claim that mbT'sBcs the ndrscrStl isConsidered farUglier and lessReadable byOthers is readable? > (granted, > underscore-style with nonabbreviated words is not unreadable, but > still extremely ugly)? Who "grants" that underscore separation with fully written words is "still extremely ugly"? Not me! I don't believe that it _is_ a matter of personal preference. I have not been able to discover an experimental study of word separation style effect on readability in programming. I've been wondering about running a small one myself, next year. But there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Now that applies to ordinary text, but until there's evidence to show that it doesn't apply to program sources, it's a reasonable working assumption that it does. If I can get approval to run an experiment, and it turns up evidence that baStudlyCapsIsMoreReadable, then I'll change my preference. read From ok at cs.otago.ac.nz Thu Dec 10 19:23:14 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Thu Dec 10 18:57:32 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <4B210021.2060206@yandex.ru> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <200912101500.42070.daniel.is.fischer@web.de> <4B210021.2060206@yandex.ru> Message-ID: On Dec 11, 2009, at 3:05 AM, Miguel Mitrofanov wrote: > Not to mention that in Emacs with glasses-mode enabled camelCase can > be made even more readable (my personal favorite is highlighting > internal capital letters with bold). And there is some reason why letters following underscores could not be similarly highlighted? Having to use machine assistance to read baStudlyCaps is pretty damning. From ok at cs.otago.ac.nz Thu Dec 10 19:28:10 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Thu Dec 10 19:02:33 2009 Subject: [Haskell-cafe] Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <4089D08C-5210-412B-965E-21EA003E2B98@cs.otago.ac.nz> On Dec 9, 2009, at 4:00 AM, Robin Green wrote: > At Thu, 10 Dec 2009 12:07:32 +0000, > Magnus Therning wrote: >> As I understand it it all started with laziness. I don't know if >> laziness is impossible without purity > > More or less. The S programming language, used for statistics, - is not pure - DOES have lazy evaluation of arguments. (For a free version, see www.r-project.org.) I suspect that the original motivation for this was so that plot(temperature, pressure) could automatically get "temperature" on the horizontal axis and "pressure" on the vertical axis, but it is also used as a lazy evaluation mechanism. In practice, a lot of S code is close to functional. > From leimy2k at gmail.com Thu Dec 10 20:34:21 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Dec 10 20:08:37 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> Message-ID: <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> > > > >> 2b. You can define brand new flow control constructs *inside* the > language > >> itself. (E.g., in Java, a "for" loop is a built-in language construct. > In > >> Haskell, "for" is a function in Control.Monad. Just a plain ordinary > >> function that anybody could write.) > >> > > > > Psst, heard about Scheme & call/cc? > > But, very importantly, purity allows you to *restrict* the flow > constructs that client code has available. If you have continuations > + mutable state you can do anything, but the more code can *do*, the > less you *know* about it. For example, providing parser combinators > as an applicative functor offers more power than a traditional parser > generator, but not enough that we can no longer parse efficiently. > Exactly my fear over unsafePerformIO in 3rd party Haskell libraries :-). One can present an interface in Haskell that looks safe, but it can be very unsafe in its implementation. Dave > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091210/53816f35/attachment.html From ok at cs.otago.ac.nz Thu Dec 10 20:43:47 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Thu Dec 10 20:18:09 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <3e1162e60912100611i73758742ofc54dca5064c137b@mail.gmail.com> Message-ID: <24E7938F-7A48-4568-92C0-4B499289C31E@cs.otago.ac.nz> On Dec 11, 2009, at 3:50 AM, John D. Earle wrote: > David, think of the machine as being the earth and laziness is in > the clouds. It reads so much better as "laziness is in the heavens". > Strict evaluation is closer to the machine. It doesn't have to be. Graph reduction hardware has been built in the past and could be again. > The relationship between a lazy algorithm and the earth is abstract; > hence, it will make creating algorithms especially efficient ones > difficult. All programming (except possibly assembly coding, and given the existence of optimising assemblers, even that) is abstract. In fact it had better be abstract, because I don't want to write different programs for SPARCs, PowerPCs, x86s, &c. I'd really rather not even write different programs for 32-bit and 64-bit environments. Given the massive amounts of stuff happening in modern processors (like the dynamic register renaming &c in x86s, deep write buffers, out-of-order execution, short SIMD vector instructions), even simple C code is a *long* way from what is really happening. To use your analogy, if the machine is the earth, C programming is floating around in a balloon _just under_ the clouds. Paradoxically, working at an abstract level can make creating efficient algorithms MUCH EASIER. Recently, I was looking at some Java code from a new book about numerical algorithms for scientists and engineers in Java. Because I have lots of uses for the Singular Value Decomposition, I chose to look at the SVD code. Version speed reason Java from book 1 rewritten in C 2 a[i][j] doesn't indirect twice transpose the matrices 4 goes with the grain of memory use LAPACK 7 algorithm, blocking for cache? Working at an abstract level ("I want (u,s,v) = svd a") instead of rolling my own low level code means that I can get _faster_ code. (There's no reason why Java couldn't call LAPACK through JNI, and if I had much numeric code to do in Java, that's what I'd do.) With the SVD (and similar things) as basic building blocks, it's much easier to develop interesting algorithms. For example, if I wanted to write my own code for Correspondence Analysis, it would be far more sensible to develop the algorithm in R (the free S) or Matlab or Octave, and _not_ write my own array loops, than to write in C. I'd probably get something much faster. Oh, and there's a new SVD algorithm being worked on for LAPACK, which is available for real numbers only in the current LAPACK release. Supposedly it's not only more accurate but faster. Change one line in my code to call that, and I get a very nice benefit from abstraction! > All of this is still a work in progress. The Haskell creed appears > to be, This is the way so stick to it! There is no Haskell "creed". People use Haskell for different reasons. Many Haskell programmers are totally pragmatic about it. Remember, PROGRAMMING IS HARD. If Haskell lets people _write_ correct programs faster, that's an enormous advantage, even if they don't _run_ faster. Once you have something actually working, you can worry about speed. The Java code I mentioned above came from a *recently* published book. Here's someone willing to put up with a factor of 7 loss of performance in order to get the other benefits of Java and persuading a publisher that a lot of other people will be happy with it too. > The idea appears to be that by sticking to the program the problems > will be overcome in time and we will be left with all the glorious > goodness. At one time it was not possible to achieve the sort of > efficiency that Haskell achieves as a matter of course. Abstraction makes it comparatively easy to switch over from String to ByteString. Purity means that taking advantage of multicore machines is already much easier than in C (with pthreads), C++ (with TBB), or Java (with itself). To be honest, I don't expect getting high performance out of Haskell to ever be easy. But then, getting high performance out of C or Fortran isn't easy either. From lrpalmer at gmail.com Thu Dec 10 21:01:24 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Dec 10 20:35:41 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> Message-ID: <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> On Thu, Dec 10, 2009 at 6:34 PM, David Leimbach wrote: >> >> >> 2b. You can define brand new flow control constructs *inside* the >> >> language >> >> itself. (E.g., in Java, a "for" loop is a built-in language construct. >> >> In >> >> Haskell, "for" is a function in Control.Monad. Just a plain ordinary >> >> function that anybody could write.) >> >> >> > >> > Psst, heard about Scheme & call/cc? >> >> But, very importantly, purity allows you to *restrict* the flow >> constructs that client code has available. ?If you have continuations >> + mutable state you can do anything, but the more code can *do*, the >> less you *know* about it. ?For example, providing parser combinators >> as an applicative functor offers more power than a traditional parser >> generator, but not enough that we can no longer parse efficiently. > > Exactly my fear over unsafePerformIO in 3rd party Haskell libraries :-). > One can present an interface in Haskell that looks safe, but it can be very > unsafe in its implementation. Hear, hear! I always meet with armies of resistance when I say this, but unsafePerformIO should die a horrible, unforgiven death. "Well what if you want blah blah blah with a pure interface?" My response: too fscking bad! If you have a pure interface, great, that means your semantics is pure, which has some nice advantages, but your implementation ain't so bite the bullet. Oh you have a proof that it is well behaved? I doubt it, because you can't prove diddly about IO because it has no specified semantics. You get a lot more from purity than just the interface. Pure code can be freely modulated by evaluation strategy (as long as semantic strictness is preserved), serialized, and verified (in the 100%-certain sort of way) with free theorems. You lose all of that when you allow even supposedly-pure-interface unsafePerformIO. unsafeCoerce, too, of course. Luke From monnier at iro.umontreal.ca Thu Dec 10 21:01:45 2009 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Thu Dec 10 20:36:24 2009 Subject: [Haskell-cafe] Re: Why? References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: > This is a matter that I genuinely at the present time do not grasp and > I am hoping that some of you who are more familiar with the Haskell > language may be able to help enlighten me. I feel the question to be > an important one. What material benefit does Haskell derive from being > a "pure" functional language as opposed to an impure one? Please > provide examples as I require instruction. I think the STM monad is one of the greatest examples of why Haskell's approach to side-effects is a resounding success. Without having to change anything to the language and compiler, i.e. as a mere library addition (more or less), you get a concurrency system with optimistic synchronization, where all the needed invariants are trivially enforced by the type-system: - no prints or other un-revertable side effects in transactions. - all accesses to shared variables are protected by a transaction. - ... Monads aren't always perfect when it comes to side-effects, but in the context of STM, they really shine. Stefan From johann.hoechtl at gmail.com Fri Dec 11 02:35:33 2009 From: johann.hoechtl at gmail.com (=?UTF-8?B?Sm9oYW5uIEjDtmNodGw=?=) Date: Fri Dec 11 02:09:52 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: <4B21F645.4010600@gmail.com> Bryan O'Sullivan wrote: > On Thu, Dec 10, 2009 at 5:01 AM, Johann H?chtl > > wrote: > > > > Yes. I'm working on a patch at the moment. > > Is there something planed to happen in 2010? > > > Retooling the I/O manager isn't a huge job, but it requires the > equivalent of several weeks of work. I tossed out my initial attempt > at a patch because I didn't have time to work on it, so I'm back to > square one. Johan Tibell and I have had occasional discussions about > picking up the thread again, but we've had a busy year and it's > moderately demanding work, so nothing has actually happened. > > If I develop the time and energy to take a serious crack at it, I will > post here to let people know. This would be an effort where having > multiple people work on different implementations concurrently would > be a shame. Yes, this is definitely a vital point of the runtime which requires carefull handling. I doubt that the estimated effort in http://hackage.haskell.org/trac/ghc/ticket/635 reflects reality;) However, factor (factorcode.org) implemented epoll, kqueue (for BSDs and MacOS) and |GetQueuedCompletionStatus for Windows in 2008. In this case the blog http://factor-language.blogspot.com/search?q=epoll and the irc logs http://www.google.com/search?q=epoll+site%3Atunes.org%2F~nef%2F%2Flogs%2Fconcatenative%2F&btnG=Search&hl=en&tbo=1&sa=2 might be helpful for a start and to avoid pitfals. Regards, Johann | From Patrick.Browne at comp.dit.ie Fri Dec 11 03:24:03 2009 From: Patrick.Browne at comp.dit.ie (pbrowne) Date: Fri Dec 11 02:58:23 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <4B2201A3.5040504@comp.dit.ie> The issue of *purity* in Haskell and this thread has confused me. At value level (not type level) is this linked with *equational reasoning*? Are the operational semantics of Haskell similar but not the same as equational logic? Why are theorem provers such as Haskabelle need? http://www.mail-archive.com/haskell-cafe@haskell.org/msg64843.html Pat From martin.hofmann at uni-bamberg.de Fri Dec 11 05:04:14 2009 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Fri Dec 11 04:37:09 2009 Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows Message-ID: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de> The following hint code causes GHCi to crash under Windows: > runInterpreter $ loadModules ["SomeModule.hs"] The error message is: GHCi runtime linker: fatal error: I found a duplicate definition for symbol _hs_gtWord64 whilst processing object file C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0 HSghc-prim-0.1.0.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. The problem does not occur under Unix or with a compiled program. IMHO hint tries to start a second instance of GHCi which is not allowed/possible under Windows. If this is the case a more telling error message would be helpful. I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My package.conf is: C:/Programme/Haskell Platform/2009.2.0.2\package.conf: Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0, ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1, containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0, ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2, haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4, haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4, utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0 Thanks, Martin From malcolm.wallace at cs.york.ac.uk Fri Dec 11 05:05:32 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Dec 11 04:41:00 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <200912101500.42070.daniel.is.fischer@web.de> <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> Message-ID: > there is enough experimentally determined about reading in general to > be certain that visible gaps between words materially improves > readability, and internal capital letters harm it. Here is a (slightly mischievous) proposal. Allow the Unicode non-breaking space character (  in HTML) as a valid character in a varid or conid. :-) Regards, Malcolm From colin at colina.demon.co.uk Fri Dec 11 05:34:08 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Dec 11 05:08:23 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: (Malcolm Wallace's message of "Fri\, 11 Dec 2009 10\:05\:32 +0000") References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <200912101500.42070.daniel.is.fischer@web.de> <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> Message-ID: >>>>> "Malcolm" == Malcolm Wallace writes: >> there is enough experimentally determined about reading in >> general to be certain that visible gaps between words >> materially improves readability, and internal capital letters >> harm it. Malcolm> Here is a (slightly mischievous) proposal. Malcolm> Allow the Unicode non-breaking space character (  in Malcolm> HTML) as a valid character in a varid or conid. Malcolm> :-) I thought of that one too (seriously). It has the disadvantage that the syntax is ambiguous to the human eye without tool support (e.g. highlighting). On the other hand humans are good at coping with such ambiguity (we do it all the time in spoken language - and delight in puns. And in written language, set is indistinguishable from set, which is indistinguishable from set, which ... - to however many distinct meanings for the word set are currently recognized). -- Colin Adams Preston Lancashire From johannes.laire at gmail.com Fri Dec 11 05:37:13 2009 From: johannes.laire at gmail.com (Johannes Laire) Date: Fri Dec 11 05:11:28 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> Message-ID: <5f271a760912110237w254d8499q8a42216842a50ac@mail.gmail.com> On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe wrote: > Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > went into Haskell forNoApparentReasonThatIHaveEverHeardOf Compare: someCoolFunc fstParam sndParam fooBarBazQuux some_cool_func fst_param snd_param foo_bar_baz_quux In the first one, it's easy to see that there are 4 identifiers. But, at least for me, the second one is significantly harder to read; spaces and underscored are too similar. So, while underscores more clearly separate words in a single *identifier* and make it easier to read, in some cases I think they make *code* with many identifiers harder to read for exactly the same reason. In languages where function application looks like "f(x,y,z)" instead of "f x y z" this isn't a problem and I often use underscores. -- Johannes Laire From noteed at gmail.com Fri Dec 11 05:41:48 2009 From: noteed at gmail.com (minh thu) Date: Fri Dec 11 05:16:24 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <5f271a760912110237w254d8499q8a42216842a50ac@mail.gmail.com> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <5f271a760912110237w254d8499q8a42216842a50ac@mail.gmail.com> Message-ID: <40a414c20912110241n7629817dpd6b4b12c0e35f9df@mail.gmail.com> 2009/12/11 Johannes Laire : > On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe wrote: >> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that >> went into Haskell forNoApparentReasonThatIHaveEverHeardOf > > Compare: > > someCoolFunc fstParam sndParam fooBarBazQuux > some_cool_func fst_param snd_param foo_bar_baz_quux Before even reading your paragraph below, I thought the second one was easier to read :) > In the first one, it's easy to see that there are 4 identifiers. But, > at least for me, the second one is significantly harder to read; > spaces and underscored are too similar. So, while underscores more > clearly separate words in a single *identifier* and make it easier to > read, in some cases I think they make *code* with many identifiers > harder to read for exactly the same reason. > > In languages where function application looks like "f(x,y,z)" instead > of "f x y z" this isn't a problem and I often use underscores. Your example should be seen with a monospaced font to be fair thought, as programming is usually done with such a font. (But both lines are easier with a monospaced font.) Cheers, Thu From marlowsd at gmail.com Fri Dec 11 05:43:09 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Dec 11 05:17:46 2009 Subject: [Haskell-cafe] Re: Fwd: Will GHC finally support epoll in 2009? In-Reply-To: References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: <4B22223D.4040109@gmail.com> On 10/12/2009 17:48, Bryan O'Sullivan wrote: > On Thu, Dec 10, 2009 at 5:01 AM, Johann H?chtl > wrote: > > > > Yes. I'm working on a patch at the moment. > > Is there something planed to happen in 2010? > > > Retooling the I/O manager isn't a huge job, but it requires the > equivalent of several weeks of work. I tossed out my initial attempt at > a patch because I didn't have time to work on it, so I'm back to square > one. Johan Tibell and I have had occasional discussions about picking up > the thread again, but we've had a busy year and it's moderately > demanding work, so nothing has actually happened. > > If I develop the time and energy to take a serious crack at it, I will > post here to let people know. This would be an effort where having > multiple people work on different implementations concurrently would be > a shame. Bryan, if you have time could you give a brief outline of the main sticking points? My gut feeling is that it shouldn't be "several weeks of work", but admittedly I've never worked with epoll(). Perhaps we need to take a step back and think about the architecture at a higher level? Cheers, Simon From dan.doel at gmail.com Fri Dec 11 08:47:17 2009 From: dan.doel at gmail.com (Dan Doel) Date: Fri Dec 11 08:21:35 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <4B2201A3.5040504@comp.dit.ie> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B2201A3.5040504@comp.dit.ie> Message-ID: <200912110847.17916.dan.doel@gmail.com> On Friday 11 December 2009 3:24:03 am pbrowne wrote: > The issue of *purity* in Haskell and this thread has confused me. > > At value level (not type level) is this linked with *equational reasoning*? > Are the operational semantics of Haskell similar but not the same as > equational logic? > > Why are theorem provers such as Haskabelle need? > http://www.mail-archive.com/haskell-cafe@haskell.org/msg64843.html The use of equational reasoning in a language like Haskell (as advocated by, say, Richard Bird) is that of writing down naive programs, and transforming them by equational laws into more efficient programs. Simple examples of this are fusion laws for maps and folds, so if we have: foo = foldr f z . map g . map h we can deforest it like so: foldr f z . map g . map h = (map f . map g = map (f . g)) foldr f z . map (g . h) = (foldr f z . map g = foldr (f . g) z) foldr (f . g . h) z now, this example is so simple that GHC can do it automatically, and that's a side benefit: a sufficiently smart compiler can use arbitrarily complex equational rules to optimize your program. But, for instance, Bird (I think) has a functional pearl paper on incrementally optimizing a sudoku solver* using equational reasoning such as this. Now, you can still do this process in an impure language, but impurity ruins most of these equations. It is not true that: map f . map g = map (f . g) if f and g are not pure, because if f has side effects represented by S, and g has side effects represented by T, then the left hand side has side effects like: T T T ... S S S ... while the right hand side has side effects like: T S T S T S ... so the equation does not hold. This is all, of course, tweaking programs using equational rules you've checked by hand. Theorem provers are for getting machines to check your proofs. Hope that helps. -- Dan * If you check the haskell wiki page on sudoku solvers, there's an entry something like 'sudoku ala Bird', written by someone else (Graham Hutton, comes to mind), that demonstrates using Bird's method. From greg at gregorycollins.net Fri Dec 11 10:09:27 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Fri Dec 11 09:43:42 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: (Bryan O'Sullivan's message of "Thu, 10 Dec 2009 09:48:31 -0800") References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: <87vdgda6oo.fsf@gregorycollins.net> "Bryan O'Sullivan" writes: > If I develop the time and energy to take a serious crack at it, I will > post here to let people know. This would be an effort where having > multiple people work on different implementations concurrently would > be a shame. I'm interested in this topic as well and have recently starting hacking timeout support into Johan's event library: http://github.com/tibbe/event http://github.com/gregorycollins/event Maybe we should form a working group? G -- Gregory Collins From johann.hoechtl at gmail.com Fri Dec 11 11:24:27 2009 From: johann.hoechtl at gmail.com (=?ISO-8859-1?Q?Johann_H=F6chtl?=) Date: Fri Dec 11 10:58:44 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: <87vdgda6oo.fsf@gregorycollins.net> References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> <87vdgda6oo.fsf@gregorycollins.net> Message-ID: <4B22723B.4020205@gmail.com> Gregory Collins wrote: > "Bryan O'Sullivan" writes: > > >> If I develop the time and energy to take a serious crack at it, I will >> post here to let people know. This would be an effort where having >> multiple people work on different implementations concurrently would >> be a shame. >> > > I'm interested in this topic as well and have recently starting hacking > timeout support into Johan's event library: > > http://github.com/tibbe/event > http://github.com/gregorycollins/event > > I think the overall goal should be to get rid of http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc, as it's in the core. Any non-blocking call to select should be save to replace by epoll, as the semantics are the same. As epoll is considerably more fine grained than non-blocking select, the architecture must support a run loop which effectively retrieves events faster than non-blocking select would do. Otherwise the effort would be futile. > Maybe we should form a working group? > > G > From waldmann at imn.htwk-leipzig.de Fri Dec 11 11:36:20 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Dec 11 11:10:36 2009 Subject: [Haskell-cafe] SmallCheck design question In-Reply-To: <404396ef0912080838l28afce10qebe050db3df22bea@mail.gmail.com> References: <4B1D8E66.4040202@imn.htwk-leipzig.de> <404396ef0912080838l28afce10qebe050db3df22bea@mail.gmail.com> Message-ID: <4B227504.8020709@imn.htwk-leipzig.de> >> 2. why depth and not size (= total number of constructors)? > That seems harder to generate terms compositionally. To create all > terms of depth n+1 you just glue together all terms of depth n, but to > create terms of size n+1 you need to glue 1 with n, 2 with n-1 etc. So? One would fear that this is inefficient because then these series (of smaller sizes) would have to be generated several times. But no, instead of class Serial a where series :: Int -> [a] one could "cache" these into series' :: [[a]] such that series k == series' !! k actually, series k == [ 0 .. k ] >>= ( series' !! ) because I'd want series' do be disjoint (each object has only one size). That should be doable by a simple rewrite of (some parts) of the library. I'm going to find a clever student to whom I could assign this ... Are there any standard test cases (i.e., they work nicely with the original Smallcheck and must continue to work with any modified version)? Best - Johannes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/9ebbf9be/signature.bin From Patrick.Browne at comp.dit.ie Fri Dec 11 12:04:08 2009 From: Patrick.Browne at comp.dit.ie (pbrowne) Date: Fri Dec 11 11:38:33 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <200912110847.17916.dan.doel@gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B2201A3.5040504@comp.dit.ie> <200912110847.17916.dan.doel@gmail.com> Message-ID: <4B227B88.8020108@comp.dit.ie> Dan, >From your example, I can appreciate the value of purity. But I am still unsure how close Haskell terms are to pure *equational logic*[1]. The operational semantics of languages like CafeOBJ[1] are very close to their intended logical semantics. CafeOBJ modules contain theories in equational logic and evaluations can be considered as proof of these theories. >From your point-free example, it seems that the Haskell compiler can perform *equational reasoning* to transform higher level (point) terms into more efficient basic Haskell code. But my questions concerns the precise semantics of this *basic* Haskell code. Two questions 1) Is this correspondence between operational and logical semantics a desirable property of *purity* in the Haskell world? 2) What, if anything, prevents the execution of a Haskell term from being a proof in equational logic? It seems that Haskells type system has this logical purity[4] My motivation for such questions is that I am researching various *algebraic styles* such as Haskell, OCAML, Maude, and CafeOBJ. My current general research question is; how closely do executable terms in these languages match their *logical* meaning. For example, languages like Java need additional logical scaffolding (like JML[3]) to give them logical machine readable meaning. I *guess* that the gap between operational and logical semantics is rather less in Haskell that in Java, and I further *guess* that the gap less again in Maude or CafeOBJ. I think a good answer to question 2) would remove the *guess* from the Haskell case. Pat [1] http://rewriting.loria.fr/documents/plaisted.ps.gz [2]http://www.forsoft.de/~rumpe/icse98-ws/tr/0202Diaconescu.ps [3] http://www.eecs.ucf.edu/~leavens/JML/ [4]http://www.haskell.org/haskellwiki/Type_arithmetic Dan Doel wrote: > The use of equational reasoning in a language like Haskell (as advocated by, > say, Richard Bird) is that of writing down naive programs, and transforming > them by equational laws into more efficient programs. Simple examples of this > are fusion laws for maps and folds, so if we have: > > foo = foldr f z . map g . map h > > we can deforest it like so: > > foldr f z . map g . map h > = (map f . map g = map (f . g)) > foldr f z . map (g . h) > = (foldr f z . map g = foldr (f . g) z) > foldr (f . g . h) z > > now, this example is so simple that GHC can do it automatically, and that's a > side benefit: a sufficiently smart compiler can use arbitrarily complex > equational rules to optimize your program. But, for instance, Bird (I think) > has a functional pearl paper on incrementally optimizing a sudoku solver* > using equational reasoning such as this. > > Now, you can still do this process in an impure language, but impurity ruins > most of these equations. It is not true that: > > map f . map g = map (f . g) > > if f and g are not pure, because if f has side effects represented by S, and g > has side effects represented by T, then the left hand side has side effects > like: > > T T T ... S S S ... > > while the right hand side has side effects like: > > T S T S T S ... > > so the equation does not hold. > > This is all, of course, tweaking programs using equational rules you've > checked by hand. Theorem provers are for getting machines to check your > proofs. > > Hope that helps. > -- Dan > > * If you check the haskell wiki page on sudoku solvers, there's an entry > something like 'sudoku ala Bird', written by someone else (Graham Hutton, > comes to mind), that demonstrates using Bird's method. From johann.hoechtl at gmail.com Fri Dec 11 12:12:38 2009 From: johann.hoechtl at gmail.com (=?ISO-8859-1?Q?Johann_H=F6chtl?=) Date: Fri Dec 11 11:46:52 2009 Subject: [Haskell-cafe] Re: killer app, again In-Reply-To: <1662913285.20091210163821@gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <3d96ac180912100527wefcdc8bo74b22b48a8d1bd0f@mail.gmail.com> <1662913285.20091210163821@gmail.com> Message-ID: On Dec 10, 2:38?pm, Bulat Ziganshin wrote: > Hello Sebastian, > > Thursday, December 10, 2009, 4:27:49 PM, you wrote: > > > The killer app for that, IMO, is parallelism these days > > btw, are you seen Google App Engine? it's python/java ATM, but i think > that haskell will be ideal fit there. it's all about > computations-in-cloud, or more precisely hosting-in-a-cloud, like > Amazon EC2 > I think the first language which would come to mind, is acutally Erlang. As a cloud server process and cloud database backend might be physically distributed, it's more logical to send messages between them asynchronously, than share state in parallel. But yes, Haskell fit's this pattern well, through the Control.Concurrent library. > so, both individual cpus and largest servers now are multi-threaded, > it just need some time so EC2/GAP developers will realize Haskell > potential > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Zigans...@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe From greg at gregorycollins.net Fri Dec 11 12:14:32 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Fri Dec 11 11:48:47 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: <4B22723B.4020205@gmail.com> ("Johann =?utf-8?Q?H=C3=B6chtl?= =?utf-8?Q?=22's?= message of "Fri, 11 Dec 2009 17:24:27 +0100") References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> <87vdgda6oo.fsf@gregorycollins.net> <4B22723B.4020205@gmail.com> Message-ID: <87my1pa0w7.fsf@gregorycollins.net> Johann H?chtl writes: > I think the overall goal should be to get rid of > http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc, > as it's in the core. I don't follow, could you explain? > Any non-blocking call to select should be save to replace by epoll, as the > semantics are the same. Not exactly the same; but keep in mind we also need to support kqueue & Windows I/O completion ports (and select() as a fallback). In an ideal world you can provide a unified API that will work across all of the platforms, with the I/O multiplexer hidden behind the interface. > As epoll is considerably more fine grained than non-blocking select, > the architecture must support a run loop which effectively retrieves > events faster than non-blocking select would do. Otherwise the effort > would be futile. It'd be hard to be slower, with select() you have to do O(n) "fdIsSet" tests. G -- Gregory Collins From bugfact at gmail.com Fri Dec 11 12:15:16 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Fri Dec 11 11:49:30 2009 Subject: [Haskell-cafe] Re: Type system speculation In-Reply-To: <7ca3f0160912101502q51eaff6ew1c28552a8cf13624@mail.gmail.com> References: <20091210074027.6067417363@Adric.ern.nps.edu> <4B215E43.5080808@btinternet.com> <7ca3f0160912101502q51eaff6ew1c28552a8cf13624@mail.gmail.com> Message-ID: How are things like this handled in say - Morrow - using extensible records? I guess when one defines functions operating on extensible records you get a lot of reuse for free (in Andrew's example, you would just extend the record with either a Checked or Unchecked label) On Fri, Dec 11, 2009 at 12:02 AM, Luke Palmer wrote: > On Thu, Dec 10, 2009 at 1:46 PM, Andrew Coppin > wrote: >> oleg@okmij.org wrote: >>> >>> Andrew Coppin wrote: >>> >>>> >>>> What we're really trying to do here is attach additional information to a >>>> value - information which exists only in the type checker's head, but has >>>> no >>>> effect on runtime behaviour. >>>> >>> >>> Haskell has had the ability to attach arbitrary many pieces of >>> (type-level) data to arbitrary types for a long time -- ever since >>> multi-parameter type classes and functional dependencies have been >>> introduced. Nowadays, type families accomplish the same with fewer >>> keystrokes. One merely needs to define a type family >>> ? ? ? ?type family Attrib n index :: * >>> which maps the existing type n and the index to an arbitrary type. >>> >> >> Ah, good point. I hadn't thought of that! >> >> So it seems you can indeed attach arbitrary attributes to any type, any >> time. However, I don't immediately see a way to construct a "safe" string >> type and an "unsafe" string type, so that you can write code which >> distinguishes between them, but that existing code that just expects a plain >> ordinary string still works. > > Well, what does existing code which just returns a plain ordinary > string return? ?Presumably unsafe, so there would have to be a way to > bias. > >> You could newtype string as two new types and >> attach whatever attributes you want to these types, but then normal string >> functions wouldn't work. Any ideas? > > That is the way I do it, with explicit conversion functions to > indicate what I think is going on. ?As I pointed out, while passing a > specialized version to ordinary functions might work (a common > technique in OO), getting them back is another matter. > > module SafeString (String, fromSafe, safe) > import Prelude hiding (String) > > newtype String = String { fromSafe :: Prelude.String } > > safe :: Prelude.String -> Maybe String > safe s | verify s = Just (String s) > ? ? ? | otherwise = Nothing > > And put in calls to safe and fromSafe explicitly. ?You might see this > as a pain, but half of them (the safe calls) are adding value by > forcing you to deal with it if your transformations are not > safety-preserving. ?The fromSafe calls could technically be omitted, > though you could argue that they are providing a nice abstraction > barrier too: ?SafeStrings, being a subtype, might have a better > representation[1] than ordinary Strings, which you may later decide, > so fromSafe is providing you with the opportunity to change that later > without affecting the client code. > > [1] For example (1) a bit-packed representation to save a little > space, or (2) allowing the SafeString module to be reproduced in a > proof assistant where the String type contains proof of its safety, so > that you can verify the client code verbatim ?(This is currently not > possible, but it is something I imagine being possible :-). > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lrpalmer at gmail.com Fri Dec 11 13:06:39 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 11 12:40:57 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <4B227B88.8020108@comp.dit.ie> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B2201A3.5040504@comp.dit.ie> <200912110847.17916.dan.doel@gmail.com> <4B227B88.8020108@comp.dit.ie> Message-ID: <7ca3f0160912111006x231fd052raa7398b63b74587d@mail.gmail.com> On Fri, Dec 11, 2009 at 10:04 AM, pbrowne wrote: > Two questions > 1) Is this correspondence between operational and logical semantics a > desirable property of *purity* in the Haskell world? > > 2) What, if anything, prevents the execution of a Haskell term from > being a proof in equational logic? > > > It seems that Haskells type system has this logical purity[4] > > > My motivation for such questions is that I am researching various > *algebraic styles* such as Haskell, OCAML, Maude, and CafeOBJ. > My current general research question is; how closely do executable terms > in these languages match their *logical* meaning. For example, languages > like Java need additional logical scaffolding (like JML[3]) to give them > logical machine readable meaning. I admit that I don't fully know what you are talking about. What do you mean by logical meaning -- as opposed to what other sort of meaning? The equational reasoning in Haskell comes from its denotational semantics (which, mind, is not completely formally specified -- but once you expand typeclasses to dictionary passing style, you get a standard DCPO semantics). If terms are equal in denotation, then they are equal by observation (modulo efficiency). So it is not equations that directly define the semantics of Haskell, but rather mapping the syntax to mathematical objects. We derive Haskell's equational reasoning from the equational reasoning in the semantic domain. That's how I see it as a user of the language. At the most abstract level, omitting some of the practical details of the language (such as the built-in numeric types), Haskell's reduction follows beta reduction with sharing, and so at that level I think the answer to (2) is "nothing". Luke > I *guess* that the gap between operational and logical semantics is > rather less in Haskell that in Java, and I further *guess* that the gap > less again in Maude or CafeOBJ. I think a good answer to question 2) > would remove the *guess* from the Haskell case. > > Pat > [1] http://rewriting.loria.fr/documents/plaisted.ps.gz > [2]http://www.forsoft.de/~rumpe/icse98-ws/tr/0202Diaconescu.ps > [3] http://www.eecs.ucf.edu/~leavens/JML/ > [4]http://www.haskell.org/haskellwiki/Type_arithmetic > > > Dan Doel wrote: >> The use of equational reasoning in a language like Haskell (as advocated by, >> say, Richard Bird) is that of writing down naive programs, and transforming >> them by equational laws into more efficient programs. Simple examples of this >> are fusion laws for maps and folds, so if we have: >> >> ? ? foo = foldr f z . map g . map h >> >> we can deforest it like so: >> >> ? ? foldr f z . map g . map h >> ? ? ? = (map f . map g = map (f . g)) >> ? ? foldr f z . map (g . h) >> ? ? ? = (foldr f z . map g = foldr (f . g) z) >> ? ? foldr (f . g . h) z >> >> now, this example is so simple that GHC can do it automatically, and that's a >> side benefit: a sufficiently smart compiler can use arbitrarily complex >> equational rules to optimize your program. But, for instance, Bird (I think) >> has a functional pearl paper on incrementally optimizing a sudoku solver* >> using equational reasoning such as this. >> >> Now, you can still do this process in an impure language, but impurity ruins >> most of these equations. It is not true that: >> >> ? ? map f . map g = map (f . g) >> >> if f and g are not pure, because if f has side effects represented by S, and g >> has side effects represented by T, then the left hand side has side effects >> like: >> >> ? ? T T T ... S S S ... >> >> while the right hand side has side effects like: >> >> ? ? T S T S T S ... >> >> so the equation does not hold. >> >> This is all, of course, tweaking programs using equational rules you've >> checked by hand. Theorem provers are for getting machines to check your >> proofs. >> >> Hope that helps. >> -- Dan >> >> * If you check the haskell wiki page on sudoku solvers, there's an entry >> something like 'sudoku ala Bird', written by someone else (Graham Hutton, >> comes to mind), that demonstrates using Bird's method. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dan.doel at gmail.com Fri Dec 11 13:34:28 2009 From: dan.doel at gmail.com (Dan Doel) Date: Fri Dec 11 13:08:46 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <7ca3f0160912111006x231fd052raa7398b63b74587d@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B227B88.8020108@comp.dit.ie> <7ca3f0160912111006x231fd052raa7398b63b74587d@mail.gmail.com> Message-ID: <200912111334.29083.dan.doel@gmail.com> On Friday 11 December 2009 1:06:39 pm Luke Palmer wrote: > That's how I see it as a user of the language. At the most abstract > level, omitting some of the practical details of the language (such as > the built-in numeric types), Haskell's reduction follows beta > reduction with sharing, and so at that level I think the answer to (2) > is "nothing". Yes, that's probably the answer, but a related question is how useful the logic is for various applications. For one, the logic that corresponds to Haskell via Curry-Howard is inconsistent, because general recursion/fix/error/negative types/etc. let you prove forall a. a But that isn't a very desirable property from a logical standpoint, because it calls into question whether any proofs you do really prove what they allege. Second, again via Curry-Howard, Haskell's (GHC's) type system corresponds to a higher-order logic without first-order quantification, because it doesn't have real dependent types. This is why you need things like Haskabelle: because the propositions (types) in Haskell *can't* talk about value-level terms, and those are generally what you want to prove things about. With enough GADT/type family fanciness, you can reconstruct (roughly) every value-level entity in the type level, and establish a correspondence between any value-level term 't' and its associated type-level term 'T', such that if you prove something about T, you know (by construction) that a related property holds for t. And then you can use the fact that Haskell is a higher- order logic to prove the things you want about T. But this is convoluted and difficult (and you still have to worry that your proof is accidentally bottom :)). -- Dan From johann.hoechtl at gmail.com Fri Dec 11 13:39:44 2009 From: johann.hoechtl at gmail.com (=?UTF-8?B?Sm9oYW5uIEjDtmNodGw=?=) Date: Fri Dec 11 13:14:00 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: <87my1pa0w7.fsf@gregorycollins.net> References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> <87vdgda6oo.fsf@gregorycollins.net> <4B22723B.4020205@gmail.com> <87my1pa0w7.fsf@gregorycollins.net> Message-ID: <4B2291F0.3060805@gmail.com> Gregory Collins wrote: > Johann H?chtl writes: > > >> I think the overall goal should be to get rid of >> http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc, >> as it's in the core. >> > > I don't follow, could you explain? > > > I might be wrong, but it's EPoll.hsc where you define the call to the Linux kernel function. This would be unneccessary, when poll (and kqueue and Windows equivalents) are already in the core. Ok, a bit more than EPoll.hsc would be unneccessary ;) What I mean is that applications like web servers should benefit immediately from a change in the exisiting core and not require a (new) library. So a change is likely neccessary in Network.Socket and Network.Socket.Internal and in the IO monad when it comes to files. If someone want's to benefit from more functionality, like overlapping IO on Windows, the extension may be platform dependent available. However, in order to produce portable code which uses non blocking IO "the new way", a programer should never have to think about the target platform. BTW: Here are also some names and ideas mentioned: http://www.haskell.org/pipermail/cvs-ghc/2008-February/041236.html I actually had web applications in mind when I asked my first question as many tiny and lightweight requests to the web server will become more and more the rule with techniques as comet or Bayeux protocoll or HTML5 web sockets. I speculate this will be even more true with per thread garbage collection in GHC 6.12.x >> Any non-blocking call to select should be save to replace by epoll, as the >> semantics are the same. >> > > Not exactly the same; but keep in mind we also need to support kqueue & > Windows I/O completion ports (and select() as a fallback). In an ideal > world you can provide a unified API that will work across all of the > platforms, with the I/O multiplexer hidden behind the interface. > > > Absolutely right, I forgot to mention. I am aware of epoll - Linux kqueue - the BSD's and MacOS; does the interface differ, on MacOS, I dont't know IO Completion Port - Windows (http://stackoverflow.com/questions/67082/what-is-the-best-epoll-kqueue-select-equvalient-on-windows) poll - Solaris >> As epoll is considerably more fine grained than non-blocking select, >> the architecture must support a run loop which effectively retrieves >> events faster than non-blocking select would do. Otherwise the effort >> would be futile. >> > > It'd be hard to be slower, with select() you have to do O(n) "fdIsSet" > tests. > > G > From greg at gregorycollins.net Fri Dec 11 14:08:22 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Fri Dec 11 13:42:38 2009 Subject: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009? In-Reply-To: <4B2291F0.3060805@gmail.com> ("Johann =?utf-8?Q?H=C3=B6chtl?= =?utf-8?Q?=22's?= message of "Fri, 11 Dec 2009 19:39:44 +0100") References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> <87vdgda6oo.fsf@gregorycollins.net> <4B22723B.4020205@gmail.com> <87my1pa0w7.fsf@gregorycollins.net> <4B2291F0.3060805@gmail.com> Message-ID: <87ein19vmh.fsf@gregorycollins.net> Johann H?chtl writes: > I might be wrong, but it's EPoll.hsc where you define the call to the Linux > kernel function. This would be unneccessary, when poll (and kqueue and Windows > equivalents) are already in the core. Ok, a bit more than EPoll.hsc would be > unneccessary ;) Not sure what you mean by "core"; see for instance the code for GHC's current I/O manager: http://darcs.haskell.org/libraries/base/GHC/Conc.lhs There's no special magic going on there, select() and friends are bound using the normal FFI mechanism. > What I mean is that applications like web servers should benefit immediately > from a change in the exisiting core and not require a (new) library. So a > change is likely neccessary in Network.Socket and > Network.Socket.Internal > and in the IO monad when it comes to > files. > If someone want's to benefit from more functionality, like overlapping IO on > Windows, the extension may be platform dependent > available. > However, in order to produce portable code which uses non blocking IO "the new > way", a programer should never have to think about the target > platform. Yes, of course. The idea would (or might) be to fold the event library into GHC directly and rewrite the I/O manager in terms of it. Many (if not all) of the library I/O functions may have to be adapted to work with a new I/O manager. By writing it as a library first we can a) write programs that use I/O multiplexing before support gets into GHC core proper b) ensure that the mechanisms are well tested and benchmarked before they are integrated into GHC G -- Gregory Collins From Patrick.Browne at comp.dit.ie Fri Dec 11 14:08:39 2009 From: Patrick.Browne at comp.dit.ie (pbrowne) Date: Fri Dec 11 13:43:02 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <7ca3f0160912111006x231fd052raa7398b63b74587d@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B2201A3.5040504@comp.dit.ie> <200912110847.17916.dan.doel@gmail.com> <4B227B88.8020108@comp.dit.ie> <7ca3f0160912111006x231fd052raa7398b63b74587d@mail.gmail.com> Message-ID: <4B2298B7.3010107@comp.dit.ie> Luke Palmer wrote: > I admit that I don't fully know what you are talking about. What do > you mean by logical meaning -- as opposed to what other sort of > meaning? Consider Maude's rewrite logic RWL[1] which has similar inference rules as equational logic(EL), but without the symmetry rule. From [1], the *logical* meaning in RWL regards the rules of rewriting logic as meta-rules for correct deduction in a logical system. Logically, each rewriting step is a logical entailment in a formal system. Note that the particular logic may vary (e.g. EL,FOPL, RWL). [1]http://maude.cs.uiuc.edu/maude1/manual/maude-manual-html/maude-manual_62.html From paul at cogito.org.uk Fri Dec 11 14:27:31 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Fri Dec 11 14:01:47 2009 Subject: [Haskell-cafe] Why? In-Reply-To: References: <8C98544430C04B15872766E13F8CFD13@JohnPC> Message-ID: <4B229D23.3080404@cogito.org.uk> On 10/12/09 12:07, Magnus Therning wrote: > > As I understand it it all started with laziness. I don't know if > laziness is impossible without purity, but talks and papers tend to > say something like "laziness has kept Haskell pure". This is true, but laziness has its own advantages. Suppose I have two modules, Foo and Bar. Foo generates a data structure which is then consumed by Bar (possibly with some other component calling both of them). In a strict language I have to choose between one of these three options: 1. Foo generates the structure all at once, and some kind of reference is then passed to Bar. This is nice, simple and modular, but it only works for small structures. There can also be a problem if the structure is slow to generate but is only consumed a bit at a time (e.g. by the user interface) because Bar can only start work once Foo has finished the whole thing. You may also find the Foo is doing lots of unnecessary work building bits of the structure that Bar uses only rarely. 2. Foo and Bar are built together in a single module with their functionality interleaved. This means that Foo can build a bit of the structure, have Bar process it, and so on. However it also destroys any modularity the system might have had. If Bar is part of the user interface, for instance, it means that core functionality gets mixed up. 3. Implement some kind of generator object. This takes a lot of code and makes the logic of Foo and Bar harder to follow. For instance the version of Foo from option 1 might have had a loop of the form "foreach i in xs". Now "i" has to be turned into some kind of member variable with logic to move to the next instance. Of course what you are really doing is creating an ad-hoc hand-coded version of lazy evaluation. Different applications are going to require different choices. Worse yet, the right answer can change. For instance you may start with option 1, then discover that the program runs too slowly. Or marketing decide that the maximum size of the data structure has to be increased. So at that point you have to rewrite a big chunk of code. Or else you go with option 2 or 3 because the designer thought it was necessary for efficiency when in fact option 1 would have done nicely. Of course with lazy evaluation you get option 3 all the time automatically. So its just not a problem. This makes the design much simpler because things that previously had to be decided by a human are now decided by the compiler. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/43faeedb/attachment.html From andrewcoppin at btinternet.com Fri Dec 11 14:46:31 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Dec 11 14:20:43 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> Message-ID: <4B22A197.8070200@btinternet.com> Stephen Tetley wrote: > C'mon Andrew - how about some facts, references? > Facts I can do. References? Not so much... >> 1. Code optimisation becomes radically easier. The compiler can make very >> drastic alterations to your program, and not chance its meaning. (For that >> matter, the programmer can more easily chop the code around too...) >> > > Which code optimizations? > In a pure language, substituting a function call with the corresponding RHS is guaranteed to not alter the program. Eliminating common subexpressions is guaranteed not to alter the meaning of the program. Something like stream fusion which replaces a data structure in memory with a loop in the program code is guaranteed not to alter the meaning of the program. Should I continue? On the other hand, turn up the optimisation settings on a C compiler high enough and the program breaks. Somewhere the compiler elides a second call to a function which actually happens to have some side-effect that the compiler isn't aware of, and your stream is now one byte out of alignment, or whatever. Fiddling with optimisation settings in GHC may make your program slow to a crawl rather than go faster, but it *never* makes it segfault on startup. > >From a different point of view, whole program compilation gives plenty > of opportunity for re-ordering transformations / optimization - Stalin > (now Stalinvlad) and MLton often generated the fastest code for their > respective (strict, impure) languages Scheme and Standard ML. > I didn't say it's impossible to optimise impure languages. I said it's much harder. >> 2. Purity leads more or less directly to laziness, which has several >> benefits: >> > > Other way round, no? > A philosopher once asked: Do we gaze at the stars because we are human? Or are we human because we gaze at the stars? Pointless, really. Is Haskell pure because it's lazy, and being impure in a lazy language would be a hellish nightmare? Or is it lazy because in a pure language, there's no reason to be strict? >> 2a. Unecessary work can potentially be avoided. (E.g., instead of a function >> for getting the first solution to an equation and a seperate function to >> generate *all* the solutions, you can just write the latter and laziness >> gives you the former by magic. > > Didn't someone quote Heinrich Apfelmus in this list in the last week or so: > > http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html > > "Well, it's highly unlikely that algorithms get faster by introducing > laziness. I mean, lazy evaluation means to evaluate only those things > that are really needed and any good algorithm will be formulated in a > way such that the unnecessary things have already been stripped off." > Writing an algorithm custom-optimised to every possible use-case is probably more efficient than using laziness. On the other hand, using laziness is probably radically less typing, and arguably not that much slower. (And then you can invoke the notion of the Sufficiently Sophisticated Compiler...) >> 2b. You can define brand new flow control constructs *inside* the language >> itself. (E.g., in Java, a "for" loop is a built-in language construct. In >> Haskell, "for" is a function in Control.Monad. Just a plain ordinary >> function that anybody could write.) >> >> > > Psst, heard about Scheme & call/cc? > No. Should I have? >> 2c. The algorithms for generating data, selecting data and processing data >> can be seperated. >> > > Granted. But some people have gone quite some way in the strict world, e.g.: > > http://users.info.unicaen.fr/~karczma/arpap/FDPE05/f20-karczmarczuk.pdf > > > >> 2d. Parallel computation. This turns out to be more tricky than you'd think, >> but it's leaps and bounds easier than in most imperative languages. >> > > Plenty of lazy and strict, pure and impure languages in this survey: > http://www.risc.uni-linz.ac.at/people/schreine/papers/pfpbib.ps.gz > All of these seem to be of the form "you can do this in an impure language". I didn't say you can't. I said it's easier. >> 3. It's much harder to accidentally screw things up by modifying a piece of >> data from one part of the program which another part is still actually >> using. (This is somewhat similar to how garbage collection makes it harder >> to free data that's still in use.) >> > > In a pure language I'd like to think its impossible... > Agreed. But - unless your program involves no I/O at all - you would be wrong... :-( Haskell programs can and sometimes do involve mutable state internally as well. And in that case, it's up to you to not accidentally do something dumb. From dpiponi at gmail.com Fri Dec 11 14:57:07 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Fri Dec 11 14:31:21 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <4B22A197.8070200@btinternet.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <4B22A197.8070200@btinternet.com> Message-ID: <625b74080912111157x591858fan3558a4b898a370c9@mail.gmail.com> On Fri, Dec 11, 2009 at 11:46 AM, Andrew Coppin wrote: > On the other hand, turn up the optimisation settings on a C compiler high > enough and the program breaks. Not if you write actual C as specified by the standard. In fact, these days gcc internally converts your program to SSA form, which is essentially pure functional code. (See here for an explanation: http://www.cs.princeton.edu/~appel/papers/ssafun.ps) The reason is exactly as you say: the purer the code, the easier it is to reason about it. -- Dan From jason.dusek at gmail.com Fri Dec 11 18:55:16 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Dec 11 18:29:30 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> Message-ID: <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> 2009/12/10 Luke Palmer : > I always meet with armies of resistance when I say this... The troops arrive. > ...but unsafePerformIO should die a horrible, unforgiven > death. "Well what if you want blah blah blah with a pure > interface?" My response:?too fscking bad! Wouldn't removing `unsafePerformIO` just force us, in many cases, to write the same thing in C and then import it? Or would you amend the FFI so "math.h sin" could not be imported pure? There are plenty of bad ways to use `unsafePerformIO`, this is true; but as we already have a tool for binding to native code in a way that trusts it to be pure, I don't see how having a way to bind to nominally side-effecting Haskell code in a way that trusts it to be pure adds anything to our troubles. -- Jason Dusek From marco-oweber at gmx.de Fri Dec 11 19:00:22 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Dec 11 18:34:54 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? Message-ID: <1260575495-sup-9064@nixos> hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: "Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the "," in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch " Of course I mailed the author. Looking at the package again I noticed that it was uploaded by someone else: GwernBranwen. gwern on #haskell told me that the author is responsive so I'll just wait some days, but others will try and fail as well. If the other person is new to haskell he may not find the fix fast. He just wants to know which of the heads is causing trouble.. Another use case would be users adding "If you're interested in this topic also have a look at XXX" Yet another use case is someone figuring out that function X was removed in version Y. He could than add a note x vanished since v.10 and everybody who wants to update cabal dependency constraints doesn't have to download the darcs repo to figure out that he should use package <= v.10 . Of course contents of wiki pages may be totally wrong because the contents were written by people knowing the package less than the maintainers and authors. But everyone knows this and will take care. This wiki can server as fail over if the maintainer is on holiday. This wiki page will prevent people blogging about packages and benchmark results anywhere on the internet. So it's much more likely that this information is read and maintained. If you use google to look for bug fixes or such you may have success. But very often you end up reading pages dated 3 years ago which are outdated. This wiki page would be I simple effective way letting users annotate packages. Costs: Make hackage add one link. It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg This link should point to the existing haskell wiki on haskell.org: http://haskell.org/haskellwiki/project-name-without-version Even if the maintainer is availible 24/h a day he won't upload a new minor version to hackage for each change. But maybe he'll paste a small note that the darcs repo is more up to date fixing issue x/y. You don't want to upload a new version because you added some documentation. Why don't you want to do that ? It's because hackage will keep every version which was uploaded once by design. Having 50 versions of one package just causes much more work for tools such as cabal install or hack-nix. Figuring out a solution to install all packages is hard enough. Maintainers can create the wiki page and subscribe to change notifications. So I don't think it'll be that much work for them to keep an eye on those wiki pages. How do you think about it? It's about centralizing information and saving your and my time. Many packages aready do have a wiki page. So why not make it easier for all to add one? Thoughts ? Currently my goal is updating some common packages so that they use extensible exceptions and base4. But when working on some patches I'd like to tell people that I'm doing so. I can't in an easy way. That's why I'm starting this thread. Marc Weber From gcross at phys.washington.edu Fri Dec 11 19:14:58 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Fri Dec 11 18:49:37 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> Message-ID: On Dec 11, 2009, at 3:55 PM, Jason Dusek wrote: > There are plenty of bad ways to use `unsafePerformIO`, this is > true; but as we already have a tool for binding to native code > in a way that trusts it to be pure, I don't see how having a > way to bind to nominally side-effecting Haskell code in a way > that trusts it to be pure adds anything to our troubles. Indeed, and I would add that we even trust that our Haskell implementation itself is pure, even though it does all sorts of side-effectful things underneath the hood. Cheers, Greg From RafaelGCPP.Linux at gmail.com Fri Dec 11 19:23:24 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Fri Dec 11 18:57:38 2009 Subject: [Haskell-cafe] GHC 6.12 status and features Message-ID: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> Hi folks, and specially Simon Marlow, I know I should probably be asking to the GHC list, but is there any update on 6.12 since October? Any probable release date? BTW, is there any feature list for the release? Thank all of you involved in bringing this new version to life. GHC rocks! Rafael Gustavo da Cunha Pereira Pinto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/8971fffa/attachment.html From lrpalmer at gmail.com Fri Dec 11 19:47:00 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Dec 11 19:21:13 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> Message-ID: <7ca3f0160912111647y6aadbcc7g98125fe1933638a4@mail.gmail.com> On Fri, Dec 11, 2009 at 4:55 PM, Jason Dusek wrote: > 2009/12/10 Luke Palmer : >> I always meet with armies of resistance when I say this... > > ?The troops arrive. > >> ...but unsafePerformIO should die a horrible, unforgiven >> death. "Well what if you want blah blah blah with a pure >> interface?" My response:?too fscking bad! > > ?Wouldn't removing `unsafePerformIO` just force us, in many > ?cases, to write the same thing in C and then import it? Or > ?would you amend the FFI so "math.h sin" could not be imported > ?pure? This is not the sort of resistance I expected :-). Naturally my unrealistic argument applies to FFI as well; sin, if imported from C, would have to return in an appropriate structure. Not necessarily IO (I don't like the idea of a universal sin-bin -- I'd rather introduce a family of structures with well-defined meanings), but the same idea. Support for commutative monads (once we understand them) may relieve some of the pain of this approach. The idea being that any code that is pure could be evaluated anywhere with a very simple interpreter. If you have pure code, you can trace it back and evaluate it in a sandbox where you don't need a C runtime, a linker, or really anything but the simplest substitution engine. *All* effects bubble their way up to the top level, so that we know from the type signature of a value the machinery we will need to run it. Pure functional code as the minimal essence of pure computation -- everything else an EDSL. Of course I am not talking about Haskell anymore. Haskell is a firm, maturing language and has no room for such radical changes. This argument applies to an eventual spiritual successor of Haskell (it is probably too liberal for Haskell' even). Luke From donn at avvanta.com Fri Dec 11 20:11:25 2009 From: donn at avvanta.com (Donn Cave) Date: Fri Dec 11 19:45:39 2009 Subject: [Haskell-cafe] Why? References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com><7ca3f0160912111647y6aadbcc7g98125fe1933638a4@mail.gmail.com> Message-ID: <20091212011125.7FDA293C47@mail.avvanta.com> Quoth Luke Palmer , ... > This is not the sort of resistance I expected :-). Naturally my > unrealistic argument applies to FFI as well; sin, if imported from C, > would have to return in an appropriate structure. Not necessarily IO > (I don't like the idea of a universal sin-bin -- I'd rather introduce > a family of structures with well-defined meanings), but the same idea. > Support for commutative monads (once we understand them) may relieve > some of the pain of this approach. Yes! I mean, I have no idea, but it seems like it's worth a look at anything that promises to replace some of the unsafePerformIO hacking with more functionally transparent ways to do the same thing. I love talking about the questionable purity of sin! but as it happens, since I don't do that much geometry I am without sin anyway. Donn From westondan at imageworks.com Fri Dec 11 20:49:14 2009 From: westondan at imageworks.com (Dan Weston) Date: Fri Dec 11 20:23:42 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <7ca3f0160912111647y6aadbcc7g98125fe1933638a4@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> <7ca3f0160912111647y6aadbcc7g98125fe1933638a4@mail.gmail.com> Message-ID: <4B22F69A.2030709@imageworks.com> Luke Palmer wrote: > The idea being that any code that is pure could be evaluated anywhere > with a very simple interpreter. If you have pure code, you can trace > it back and evaluate it in a sandbox where you don't need a C runtime, > a linker, or really anything but the simplest substitution engine. > *All* effects bubble their way up to the top level, so that we know > from the type signature of a value the machinery we will need to run The alternative is not much better: syntactic sugar (say a "wrapping" keyword similar to "deriving") that wraps up a pure type in a State, ST, or IO. The inevitable result is that *every* type from the lazy programmer will be so wrapped. Many programmers overdo the IO monad as it is. With suitable sugar, they will become addicted! Dan From jason.dusek at gmail.com Fri Dec 11 21:07:35 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Dec 11 20:41:49 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <7ca3f0160912111647y6aadbcc7g98125fe1933638a4@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7ca3f0160912101513k2ad64cf0i15518d62285063be@mail.gmail.com> <3e1162e60912101734l27a34030x135ae804eff53e75@mail.gmail.com> <7ca3f0160912101801x482aae13j3ad19797655df5a3@mail.gmail.com> <42784f260912111555y71fa21d9q589325070258d8f2@mail.gmail.com> <7ca3f0160912111647y6aadbcc7g98125fe1933638a4@mail.gmail.com> Message-ID: <42784f260912111807k272d7290w9b392899be0c6ded@mail.gmail.com> 2009/12/11 Luke Palmer : > The idea being that any code that is pure could be evaluated > anywhere with a very simple interpreter.?If you have pure > code, you can trace it back and evaluate it in a sandbox where > you don't need a C runtime, a linker, or really anything but > the simplest substitution engine. *All* effects bubble their > way up to the top level, so that we know from the type > signature of a value the machinery we will need to run it. This sounds good but there is something puzzling about it. Where do we draw the line between "machinery" and "packages"? The types don't tell us what libraries we need. They don't tell us how much RAM/CPU we need, either. > Pure functional code as the minimal essence of pure > computation -- everything else an EDSL. Partial or total code? -- Jason Dusek From gwern0 at gmail.com Fri Dec 11 21:23:26 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri Dec 11 20:57:38 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <1260575495-sup-9064@nixos> References: <1260575495-sup-9064@nixos> Message-ID: On Fri, Dec 11, 2009 at 7:00 PM, Marc Weber wrote: > hackage is success because: > a) many (most) people do use it (by uploading packages) > b) it is a comprehensive list of availible packages if not the most > ? ?comprehensive one > > Duncan, can you write about your concerns briefly why some maintainers may dislike > this idea ? > > Hackage is missing one feature: > It is very static. I mean if you have a patch or a question or a comment > you have to lookup the darcs repository, write the patch then contact > the author and wait.. If the author replies everything is fine. > If he doesn't you don't know what to do. And if he does your commitment > still doesn't show up on hackage. > > Using a wiki page for each project enables anybody to add comments. > I'm thinking about this kind of comments: > > ?"Interlude doesn't work for me. It looks like the interlude.h file > ?passes a tuple to the reportError function which doesn't expect a tuple. > ?You can fix it by removing the "," in the .h file. > ?Try this patch: > ?http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch > ?" > > ?Of course I mailed the author. Looking at the package again I noticed > ?that it was uploaded by someone else: GwernBranwen. > ?gwern on #haskell told me that the author is responsive so I'll just > ?wait some days, but others will try and fail as well. > ?If the other person is new to haskell he may not find the fix > ?fast. He just wants to know which of the heads is causing trouble.. > > Another use case would be users adding > "If you're interested in this topic also have a look at XXX" > > Yet another use case is someone figuring out that function X was removed > in version Y. He could than add a note > > x vanished since v.10 and everybody who wants to update cabal dependency > constraints doesn't have to download the darcs repo to figure out that > he should use package <= v.10 . > > Of course contents of wiki pages may be totally wrong because the > contents were written by people knowing the package less than the > maintainers and authors. But everyone knows this and will take care. > > This wiki can server as fail over if the maintainer is on holiday. > > This wiki page will prevent people blogging about packages and benchmark > results anywhere on the internet. So it's much more likely that this > information is read and maintained. > If you use google to look for bug fixes or such you may have success. > But very often you end up reading pages dated 3 years ago which are > outdated. > > This wiki page would be I simple effective way letting users annotate > packages. > > Costs: Make hackage add one link. > It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg > This link should point to the existing haskell wiki on haskell.org: > http://haskell.org/haskellwiki/project-name-without-version Would the link check for the article actually existing? Not much good to point people to a wiki page that doesn't exist, unless they know and intend to contribute something. Also, even if the article existed, how many people will feel like clicking on it to see what may be there? I'd suggest the code would check for an existing page, be colored red (or omitted?) if it doesn't, and if it does exist, then add a hyperlinks - and also load the page in a small frame. (I have some custom JavaScript on Wikipedia that loads in a frame talk pages beneath/at the bottom of an article; I can attest from personal experience that the quick glance-ability this adds is very valuable and makes me much more likely to see what a talk page has to add, takes up minimal screen real estate, and since it loads after everything else does, has a minimal performance penalty.) -- gwern From duncan.coutts at googlemail.com Fri Dec 11 21:26:30 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Dec 11 21:00:46 2009 Subject: [Haskell-cafe] Re: What about adding a wiki for each haskell project? In-Reply-To: <1260575495-sup-9064@nixos> References: <1260575495-sup-9064@nixos> Message-ID: <1260584790.9220.4582.camel@localhost> On Sat, 2009-12-12 at 01:00 +0100, Marc Weber wrote: > hackage is success because: > a) many (most) people do use it (by uploading packages) > b) it is a comprehensive list of availible packages if not the most > comprehensive one > > Duncan, can you write about your concerns briefly why some maintainers may dislike > this idea ? I added a section to the wiki page you created. > Hackage is missing one feature: It's missing lots of features! :-) Duncan From phil at beadling.co.uk Fri Dec 11 21:57:22 2009 From: phil at beadling.co.uk (Philip Beadling) Date: Fri Dec 11 21:31:35 2009 Subject: [Haskell-cafe] Parallel foldl doesn't work correctly Message-ID: <1260586642.3898.9.camel@phil-desktop> Hi, Can anyone put me right here. I am trying to use a setup similar to parMap to spark each valuation in a list in parallel, where the resulting (evaluated) list is folded to produce a final single result. Having done the obligatory google, I modified a few common examples to give: pfoldl f acc xs = foldl' f acc (xs `using` parList rwhnf) This compiles and if I monitor my CPUs it starts to use both cores, but after approx 10 seconds, one core drops to low rate (I'm using a 2 core machine). The end result is that -N2 is actually a bit slower than -N1! I'm guessing I haven't grasped the concept properly - although as map is just 'foldl (+) 0' I'm at a loss to see why this approach wouldn't work given it is pretty similar to parMap - could anyone point out what I'm missing? If it's any use the context of the code is below. Many thanks! Phil. mc :: MonteCarloUserData -> [[Double]] -> Double mc userData rndss = existentialResult (pfoldl f existenAvg rndss) $ numOfSims userData where f = flip $ existentialCombine . payOff' . expiryValue payOff' = existentialPayOff userData expiryValue = foldl' (existentialEvolve userData) (stock userData) existenAvg = averager userData From allbery at ece.cmu.edu Fri Dec 11 22:21:09 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Dec 11 21:55:38 2009 Subject: [Haskell-cafe] (semi OT) Fwd: Old math reveals new thinking in children's cognitive development References: <1D43DD27-EED2-47B1-B076-B21707AA2ED0@kf8nh.com> Message-ID: <1F021890-E8D2-434A-8474-E5E86E4940BA@ece.cmu.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/0bd2fa51/PGP.bin From Andrejs.Sisojevs at nextmail.ru Fri Dec 11 23:01:09 2009 From: Andrejs.Sisojevs at nextmail.ru (Andrey Sisoyev) Date: Fri Dec 11 22:35:20 2009 Subject: [Haskell-cafe] ANNOUNCE: PCLT-0.1 and PCLT-DB-0.1 Message-ID: <26754004.post@talk.nabble.com> Hello, cafe! It's an honor for me to announce my first two packages, I developed in Haskell: ** http://hackage.haskell.org/package/PCLT ** http://hackage.haskell.org/package/PCLT-DB "PCLT" is an abbreviation for "Parametric Composable Localizable Templates" - in fact it should also hold Detalizable. Term "Detailizable content (message)" in this package has a following meaning: some content, representing which it is possible to regulate, in how much details it is represented. "Localizable" means "localizable in languages", which is "a message is available in multiple languages". "Composable" - it is possible to compose multiple templates into one. Conceptually, this package is a powerful extension to the well known Show class. Whenever you feel, that common Show is not enough for your needs, please consider using my PCLT. The extension is thought to be embedded in any Haskell program, which requires multilingual support, and/or where messages should be detailizable. PCLT-DB is an addon to PCLT, which enhances catalog with PostgreSQL powers. ER diagram: http://i1.fastpic.ru/big/2009/1212/f0/5b9845716e5a6984e9bc9d62a61928f0.png Both packages are well documented, has "Hello World" examples, and are selfexamples - the PCLT errors representations are available in two languages: English and Russian. Used license: LGPL. Regards, Andrey Sisoyev -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-PCLT-0.1-and-PCLT-DB-0.1-tp26754004p26754004.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From tomahawkins at gmail.com Fri Dec 11 23:04:54 2009 From: tomahawkins at gmail.com (Tom Hawkins) Date: Fri Dec 11 22:39:07 2009 Subject: [Haskell-cafe] Using Atom's task scheduler for existing C code. Message-ID: <594c1e830912112004s6605eba8ge991381315688d0e@mail.gmail.com> Today we were working on integrating Atom code with some hand-written C, and one of my colleagues posed the question: Is it possible to use Atom just for its task scheduler for existing C code? This turns out to be very simple. It just requires a few combinators built on top of 'action'. -- Call a C function with type 'void f(void)'. call :: Name -> Atom () call n = action (\ _ -> n ++ "()") [] -- Call a C function in its own rule, atomically. callAtomic :: Name -> Atom () callAtomic n = atom n $ call n -- Call a C function atomically with a guard condition. callGuardedAtomic :: E Bool -> Name -> Atom () callGuardedAtomic g n = atom n (cond g >> call n) Then scheduling a collection of tasks becomes easy: -- 20 millisecond tasks. period 20 $ do callAtomic "task1" callAtomic "task2" -- 5 millisecond tasks. period 5 $ do callAtomic "task3" callAtomic "task4" -- 1 millisecond tasks. period 1 $ do callGuardedAtomic task5Ready "task5" callGuardedAtomic task6Ready "task6" I'll added these 'call' combinators in the next release of Atom. From korpios at korpios.com Fri Dec 11 23:21:19 2009 From: korpios at korpios.com (Tom Tobin) Date: Fri Dec 11 22:55:33 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <87r5r5d8ma.fsf@malde.org> <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> Message-ID: On Tue, Dec 8, 2009 at 6:31 PM, Tom Tobin wrote: > Question 2 can be "If the answer to 1 is no, is there *any* > circumstance under which the author of Y can distribute the source of > Y under a non-GPL license?" I'd like to get these questions out to the SFLC so we can satisfy our curiosity; at the moment, here's what I'd be asking: Background: X is a library distributed under the terms of the GPL. Y is another library which calls external functions in the API of X, and requires X to compile. X and Y have different authors. 1) Can the author of Y legally distribute the *source* of Y under a non-GPL license, such as the 3-clause BSD license or the MIT license? 2) If the answer to 1 is "no", is there *any* circumstance under which the author of Y can distribute the source of Y under a non-GPL license? 3) If the answer to 1 is "yes", what specifically would trigger the redistribution of a work in this scenario under the GPL? Is it the distribution of X+Y *together* (whether in source or binary form)? 4) If the answer to 1 is "yes", does this mean that a "BSD-licensed" library does not necessarily mean that closed-source software can be distributed which is based upon such a library (if it so happens that the library in turn depends on a copylefted library)? By the way, apologies to the author of Hakyll ? I'm sure this isn't what you had in mind when you announced your library! I'm just hoping that we can figure out what our obligations are based upon the GPL, since I'm not so sure myself anymore. From korpios at korpios.com Fri Dec 11 23:26:55 2009 From: korpios at korpios.com (Tom Tobin) Date: Fri Dec 11 23:01:09 2009 Subject: [Haskell-cafe] (semi OT) Fwd: Old math reveals new thinking in children's cognitive development In-Reply-To: <1F021890-E8D2-434A-8474-E5E86E4940BA@ece.cmu.edu> References: <1D43DD27-EED2-47B1-B076-B21707AA2ED0@kf8nh.com> <1F021890-E8D2-434A-8474-E5E86E4940BA@ece.cmu.edu> Message-ID: On Fri, Dec 11, 2009 at 9:21 PM, Brandon S. Allbery KF8NH wrote: > Unexpected applications of category theory for $500, Alex.... Before you know it, they're going to be modeling mental processes as monads. :p From nowgate at yahoo.com Fri Dec 11 23:30:19 2009 From: nowgate at yahoo.com (michael rice) Date: Fri Dec 11 23:04:31 2009 Subject: [Haskell-cafe] "--" comments Message-ID: <521540.75394.qm@web31104.mail.mud.yahoo.com> I'm just noticing that "--" comments don't seem to work properly when the first character following them is a '*'. Michael --*I like asterisks --*I like asterisks --*I like asterisks --*I like asterisks double x = x+x Prelude> :l double [1 of 1] Compiling Main???????????? ( double.hs, interpreted ) double.hs:1:0: parse error on input `--*' Failed, modules loaded: none. Prelude> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/5cce5dfc/attachment.html From pumpkingod at gmail.com Fri Dec 11 23:33:41 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Fri Dec 11 23:07:54 2009 Subject: [Haskell-cafe] "--" comments In-Reply-To: <521540.75394.qm@web31104.mail.mud.yahoo.com> References: <521540.75394.qm@web31104.mail.mud.yahoo.com> Message-ID: let (--*) = (+) in 5 --* 6 ===> 11 The comment is introduced by -- followed by a non-symbol (because if followed by a symbol, it might be an operator) Hope this helps! Dan On Fri, Dec 11, 2009 at 11:30 PM, michael rice wrote: > I'm just noticing that "--" comments don't seem to work properly when the > first character following them is a '*'. > > Michael > > > --*I like asterisks > --*I like asterisks > --*I like asterisks > --*I like asterisks > > double x = x+x > > > Prelude> :l double > [1 of 1] Compiling Main ( double.hs, interpreted ) > > double.hs:1:0: parse error on input `--*' > Failed, modules loaded: none. > Prelude> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/3b7fc3e8/attachment.html From allbery at ece.cmu.edu Fri Dec 11 23:34:47 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Dec 11 23:09:14 2009 Subject: [Haskell-cafe] "--" comments In-Reply-To: <521540.75394.qm@web31104.mail.mud.yahoo.com> References: <521540.75394.qm@web31104.mail.mud.yahoo.com> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/204c2fcc/PGP.bin From nowgate at yahoo.com Fri Dec 11 23:37:54 2009 From: nowgate at yahoo.com (michael rice) Date: Fri Dec 11 23:12:06 2009 Subject: [Haskell-cafe] "--" comments In-Reply-To: Message-ID: <722777.95854.qm@web31107.mail.mud.yahoo.com> Cool! Didn't know that, and the Haskell syntax I looked up made no mention of it. Thanks, Michael --- On Fri, 12/11/09, Daniel Peebles wrote: From: Daniel Peebles Subject: Re: [Haskell-cafe] "--" comments To: "michael rice" Cc: haskell-cafe@haskell.org Date: Friday, December 11, 2009, 11:33 PM let (--*) = (+) in 5 --* 6===> 11 The comment is introduced by -- followed by a non-symbol (because if followed by a symbol, it might be an operator) Hope this helps! Dan On Fri, Dec 11, 2009 at 11:30 PM, michael rice wrote: I'm just noticing that "--" comments don't seem to work properly when the first character following them is a '*'. Michael --*I like asterisks --*I like asterisks --*I like asterisks --*I like asterisks double x = x+x Prelude> :l double [1 of 1] Compiling Main???????????? ( double.hs, interpreted ) double.hs:1:0: parse error on input `--*' Failed, modules loaded: none. Prelude> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/65d4146f/attachment.html From nowgate at yahoo.com Fri Dec 11 23:44:11 2009 From: nowgate at yahoo.com (michael rice) Date: Fri Dec 11 23:18:23 2009 Subject: [Haskell-cafe] "--" comments In-Reply-To: Message-ID: <280534.81747.qm@web31104.mail.mud.yahoo.com> I'd seen Haddock occasionally mentioned in posts but hadn't gotten to it yet. Looks interesting. Thanks, Michael --- On Fri, 12/11/09, Brandon S. Allbery KF8NH wrote: From: Brandon S. Allbery KF8NH Subject: Re: [Haskell-cafe] "--" comments To: "michael rice" Cc: "Brandon S. Allbery KF8NH" , haskell-cafe@haskell.org Date: Friday, December 11, 2009, 11:34 PM On Dec 11, 2009, at 23:30 , michael rice wrote:I'm just noticing that "--" comments don't seem to work properly when the first character following them is a '*'. I believe the spec only treats "-- " as a comment leader; this is why Haddock markup has a space between the "--" and the markup. --?brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.comsystem administrator [openafs,heimdal,too many hats] allbery@ece.cmu.eduelectrical and computer engineering, carnegie mellon university ? ?KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091211/936c176f/attachment.html From newsham at lava.net Sat Dec 12 00:16:47 2009 From: newsham at lava.net (Tim Newsham) Date: Fri Dec 11 23:51:01 2009 Subject: [Haskell-cafe] consulting and contracting Message-ID: I was wondering how many haskell consultants and contractors (ie. freelance programmers) there are and how much demand there is for their work. Also what kind of work do most haskell consultants and contractors get? Is it primarily focused around developing and maintaining haskell compilers and tools? Mostly related to academia? Spread out around several areas? Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com From jv at informatik.uni-bonn.de Sat Dec 12 01:35:46 2009 From: jv at informatik.uni-bonn.de (=?ISO-8859-1?Q?Janis_Voigtl=E4nder?=) Date: Sat Dec 12 01:09:58 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <20091212035545.401FE3249BB@www.haskell.org> References: <20091212035545.401FE3249BB@www.haskell.org> Message-ID: <4B2339C2.2010605@informatik.uni-bonn.de> Andrew Coppin wrote: > On the other hand, turn up the optimisation settings on a C compiler > high enough and the program breaks. Somewhere the compiler elides a > second call to a function which actually happens to have some > side-effect that the compiler isn't aware of, and your stream is now one > byte out of alignment, or whatever. Fiddling with optimisation settings > in GHC may make your program slow to a crawl rather than go faster, but > it *never* makes it segfault on startup. Note, though, that "slow to crawl" may go as far as "not terminate". GHC's optimizer can make a terminating program nonterminating. For some discussion, see: http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#Discussion In fact, one can also make up examples where turning on optimization lets GHC transform a "good" program into one halting with an arbitrary error (division by zero, say). The recipe for (artificial) such examples can be found in footnote 2 of: http://www.iai.uni-bonn.de/~jv/TUD-FI09-06.pdf The error "in the wild" that is mentioned on the wiki page occurred in the context of the stream fusion library development. Best regards, Janis. -- Jun.-Prof. Dr. Janis Voigtl?nder http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de From ravi_n at alum.mit.edu Sat Dec 12 01:48:28 2009 From: ravi_n at alum.mit.edu (Ravi Nanavati) Date: Sat Dec 12 01:22:40 2009 Subject: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882) In-Reply-To: <161d443c0912112244y64813d12kb54c4cd8587a2152@mail.gmail.com> References: <161d443c0912112244y64813d12kb54c4cd8587a2152@mail.gmail.com> Message-ID: <161d443c0912112248l6de7c517h22270e5dd875d12b@mail.gmail.com> ---------- Forwarded message ---------- From: Ravi Nanavati Date: Sat, Dec 12, 2009 at 1:44 AM Subject: Next meeting: December 17th at MIT (32-G882) To: bostonhaskell@googlegroups.com I'm pleased to announce the December meeting of the Boston Area Haskell Users' Group. The meeting has been scheduled for Thursday, December 17th from 7pm to 9pm. Like recent meetings, it will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). Based on the responses to my previous message, our featured presenter will be Ryan Newton who will talk about the Intel Concurrent Collections for Haskell. Following his presentation, we will have our traditional break. After the break, we're going to try a joint programming exercise involving the collections. If anyone has a suggestion for an interesting programming exercise that would take advantage of the collections, please speak up (since otherwise Ryan and I will see what we can come up with next week). The December attendance poll is at: http://doodle.com/p2zcnca6k39iptb4 As always, responding to this poll will help with two things: 1. Getting an idea of what fraction of the Boston-area Haskell community can and can't attend this meeting (to help with future scheduling). 2. Giving me an estimated count of attendees, since I have talked my wife into baking some more goodies and bringing drinks again. Helping with BostonHaskell (besides volunteering to speak at future meetings): 1. Sponsorship of refreshments is still being eagerly solicited (especially as, for personal reasons, the Cupcake Fund is running low). 2. Please let me know if you're willing to arrive early (6:30pm) to stand by the door and let people into the 8th floor. I'm guessing 1 or 2 volunteers is enough here. 3. If someone is willing to edit the HaskellWiki page, post to reddit or otherwise publicize the meeting please just go ahead and do that (especially as I'm sending this out on the later side). If you have any questions about the meeting please send them to them BostonHaskell mailing list: bostonhaskell@googlegroups.com or contact me directly. I look forward to seeing many Boston-area Haskellers at the December meeting! Thank you, ?- Ravi Nanavati From lrpalmer at gmail.com Sat Dec 12 03:03:31 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Dec 12 02:37:43 2009 Subject: [Haskell-cafe] Pure extremism (was: Re: Why?) Message-ID: <7ca3f0160912120003y682deac1q971d229d82ccfbae@mail.gmail.com> On Fri, Dec 11, 2009 at 7:07 PM, Jason Dusek wrote: > 2009/12/11 Luke Palmer : >> The idea being that any code that is pure could be evaluated >> anywhere with a very simple interpreter.?If you have pure >> code, you can trace it back and evaluate it in a sandbox where >> you don't need a C runtime, a linker, or really anything but >> the simplest substitution engine. *All* effects bubble their >> way up to the top level, so that we know from the type >> signature of a value the machinery we will need to run it. > > ?This sounds good but there is something puzzling about it. > ?Where do we draw the line between "machinery" and "packages"? > ?The types don't tell us what libraries we need. I don't follow this. Do you mean external libraries, such as "the library used to execute an IO type"? That makes sense to me, though in that case the types do tell. Or you might mean what *haskell* libraries does a piece of code depend on? To address that, note that I consider a statement like: import Control.Monad.State As a form of impurity in a sense (it is hard to say what I consider it, actually, but I think it inhibits reasoning and verification). What version are you importing? From where are you importing it ; where is it defined? These things depend on the compiler environment, which means that the meaning of a piece of code depends on who is compiling it. I have brainstormed solutions to this problem while thinking about my (currently on hold or dead) Udon project: http://lukepalmer.wordpress.com/2008/11/19/udon-sketch-2/ . But it is just a brainstorm, nothing I would sign in blood. I'd love it if more people were thinking about these kinds of problems (Any papers you well-read folks know about?) > They don't?tell us how much RAM/CPU we need, either. And these! My ideas for these are now firmly beyond Haskell and way out in the ill-defined vaporware space. I discuss in abstract the idea of distinguishing the performance semantics from the denotation of a piece of code here: http://lukepalmer.wordpress.com/2009/06/12/the-role-of-a-core-calculus/ . Brainstorm disclaimer applies, and I want to see more research! (Papers?) > >> Pure functional code as the minimal essence of pure >> computation -- everything else an EDSL. > > ?Partial or total code? When the state of the art catches up, total for sure. Why reason with DCPOs when you can reason with the mathematical objects themselves? But when you require functions to be total, you end up needing to prove a lot more about them just to convince the compiler that they will terminate. Functional proof assistants are a wonderful area of research, but are still very early and it is frickin' hard to prove stuff about code. My belief is that time is all that is necessary here -- the research will continue and it will become easier and easier to prove properties about code (probably never completely automatic, but someday I hope to "handwave the essence" of a proof and have the computer fill in the bullshit details). But when it's easy enough, then partiality is definitely an "effect" to be modeled as well. It has the advantage, unlike most effects, that given a good model, you can prove your way out of it. I.e. write a function with a partiality effect, then elsewhere prove that it actually is total so you can drop the effect. I seem to recall a proof-of-concept of this idea for Coq. There are many levels to purity, and I think as research progresses we will gradually be able to go to the stricter levels while remaining productive. It gives me comfort to see a long road ahead -- I don't like to see perfect languages, because that's just me seeing my own ignorance :-) Luke From simon at joyful.com Sat Dec 12 03:41:37 2009 From: simon at joyful.com (Simon Michael) Date: Sat Dec 12 03:15:53 2009 Subject: [Haskell-cafe] hledger 0.7 released Message-ID: I'm pleased to announce hledger 0.7. Thanks to Marko Koci? who contributed many fixes for hlint warnings. To install/upgrade: cabal update && cabal install hledger [-fweb] [- fvty] Documentation: http://hledger.org Release notes: * price history support (first cut): P directives now work, though differently from c++ ledger. Each posting amount takes its fixed unit price from the price history (or @) when available. This is simple and useful for things like foreign currency expenses (but not investment tracking). Like ledger, balance and register don't show amount prices any more, and don't separate differently-priced amounts. Unlike ledger, print shows all amount prices, and supports -B. * --effective option, will use transactions' effective dates if any * convert: new rules file format, find/create rules file automatically, more robust parsing, more useful --debug output * print: always sort by date, fix long account name truncation, align amounts, show end of line comments, show all amounts for clarity (don't elide the final balancing amount) * ui: use vty 4, fixes non-ascii and gnome terminal problems (issues #3, #4) * web: allow data entry, react to data file changes, better layout, help links, remove histogram command and filter fields for now, fix bad localhost redirect, filter form did not work in eg firefox (issue #7), reset link did not work in all browsers * parsing: require whitespace between date and status code, allow (and ignore) a time in price records, better error messages, non-zero exit code on parse failure * display non-ascii error messages properly (issue #5) * fix an arithmetic bug that occasionally rejected valid transactions * fix a regex bug in showtree * don't break if HOME is undefined * --debug now implies --verbose * add functional tests like ledger's, use test-framework for speedy running, release shelltestrunner as a separate package * many hlint cleanups (Marko Koci?) * many site and documentation updates Stats: 2 contributors, 175 days since release, 182 commits, 3320 non-test code lines, 97 tests, 53% test coverage, performance: similar (http://hledger.org/profs/200912111852.bench) Best, -Simon From bulat.ziganshin at gmail.com Sat Dec 12 03:40:56 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Dec 12 03:22:01 2009 Subject: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882) In-Reply-To: <161d443c0912112248l6de7c517h22270e5dd875d12b@mail.gmail.com> References: <161d443c0912112244y64813d12kb54c4cd8587a2152@mail.gmail.com> <161d443c0912112248l6de7c517h22270e5dd875d12b@mail.gmail.com> Message-ID: <1885217988.20091212114056@gmail.com> Hello Ravi, Saturday, December 12, 2009, 9:48:28 AM, you wrote: > Based on the responses to my previous message, our featured presenter > will be Ryan Newton who will talk about the Intel Concurrent > Collections for Haskell. awesome! you may try it on many typical unix text processing tasks, such as word frequencies counting, or building statistics from logfiles -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From stephen.tetley at gmail.com Sat Dec 12 04:41:43 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 12 04:15:57 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: References: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> Message-ID: <5fdc56d70912120141j3a772bb7u1be20def620f9687@mail.gmail.com> 2009/12/12 Tom Tobin : > > 1) Can the author of Y legally distribute the *source* of Y under a > non-GPL license, such as the 3-clause BSD license or the MIT license? Hello Tom If the answer to this isn't yes, I'll buy a hat and eat it... As source, Y (the BSD3 library) can surely be distributed as the author sees fit. The author could even distribute Y as source under a non-GPL _compatible_ license. This would hamper the utility Y, neither the author of Y nor anyone else could distribute an executable that agglomerates X and Y, but I honestly can't see how the existence of library X (GPL) can make it illegal to distribute other distinct works (my emphasis on _distinct_). Now, author X could choose to sue author Y for copyright infringement. If such a case happened it might set the precedent for what a 'derived work' is - vis-a-vis GPL and libraries - from my cursory web searching, such a case hasn't happened. From the 'Linking and derived works' bit in the Wikipedia page, the judgement on copyright law notes "the infringing work must incorporate a portion of the copyrighted work in some form", surely the judges would have to decide whether or not calling API's and reusing datatypes is incorporation. http://en.wikipedia.org/wiki/GNU_General_Public_License > 3) If the answer to 1 is "yes", what specifically would trigger the > redistribution of a work in this scenario under the GPL? Is it the > distribution of X+Y *together* (whether in source or binary form)? Don't know. In the case of Hakyll and other packages on Hackage, the distribution is in source form. If someone wanted to repackage the code from Hackage as a binary distro they would have different obligations. > 4) If the answer to 1 is "yes", does this mean that a "BSD-licensed" > library does not necessarily mean that closed-source software can be > distributed which is based upon such a library (if it so happens that > the library in turn depends on a copylefted library)? The 'closed-source' software here still depends on a 'copyleft' library - if the library is GPL then the terms of the GPL apply. Whether there is an intermediary BSD licensed library is surely immaterial. Best wishes Stephen From mlesniak at uni-kassel.de Sat Dec 12 04:56:07 2009 From: mlesniak at uni-kassel.de (Michael Lesniak) Date: Sat Dec 12 04:30:25 2009 Subject: [Haskell-cafe] Parallel foldl doesn't work correctly In-Reply-To: <1260586642.3898.9.camel@phil-desktop> References: <1260586642.3898.9.camel@phil-desktop> Message-ID: <5f8b37690912120156q35d21ffbnf19f846497553f35@mail.gmail.com> Hello, > This compiles and if I monitor my CPUs it starts to use both cores, but > after approx 10 seconds, one core drops to low rate (I'm using a 2 core > machine). Just a shot in the dark: what OS are you using? I have had some problems with GHC 6.10.4 and Ubuntu Karmic Koala{1[, which are fixed for me in GHC 6.12 RC1. - Michael [1] http://www.mlesniak.com/2009/12/01/ghc-6-12-rc1-and-ubuntu-9-10-karmic-koala/ From uzytkownik2 at gmail.com Sat Dec 12 05:08:17 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Sat Dec 12 04:42:52 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: <1260586642.3898.9.camel@phil-desktop> References: <1260586642.3898.9.camel@phil-desktop> Message-ID: <1260612497.2575.13.camel@picard> On Sat, 2009-12-12 at 02:57 +0000, Philip Beadling wrote: > Hi, > > Can anyone put me right here. I am trying to use a setup similar to > parMap to spark each valuation in a list in parallel, where the > resulting (evaluated) list is folded to produce a final single result. > > Having done the obligatory google, I modified a few common examples to > give: > > pfoldl f acc xs = foldl' f acc (xs `using` parList rwhnf) > > > This compiles and if I monitor my CPUs it starts to use both cores, but > after approx 10 seconds, one core drops to low rate (I'm using a 2 core > machine). > > The end result is that -N2 is actually a bit slower than -N1! > > I'm guessing I haven't grasped the concept properly - although as map is > just 'foldl (+) 0' I'm at a loss to see why this approach wouldn't work > given it is pretty similar to parMap - could anyone point out what I'm > missing? > > If it's any use the context of the code is below. > > Many thanks! > > > Phil. At least IMHO foldl cannot be pararalized since it have rather strong dependencies i.e. only calculation of acc and first value of list. If operation is associative it can be done using divide et impera spliting list in half and operating on it pararerlly then split in half etc. 8 stages (the same number (O n) as normally + cost of synchronization etc). 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 3 operations (to be more specific O (log n)): 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 Regards PS. I don't know nor understend the pararell library. Maybe I don't understend something but without associativity IMHO data is too interdependent IMHO to do something. From noteed at gmail.com Sat Dec 12 05:54:21 2009 From: noteed at gmail.com (minh thu) Date: Sat Dec 12 05:28:54 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <5fdc56d70912120141j3a772bb7u1be20def620f9687@mail.gmail.com> References: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> <5fdc56d70912120141j3a772bb7u1be20def620f9687@mail.gmail.com> Message-ID: <40a414c20912120254g476138d1la6e3228c04fa66a9@mail.gmail.com> 2009/12/12 Stephen Tetley : > 2009/12/12 Tom Tobin : > >> >> 1) Can the author of Y legally distribute the *source* of Y under a >> non-GPL license, such as the 3-clause BSD license or the MIT license? > > Hello Tom > > If the answer to this isn't yes, I'll buy a hat and eat it... > > As source, Y (the BSD3 library) can surely be distributed as the > author sees fit. The author could even distribute Y as source under a > non-GPL _compatible_ license. This would hamper the utility Y, neither > the author of Y nor anyone else could distribute an executable that > agglomerates X and Y, but I honestly can't see how the existence of > library X (GPL) can make it illegal to distribute other distinct works > (my emphasis on _distinct_). > > Now, author X could choose to sue author Y for copyright infringement. > If such a case happened it might set the precedent for what a 'derived > work' is - vis-a-vis GPL and libraries - from my cursory web > searching, such a case hasn't happened. From the 'Linking and derived > works' bit in the Wikipedia page, the judgement on copyright law notes > "the infringing work must incorporate a portion of the copyrighted > work in some form", surely the judges would have to decide whether or > not calling API's and reusing datatypes is incorporation. > > http://en.wikipedia.org/wiki/GNU_General_Public_License > > >> 3) If the answer to 1 is "yes", what specifically would trigger the >> redistribution of a work in this scenario under the GPL? Is it the >> distribution of X+Y *together* (whether in source or binary form)? > > Don't know. > > In the case of Hakyll and other packages on Hackage, the distribution > is in source form. If someone wanted to repackage the code from > Hackage as a binary distro they would have different obligations. > >> 4) If the answer to 1 is "yes", does this mean that a "BSD-licensed" >> library does not necessarily mean that closed-source software can be >> distributed which is based upon such a library (if it so happens that >> the library in turn depends on a copylefted library)? > > The 'closed-source' software here still depends on a 'copyleft' > library - if the library is GPL then the terms of the GPL apply. > Whether there is an intermediary BSD licensed library is surely > immaterial. I'd like to point out a possible situation, that makes the questions even more interesting. Say the author of Y (the BSD licensed code) is used to install its code, Y, along of its requisite X (under GPL) to customer locations. Note that Y and X are not (re)distributed in compiled form. In fact, the client could have the internal resource to install and configure Y and its requisite himself (if Y was made available to him). Is it ok in regard of the GPL ? Cheers, Thu From frank at geoinfo.tuwien.ac.at Sat Dec 12 06:12:55 2009 From: frank at geoinfo.tuwien.ac.at (Andrew U. Frank) Date: Sat Dec 12 05:47:10 2009 Subject: [Haskell-cafe] wiki in hackage Message-ID: <200912121212.55287.frank@geoinfo.tuwien.ac.at> i think to add a wiki to each package is a great idea. as a default, it could be started automatically by uploading to hackage and filled with the readme.txt file (if availble) in the tar uploaded. if it is empty and exist, it is a point to check for when a package does not install immediately. alternatively, one has to search the web to see if there is some place with notices about this package. i would have loved to see wiki's for packages to post my result of work- arounds for problems with dependencies, small changes in source code etc. that could be posted there till the maintainer finds time to produce a new version. great idea! andrew frank From shinnonoir at gmail.com Sat Dec 12 06:19:12 2009 From: shinnonoir at gmail.com (Raynor Vliegendhart) Date: Sat Dec 12 05:53:24 2009 Subject: [Haskell-cafe] "--" comments In-Reply-To: References: <521540.75394.qm@web31104.mail.mud.yahoo.com> Message-ID: <6d961e560912120319g1d3367f8id77020d27e311d89@mail.gmail.com> On Sat, Dec 12, 2009 at 5:34 AM, Brandon S. Allbery KF8NH wrote: > > > On Dec 11, 2009, at 23:30 , michael rice wrote: > > > > I'm just noticing that "--" comments don't seem to work properly when the first character following them is a '*'. > > I believe the spec only treats "-- " as a comment leader; this is why Haddock markup has a space between the "--" and the markup. The spec [1] treats anything that starts with two or more dashes not followed by a non-symbol to be the start of a comment. [1] http://www.haskell.org/onlinereport/syntax-iso.html From stephen.tetley at gmail.com Sat Dec 12 07:32:09 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 12 07:06:22 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <40a414c20912120254g476138d1la6e3228c04fa66a9@mail.gmail.com> References: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> <5fdc56d70912120141j3a772bb7u1be20def620f9687@mail.gmail.com> <40a414c20912120254g476138d1la6e3228c04fa66a9@mail.gmail.com> Message-ID: <5fdc56d70912120432v23b359k70d8e73215e25342@mail.gmail.com> Hi Thu That would sound like 'private use' to me[1] which is permitted by the GPL. If the client later wanted to *distribute* the agglomerated work the GPL would apply. Distribution being the key point, as at that stage the client is no longer using the agglomeration privately. Best wishes Stephen [1] insert the usual caveats for 'interpretation' - I'm not a lawyer, your mileage may vary, etcetera. Similar the limits on 'client' would need some definition vis-a-vis distribution, one person would surely be fine, extrapolating up to multi-national companies I'm not sure. 2009/12/12 minh thu : > I'd like to point out a possible situation, that makes the questions > even more interesting. > > Say the author of Y (the BSD licensed code) is used to install its > code, Y, along of its requisite X (under GPL) to customer locations. > Note that Y and X are not (re)distributed in compiled form. In fact, > the client could have the internal resource to install and configure Y > and its requisite himself (if Y was made available to him). > > Is it ok in regard of the GPL ? > > Cheers, > Thu > From doug_j_burke at yahoo.com Sat Dec 12 08:07:00 2009 From: doug_j_burke at yahoo.com (Doug Burke) Date: Sat Dec 12 07:41:12 2009 Subject: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882) In-Reply-To: <1885217988.20091212114056@gmail.com> Message-ID: <766095.75864.qm@web65611.mail.ac4.yahoo.com> --- On Sat, 12/12/09, Bulat Ziganshin wrote: > From: Bulat Ziganshin > Subject: Re: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882) > To: "Ravi Nanavati" > Cc: haskell-cafe@haskell.org > Date: Saturday, December 12, 2009, 3:40 AM > Hello Ravi, > > Saturday, December 12, 2009, 9:48:28 AM, you wrote: > > > Based on the responses to my previous message, our > featured presenter > > will be Ryan Newton who will talk about the Intel > Concurrent > > Collections for Haskell. > > awesome! you may try it on many typical unix text > processing tasks, > such as word frequencies counting, or building statistics > from > logfiles > > > -- > Best regards, > Bulat? ? ? ? ? ? ? Perhaps something like http://www.tbray.org/ongoing/When/200x/2009/12/08/WF-Tuning-Clojure :-) Doug From marco-oweber at gmx.de Sat Dec 12 08:13:32 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Dec 12 07:48:06 2009 Subject: [Haskell-cafe] Re: What about adding a wiki for each haskell project? In-Reply-To: <1260584790.9220.4582.camel@localhost> References: <1260575495-sup-9064@nixos> <1260584790.9220.4582.camel@localhost> Message-ID: <1260623334-sup-9891@nixos> Excerpts from Duncan Coutts's message of Sat Dec 12 03:26:30 +0100 2009: > On Sat, 2009-12-12 at 01:00 +0100, Marc Weber wrote: > > hackage is success because: > > a) many (most) people do use it (by uploading packages) > > b) it is a comprehensive list of availible packages if not the most > > comprehensive one > > > > Duncan, can you write about your concerns briefly why some maintainers may dislike > > this idea ? > > I added a section to the wiki page you created. I didn't paste the link earlier because I was no longer sure whether a wiki page is the best thing todo. Anyway here it is: http://haskell.org/haskellwiki/Hackage_wiki_page_per_project_discussion Duncan added this section: 3 Concerns My (DuncanCoutts) concern is about the consent from package authors. Hackage is a social bargain. We ask package authors to distribute their work through hackage because it provides benefits to the community. If we impose too much on package authors then they may decide it's just not worth it. In particular, if we automatically create a wiki page for every package then we are imposing additional obligations on package authors. As a package author I might be concerned that this wiki page duplicates an existing home page or bug tracking system. If there's a wiki page about my project then I am effectively obligated to check it from time to time, since users will inevitably report bugs etc there. It is that extra obligation that package authors may resent. There is no problem with such a feature being opt-in, but whether it is something we require and impose on package authors needs much more of a social consensus before we go ahead. So how do we reach this consensus? Is it feasable to ask all package authors which uploaded anything to hackage? Duncan, can you also separate your thoughts and switch in two different roles: a) You as package maintainer (eg supporting cabal) b) You as cabal (& hackage) maintainer thinking about package maintainers contributing to hackage. Thus are you concerned yourself ? Would you prefer opt-in for the projects *you* maintain ? Do you think package authors which do care (and which have a bug tracking system and a home page (eg gtk2hs)) would be willing to add those links to the wiki? It could look like this: Dear user. Let me tell you about: * package bug tracking system (link) * package homepage (link) * package mailinglist (...) * package repository: darcs get ..... And people will follow those links and create a bug report. Moreover I think they would be even thankful! If they don't they are just stupid. And you'll always meet this kind of users.. And again: We generated value because you don't have to upload a new package to tell users about a new homepage or a new bug tracking system or whatever. They will find it by themselves without magic and without contacting you and without looking at the darcs repository (which may take much time ..) If you have time to maintain a package you also have time to ad 4 links or less. If you don't this means you don't care which is also fine. Marc Weber From bulat.ziganshin at gmail.com Sat Dec 12 08:19:56 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Dec 12 07:55:22 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <5fdc56d70912120432v23b359k70d8e73215e25342@mail.gmail.com> References: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> <5fdc56d70912120141j3a772bb7u1be20def620f9687@mail.gmail.com> <40a414c20912120254g476138d1la6e3228c04fa66a9@mail.gmail.com> <5fdc56d70912120432v23b359k70d8e73215e25342@mail.gmail.com> Message-ID: <84438083.20091212161956@gmail.com> Hello Stephen, Saturday, December 12, 2009, 3:32:09 PM, you wrote: > the GPL would apply. Distribution being the key point, as at that > your mileage may vary, etcetera. Similar the limits on 'client' would > need some definition vis-a-vis distribution, one person would surely > be fine, extrapolating up to multi-national companies I'm not sure. afaik, it's still ok while inside one company -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From haskell at benmachine.co.uk Sat Dec 12 08:46:28 2009 From: haskell at benmachine.co.uk (Ben Millwood) Date: Sat Dec 12 08:20:43 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: <1260612497.2575.13.camel@picard> References: <1260586642.3898.9.camel@phil-desktop> <1260612497.2575.13.camel@picard> Message-ID: On Sat, Dec 12, 2009 at 10:08 AM, Maciej Piechotka wrote: > If operation is associative it can be done using divide et impera > spliting list in half and operating on it pararerlly then split in half > etc. I implemented something like this as an exercise: http://benmachine.co.uk/parconcat.hs It took me a little while to get everything to par as it should and I'm still not sure I'm doing it in the most efficient way, but there it is. (If the output is nonsense, you might try changing hPutStrLn stderr into putStrLn so that it's buffered and arrives in blocks). From Patrick.Browne at comp.dit.ie Sat Dec 12 09:08:11 2009 From: Patrick.Browne at comp.dit.ie (pbrowne) Date: Sat Dec 12 08:42:36 2009 Subject: [Haskell-cafe] Re: Why? In-Reply-To: <4B227B88.8020108@comp.dit.ie> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B2201A3.5040504@comp.dit.ie> <200912110847.17916.dan.doel@gmail.com> <4B227B88.8020108@comp.dit.ie> Message-ID: <4B23A3CB.2000501@comp.dit.ie> pbrowne wrote: > 2) What, if anything, prevents the execution of a Haskell term from > being a proof in equational logic? I have done some checking to try to answer my own question. The answer *seems* to be that there *seems* to be three things that prevent Haskell terms being true equations. Any feedback on these three reason would be welcome. If they are valid reasons, what is their possible impact? Pat --------------------Reason (1)------------------ There are some equations that are not expressible in Haskell. Quoting form: http://www.mail-archive.com/haskell-cafe@haskell.org/msg64843.html Is there any way to achieve such a proof in Haskell itself? > GHC appears to reject equations such has > mirror (mirror x) = x > mirror (mirror(Node x y z)) = Node x y z Eugene Kirpichov Fri, 25 Sep 2009 04:19:32 -0700 It is not possible at the value level, because Haskell does not support dependent types and thus cannot express the type of the proposition "forall a . forall x:Tree a, mirror (mirror x) = x", and therefore a proof term also cannot be constructed. Another example from [5]. A partial order that is also linear is called a total order. The class linorder of total orders is specified using the usual total order axioms. Of course, such axiomatizations are not possible in Haskell. --------------------Reason (2)------------------ According to Thompson [1] the equations in Miranda (and I assume Haskell) are not pure mathematical equations due to *where* and other reasons. According to Danielsson [2] the fact that they are not always structurally equations does not prevent functional programmers from using them as if they were valid equations. Danielsson show that this informal *fast and loose* use of equational axioms and theorems is *morally correct*. In particular, it is impossible to transform a terminating program into a looping one. These results justify the informal reasoning that functional programmers use. --------------------Reason (3)------------------ There is no formal specification for the meaning of a Haskell program (i.e. its meaning is not defined in a logic). At the level of precise logical specification and logical interoperability this could be a problem (e.g. semantic web likes logic). This should not be a problem for programming tasks, after all most languages like Java do not have a formal semantic definition in logic (ML, Maude[3] and CafeOBJ[4] do). [1]A Logic for Miranda, Revisited (1994) by Simon Thompson http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.55.149 [2] Fast and Loose Reasoning is Morally Correct - Danielsson, Hughes http://citeseer.ist.psu.edu/733155.html [3] http://maude.cs.uiuc.edu/ [4] http://www.ldl.jaist.ac.jp/cafeobj/ [5]Translating Haskell to Isabelle: Torrini, Lueth,Maeder,Mossakowski http://es.cs.uni-kl.de/TPHOLs-2007/proceedings/B-178.pdf From batterseapower at hotmail.com Sat Dec 12 09:22:12 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Dec 12 08:56:23 2009 Subject: [Haskell-cafe] GHC 6.12 status and features In-Reply-To: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> References: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> Message-ID: <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto : > I know I should probably be asking to the GHC list, but is there any update > on 6.12 since October? Any probable release date? It looks like haskell.org just acquired this page, though it's not yet linked to from anywhere else: http://haskell.org/ghc/download_ghc_6_12_1.html > BTW, is there any feature list for the release? http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html Cheers, Max From daniel.is.fischer at web.de Sat Dec 12 09:44:54 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Dec 12 09:20:34 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <200912101500.42070.daniel.is.fischer@web.de> <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> Message-ID: <200912121544.54220.daniel.is.fischer@web.de> Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: > On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: > > Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: > >> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > >> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, > > > > mb_t's_bcs the ndrscr_stl is considered far uglier and less readable > > by others > > Come ON. Argue honestly! Thanks, but I have to return that compliment. > The problem with that text is *NOT* the > underscores but the insanely heavy abbreviation. As stated in the parenthesis immediately afterwards. > We all agree that > insanely heavy abbreviation is bad, but do you *really* want to > claim that > mbT'sBcs the ndrscrStl isConsidered farUglier and lessReadable byOthers > is readable? I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. > > > (granted, > > underscore-style with nonabbreviated words is not unreadable, but > > still extremely ugly)? > > Who "grants" that underscore separation with fully written words is > "still extremely ugly"? Not me! Is that remark really unclear, or did you intentionally choose the bracketing you did to make a polemical point? (This is a serious enquiry about the English language. In German, the analogous construction to "granted, a, but b" ["zugegeben, a, aber b"] is parsed "(granted, a), but b", can it really be parsed as "granted, (a, but b)" in English?) (granted, ... is not unreadable. But it is still ...) Clearly, *I* grant - or admit, concede - that it is *readable*. Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. > > I don't believe that it _is_ a matter of personal preference. I believe that even readability is strongly influenced by personal preference (more by experience - what you're used to). However, the sentence about preference was more concerned with aesthetics. > I have not been able to discover an experimental study of word > separation style effect on readability in programming. I've been > wondering about running a small one myself, next year. But there > is enough experimentally determined about reading in general to > be certain that visible gaps between words materially improves > readability, and internal capital letters harm it. Now that > applies to ordinary text, but until there's evidence to show that > it doesn't apply to program sources, it's a reasonable working > assumption that it does. I doubt that. Sourcecode is so different from ordinary text (a line of sourcecode rarely contains more than four or five words), that I'd be very wary to transfer the findings for one to the other. If somebody claimed that of x <- take_while some_condition some_list and x <- takeWhile someCondition someList either was objectively more readable than the other, I wouldn't believe it without lots and lots of hard evidence. I believe you find the first more readable, however, for me the underscores push the space-separated parts together, so that I have the tendency to bracket it x <- take (while some) (condition some) list on first glance. It resolves when focusing on the line, however. (And, of course, the problem doesn't turn up for x <- take_while (<= 1000) [3,7 .. ] or similar.) From matthew.pocock at ncl.ac.uk Sat Dec 12 10:25:55 2009 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Sat Dec 12 10:00:08 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <200912121544.54220.daniel.is.fischer@web.de> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <200912101500.42070.daniel.is.fischer@web.de> <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> <200912121544.54220.daniel.is.fischer@web.de> Message-ID: > x <- take_while some_condition some_list > > and > > x <- takeWhile someCondition someList x <- take-while some-condition some-list As someone who is dyslexic, I find both camelCase and dashes far easier to read than underscores. I find it hard to count the words in the underscore version - the underscores and spaces confuse me. Dashes do not, presumably because they are 'within' the line of sight for the letters. However, I can't help feeling that if we use good IDEs, we could 'internationalize' identifiers into english/french/chinese/camel/dash or whatever. Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091212/06dc1028/attachment.html From aslatter at gmail.com Sat Dec 12 10:41:05 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Dec 12 10:15:16 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <1260575495-sup-9064@nixos> References: <1260575495-sup-9064@nixos> Message-ID: <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> On Fri, Dec 11, 2009 at 6:00 PM, Marc Weber wrote: > > Hackage is missing one feature: > It is very static. I mean if you have a patch or a question or a comment > you have to lookup the darcs repository, write the patch then contact > the author and wait.. If the author replies everything is fine. > If he doesn't you don't know what to do. And if he does your commitment > still doesn't show up on hackage. > > Using a wiki page for each project enables anybody to add comments. > I'm thinking about this kind of comments: > > ?"Interlude doesn't work for me. It looks like the interlude.h file > ?passes a tuple to the reportError function which doesn't expect a tuple. > ?You can fix it by removing the "," in the .h file. > ?Try this patch: > ?http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch > ?" > One thing you can do today is enter a homepage URL into your .cabal file which is a link to the haskell-wiki. >From there you can construct the initial pages of the wiki in a manner that makes it obvious you welcome participation. This also means we're not creating a wiki for the more mature projects like darcs whose hompage already is a wiki, and who have active mailing lists and the like. Antoine From 8mayday at gmail.com Sat Dec 12 10:58:12 2009 From: 8mayday at gmail.com (Andrey Popp) Date: Sat Dec 12 10:32:43 2009 Subject: [Haskell-cafe] Preserving data type information Message-ID: I am writing URL parsing library which works the following way: - User have a spec of URL, like this: > f :: String > f = "/archive/ - There is data type and parser for specs: > data Value = IntegerValue Integer | CharValue Char > parseSpec :: Parser (Parser (Map String Value)) - So after parsing spec I have parser for URLs and after parsing them ? I have mapping from strings to Value values extracted from URL and then I can process them. Now, I want to others to extend my specs by providing additional types, for example: > spec :: String > spec = "/archive/ And store year in: > data Year = Year Integer But for that I need to extend Value data type too: > data Value = Integer Value | CharValue Char | YearValue Year Which is undesirable... So, I decide to use type class instead of Value type: > class Value a > instance Value Integer > instance Value Char > instance Value Year > parseSpec :: (Value a) => Parser (Parser (Map String a)) But after parsing URL I have mapping from string to some values of type (Value a) => a which I can't process, but only by applying functions from Value type class, which is limited. So, is there any way to extract type information from containers like (Value a) => Map String a? Something like this: > getInteger :: (Value a) => Map String a -> Maybe Integer Or maybe, am I doing something wrong from the beginning? From stephen.tetley at gmail.com Sat Dec 12 11:18:19 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat Dec 12 10:52:32 2009 Subject: [Haskell-cafe] Preserving data type information In-Reply-To: References: Message-ID: <5fdc56d70912120818w63ed4afer3352269ea69b7e1c@mail.gmail.com> Hi Andrey Dynamic types are a possibility, if you want to handle an 'open set' of types: http://www.haskell.org/ghc/docs/6.10.3/html/libraries/base/Data-Dynamic.html & http://people.cs.uu.nl/arthurb/dynamic.html Although I don't see your use case as needing heterogeneous lists, section 2 of the HList paper enumerates the design options available for 'open types' (the authors conclude against dynamics in this case). http://homepages.cwi.nl/~ralf/HList/ Best wishes Stephen From marco-oweber at gmx.de Sat Dec 12 12:09:16 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Dec 12 11:43:46 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> Message-ID: <1260637694-sup-6120@nixos> Hi Antoine. One of the main goals is to have a place to a put information when you're not the maintainer. Of course I can put everything into *my* cabal files. I don't want to do this for projects I don't maintain. I'd like to ask maintainers first. But while this question - reply cycle is in progress I'd like to add a link to my patches. About darcs: Sure. Nobody want's to duplicate the contents of the darcs web page. However you can add a link to it. I wonder which is the way to ask all maintainers how they like this idea or more important: Why they might dislike having a wiki page others may edit as well. Marc Weber From korpios at korpios.com Sat Dec 12 12:15:10 2009 From: korpios at korpios.com (Tom Tobin) Date: Sat Dec 12 11:49:20 2009 Subject: [Haskell-cafe] Re: ANN: hakyll-0.1 In-Reply-To: <40a414c20912120254g476138d1la6e3228c04fa66a9@mail.gmail.com> References: <4ec472cb0912081413u7e1955a5rcbb118986b2c1e49@mail.gmail.com> <20091209100902.6b76ff96.mle+hs@mega-nerd.com> <1260318302.7272.59.camel@localhost> <5fdc56d70912120141j3a772bb7u1be20def620f9687@mail.gmail.com> <40a414c20912120254g476138d1la6e3228c04fa66a9@mail.gmail.com> Message-ID: On Sat, Dec 12, 2009 at 4:54 AM, minh thu wrote: > I'd like to point out a possible situation, that makes the questions > even more interesting. > > Say the author of Y (the BSD licensed code) is used to install its > code, Y, along of its requisite X (under GPL) to customer locations. > Note that Y and X are not (re)distributed in compiled form. In fact, > the client could have the internal resource to install and configure Y > and its requisite himself (if Y was made available to him). > > Is it ok in regard of the GPL ? I think the answer to this will be the same as the answer to question 1. From keithshep at gmail.com Sat Dec 12 12:16:29 2009 From: keithshep at gmail.com (Keith Sheppard) Date: Sat Dec 12 11:50:39 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <1260637694-sup-6120@nixos> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <1260637694-sup-6120@nixos> Message-ID: <92e42b740912120916w48512565m378b2e6a9f641b0@mail.gmail.com> What about if during the "Checking a Cabal package" upload step there was a check to see if there was a homepage in the cabal file? If there is no homepage we could have something like: "Your cabal file does not contain a link to a project homepage. You may want to add a haskell wiki link as your homepage by adding the following line to your cabal file..." This would not force the wiki page on anyone but it would add a nudge to anyone who just didn't think about it. -Keith On Sat, Dec 12, 2009 at 12:09 PM, Marc Weber wrote: > Hi Antoine. > > One of the main goals is to have a place to a put information when > you're not the maintainer. Of course I can put everything into *my* > cabal files. I don't want to do this for projects I don't maintain. > I'd like to ask maintainers first. But while this question - reply cycle > is in progress I'd like to add a link to my patches. > > About darcs: Sure. Nobody want's to duplicate the contents of the darcs > web page. However you can add a link to it. > > I wonder which is the way to ask all maintainers how they like this > idea or more important: Why they might dislike having a wiki page > others may edit as well. > > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- keithsheppard.name From korpios at korpios.com Sat Dec 12 12:32:55 2009 From: korpios at korpios.com (Tom Tobin) Date: Sat Dec 12 12:07:08 2009 Subject: [Haskell-cafe] GHC 6.12 status and features In-Reply-To: <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> References: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> Message-ID: On Sat, Dec 12, 2009 at 8:22 AM, Max Bolingbroke wrote: > 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto : >> I know I should probably be asking to the GHC list, but is there any update >> on 6.12 since October? Any probable release date? > > It looks like haskell.org just acquired this page, though it's not yet > linked to from anywhere else: > > http://haskell.org/ghc/download_ghc_6_12_1.html Aw, no OS X package yet ... :-) From dagit at codersbase.com Sat Dec 12 13:13:44 2009 From: dagit at codersbase.com (Jason Dagit) Date: Sat Dec 12 12:47:54 2009 Subject: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap In-Reply-To: References: Message-ID: Hi Heinrich, On Sat, Dec 12, 2009 at 2:42 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote: > Jason Dagit wrote: > > My next experiment will be to find ways to express "take this operation > and > > apply it to a stream without letting the stream leak". One implication is > > that gzReadFilePS should not be used outside of a core set of modules > which > > have been auideted to be resource concious. Another implication is that > we > > need to be really careful about wether or not we allow returning of > > sequences of patches. Possibly, we need several foldl-like functions > that > > open the stream internally. For example, to process the pending maybe we > > should have: > > withPending :: (a -> Patch -> a) -> IO a > > > > And withPending would start the streaming and make sure that the stream > > cannot be visible as a data dependency outside of withPending. > > Just a small comment on a potential flaw in this scheme and the > observation that even the rank-2 type trick from the ST s monad > wouldn't help. > I would say it does help, but it doesn't make it perfect. > > > Namely, withPending does not guarantee that the stream does not leak, > it only makes it more natural/convenient to formulate one's code so that > it doesn't leak. In particular, using (:) as argument pretty much > defeats the whole purpose: > Right. And the iteratee library points out that your iteratees have to be well-behaved (I think there they say "bounded"). I'm well aware of this issue and thanks for pointing it out for others who are reading along. > > withPending (flip (:)) > > Fortunately, the type system can ensure that the patches don't leak. > > withPending :: (forall s. a -> Patch s -> a) -> IO a > > Now, a may not mention s and the type checker will reject flip (:) > as argument. See also > > Oleg Kiselyov, Chung-chieh Shan. > Lightweight Monadic Regions. > http://www.cs.rutgers.edu/~ccshan/capability/region-io.pdf > > for an elaboration of this technique. > I'm still on the fence as to whether this style of writing it will add value greater than the complexity it brings. I am certainly considering it :) The darcs source does other things that are also fairly complex. > > > However, the line between leaking and not leaking is very thin here. As > soon as we are given for example a function > > name :: Patch s -> String > > that discards the s , its results can "leak", in the sense that we > could now build a list of names > > foo :: IO [String] > foo = withPending . flip $ (:) . name > > Even worse, any type a that doesn't have O(1) space usage will "leak" > > bar :: IO [()] > bar = withPending . flip $ const (() :) > > In other words, exporting only a foldl' -like interface does not really > prevent us from writing functions that have O(n) instead of O(1) space > usage. But trying to rectify that with the forall s trick is a doomed > idea, too. > I realize it's not perfect, but the problem we have now is that it's too easy to write things that have dismal space usage. If we can't force proper space usage, how can we make it more natural to have bounded space? Or at least a good approximation. It seems that: * foldl'-style helps * rank-n can help * no approach I've seen *forces* the behavior we want * existing code and bug reports demonstrate we need to improve the situation I'm open to suggestions on how to ensure the code has the space behavior I want. Lazy IO* and streams of patches is more compositional and natural to Haskell programmers, but it seems that it's too hard to ensure the code has reasonable space usage. At least where the darcs source is concerned. Therefore, I think the status quo demonstrates that in the darcs source it's worth experimenting with alternatives to lazy io and streams. In other words, the human effort to make the code behave how we want is currently too high and that's the issue I want to address. I don't know how we could make it impossible to have space leaks, although that would be interesting. (*) Note: Lazy IO itself is used in very few places in darcs these days because it has lead to serious bugs. These days me point is more about big streams getting retained. Finding where and why has proven difficult. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091212/d0b070be/attachment.html From 8mayday at gmail.com Sat Dec 12 15:02:35 2009 From: 8mayday at gmail.com (Andrey Popp) Date: Sat Dec 12 14:37:06 2009 Subject: [Haskell-cafe] Preserving data type information In-Reply-To: <5fdc56d70912120818w63ed4afer3352269ea69b7e1c@mail.gmail.com> References: <5fdc56d70912120818w63ed4afer3352269ea69b7e1c@mail.gmail.com> Message-ID: Hi, Stephen. Thanks a lot ? HList paper gave me a good overview of possible soultions. For the first try I will stuck with Data.Dynamic. On Sat, Dec 12, 2009 at 7:18 PM, Stephen Tetley wrote: > Hi Andrey > > Dynamic types are a possibility, if you want to handle an 'open set' of types: > > http://www.haskell.org/ghc/docs/6.10.3/html/libraries/base/Data-Dynamic.html > & > http://people.cs.uu.nl/arthurb/dynamic.html > > Although I don't see your use case as needing heterogeneous lists, > section 2 of the HList paper enumerates the design options available > for 'open types' (the authors conclude against dynamics in this case). > > http://homepages.cwi.nl/~ralf/HList/ > > Best wishes > > Stephen > -- ? ?????????, ?????? ????. +7 911 740 24 91 From ezyang at MIT.EDU Sat Dec 12 15:03:49 2009 From: ezyang at MIT.EDU (Edward Z. Yang) Date: Sat Dec 12 14:38:33 2009 Subject: [Haskell-cafe] Token parsers in parsec consume trailing whitespace Message-ID: <1260647846-sup-4688@ezyang> I recently ran into a nasty little bug where token parsers in parsec consume trailing whitespace, which were consuming newlines and thus bamboozling a higher-level "sepBy" combinator. I replaced my instances of 'natural' with 'read <$> many1 digit', but this gave rise to the following questions: 1. Is there a more elegant way of doing number parsing? In particular, are there token parsers that don't consume trailing whitespace, or is there a better way to do this with the primitives. 2. It seems that the "token" approach of parsing lends itself to a different style of parsing than the one I'm doing, namely, instead of assuming all of your parsers consume exactly what they need, and no more, you assume that they consume what they need and spaces. Thus, code that looks like: do foo <- fooParser spaces bar <- barParser spaces baz <- bazParser return $ FooBarBaz foo bar baz becomes: FooBarBaz <$> fooParser <*> barParser <*> bazParser And instead of using sepBy you just use many. One of the problems I see with this approach is if I was using sepBy newline, the new token oriented parser has no way of distinguishing "foo bar baz\nfoo bar baz" from "foo bar baz foo bar baz", which is something I might want to care about. Which method do you prefer? 3. Not so much a question as a comment: when parsing entire files, be sure to add the eof combinator at the end! Cheers, Edward From shahn at cs.tu-berlin.de Sat Dec 12 16:00:40 2009 From: shahn at cs.tu-berlin.de (Soenke Hahn) Date: Sat Dec 12 15:34:53 2009 Subject: [Haskell-cafe] writing graphs with do-notation Message-ID: <200912122200.40692.shahn@cs.tu-berlin.de> Hi! Some time ago, i needed to write down graphs in Haskell. I wanted to be able to write them down without to much noise, to make them easily maintainable. I came up with a way to define graphs using monads and the do notation. I thought this might be interesting to someone, so i wrote a small script to illustrate the idea. Here's an example: example :: Graph String example = buildGraph $ do a <- mkNode "A" [] b <- mkNode "B" [a] mkNode "C" [a, b] In this graph there are three nodes identified by ["A", "B", "C"] and three edges ([("A", "B"), ("A", "C"), ("B", "C")]). Think of the variables a and b as outputs of the nodes "A" and "B". Note that each node identifier needs to be mentioned only once. Also the definition of edges (references to other nodes via the outputs) can be checked at compile time. The attachment is a little script that defines a Graph-type (nothing elaborate), the "buildGraph" function and an example graph that is a little more complex than the above. The main function of the script prints the example graph to stdout to be read by dot (or similar). By the way, it is possible to define cyclic graphs using mdo (RecursiveDo). I haven't come across something similar, so i thought, i'd share it. What do you think? S?nke -------------- next part -------------- A non-text attachment was scrubbed... Name: Graph-Monads.hs Type: text/x-haskell Size: 1930 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091212/f598e52b/Graph-Monads.bin From johann.hoechtl at gmail.com Sat Dec 12 16:37:50 2009 From: johann.hoechtl at gmail.com (=?ISO-8859-1?Q?Johann_H=F6chtl?=) Date: Sat Dec 12 16:12:00 2009 Subject: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap In-Reply-To: References: Message-ID: <69323e21-693a-41f8-9a42-e7a7f18ca683@u7g2000yqm.googlegroups.com> On Dec 12, 7:13?pm, Jason Dagit wrote: > Hi Heinrich, > > On Sat, Dec 12, 2009 at 2:42 AM, Heinrich Apfelmus < > > > > apfel...@quantentunnel.de> wrote: > > Jason Dagit wrote: > > > My next experiment will be to find ways to express "take this operation > > and > > > apply it to a stream without letting the stream leak". One implication is > > > that gzReadFilePS should not be used outside of a core set of modules > > which > > > have been auideted to be resource concious. ?Another implication is that > > we > > > need to be really careful about wether or not we allow returning of > > > sequences of patches. ?Possibly, we need several foldl-like functions > > that > > > open the stream internally. ?For example, to process the pending maybe we > > > should have: > > > withPending :: (a -> Patch -> a) -> ?IO a > > > > And withPending would start the streaming and make sure that the stream > > > cannot be visible as a data dependency outside of withPending. > > > Just a small comment on a potential flaw in this scheme and the > > observation that even the rank-2 type trick from the ?ST s ?monad > > wouldn't help. > > I would say it does help, but it doesn't make it perfect. > > > > > Namely, ?withPending ?does not guarantee that the stream does not leak, > > it only makes it more natural/convenient to formulate one's code so that > > it doesn't leak. In particular, using ?(:) ?as argument pretty much > > defeats the whole purpose: > > Right. ?And the iteratee library points out that your iteratees have to be > well-behaved (I think there they say "bounded"). ?I'm well aware of this > issue and thanks for pointing it out for others who are reading along. > > > > > > > ? withPending (flip (:)) > > > Fortunately, the type system can ensure that the patches don't leak. > > > ? withPending :: (forall s. a -> Patch s -> a) -> IO a > > > Now, ?a ?may not mention ?s ?and the type checker will reject ?flip (:) > > ?as argument. See also > > > ?Oleg Kiselyov, Chung-chieh Shan. > > ?Lightweight Monadic Regions. > > ?http://www.cs.rutgers.edu/~ccshan/capability/region-io.pdf > > > for an elaboration of this technique. > > I'm still on the fence as to whether this style of writing it will add value > greater than the complexity it brings. ?I am certainly considering it :) > The darcs source does other things that are also fairly complex. > > > > > > > However, the line between leaking and not leaking is very thin here. As > > soon as we are given for example a function > > > ? name :: Patch s -> String > > > that discards the ?s , its results can "leak", in the sense that we > > could now build a list of names > > > ? foo :: IO [String] > > ? foo = withPending . flip $ (:) . name > > > Even worse, any type ?a ?that doesn't have O(1) space usage will "leak" > > > ? bar :: IO [()] > > ? bar = withPending . flip $ const (() :) > > > In other words, exporting only a ?foldl' -like interface does not really > > prevent us from writing functions that have O(n) instead of O(1) space > > usage. But trying to rectify that with the ?forall s ?trick is a doomed > > idea, too. > > I realize it's not perfect, but the problem we have now is that it's too > easy to write things that have dismal space usage. ?If we can't force proper > space usage, how can we make it more natural to have bounded space? ?Or at > least a good approximation. > > It seems that: > ?* foldl'-style helps > ?* rank-n can help > ?* no approach I've seen *forces* the behavior we want > ?* existing code and bug reports demonstrate we need to improve the > situation > > I'm open to suggestions on how to ensure the code has the space behavior I > want. ?Lazy IO* and streams of patches is more compositional and natural to > Haskell programmers, but it seems that it's too hard to ensure the code has > reasonable space usage. ?At least where the darcs source is concerned. > Therefore, I think the status quo demonstrates that in the darcs source it's > worth experimenting with alternatives to lazy io and streams. ?In other > words, the human effort to make the code behave how we want is currently too > high and that's the issue I want to address. ?I don't know how we could make > it impossible to have space leaks, although that would be interesting. > As a beginner to Haskell, I am only 1/3 through RWH, those lines scare me in a sense to question my effort. I simply can not distinguish if this discussion is somewhat pathological in a sense that every access to the outside world imposes dangers and an additional exception handler here and there and an additional if-statement to handle error return codes will suffice. Or lazy evaluation, IO monads and the whole story behind unsafePerformIO was an additional layer of self-deception and unpredictable effects from the outside world and lazy evaluation can NEVER be satisfactory handled. > (*) Note: Lazy IO itself is used in very few places in darcs these days > because it has lead to serious bugs. ?These days me point is more about big > streams getting retained. ?Finding where and why has proven difficult. > > Thanks, > Jason > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe From RafaelGCPP.Linux at gmail.com Sat Dec 12 18:16:44 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Sat Dec 12 17:50:55 2009 Subject: [Haskell-cafe] GHC 6.12 status and features In-Reply-To: <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> References: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> Message-ID: <351ff25e0912121516y38641ce6sd7177708f0127b99@mail.gmail.com> THANKS!! Just in time for Christmas!! On Sat, Dec 12, 2009 at 12:22, Max Bolingbroke wrote: > 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto < > RafaelGCPP.Linux@gmail.com>: > > I know I should probably be asking to the GHC list, but is there any > update > > on 6.12 since October? Any probable release date? > > It looks like haskell.org just acquired this page, though it's not yet > linked to from anywhere else: > > http://haskell.org/ghc/download_ghc_6_12_1.html > > > BTW, is there any feature list for the release? > > http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html > > Cheers, > Max > -- Rafael Gustavo da Cunha Pereira Pinto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091212/4ea93320/attachment.html From dgorin at dc.uba.ar Sat Dec 12 18:24:20 2009 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Sat Dec 12 17:58:38 2009 Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows In-Reply-To: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de> References: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar> Hi, Martin Do you have a complete example one can use to reproduce this behavior? (preferably a short one! :P) In any case, I'm resending your message to the glasgow-haskell-users list to see if a ghc guru recognize the error message. It is strange that the problem only manifests on Windows.... Daniel On Dec 11, 2009, at 7:04 AM, Martin Hofmann wrote: > The following hint code causes GHCi to crash under Windows: > >> runInterpreter $ loadModules ["SomeModule.hs"] > > The error message is: > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol _hs_gtWord64 whilst processing object file > C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0 > HSghc-prim-0.1.0.o > This could be caused by: > * Loading two different object files which export the same symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting now. Sorry. > > The problem does not occur under Unix or with a compiled program. IMHO > hint tries to start a second instance of GHCi which is not > allowed/possible under Windows. If this is the case a more telling > error > message would be helpful. > > I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My > package.conf is: > > C:/Programme/Haskell Platform/2009.2.0.2\package.conf: > Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, > HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1, > QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0, > ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, > bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1, > containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3), > (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), > (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, > fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0, > ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2, > haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4, > haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2, > integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, > old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, > parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0, > process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, > regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, > syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4, > utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0 > > Thanks, > > Martin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dagit at codersbase.com Sat Dec 12 19:07:51 2009 From: dagit at codersbase.com (Jason Dagit) Date: Sat Dec 12 18:42:01 2009 Subject: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap In-Reply-To: <69323e21-693a-41f8-9a42-e7a7f18ca683@u7g2000yqm.googlegroups.com> References: <69323e21-693a-41f8-9a42-e7a7f18ca683@u7g2000yqm.googlegroups.com> Message-ID: On Sat, Dec 12, 2009 at 1:37 PM, Johann H?chtl wrote: > > > On Dec 12, 7:13 pm, Jason Dagit wrote: > > Hi Heinrich, > > > > On Sat, Dec 12, 2009 at 2:42 AM, Heinrich Apfelmus < > > > > > > > > apfel...@quantentunnel.de> wrote: > > > Jason Dagit wrote: > > > > My next experiment will be to find ways to express "take this > operation > > > and > > > > apply it to a stream without letting the stream leak". One > implication is > > > > that gzReadFilePS should not be used outside of a core set of modules > > > which > > > > have been auideted to be resource concious. Another implication is > that > > > we > > > > need to be really careful about wether or not we allow returning of > > > > sequences of patches. Possibly, we need several foldl-like functions > > > that > > > > open the stream internally. For example, to process the pending > maybe we > > > > should have: > > > > withPending :: (a -> Patch -> a) -> IO a > > > > > > And withPending would start the streaming and make sure that the > stream > > > > cannot be visible as a data dependency outside of withPending. > > > > > Just a small comment on a potential flaw in this scheme and the > > > observation that even the rank-2 type trick from the ST s monad > > > wouldn't help. > > > > I would say it does help, but it doesn't make it perfect. > > > > > > > > > Namely, withPending does not guarantee that the stream does not leak, > > > it only makes it more natural/convenient to formulate one's code so > that > > > it doesn't leak. In particular, using (:) as argument pretty much > > > defeats the whole purpose: > > > > Right. And the iteratee library points out that your iteratees have to > be > > well-behaved (I think there they say "bounded"). I'm well aware of this > > issue and thanks for pointing it out for others who are reading along. > > > > > > > > > > > > > withPending (flip (:)) > > > > > Fortunately, the type system can ensure that the patches don't leak. > > > > > withPending :: (forall s. a -> Patch s -> a) -> IO a > > > > > Now, a may not mention s and the type checker will reject flip (:) > > > as argument. See also > > > > > Oleg Kiselyov, Chung-chieh Shan. > > > Lightweight Monadic Regions. > > > http://www.cs.rutgers.edu/~ccshan/capability/region-io.pdf > > > > > > for an elaboration of this technique. > > > > I'm still on the fence as to whether this style of writing it will add > value > > greater than the complexity it brings. I am certainly considering it :) > > The darcs source does other things that are also fairly complex. > > > > > > > > > > > > > However, the line between leaking and not leaking is very thin here. As > > > soon as we are given for example a function > > > > > name :: Patch s -> String > > > > > that discards the s , its results can "leak", in the sense that we > > > could now build a list of names > > > > > foo :: IO [String] > > > foo = withPending . flip $ (:) . name > > > > > Even worse, any type a that doesn't have O(1) space usage will "leak" > > > > > bar :: IO [()] > > > bar = withPending . flip $ const (() :) > > > > > In other words, exporting only a foldl' -like interface does not > really > > > prevent us from writing functions that have O(n) instead of O(1) space > > > usage. But trying to rectify that with the forall s trick is a doomed > > > idea, too. > > > > I realize it's not perfect, but the problem we have now is that it's too > > easy to write things that have dismal space usage. If we can't force > proper > > space usage, how can we make it more natural to have bounded space? Or > at > > least a good approximation. > > > > It seems that: > > * foldl'-style helps > > * rank-n can help > > * no approach I've seen *forces* the behavior we want > > * existing code and bug reports demonstrate we need to improve the > > situation > > > > I'm open to suggestions on how to ensure the code has the space behavior > I > > want. Lazy IO* and streams of patches is more compositional and natural > to > > Haskell programmers, but it seems that it's too hard to ensure the code > has > > reasonable space usage. At least where the darcs source is concerned. > > Therefore, I think the status quo demonstrates that in the darcs source > it's > > worth experimenting with alternatives to lazy io and streams. In other > > words, the human effort to make the code behave how we want is currently > too > > high and that's the issue I want to address. I don't know how we could > make > > it impossible to have space leaks, although that would be interesting. > > > > As a beginner to Haskell, I am only 1/3 through RWH, those lines scare > me in a sense to question my effort. I simply can not distinguish if > this discussion is somewhat pathological in a sense that every access > to the outside world imposes dangers and an additional exception > handler here and there and an additional if-statement to handle error > return codes will suffice. > We're not talking about exception handling :) And yes, Heinrich is talking about pathological cases. > Or lazy evaluation, IO monads and the whole story behind > unsafePerformIO was an additional layer of self-deception and > unpredictable effects from the outside world and lazy evaluation can > NEVER be satisfactory handled. > We're not talking about unsafePerformIO either. The discussion at hand is much simpler. Given a large stream of data, how should you style your code so that it's easy to reason about the space usage? This is an important question in every programming language I've ever used. Also, IO need not enter the discussion except that in darcs the streams of data come from the disk. I think moving the discussion to haskell-cafe was a mistake. I said what I said in a very specific context (that of the darcs developers mailing list), which is likely no longer clear. Sorry for any distress this has caused you. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091212/5e5847de/attachment.html From wren at freegeek.org Sat Dec 12 21:28:59 2009 From: wren at freegeek.org (wren ng thornton) Date: Sat Dec 12 20:57:35 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> Message-ID: <4B24516B.6010400@freegeek.org> Marc Weber wrote: > Hackage is missing one feature: > It is very static. I mean if you have a patch or a question or a comment > you have to lookup the darcs repository, write the patch then contact > the author and wait.. If the author replies everything is fine. > If he doesn't you don't know what to do. And if he does your commitment > still doesn't show up on hackage. > > Using a wiki page for each project enables anybody to add comments.[...] Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. We already have community.haskell.org for authors to host their webpages and Darcs repos. And apparently they offer Trac and MailMan since last I checked. It seems to me that the proper place to offer services like wikis (Trac has one) and task trackers (Trac has one of those too) is through the community.haskell.org server. These services are essential for project maintinence, but Hackage doesn't seem like the right place for adding them. Rather than giving Hackage wikis, perhaps it would be better to point more people towards community.haskell.org and maybe increase the options offered there (in case people dislike Trac). One simple improvement to Hackage which would be nice and which would integrate well with community.haskell.org is if there were additional (optional) fields added to give urls for the wiki and task tracker separately from the main project homepage. Naturally, the homepage should have links to the wiki and tracker as well, but having direct links from Hackage would lower the cost for users to find out where they can post patches, comments, etc. -- Live well, ~wren From tphyahoo at gmail.com Sat Dec 12 21:34:00 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Dec 12 21:08:10 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <1260575495-sup-9064@nixos> References: <1260575495-sup-9064@nixos> Message-ID: <910ddf450912121834g6591ea2awfae2f42186557990@mail.gmail.com> patch-tag.com has wikis now. They are some buggy behaviors I still need to address so I haven't blogged or otherwise drawn attention to it (arrrg) but my hope is that, quite soon, this will be quite slick and quite useful. 2009/12/11 Marc Weber > hackage is success because: > a) many (most) people do use it (by uploading packages) > b) it is a comprehensive list of availible packages if not the most > comprehensive one > > Duncan, can you write about your concerns briefly why some maintainers may > dislike > this idea ? > > Hackage is missing one feature: > It is very static. I mean if you have a patch or a question or a comment > you have to lookup the darcs repository, write the patch then contact > the author and wait.. If the author replies everything is fine. > If he doesn't you don't know what to do. And if he does your commitment > still doesn't show up on hackage. > > Using a wiki page for each project enables anybody to add comments. > I'm thinking about this kind of comments: > > "Interlude doesn't work for me. It looks like the interlude.h file > passes a tuple to the reportError function which doesn't expect a tuple. > You can fix it by removing the "," in the .h file. > Try this patch: > > http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch > " > > Of course I mailed the author. Looking at the package again I noticed > that it was uploaded by someone else: GwernBranwen. > gwern on #haskell told me that the author is responsive so I'll just > wait some days, but others will try and fail as well. > If the other person is new to haskell he may not find the fix > fast. He just wants to know which of the heads is causing trouble.. > > Another use case would be users adding > "If you're interested in this topic also have a look at XXX" > > Yet another use case is someone figuring out that function X was removed > in version Y. He could than add a note > > x vanished since v.10 and everybody who wants to update cabal dependency > constraints doesn't have to download the darcs repo to figure out that > he should use package <= v.10 . > > Of course contents of wiki pages may be totally wrong because the > contents were written by people knowing the package less than the > maintainers and authors. But everyone knows this and will take care. > > This wiki can server as fail over if the maintainer is on holiday. > > This wiki page will prevent people blogging about packages and benchmark > results anywhere on the internet. So it's much more likely that this > information is read and maintained. > If you use google to look for bug fixes or such you may have success. > But very often you end up reading pages dated 3 years ago which are > outdated. > > This wiki page would be I simple effective way letting users annotate > packages. > > Costs: Make hackage add one link. > It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg > This link should point to the existing haskell wiki on haskell.org: > http://haskell.org/haskellwiki/project-name-without-version > > > Even if the maintainer is availible 24/h a day he won't upload a new > minor version to hackage for each change. But maybe he'll paste a small > note that the darcs repo is more up to date fixing issue x/y. > You don't want to upload a new version because you added some > documentation. > Why don't you want to do that ? > It's because hackage will keep every version which was uploaded once by > design. Having 50 versions of one package just causes much more work for > tools such as cabal install or hack-nix. Figuring out a solution to > install all packages is hard enough. > > Maintainers can create the wiki page and subscribe to change > notifications. So I don't think it'll be that much work for them to keep > an eye on those wiki pages. > > How do you think about it? > It's about centralizing information and saving your and my time. > Many packages aready do have a wiki page. So why not make it easier for > all to add one? > > Thoughts ? > > Currently my goal is updating some common packages so that they use > extensible exceptions and base4. > But when working on some patches I'd like to tell people that I'm doing > so. I can't in an easy way. That's why I'm starting this thread. > > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091212/0aedc534/attachment.html From marco-oweber at gmx.de Sat Dec 12 21:42:47 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Dec 12 21:17:17 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <4B24516B.6010400@freegeek.org> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> Message-ID: <1260671327-sup-3205@nixos> Hi Wren, Thank you for taking the time for replying. Can you reread the wiki section labeled "implementation details"? I don't want hackage to be the wiki. I only want hackage to host a link to the wiki. There maybe reasons to host the wiki on hackage. Eg hackage does know when a package get's updated. Thus it could update some information on the wiki automatically. But it could do so on the community server as well. I proposed reusing the existing haskell.org/haskellwiki. If all features of the wiki are use its fine. The main idea is provide some minimal editable content so that you don't have to upload new cabal packages because of some small changes. > One simple improvement to Hackage which would be nice and which would > integrate well with community.haskell.org is if there were additional > (optional) fields added to give urls for the wiki and task tracker > separately from the main project homepage. EvanMartin asked for this wiki: field feature as well. Do you think changing the homepage field to contain a list would suffice? Or do you feel having an explicit wiki field is preferable? > should have links to the wiki and tracker as well, but having direct > links from Hackage would lower the cost for users to find out where they > can post patches, comments, etc. Yes. That's one main point. Hackage is the entry point many users find. It's kind of standard. But hackage itself is too static. Uploading a new .cabal file is not the perfect way to add a link to a blog post or such. The easiest idea I came up was provide a link to the haskell.org/haskellwiki. The second thought I had in mind was "Don't spend too much time on this". Anyway I feel this is important. So may I ask you to add the alternative that the community server can be used equally well to the wiki page? http://haskell.org/haskellwiki/?title=Hackage_wiki_page_per_project_discussion&action=edit Keep in mind that if we host the wiki pages on haskell.org they are found by the haskell.org search. Marc Weber From semanticphilosopher at googlemail.com Sun Dec 13 04:08:52 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Sun Dec 13 03:43:07 2009 Subject: [Haskell-cafe] writing graphs with do-notation In-Reply-To: <200912122200.40692.shahn@cs.tu-berlin.de> References: <200912122200.40692.shahn@cs.tu-berlin.de> Message-ID: <0E9C3366-3286-4B06-BFB4-D4D2E94B9F02@gmail.com> Neat Surely there is somewhere in the haskell Twiki that something like this should live? Neil On 12 Dec 2009, at 21:00, Soenke Hahn wrote: > Hi! > > Some time ago, i needed to write down graphs in Haskell. I wanted to > be able > to write them down without to much noise, to make them easily > maintainable. I > came up with a way to define graphs using monads and the do > notation. I thought > this might be interesting to someone, so i wrote a small script to > illustrate > the idea. Here's an example: > > example :: Graph String > example = buildGraph $ do > a <- mkNode "A" [] > b <- mkNode "B" [a] > mkNode "C" [a, b] > > In this graph there are three nodes identified by ["A", "B", "C"] > and three > edges ([("A", "B"), ("A", "C"), ("B", "C")]). Think of the variables > a and b > as outputs of the nodes "A" and "B". Note that each node identifier > needs to be > mentioned only once. Also the definition of edges (references to > other nodes > via the outputs) can be checked at compile time. > > The attachment is a little script that defines a Graph-type (nothing > elaborate), the "buildGraph" function and an example graph that is a > little > more complex than the above. The main function of the script prints > the > example graph to stdout to be read by dot (or similar). > > By the way, it is possible to define cyclic graphs using mdo > (RecursiveDo). > > I haven't come across something similar, so i thought, i'd share it. > What do > you think? > > S?nke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From apfelmus at quantentunnel.de Sun Dec 13 05:53:57 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Sun Dec 13 05:28:30 2009 Subject: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap In-Reply-To: References: <69323e21-693a-41f8-9a42-e7a7f18ca683@u7g2000yqm.googlegroups.com> Message-ID: Jason Dagit wrote: > Johann H?chtl wrote: >> >> As a beginner to Haskell, I am only 1/3 through RWH, those lines scare >> me in a sense to question my effort. I simply can not distinguish if >> this discussion is somewhat pathological in a sense that every access >> to the outside world imposes dangers and an additional exception >> handler here and there and an additional if-statement to handle error >> return codes will suffice. >> > > We're not talking about exception handling :) And yes, Heinrich is talking > about pathological cases. > > >> Or lazy evaluation, IO monads and the whole story behind >> unsafePerformIO was an additional layer of self-deception and >> unpredictable effects from the outside world and lazy evaluation can >> NEVER be satisfactory handled. >> > > We're not talking about unsafePerformIO either. > > The discussion at hand is much simpler. Given a large stream of data, how > should you style your code so that it's easy to reason about the space > usage? This is an important question in every programming language I've > ever used. Also, IO need not enter the discussion except that in darcs the > streams of data come from the disk. I think moving the discussion to > haskell-cafe was a mistake. I said what I said in a very specific context > (that of the darcs developers mailing list), which is likely no longer > clear. > > Sorry for any distress this has caused you. Ah, I didn't mean to cause distress to anyone by cross-posting to the caf?. I just thought that a discussion "Is there a style of writing Haskell that makes it easy to ensure bounded space usage?" could be of general interest. Johann, don't worry, lazy evaluation is awesome. :) See for example http://apfelmus.nfshost.com/quicksearch.html It's just that laziness not a free lunch; predicting memory ("space") usage does become more difficult. Which is not really surprising since deferring the evaluation of thunks until they are demanded also means that they will store different expressions of possibly different sizes before and after they are demanded. Classic examples are ones = 1:ones taking O(1) memory instead of an infinite amount and foldl (+) 0 [1..n] taking O(n) memory as opposed to foldl' (+) 0 [1..n] which only takes O(1) memory. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From ketil at malde.org Sun Dec 13 06:16:59 2009 From: ketil at malde.org (Ketil Malde) Date: Sun Dec 13 05:51:04 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <4B24516B.6010400@freegeek.org> (wren ng thornton's message of "Sat, 12 Dec 2009 21:28:59 -0500") References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> Message-ID: <87eimzi0no.fsf@malde.org> wren ng thornton writes: >> Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. > Because of Duncan's concerns about imposing too much burden on > authors, and because there are many mature projects which already have > wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. Other packages are orphaned or see little interest from their author. > We already have community.haskell.org for authors to host their > webpages and Darcs repos. [..] > Rather than giving Hackage wikis, > perhaps it would be better to point more people towards > community.haskell.org and maybe increase the options offered there (in > case people dislike Trac). This is great, but I view this as a different issue. -k -- If I haven't seen further, it is by standing in the footprints of giants From apfelmus at quantentunnel.de Sun Dec 13 06:47:01 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Sun Dec 13 06:21:33 2009 Subject: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap In-Reply-To: References: Message-ID: Jason Dagit wrote: >>> withPending :: (a -> Patch -> a) -> IO a >>> >>> And withPending would start the streaming and make sure that the stream >>> cannot be visible as a data dependency outside of withPending. > > [...] > > Heinrich Apfelmus wrote: >> >> In other words, exporting only a foldl' -like interface does not really >> prevent us from writing functions that have O(n) instead of O(1) space >> usage. But trying to rectify that with the forall s trick is a doomed >> idea, too. > > I realize it's not perfect, but the problem we have now is that it's too > easy to write things that have dismal space usage. If we can't force proper > space usage, how can we make it more natural to have bounded space? Or at > least a good approximation. > > It seems that: > * foldl'-style helps > * rank-n can help > * no approach I've seen *forces* the behavior we want > * existing code and bug reports demonstrate we need to improve the > situation Yep, I agree completely; except for the rank-n (rank-2) trick where I'm more pessimistic. I think rank-2 works fine for things like ensuring that file handles are closed properly. But for the purpose of ensuring O(1) space usage, I think that withPending . flip $ const (() :) demonstrates that rank-2 is not worth the complexity they bring. Still, the idea of tracking resource usage in the type system is attractive. > I'm open to suggestions on how to ensure the code has the space behavior I > want. I've got another, unfinished idea: >> Namely, withPending does not guarantee that the stream does not leak, >> it only makes it more natural/convenient to formulate one's code so that >> it doesn't leak. In particular, using (:) as argument pretty much >> defeats the whole purpose: > > Right. And the iteratee library points out that your iteratees have to be > well-behaved (I think there they say "bounded"). I'm well aware of this > issue and thanks for pointing it out for others who are reading along. How about tracking the requirement of "bounded" in the type system? In particular, I'm thinking of a type class class NFData a => Small a where the idea is that all types that can be stored in constant space are members of this class. For example, we have instance Small () instance Small Int instance Small Char instance (Small a, Small b) => Small (a,b) instance (Small a, Small b) => Small (Either a b) but recursive types like [a] or String are not allowed to be members. Then, withPending :: Small a => (a -> Patch -> a) -> IO a which is based on the function foldlSmall :: Small b => (b -> a -> b) -> b -> [a] -> b foldlSmall f b [] = foldlSmall f b (x:xs) = foldlSmall f b' xs where b' = rnf (f b x) is pretty much guaranteed to run in O(1) space. Well, that depends on f , but the point is it's not foldlSmall who introduces the space leak, it's the argument that takes all the blame. > In other words, the human effort to make the code behave how we want is > currently too high and that's the issue I want to address. I don't know how > we could make it impossible to have space leaks, although that would be > interesting. I opine that aiming for the latter (making space leaks impossible) while experimenting brings you closer to the actual goal (making them easy to avoid) when it comes to putting these experiments into practice. But that's just me. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From bertram.felgenhauer at googlemail.com Sun Dec 13 06:57:07 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun Dec 13 06:31:22 2009 Subject: [Haskell-cafe] Are there standard idioms for lazy, pure error handling? In-Reply-To: <1259578923.4896.85252.camel@localhost> References: <3283f7fe0911292122k6b6aed0i21621d59591463cd@mail.gmail.com> <1259578923.4896.85252.camel@localhost> Message-ID: <20091213115707.GA2199@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Duncan Coutts wrote: > Another approach that some people have advocated as a general purpose > solution is to use: > > data Exceptional e a = Exceptional { > exception :: Maybe e > result :: a > } > > However it's pretty clear from the structure of this type that it cannot > cope with lazy error handling in sequences. If you try it you'll find > you cannot do it without space leaks. It's not all that clear. Consider this toy example (from a private discussion with Henning Thielemann a while ago), which runs in constant space: import System.IO.Unsafe import System.Environment import Control.Monad import Data.List data Exceptional e a = Exceptional { exception :: Maybe e, result :: a } ok a = Exceptional Nothing a fault e a = Exceptional (Just e) a faulty :: Int -> IO (Exceptional Int [Int]) faulty 0 = return (fault 0 []) faulty 1 = return (ok []) faulty n = unsafeInterleaveIO $ do -- getChar r <- faulty (n-2) return $ Exceptional (exception r) (n : result r) main = do n <- readIO . head =<< getArgs Exceptional exc res <- faulty n print $ last res when (n `mod` 3 == 0) $ print exc This works because ghc's garbage collector evaluates record selectors. (There are a simpler cases where this matters, for example last $ fst $ unzip [(a,a) | a <- [1..100000000]] which also runs in constant space.) The approach is very fragile, though. For example, if we change main to main = do n <- readIO . head =<< getArgs f <- faulty n print $ last (result f) when (n `mod` 3 == 0) $ print (exception f) then the space leak reoccurs - doing the pattern match on the Excpeptional constructor before using the result is essential. Bad things also happen if ghc's optimiser turns the record selectors into explicit pattern matches in the worker ('faulty' in the example). Kind regards, Bertram From cimarosti at gmail.com Sun Dec 13 07:00:32 2009 From: cimarosti at gmail.com (Adam Cimarosti) Date: Sun Dec 13 06:34:43 2009 Subject: [Haskell-cafe] GHC 6.12 status and features In-Reply-To: References: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> Message-ID: <71004E66-00D0-4841-B2C1-980710999B9F@gmail.com> WIth 6.10.4 there's a major bug with Snow leopard: It doesn't work (Cannot compile 64-bit). Is this fixed in the new release? Adam On 12 Dec 2009, at 17:32, Tom Tobin wrote: > On Sat, Dec 12, 2009 at 8:22 AM, Max Bolingbroke > wrote: >> 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto > >: >>> I know I should probably be asking to the GHC list, but is there >>> any update >>> on 6.12 since October? Any probable release date? >> >> It looks like haskell.org just acquired this page, though it's not >> yet >> linked to from anywhere else: >> >> http://haskell.org/ghc/download_ghc_6_12_1.html > > Aw, no OS X package yet ... :-) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From stephen.tetley at gmail.com Sun Dec 13 07:46:54 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sun Dec 13 07:21:04 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <87eimzi0no.fsf@malde.org> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> <87eimzi0no.fsf@malde.org> Message-ID: <5fdc56d70912130446i46d5b519n761803b4f499f371@mail.gmail.com> Hello everyone, Could a new mailing list for patches and/or commentary do the work of the proposed package Wikis? Similar to the libraries list but separate so it doesn't pollute the libraries list from its important job of discussing and refining the core libs. >From my perspective, mails have two useful and apparent properties - messages are authored and time stamped, and viewing the list through Gmane or whatever would allow people to keep up to date without burdening their inboxes. With a Wiki the authorship and time stamp are deep within the history - on a Wiki, one would expect people to be respectful, but you never know. Also my personal feeling is that Wiki comments would go the way of (elaborate) source code comments - vis the old chestnut "Are out of date comments, better than no comments?" Best wishes Stephen From wren at freegeek.org Sun Dec 13 07:54:04 2009 From: wren at freegeek.org (wren ng thornton) Date: Sun Dec 13 07:22:37 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <87eimzi0no.fsf@malde.org> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> <87eimzi0no.fsf@malde.org> Message-ID: <4B24E3EC.9090504@freegeek.org> Ketil Malde wrote: > wren ng thornton writes: > >>> Using a wiki page for each project enables anybody to add comments.[...] > > I think this is a great idea. > >> Because of Duncan's concerns about imposing too much burden on >> authors, and because there are many mature projects which already have >> wikis etc, I have a counter-proposal. > > I don't this this is the same thing. Marc's proposal would provide a > scratch pad for random users to discuss or comment on various stuff on > Hackage. At least the way I see it, it is primarily *not* for use by > the author, and in fact most useful when the author is not around to > actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. My interpretation of Duncan's concern ---not meaning to put words in his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. I understand that y'all think giving users a place for feedback is different than giving authors the tools to communicate with their users, but I don't think they're all that different. Why not push for authors to have a section of their wikis devoted to users' notes? That would have the same effect of allowing users to speak out without fracturing each project's community. Institutionalizing a place for users to make comments separate from the authors' resources can't be a good thing. It sets up a community divide between users and authors. It can confuse new users who can't figure out which to go to for official answers. It can cause users to just post their fixes rather than trying to contact the maintainers. Etc. I can't think of any way this separation could lead to good for any project's community. > E.g. my package that was used as an example, while (arguably) useful, is > way to small for me to bother with setting up a full site with web pages > or bug trackers, etc. So someone else should set them up for you? I don't get it. Either you want ways to communicate with your users or you don't. If it's just a matter of not wanting to do the work *yourself*, then I'm back to my previous post. The community server (or similar hosts) should make it trivial to set things up. I think it only takes one command to set up Trac on community.haskell.org. The only thing I can think might need changing is if the community server only allows per-project Trac instances instead of also having per-user instances so someone can have a single one for all their little projects. If they don't offer per-user instances (I haven't checked) then I'm all for adding them. > Other packages are orphaned or see little > interest from their author. That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? We have a long history of community-based maintenance for the main libraries that (used to) ship with GHC. It may not be the best model, but it should suffice for keeping the cobwebs off. I don't have anything against wikis, nor against Hackage having links to wikis. But I don't think Hackage is the right place for hosting the wikis themselves. This has the distinct feel of trying to legislate community into existence. But community isn't something you can legislate. Adding things to try to force community building just leads to bloated web-interfaces and trivializes the communities that do exist. There are a number of project hosts that have gone down this route, and it leads to ghettoization and abandoned projects with lots of infrastructure around their carcasses. The more forced overhead there is the more people will decide not to post their small projects, and the more quickly they'll abandon them if they do post. The thing I've liked most about Hackage is that it's like CPAN but moreso. CPAN is an excellent resource, but it has a few sticking points that make the barrier to entry and the cost of posting higher than they should be. Places like SourceForge or GoogleCode have very high barriers to entry, but they're going after a different audience. I think we want to emulate CPAN more than SF, for the sake of growing a wide collection of libraries. -- Live well, ~wren From marco-oweber at gmx.de Sun Dec 13 08:02:13 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Dec 13 07:36:42 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <4B24E3EC.9090504@freegeek.org> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> <87eimzi0no.fsf@malde.org> <4B24E3EC.9090504@freegeek.org> Message-ID: <1260708978-sup-2920@nixos> Excerpts from wren ng thornton's message of Sun Dec 13 13:54:04 +0100 2009: > Ketil Malde wrote: > > wren ng thornton writes: > > > >>> Using a wiki page for each project enables anybody to add comments.[...] > > > > I think this is a great idea. > > > >> Because of Duncan's concerns about imposing too much burden on > >> authors, and because there are many mature projects which already have > >> wikis etc, I have a counter-proposal. > > > > I don't this this is the same thing. Marc's proposal would provide a > > scratch pad for random users to discuss or comment on various stuff on > > Hackage. At least the way I see it, it is primarily *not* for use by > > the author, and in fact most useful when the author is not around to > > actively support his project. > > But if it's a wiki, wouldn't people be able to add changes themselves? > Isn't that the idea behind wikis? Sure, the authors could lock down > their wikis, but I don't get the feeling that many would. > > My interpretation of Duncan's concern ---not meaning to put words in his > mouth--- is that adding a Hackage wiki could place undue burden on the > authors. If authors already have a wiki, then a Hackage wiki is just an > extra place to check for feedback which will be prone to duplication and > being out-of-date. Indeed I didn't want hackage to host the wiki. I only want hackage to host the link to the wiki page. If this burden exist can we make it smaller by using a wiki which can send emails to the author (or the dev mailinglists) whenever there is a change? Then authors don't have to poll the wiki pages themselves. Anyway I feel this is going nowhere. The people which may benefit a lot are beginners. I learned that there are some maintainers who do follow Duncan's concerns. So let me start a last thread on beginners@haskell.org. If they all say they fear outdated content more than they appreciate nice howtos or bugfixes which haven't been uploaded yet I'll forget about this idea and shut up. comparison to haskell.org/haskellwiki ===================================== Let's not forget that haskell.org is a nice source of information. It's a wiki as well. What makes haskell.org/haskellwiki (all other pages) that much different from what I propose? Let's wait and see what beginners think. Thank you very much for participating Marc Weber From ketil at malde.org Sun Dec 13 08:12:22 2009 From: ketil at malde.org (Ketil Malde) Date: Sun Dec 13 07:46:27 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <4B24E3EC.9090504@freegeek.org> (wren ng thornton's message of "Sun, 13 Dec 2009 07:54:04 -0500") References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> <87eimzi0no.fsf@malde.org> <4B24E3EC.9090504@freegeek.org> Message-ID: <87aaxnhvbd.fsf@malde.org> wren ng thornton writes: > Ketil Malde wrote: >> At least the way I see it, it is primarily *not* for use by >> the author, and in fact most useful when the author is not around to >> actively support his project. > But if it's a wiki, wouldn't people be able to add changes themselves? > Isn't that the idea behind wikis? Sure, the authors could lock down > their wikis, but I don't get the feeling that many would. (I'm sorry, you are correct of course, but I don't see how this applies to any of what I wrote?) > his mouth--- is that adding a Hackage wiki could place undue burden on > the authors. If authors already have a wiki, then a Hackage wiki is > just an extra place to check for feedback which will be prone to > duplication and being out-of-date. So if there's already a wiki, the author is "forced" to put a link on the Hackage to his own Wiki (unless it is automated from links in the .cabal file). If there isn't one, we get one. > I understand that y'all think giving users a place for feedback is > different than giving authors the tools to communicate with their > users, but I don't think they're all that different. This is all assuming there *is* an author. I don't see your objections as very convincing - there is a ton of projects, libraries etc on Hackage. How many even have home pages? Bug trackers? That are updated? And: how many discontinued or orphaned or deprecated projects have updated home pages that point the user in a sensible direction? >> E.g. my package that was used as an example, while (arguably) useful, is >> way to small for me to bother with setting up a full site with web pages >> or bug trackers, etc. > So someone else should set them up for you? No, someone else should set it up for *them*. You can't seriously mean that an auto-generated wiki page puts a "burden" on authors, while at the same time suggest that the authors have a duty to provide all kinds of supporting infrastructure. For projects they are no longer interested in? > Either you want ways to communicate with your users or you don't. The problem is when I don't. >> Other packages are orphaned or see little interest from their author. > That's a separate issue isn't it? Why not have an adopt-a-package > program where the community determines which packages are orphaned and > sets up and maintains wikis and other resources for them until a new > maintainer can be found? You know, this is a great idea! And a great starting point would be a wiki, with a page for each library where information about it can be recorded by users as and when it is discovered. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From stephen.tetley at gmail.com Sun Dec 13 08:31:08 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sun Dec 13 08:05:16 2009 Subject: [Haskell-cafe] What about adding a wiki for each haskell project? In-Reply-To: <87aaxnhvbd.fsf@malde.org> References: <1260575495-sup-9064@nixos> <694519c50912120741p3ee5a4a9s3a97407b32bf3588@mail.gmail.com> <4B24516B.6010400@freegeek.org> <87eimzi0no.fsf@malde.org> <4B24E3EC.9090504@freegeek.org> <87aaxnhvbd.fsf@malde.org> Message-ID: <5fdc56d70912130531ycebebc9x43f58f3d4bc75f73@mail.gmail.com> 2009/12/13 Ketil Malde : > wren ng thornton writes: > >> That's a separate issue isn't it? Why not have an adopt-a-package >> program where the community determines which packages are orphaned and >> sets up and maintains wikis and other resources for them until a new >> maintainer can be found? > > You know, this is a great idea! ?And a great starting point would be a > wiki, with a page for each library where information about it can > be recorded by users as and when it is discovered. :-) > I'm sure there was a page on haskell.org before it moved to the wiki for this. Of course, now with orphan in my search string I only get references to orphan instances. Best wishes Stephen From phil at beadling.co.uk Sun Dec 13 13:09:34 2009 From: phil at beadling.co.uk (Philip Beadling) Date: Sun Dec 13 12:43:36 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: References: <1260586642.3898.9.camel@phil-desktop> <1260612497.2575.13.camel@picard> Message-ID: <1260727774.3898.104.camel@phil-desktop> On Sat, 2009-12-12 at 13:46 +0000, Ben Millwood wrote: > On Sat, Dec 12, 2009 at 10:08 AM, Maciej Piechotka > wrote: > > If operation is associative it can be done using divide et impera > > spliting list in half and operating on it pararerlly then split in half > > etc. > Thank you very much for the replies. I've come to the conclusion that, yep, you can't (directly) parallelise of fold operation, as fold guarantees order of processing. With something like map the runtime is free to continue sparking function application to each element without waiting for the result. So we spark f x, force evaluation of the remainder of the xs and recurse. I'm *guessing* at a detailed level when we are creating the output list, haskell can concat each result element before f x returns due to laziness - that is, haskell doesn't need to wait for evaluation of f x, before continuing? With fold, and specifically with foldl (+), this isn't the case as (+) is strict on both arguments and thus it cannot continue until each sparked evaluation has completed and combined with the accumulator. If (+) was not strict on both arguments, I'm not sure if could solider on... assuming I've understood map correctly!? Writing it out long hand (sorry if this is tedious!), we have: using :: a -> Strategy a -> a using x s = s x `seq` x rwhnf :: Strategy a rwhnf x = x `seq` () parList :: Strategy a -> Strategy [a] parList strat [] = () parList strat (x:xs) = strat x `par` (parList strat xs) parMap :: Strategy b -> (a -> b) -> [a] -> [b] parMap strat f = (`using` parList strat) . map f 'using' applies a strategy to an item, and then returns the item. 'parList' is a (combinator) strategy which applies an atomic strategy to each element in the list *in parallel* (for example forcing each element to WHNF). So for parMap we have xs passed into 'map f' - the result is then passed to 'using' which will force application of 'f' on each element in parallel by way of 'parList'. No forced evaluation is dependant on a previous evaluation. Now for parFoldl - a crude and wrong representation for my purposes could be: parFoldl :: Num b => Strategy b -> (a -> b) -> [a] -> b parFoldl strat f = sum . (`using` parList strat) . map f This isn't really a fold of course, but it is doing roughly the same thing, it's summing the results of applying function 'f' to each element in a list. The problem here is that sum will only allow one spark at a time, because sum [] = 0 sum (x:xs) = x + sum xs So we get something like: 0 + (x4 + (x3 + (x2 + (x1)))) For example the result for (x4 + previous) can only be evaluated after x3, x2 and x1 have been evaluated. This means it won't spark evaluation on x4 until (x3 + ....) has been evaluated, thus only one core is ever used. I believe fold is just the general case of sum and the same logic applies. I suppose my questions are: Have I got this right, if not very succinct!? Is it purely the strictness of (+) that causes this situation? Ignoring DPH, is it possible to write a parallel fold avoiding something like the technique below? Anyhow, a workaround similar to those suggested I came up with is to divide the folds up across the cores and then sum the sub-folds - this produces approximately double the performance across two cores: import Control.Parallel.Strategies (parMap,rwhnf) import Data.List (foldl') import Data.List.Split (chunk) import GHC.Conc (numCapabilities) -- Prepare to share work to be -- done across available cores chunkOnCpu :: [a] -> [[a]] chunkOnCpu xs = chunk (length xs `div` numCapabilities) xs -- Spark a fold of each chunk and -- sum the results. Only works because -- for associative folds. foldChunks :: ([a] -> a) -> (a -> b -> a) -> a -> [[b]] -> a foldChunks combineFunc foldFunc acc = combineFunc . (parMap rwhnf $ foldl' foldFunc acc) -- Some pointless work to keep thread busy workFunc :: Int -> Int workFunc 1 = 1 workFunc x = workFunc $ x - 1 -- Do some work on element x and append foldFunc :: Int -> Int -> Int foldFunc acc x = acc + workFunc x testList = repeat 1000000000 answer = foldChunks sum foldFunc 0 $ chunkOnCpu (take 50 testList) main :: IO() main = print answer From korpios at korpios.com Sun Dec 13 13:32:40 2009 From: korpios at korpios.com (Tom Tobin) Date: Sun Dec 13 13:06:50 2009 Subject: [Haskell-cafe] GHC 6.12 status and features In-Reply-To: <71004E66-00D0-4841-B2C1-980710999B9F@gmail.com> References: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> <9d4d38820912120622y6e2c7b1enc5cd424ea39edf7f@mail.gmail.com> <71004E66-00D0-4841-B2C1-980710999B9F@gmail.com> Message-ID: On Sun, Dec 13, 2009 at 6:00 AM, Adam Cimarosti wrote: > WIth 6.10.4 there's a major bug with Snow leopard: It doesn't work (Cannot > compile 64-bit). Well, it works as long as you apply a workaround and have universal (combo 32/64-bit) libraries available ? albeit it would be much nicer to have 64-bit support. From ok at cs.otago.ac.nz Sun Dec 13 17:13:37 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Dec 13 16:48:31 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <200912101500.42070.daniel.is.fischer@web.de> <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> Message-ID: <5549CA88-F987-43F8-B8FA-A76533324701@cs.otago.ac.nz> I too thought of using NBSP as a word separator. Unicode is replete with spaces of various widths and usages. I suggest, however, that Haskell code does tend to require careful reading, and that ambiguities (like the word boundaries that baStudlyCapsMakesSoHardToLocateQuickly) that we might tolerate in contexts where the text is fairly predictable are far less tolerable in stuff that requires a close reading. One of the problems with baStudlyCaps is that it can give Stress to the wrong words. Take takeWhile as an example. The "while" bit is humanly recoverable because a function follows it. The thing that you most need to see is "take". But it's the least informative part of the name (While) that is stressed. The "visible blank" U+2423 (Unicode calls it an "Open Box", but its function is to visibly indicate a blank) might?just?do, but you might as well use underscores (or hyphens). From ok at cs.otago.ac.nz Sun Dec 13 18:24:28 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Dec 13 17:58:39 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <5f271a760912110237w254d8499q8a42216842a50ac@mail.gmail.com> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <5f271a760912110237w254d8499q8a42216842a50ac@mail.gmail.com> Message-ID: On Dec 11, 2009, at 11:37 PM, Johannes Laire wrote: > On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe > wrote: >> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that >> went into Haskell forNoApparentReasonThatIHaveEverHeardOf > > Compare: > > someCoolFunc fstParam sndParam fooBarBazQuux > some_cool_func fst_param snd_param foo_bar_baz_quux > > In the first one, it's easy to see that there are 4 identifiers. But, > at least for me, the second one is significantly harder to read; > spaces and underscored are too similar. To me the gaps in the second one were clear and distinct. In any case, it's not clear that you *need* to "see that there are 4 identifiers". You need to see the *first* identifier, and then you need to see the second, &c, but let's face it, how often do you need to count the words in a sentence at a glance? And what good does it do to know there are four identifiers if you have to go back with a magnifying class to tell what the identifiers mean? I wrote a little program to search for runs of identifiers without intervening newlines or other tokens. I fed it 56,322 lines of Haskell from various sources. Here's the distribution: Len Tally iCap iCap is the average number of internal 1 84,474 0.21 capital letters in all of the words in 2 27,092 0.32 a run. 3 9,273 0.44 4 3,176 0.45 5 866 0.49 6 165 0.47 7 87 0.36 8 98 0.73 9 42 0.36 10 9 0.22 11 5 0.20 12 7 0.71 13 1 0.00 The longest run was "j then Q i xs ys j else Q j ys xs i" which would be the same under any word separation variant. We see from the "iCap" column that on the whole, the average number of internalCapitals per run is less than one. Looking in some detail at the runs with 4 words, I found that the typical pattern is someHairyGreatFunctionName i x xs with a touch of if okToProceedWith x then In fact, out of 3,176 runs with four words, 2,144 of them didn't have any internal capitals in the first place, so would not be at all affected by a change in word separation style. Having examined the remaining 1032 cases with some care, I honestly couldn't find any cases whose readability was worsened by by underscore separation. Don't forget, some of the arguments are constructors, and using underscore (or hyphen) separation makes it *easier* to see them, because they no longer look like parts of identifiers. From jfredett at gmail.com Sun Dec 13 18:45:29 2009 From: jfredett at gmail.com (jfredett@gmail.com) Date: Sun Dec 13 18:19:37 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 142 - December 13, 2009 Message-ID: <4b257c99.9553f10a.126f.fffff617@mx.google.com> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20091213 Issue 142 - December 13, 2009 --------------------------------------------------------------------------- Welcome to issue 142 of HWN, a newsletter covering developments in the [1]Haskell community. First of all, apologies for the late edition, I've only one set of finals left, and then everything should return to a normal schedule (at least, that's the plan). This week brings lots of development on the various usb utilities, an edition of the Haskell Web News (which covers, in summary, the events of the previous month in the Haskell online community), and some really great discussion about why Haskell is Pure. Until next week, Haskeller's, your Haskell Weekly News! Announcements Next meeting: December 17th at MIT (32-G882). Ravi Nanavati [2]announced the next meeting of the Boston Area Haskell User Group. Ryan Newton will be talking about Intel Concurrent Collections for Haskell. PCLT-0.1 and PCLT-DB-0.1. Andrey Sisoyev [3]announced his first two packages he's developed in Haskell. Both of his new packages relate to localization of packages. Announcing a summer internship for a NASA-sponsored project. Lee Pike [4]announced a new summer internship sponsored by NASA and Galois, Inc. unicode-symbols-0.1.1. Roel van Dijk [5]announced the release of his package 'unicode-symbols'. This packages offers alternative symbols for a number of common function and operators from the base and container packages. ls-usb-0.1.0.2. Roel van Dijk [6]announced a minor update of ls-usb, his package for listing USB devices connected to your system. usb-safe-0.1. Bas van Dijk [7]announced the release of his package usb-safe, which provides an abstract interface to the bindings-libusb library. usb-0.3. Bas van Dijk [8]announced a new release of his 'usb' library for high-level communication with usb devices from Haskell. bindings-libusb-1.4.2. Bas van Dijk [9]announced a new version of bindings-libusb, a DSL based, low level binding to libusb The Haskell Web News: December 2009 Edition. Don Stewart [10]announced the Haskell Web News for December. new installment of failure framework. Michael Snoyman [11]announced the next installment of the Failure Framework. PortAudio Windows Tutorial and Binaries. M Xyz [12]announced a tutorial for setting up PortAudio on Windows readline-statevar-1.0.1.0. Krzysztof Skrzetnicki [13]announced a small wrapper for readline. hakyll-0.1. Jasper van der Jeugt [14]announced Hakyll, a simple static site generator written in Haskell. Discussion Why? John D. Earle [15]asked about what benefits of purity in Haskell. Type system speculation. Andrew Coppin [16]asked about why we Haskeller's (including himself) are so obsessed with the type system. To Hackage or not to Hackage. John Van Enk [17]asked about whether it was worth putting a package on Hackage. Hayoo and Hoogle (beginner question). drostin77 [18]asked our 'Hopefully Helpful Haskell Community' about the differences between Hoogle and Hayoo. Blog noise [19]Haskell news from the [20]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Manuel M T Chakravarty: [21]Using DTrace to track scheduler events of GHC's runtime. * Darcs: [22]darcs weekly news #47. * Brent Yorgey: [23]Mgu's and universal properties. * Philip Wadler: [24]Computer Science Education Week. * Bryan O'Sullivan: [25]The performance of Data.Text. * Neil Brown: [26]Solving the Santa Claus Problem with Conjunction. * Douglas M. Auclair (geophf): [27]Don't know; don't care: Whatever. * Ivan Lazar Miljenovic: [28]Command Input/Output and blocking. * Galois, Inc: [29]Tech Talk: John Launchbury presents Conal Elliottâs âBeautiful Differentiationâ. * Well-Typed.Com: [30]Talk at the Functional Programming eXchange. * Neil Brown: [31]The Problem with Parallel Participants Professing Priority. * Sean Leather: [32]Draft: "Pull-Ups, Push-Downs, and Passing It Around: Exercises in Functional Incrementalization". * Mikael Vejdemo Johansson (Syzygy-): [33]Coordinatization with hom complexes. * Haskell Web News: [34]What's new in Haskell? December 2009. * Dan Piponi (sigfpe): [35]Where do monads come from?. * Michael Snoyman: [36]Two language extensions. Quotes of the Week * sproingie: | {-# LANGUAGE NoTypeChecking #-} * kmc: the usual structure for a Haskell program is a crunchy IO shell with a gooey chocolate pure function center * sproingie: if it makes Cale's brane asplode, i think there's no hope for me understanding it * Wikipedia: In topology, the long line (or Alexandroff line) is a topological space analogous to the real line, but much longer. * ray: a monad tutorial is like a sausage factory * TomTobin: ::facepalm:: I wrote "Foobar" as a placeholder as I was typing [for the author's name], and never replaced it [in my email]. * ski: > (let id :: (forall id. id -> id) -> id -> id; id id = id id in id) id 5 * dmwit: analogies are endofunctors in the category of bad explanations * knobo: I really like this :) I can see that haskell is really cool now. This i a "matrix moment" for me :) About the Haskell Weekly News New editions are posted to [37]the Haskell mailing list as well as to [38]the Haskell Sequence and [39]Planet Haskell. [40]RSS is also available, and headlines appear on [41]haskell.org. To help create new editions of this newsletter, please see the information on [42]how to contribute. Send stories to jfredett . at . gmail . dot . com. The darcs repository is available at darcs get [43]http://patch-tag.com/r/jfredett/HWN2/pullrepo HWN2 . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67829 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67818 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67637 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67628 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67624 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67623 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67622 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67621 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67455 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67417 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67407 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67328 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/67312 15. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67702 16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67658 17. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67551 18. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67412 19. http://planet.haskell.org/ 20. http://haskell.org/haskellwiki/Blog_articles 21. http://justtesting.org/post/281294210 22. http://blog.darcs.net/2009/12/darcs-weekly-news-47.html 23. http://byorgey.wordpress.com/2009/12/11/mgus-and-universal-properties/ 24. http://wadler.blogspot.com/2009/12/computer-science-education-week.html 25. http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ 26. http://chplib.wordpress.com/2009/12/10/solving-the-santa-claus-problem-with-conjunction/ 27. http://logicaltypes.blogspot.com/2008/07/dont-know-dont-care-whatever.html 28. http://ivanmiljenovic.wordpress.com/2009/12/10/command-inputoutput-and-blocking/ 29. http://www.galois.com/blog/2009/12/09/tech-talk-john-launchbury-presents-conal-elliots-beautiful-differentiation/ 30. http://blog.well-typed.com/2009/12/talk-at-the-functional-programming-exchange/ 31. http://chplib.wordpress.com/2009/12/08/the-problem-with-parallel-participants-professing-priority/ 32. http://feedproxy.google.com/~r/splonderzoek/~3/vjibqjB5x04/draft-pull-ups-push-downs-and-passing.html 33. http://blog.mikael.johanssons.org/archive/2009/12/coordinatization-with-hom-complexes/ 34. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ 35. http://blog.sigfpe.com/2009/12/where-do-monads-come-from.html 36. http://snoyberg.wordpress.com/2009/12/07/two-language-extensions/ 37. http://www.haskell.org/mailman/listinfo/haskell 38. http://sequence.complete.org/ 39. http://planet.haskell.org/ 40. http://sequence.complete.org/node/feed 41. http://haskell.org/ 42. http://haskell.org/haskellwiki/HWN 43. http://patch-tag.com/r/jfredett/HWN2/pullrepo%20HWN2 From ehamberg at gmail.com Sun Dec 13 19:03:52 2009 From: ehamberg at gmail.com (Erlend Hamberg) Date: Sun Dec 13 18:37:13 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 142 - December 13, 2009 In-Reply-To: <4b257c99.9553f10a.126f.fffff617@mx.google.com> References: <4b257c99.9553f10a.126f.fffff617@mx.google.com> Message-ID: <200912140104.01054.ehamberg@gmail.com> Hi, First and foremost; thanks for your work on the HWN. It is greatly appreciated. :) Just a quick tip: On Monday 14. December 2009 00.45.29 jfredett@gmail.com wrote: > Until next week, Haskeller's, [?] > why we Haskeller's [?] Both of these refer to many ?haskellers? ? no apostrophe should be put before the ?s? as that would mean *one* haskeller having something. (?A haskeller's best friend?.) -- Erlend Hamberg "Everything will be ok in the end. If its not ok, its not the end." GPG/PGP: 0xAD3BCF19 45C3 E2E7 86CA ADB7 8DAD 51E7 3A1A F085 AD3B CF19 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091213/a383ee0a/attachment.bin From jfredett at gmail.com Sun Dec 13 19:32:55 2009 From: jfredett at gmail.com (Joe Fredette) Date: Sun Dec 13 19:07:09 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 142 - December 13, 2009 In-Reply-To: <200912140104.01054.ehamberg@gmail.com> References: <4b257c99.9553f10a.126f.fffff617@mx.google.com> <200912140104.01054.ehamberg@gmail.com> Message-ID: <5EB17A64-0F03-4AA8-95EC-BF85AE46B062@gmail.com> English, while my first language (and in fact, only language...) is also my worst language... Thanks for catching the grammar snafu. While I'm here, please note that the issue number is off as well, it's fixed in the version on sequence.complete.org, but not in the email version. /Joe On Dec 13, 2009, at 7:03 PM, Erlend Hamberg wrote: > Hi, > > First and foremost; thanks for your work on the HWN. It is greatly > appreciated. :) > > Just a quick tip: > > On Monday 14. December 2009 00.45.29 jfredett@gmail.com wrote: >> Until next week, Haskeller's, [?] >> why we Haskeller's [?] > > Both of these refer to many ?haskellers? ? no apostrophe should be > put before > the ?s? as that would mean *one* haskeller having something. (?A > haskeller's > best friend?.) > > -- > Erlend Hamberg > "Everything will be ok in the end. If its not ok, its not the end." > GPG/PGP: 0xAD3BCF19 > 45C3 E2E7 86CA ADB7 8DAD 51E7 3A1A F085 AD3B CF19 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ok at cs.otago.ac.nz Sun Dec 13 19:44:16 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Dec 13 19:18:25 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <200912121544.54220.daniel.is.fischer@web.de> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <200912101500.42070.daniel.is.fischer@web.de> <62BA77CC-AF81-49B0-8A44-1F214FF13898@cs.otago.ac.nz> <200912121544.54220.daniel.is.fischer@web.de> Message-ID: On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote: > Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: >> On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: >>> Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: >>>> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that >>>> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, >>> >>> mb_t's_bcs the ndrscr_stl is considered far uglier and less readable >>> by others >> >> Come ON. Argue honestly! > > Thanks, but I have to return that compliment. Not a bit of it. "mb_t's_bcs the ndrscr_stl" was NOT playing fair and you knew it. > I claim that the part not using insanely abbreviated words > (isConsidered, farUglier, > byOthers) *is* readable. > Also that moderately abbreviated words are readable in camelCase as > well as under_score. I guess we must mean different things by "readable" then. I've approached my head of department about running an experiment. > > >> >>> (granted, >>> underscore-style with nonabbreviated words is not unreadable, but >>> still extremely ugly)? >> >> Who "grants" that underscore separation with fully written words is >> "still extremely ugly"? Not me! > > Is that remark really unclear, Yes, it is really unclear. It read as "x (granted that y)". For clarity, it should have been "(still extremely ugly, granted that underscore-style with nonabbreviated words is not unreadable)". > Nobody *grants* anything is ugly or not, that is an aesthetic > judgment, as such entirely a > matter of personal preference - you can agree with it or not. Where is it written that aesthetic judgements are _entirely_ a matter of personal preference? As a student I was in the Archaeological society. One of the things I learned was this: - many ancient cultures would ritually "kill" grave goods - some grave goods would be smashed up, others would just have a chip out of them - as a rule, the ones that were least damaged were the ones the archaeologists considered to be the most beautiful (after repair). If an aesthetic sense about pots can be shared by modern archaeologists and people living five thousand years ago, it's hardly "entirely personal". What you may not appreciate is that I have been a Smalltalk programmer for a long time. I've read and written a lot of code like printSolutions (self sendSolutionsUsing: Empty and: Empty to: [:p :n | Transcript nextPutAll: 'p = '; print: p; nextPutAll: ', n = '; print: n; nextPut: $.; cr. true "stop after reporting first solution"] ) ifFalse: [ Transcript nextPutAll: 'No solutions.'; cr]. If it were just a matter of experience, then this experience should surely have taught me to love baStudlyCaps. > >> I have not been able to discover an experimental study of word >> separation style effect on readability in programming. I've been >> wondering about running a small one myself, next year. But there >> is enough experimentally determined about reading in general to >> be certain that visible gaps between words materially improves >> readability, and internal capital letters harm it. Now that >> applies to ordinary text, but until there's evidence to show that >> it doesn't apply to program sources, it's a reasonable working >> assumption that it does. > > I doubt that. Until the evidence is in, what other reasonable working assumption is there? > Sourcecode is so different from ordinary text (a line of sourcecode > rarely > contains more than four or five words), OK, let's try it. Shakespeare sonnet number 1, first four lines, but split into shorter chunks With spaces: From fairest creatures we desire increase, That thereby beauty's rose might never die, But as the riper should by time decease, His tender heir might bear his memory: With underscores: From fairest_creatures we desire_increase, That thereby beauty's_rose might_never_die, But as the_riper should by_time decease, His tender_heir might_bear his_memory: With baStudlyCaps: From fairestCreatures we desireIncrease, That thereby beauty'sRose mightNeverDie, But as theRiper should byTime decease, His tenderHeir mightBear hisMemory: baStudlyCaps doesn't read any better with short lines. > that I'd be very wary to transfer the findings for > one to the other. It's not uncommon for style guides to explicitly recommend that program code should be spaced like text. Apple notoriously violate this in Objective C. Where Smalltalk would have this sendSolutionsUsing: Empty and: Empty to: that Objective C practice is to write [this sendSolutionsUsing:Empty and:Empty to:that] > If somebody claimed that of > > x <- take_while some_condition some_list > > and > > x <- takeWhile someCondition someList > > either was objectively more readable than the other, I wouldn't > believe it without lots and lots of hard evidence. "Persaude a man against his will, he's of the same opinion still." How _much_ evidence? That's an artificial example. Haskell code doesn't tend to look like that. It's much more likely to be a choice between x' <- takeWhile p x and x' <- take_while p x I'll repeat the run length figures I previously posted today, but this time as percentages len pct 1 67% 2 22% 3 7% 4 3% 5 1% >5 <1% > for me the underscores push the > space-separated parts together, so that I have the tendency to > bracket it > > x <- take (while some) (condition some) list Such lines are rare. In my sample (very little of which was my own), under 14% of (lines having at least one identifier) had two or more internal capitals. Let's look at the number of internal capitals per run: 0 99324 79% 1 20761 16% 2 4100 3% 3 791 3..10 all have under 1% each; 4 221 the sum is 2% 5 68 6 11 7 14 8 4 9 0 10 1 takeWhile someCondition someList has three internal capitals, so it's one of just the 5% of lines with three or more. Let's try a more specific question: what proportions of runs have the pattern aB cD eF? 44 out of 125295, or 0.00035. You're asking me to sacrifice readability everywhere else for the sake of one line in every 2850? (Not that I do find that line more readable in basStudlyCaps.) In any case, I think it's just possible that the point of the thread may have been lost, which is that it is possible and practical to let *both* the people who like to read and write baStudlyCaps *and* the people who don't see what they find readable *without* impairing readability for the others. takeWhile can be automatically converted to take_while for viewing and editing. take_while can be automatically converted to takeWhile for viewing and editing. All without confusion except when both styles are used at once. I for one never suggested that baStudlyCappers should stop doing their thing and do my thing; I just don't want them inflicting it on me (and others like me). I quite see the justice of the argument running the other way, and I *don't* advocate baStudlyCappers being made to read and write readable_identifiers and (at least in this thread) never did. From jason.dusek at gmail.com Sun Dec 13 19:49:54 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Dec 13 19:24:00 2009 Subject: [Haskell-cafe] Re: Pure extremism (was: Re: Why?) In-Reply-To: <7ca3f0160912120003y682deac1q971d229d82ccfbae@mail.gmail.com> References: <7ca3f0160912120003y682deac1q971d229d82ccfbae@mail.gmail.com> Message-ID: <42784f260912131649w20a5236auc76375d3f3c94ed3@mail.gmail.com> 2009/12/12 Luke Palmer : > On Fri, Dec 11, 2009 at 7:07 PM, Jason Dusek wrote: > >?Where do we draw the line between "machinery" and "packages"? > >?The types don't tell us what libraries we need. > > ...you might mean what *haskell* libraries does a piece of > code depend on? Yes, that's what I mean. >?To address that, note that I consider a statement like: > > import Control.Monad.State > > As a form of impurity in a sense... It's not referentially transparent, that's for sure. > I have brainstormed solutions to this problem while thinking about my > (currently on hold or dead) Udon project... I remember reading about that. As regards the object identity problem, say we just talk about uniquely naming bytestrings. Well, different bytestrings are different so they are "their own name"; if we don't want to compare them via substring matching, though, then we need a consensus algorithm to name them identically across nodes on the WAN. I wonder if a solipsistic internal namespace is not a workable solution? My repo knows objects (patches) I created as having unqualified names; objects from your computer are labelled as "Luke's repo/..." and vice versa. The repo can be garbage collected for patches that are actually the same by background string equality checks. As someone -- I think it was you? -- suggested on the list a little while ago, the chance of hash collision is not zero. -- Jason Dusek From donn at avvanta.com Sun Dec 13 20:31:58 2009 From: donn at avvanta.com (Donn Cave) Date: Sun Dec 13 20:06:05 2009 Subject: [Haskell-cafe] getting data through foreign layer without marshalling Message-ID: <20091214013158.738E0F3937@mail.avvanta.com> I'm working with a C++ application library, of the sort where you instantiate a subclass of the library object and it dispatches your functions on receipt of various events. With multiple OS threads, by the way. This works all right so far, with some C++ boilerplate and Haskell FunPtrs created via the foreign "wrapper" option, but I am not crazy about marshalling the application data, to get it to the C++ object and back to my application functions. So, I'm wondering if the way I'm trying to thread application data through the C++ layer is reasonably fool-proof - I mean, empirically it works in a simple test, but are there going to be storage issues, etc.? Is there a better way to do it? Briefly, - my callbacks AppData -> CPlusObjectPtr -> P0 ... -> IO Pn - the FunPtr inserted into C++ object FunPtr (CPlusObjectPtr -> P0 ... -> IO Pn) ... i.e, I apply the AppData parameter first - I rewrite the C++ object's FunPtrs every time I update the application data (freeHaskellFunPtr prior values.) I'm just not sure where AppData lives while it's referenced in a FunPtr via partial application, if there might be multiple copies, etc. thanks! Donn Cave, donn@avvanta.com From ok at cs.otago.ac.nz Sun Dec 13 21:17:17 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Dec 13 20:51:30 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> Message-ID: On Dec 14, 2009, at 6:16 AM, John D. Earle wrote: > I am already familiar with SUA and it doesn't make Windows POSIX > complaint in a way that I would call genuine. I grant you that certain aspects of Windows POSIX support have earned it the "DeathStation 9000" label, but it's genuine enough to have earned this claim in the Wikipedia entry for POSIX: "Microsoft Windows Services for UNIX 3.5 ? enables >>> full POSIX compliance for certain Microsoft Windows products." I also grant you that the Microsoft POSIX subsystem only supported the 1990 version of POSIX and has been described as "close to useless". But of SUA it has been said "As of 2004, server versions of Windows have a POSIX subsystem that supports threads, signals, sockets, and shared memory, less than twenty years after the standard was finalized, and only a little over a decade after Microsoft began advertising POSIX compliance." > It was something I evaluated. There was no point in your mentioning > that it exists unless you had ulterior motives. "ulterior: being intentionally concealed so as to deceive". Nope. You said that Apple and Microsoft hadn't gone down the POSIX line. I pointed out that current MacOS _is_ a Unix; until today I've relied on Single Unix Specification version 3 documents to guide my Mac programming which makes it close enough for me. Today I downloaded the SUSv4 spec (POSIX 2008). I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA. For that matter, no version of Linux, no version of BSD, and no version of OpenSolaris is certified POSIX-compliant (open source projects change too fast for certification to be cheap). Microsoft can't "go the POSIX route" exclusively without killing their cash cow. VMS was the first POSIX-certified system, but that didn't mean DEC or VMS users abandoning VMS. zOS is POSIX-compliant, but I expect most sites running zOS have no intention of switching, and IBM have no intention of making them. > > It isn't what they are telling you that matters; it is what they are > not telling you. It is called a half truth. If Haskell wants to be > saved, it has got to give up the lying. What on earth is Haskell lying about? What does Haskell need to be saved from? (Its growing popularity and mushrooming library?) From mle+hs at mega-nerd.com Sun Dec 13 21:44:22 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun Dec 13 21:18:41 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> Message-ID: <20091214134422.722a9d50.mle+hs@mega-nerd.com> Richard O'Keefe wrote: > I also pointed out that Windows NT had a fully compliant > POSIX subsystem, by design, and that Microsoft cared at least enough > about POSIX support to buy the company that made what is now SUA. How does that explain things like fstat() and stat() returning different values for the same file: http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html That bug exists in windows XP, Vista and 7. > For that matter, no version of Linux, no version of BSD, and no version > of OpenSolaris is certified POSIX-compliant (open source projects change > too fast for certification to be cheap). For the last decade I have been the main author of libsndfile: http://www.mega-nerd.com/libsndfile/ a library that requires nothing of POSIX other than file I/O but needs to run on windows and *nix. You would think that Microsoft's much touted POSIX support would mean that the POSIX calls I used on *nix would JustWork(tm) on windows. Unfortunately, due to bugs in Microsoft's POSIX implementation this is not the case. Bugs include: - fstat() (64 bit file length aware version) returning the wrong file length after a write (win9x). - lseek() (64 bit file length aware version) to SEEK_END not actually going to the end of the file (win2000 and win2003). - fstat() and stat() returning different results on the same file (XP, Vista and 7). Because testing for and working around these bugs is simply too difficult, I have been forced to maintain tow versions of the file I/O code, one POSIX (that works on *nix including Mac OS X) and for windows, the native windows file I/O API. I suspect that authors of other open source projects that started on Linux and were then ported to windows would have similar stories of egregious unfixed bugs in Microsoft's POSIX implementation. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From phil at beadling.co.uk Sun Dec 13 21:59:29 2009 From: phil at beadling.co.uk (Philip Beadling) Date: Sun Dec 13 21:33:32 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: <1260727774.3898.104.camel@phil-desktop> References: <1260586642.3898.9.camel@phil-desktop> <1260612497.2575.13.camel@picard> <1260727774.3898.104.camel@phil-desktop> Message-ID: <1260759569.3898.114.camel@phil-desktop> > -- Prepare to share work to be > -- done across available cores > chunkOnCpu :: [a] -> [[a]] > chunkOnCpu xs = chunk (length xs `div` numCapabilities) xs > > -- Spark a fold of each chunk and > -- sum the results. Only works because > -- for associative folds. > foldChunks :: ([a] -> a) -> (a -> b -> a) -> a -> [[b]] -> a > foldChunks combineFunc foldFunc acc = > combineFunc . (parMap rwhnf $ foldl' foldFunc acc) I should probably point out that use of chunk above isn't a good idea in anything beyond a toy example. If you have used a list comprehension to create your input then splitting it like the above results in thunks that grow with list size as chunk forces generation of the list. This rapidly negates any advantage gained from processing across >1 core! This is easily solved - just alter the generating function to create a *list* of list comprehensions equal in length to the number of cores you wish to process across, rather than create one list that is split across the cores later. From dagit at codersbase.com Sun Dec 13 23:04:47 2009 From: dagit at codersbase.com (Jason Dagit) Date: Sun Dec 13 22:38:53 2009 Subject: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap In-Reply-To: References: Message-ID: On Sun, Dec 13, 2009 at 3:47 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote: > How about tracking the requirement of "bounded" in the type system? In > particular, I'm thinking of a type class > > class NFData a => Small a > > where the idea is that all types that can be stored in constant space > are members of this class. For example, we have > > instance Small () > instance Small Int > instance Small Char > instance (Small a, Small b) => Small (a,b) > instance (Small a, Small b) => Small (Either a b) > > but recursive types like [a] or String are not allowed to be members. > I like this. It's easy to audit for weird instances of Small. It seems like we also need: instance Small (IO ()) Which is not necessarily bounded due to things like IORefs. See below for why I think it would be a useful instance. > Then, > > withPending :: Small a => (a -> Patch -> a) -> IO a > > which is based on the function > > foldlSmall :: Small b => (b -> a -> b) -> b -> [a] -> b > foldlSmall f b [] = > foldlSmall f b (x:xs) = foldlSmall f b' xs > where b' = rnf (f b x) > > is pretty much guaranteed to run in O(1) space. Well, that depends on f > , but the point is it's not foldlSmall who introduces the space leak, > it's the argument that takes all the blame. > I could also see, us needing this: bracketSmall :: (Small c) => IO a -> (a -> IO b) -> (a -> IO c) -> IO c I'm not sure if b needs to be Small, since it's just supposed to be the return value of the deallocation step. Actually, since we didn't (yet) make functions an instance of Small, we may need to say this type: bracketFoldSmall :: (Small c) => IO a -> (a -> IO b) -> ((c -> a -> c) -> c -> a -> c) -> IO c Here I'm imagining 'a', being something like a list of patches. It's a big stream we want to process. Furthermore, it seems like we probably want c = IO (). This would be useful if we wanted to do some output for each patch in the sequence. But, as I think about it, it seems like if we allow ST or IO in these "small" functions or as instances of Small then we lose our guarantees. Yet, it seems that having functions like bracketSmall are necessary if we want to hide the stream itself from being exposed outside of the traversal function. For example, your foldlSmall doesn't leak, but something at the same level of scope as it could leak the list. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091213/09275dc1/attachment.html From daniel.is.fischer at web.de Sun Dec 13 23:11:59 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Dec 13 22:47:36 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <200912121544.54220.daniel.is.fischer@web.de> Message-ID: <200912140511.59752.daniel.is.fischer@web.de> Am Montag 14 Dezember 2009 01:44:16 schrieb Richard O'Keefe: > On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote: > > Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: > >> On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: > >>> Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: > >>>> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that > >>>> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, > >>> > >>> mb_t's_bcs the ndrscr_stl is considered far uglier and less readable > >>> by others > >> > >> Come ON. Argue honestly! > > > > Thanks, but I have to return that compliment. > > Not a bit of it. "mb_t's_bcs the ndrscr_stl" was NOT playing > fair and you knew it. 1. I wasn't playing in the under_score vs. camelCase game, just proposing a possible reason why the camelCase may have been chosen for Haskell's standard libraries. For that, I deliberately used an unrealistically exaggerated example of unreadable underscores. Even more unrealistic than your camelCase parody. The very next thing, I said that full_word_underscores is *not* unreadable, making clear (apparently not to you, sorry about that) that the example is not to be taken at face value. 2. Below, you say that it was an honest misunderstanding, so it's okay then. I didn't expect that to be the case but suspected intentional misinterpretation. > > > I claim that the part not using insanely abbreviated words > > (isConsidered, farUglier, > > byOthers) *is* readable. > > Also that moderately abbreviated words are readable in camelCase as > > well as under_score. > > I guess we must mean different things by "readable" then. By readable, I mean (broadly) "easy to read". Of course, some find is_considered far_uglier by_others easier to read, others harder, and yet others find both equally easy to read. I have no difficulty believing that some find either of the styles hard to read, but I don't expect experienced programmers to be in that group. > > I've approached my head of department about running an experiment. > > >>> (granted, > >>> underscore-style with nonabbreviated words is not unreadable, but > >>> still extremely ugly)? > >> > >> Who "grants" that underscore separation with fully written words is > >> "still extremely ugly"? Not me! > > > > Is that remark really unclear, > > Yes, it is really unclear. It read as "x (granted that y)". Aha. English more fragile than thought. Sorry. > For clarity, it should have been "(still extremely ugly, granted that > underscore-style with nonabbreviated words is not unreadable)". No, that is not what I meant. [Granted,] Underscore-style with nonabbreviated words is not unreadable. Even with written-out words, underscore-style is still extremely[1] ugly. [1] This, however, is an exaggeration as far as I'm concerned. I find the underscore-style ugly, but not extremly so. It was your "amazinglyUgly" which caused it to appear in that sentence. > > > Nobody *grants* anything is ugly or not, that is an aesthetic > > judgment, as such entirely a > > matter of personal preference - you can agree with it or not. > > Where is it written that aesthetic judgements are _entirely_ a > matter of personal preference? I think you could find that written in many texts on aesthetic relativism. Doesn't matter, though. Of course, one's personal preferences aren't developed in a vacuum, they are strongly influenced by genes and society. So a lot of preferences are shared within a culture and even across cultures and aesthetic judgments aren't entirely *individual*. Nevertheless, I'm convinced that there is no Platonic idea Beauty (or Ugliness) and that if A says that van Gogh's Sunflowers is a beautiful picture while B says it's ugly, it's not the case that one is objectively right, the other wrong. Both are judgments based on their respective preferences and nothing else (unless: lying, acting, succumbing to social pressure, other reasons to not express one's actual opinion). > > As a student I was in the Archaeological society. > One of the things I learned was this: > - many ancient cultures would ritually "kill" grave goods > - some grave goods would be smashed up, others would just > have a chip out of them > - as a rule, the ones that were least damaged were the ones > the archaeologists considered to be the most beautiful (after > repair). > If an aesthetic sense about pots can be shared by modern archaeologists > and people living five thousand years ago, it's hardly "entirely > personal". Depends on what you mean by "entirely personal". All I'm saying is that one can find a thing beautiful which another finds ugly. > > What you may not appreciate is that I have been a Smalltalk programmer > for a long time. I've read and written a lot of code like > > printSolutions > (self sendSolutionsUsing: Empty and: Empty to: [:p :n | > Transcript nextPutAll: 'p = '; print: p; > nextPutAll: ', n = '; print: n; nextPut: $.; cr. > true "stop after reporting first solution"] > ) ifFalse: [ > Transcript nextPutAll: 'No solutions.'; cr]. > > If it were just a matter of experience, then this experience should > surely have taught me to love baStudlyCaps. No. It should have tought you to *read* camelCase - unless your aversion is so strong that you actively refuse to learn reading it. > > >> I have not been able to discover an experimental study of word > >> separation style effect on readability in programming. I've been > >> wondering about running a small one myself, next year. But there > >> is enough experimentally determined about reading in general to > >> be certain that visible gaps between words materially improves > >> readability, and internal capital letters harm it. Now that > >> applies to ordinary text, but until there's evidence to show that > >> it doesn't apply to program sources, it's a reasonable working > >> assumption that it does. > > > > I doubt that. > > Until the evidence is in, what other reasonable working > assumption is there? > None. > > Sourcecode is so different from ordinary text (a line of sourcecode > > rarely > > contains more than four or five words), > > OK, let's try it. Shakespeare sonnet number 1, > first four lines, but split into shorter chunks > > With spaces: > > From fairest creatures > we desire increase, > That thereby > beauty's rose might never die, > But as the riper should > by time decease, > His tender heir > might bear his memory: > > With underscores: > > From fairest_creatures > we desire_increase, > That thereby > beauty's_rose might_never_die, > But as the_riper should > by_time decease, > His tender_heir > might_bear his_memory: > > With baStudlyCaps: > > From fairestCreatures > we desireIncrease, > That thereby > beauty'sRose mightNeverDie, > But as theRiper should > byTime decease, > His tenderHeir > mightBear hisMemory: > > baStudlyCaps doesn't read any better with short lines. I have no trouble reading either version. And that although this is not what camelCase is intended for (as far as I know, the purpose of it is to mark word boundaries within *one token* [identifier]). > > > that I'd be very wary to transfer the findings for > > one to the other. > > It's not uncommon for style guides to explicitly > recommend that program code should be spaced like text. > Apple notoriously violate this in Objective C. > Where Smalltalk would have > > this sendSolutionsUsing: Empty and: Empty to: that > > Objective C practice is to write > > [this sendSolutionsUsing:Empty and:Empty to:that] > So? Whitespace helps tokenising and thus increases readability (for me, at least). What's the relation to the question whether camel case and underscore are readable or not? > > If somebody claimed that of > > > > x <- take_while some_condition some_list > > > > and > > > > x <- takeWhile someCondition someList > > > > either was objectively more readable than the other, I wouldn't > > believe it without lots and lots of hard evidence. > > "Persaude a man against his will, he's of the same opinion still." > How _much_ evidence? Replicated studies with enough participants from enough different environments/cultures showing that more than 99% of the participants find it clearly more readable. That's due to the *objectively*; for such a strong claim, you need unusually strong evidence. If you claim that a [large] majority find one more readable, it's far easier. And if it turns out that a large majority finds underscores more readable, that would be a sufficient reason to use that [for new languages - mixing camel case and underscores in one language I believe to be as bad as usngabbrvtdwrdswocapsorundrscores]. I take the widespread presence of both as an indication that the majority isn't very large, so you'd have a little work to do to convince me. > That's an artificial example. Haskell code doesn't tend to look > like that. It's much more likely to be a choice between > x' <- takeWhile p x > and x' <- take_while p x And in such code *I* see _no_ difference in readability. Both read flawlessly, without any hiccough. It's when more than two several-word identifiers are juxtaposed that readability degrades (for both). You should've tried enumFromThenToWithCuteExtraForKicks - such identifiers I find actually harder to read in camel case than with underscores. But using such identifiers is evil and wrong anyway. > > I'll repeat the run length figures I previously posted today, > but this time as percentages > > len pct > 1 67% > 2 22% > 3 7% > 4 3% > 5 1% > > >5 <1% > > > > for me the underscores push the > > space-separated parts together, so that I have the tendency to > > bracket it > > > > x <- take (while some) (condition some) list > > Such lines are rare. > In my sample (very little of which was my own), > under 14% of (lines having at least one identifier) > had two or more internal capitals. > > Let's look at the number of internal capitals per run: > > 0 99324 79% > 1 20761 16% > 2 4100 3% > 3 791 3..10 all have under 1% each; > 4 221 the sum is 2% > 5 68 > 6 11 > 7 14 > 8 4 > 9 0 > 10 1 > > takeWhile someCondition someList has three internal > capitals, so it's one of just the 5% of lines with three or more. > Let's try a more specific question: > what proportions of runs have the pattern > aB cD eF? > 44 out of 125295, or 0.00035. > You're asking me to sacrifice readability everywhere else > for the sake of one line in every 2850? (Not that I do > find that line more readable in basStudlyCaps.) Not at all. What gave you that idea? Since camel case is the style used in the overwhelming majority of Haskell code and I consider mixing the two styles really bad, I ask you to use that in your public code, even if grudgingly. You prefer to read and write code in underscore style. Others prefer camel case. Without an easy way to convert, at least one group won't be happy. You have already posted a preprocessor to convert between the two styles, I think. That's good. If I can help improving it and making it more usable, I'd be happy to (there are a couple of points where the transformation is not trivial, {-# OPTIONS_GHC #-}, foreign import). From jgd at well.com Mon Dec 14 00:22:09 2009 From: jgd at well.com (J. Greg Davidson) Date: Sun Dec 13 23:58:20 2009 Subject: [Haskell-cafe] platform configure fails to find freeglut Message-ID: <1260768129.9206.26.camel@shevek.puuhonua.org> I'm trying to install haskell-platform-2009.2.0.2 on OpenSuse 11.2 Gnu/Linux 2.6.27.39-0.2-default #1 SMP x86_64 My currently installed packages include ghc-6.10.4-5.7 freeglut-080721-20.2.1 ghc-GLUT-doc-2.1.2.0-1.13 ghc-GLUT-devel-2.1.2.0-1.13 ghc-GLUT-prof-2.1.2.0-1.13 When I try to ./configure I get checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no configure: error: The GLUT C library is required One would think that with all of this good glut stuff I have installed the configure script would be satisfied, but it's not. Searching for answers only turned up other people with the same problem. Can someone assist me in fixing the problem? BTW - is there an official bug repository for the Haskell Platoform? I couldn't find that either, and I think it's very important! Thanks, _Greg P.S. In case it matters, here are most of my installed haskell packages: ghc-6.10.4-5.7 ghc-binary-devel-0.5.0.1-1.12 ghc-binary-doc-0.5.0.1-1.12 ghc-cairo-devel-0.10.1-1.4 ghc-data-accessor-devel-0.2.0.2-1.7 ghc-data-accessor-doc-0.2.0.2-1.7 ghc-data-accessor-monads-fd-devel-0.2-1.7 ghc-data-accessor-monads-fd-doc-0.2-1.7 ghc-data-accessor-template-devel-0.2.1.1-1.7 ghc-data-accessor-template-doc-0.2.1.1-1.7 ghc-derive-devel-0.1.4-2.55 ghc-derive-doc-0.1.4-2.55 ghc-Diff-devel-0.1.2-1.13 ghc-Diff-doc-0.1.2-1.13 ghc-doc-6.10.4-5.7 ghc-fingertree-devel-0.0-1.12 ghc-fingertree-doc-0.0-1.12 ghc-glib-devel-0.10.1-1.4 ghc-GLUT-devel-2.1.2.0-1.13 ghc-GLUT-doc-2.1.2.0-1.13 ghc-GLUT-prof-2.1.2.0-1.13 ghc-gtk2hs-common-0.10.1-1.4 ghc-gtk2hs-doc-0.10.1-1.4 ghc-gtk-devel-0.10.1-1.4 ghc-monads-fd-devel-0.0.0.1-1.9 ghc-monads-fd-doc-0.0.0.1-1.9 ghc-OpenGL-devel-2.2.2.0-1.15 ghc-OpenGL-doc-2.2.2.0-1.15 ghc-OpenGL-prof-2.2.2.0-1.15 ghc-paths-devel-0.1.0.5-19.14 ghc-paths-doc-0.1.0.5-19.14 ghc-pointedlist-devel-0.3.1-2.6 ghc-pointedlist-doc-0.3.1-2.6 ghc-prof-6.10.4-5.7 ghc-pureMD5-devel-0.2.4-1.7 ghc-pureMD5-doc-0.2.4-1.7 ghc-regex-tdfa-devel-1.1.1-1.10 ghc-regex-tdfa-doc-1.1.1-1.10 ghc-rosezipper-devel-0.1-1.7 ghc-rosezipper-doc-0.1-1.7 ghc-split-devel-0.1.1-1.12 ghc-split-doc-0.1.1-1.12 ghc-terminfo-devel-0.3.0.2-1.14 ghc-terminfo-doc-0.3.0.2-1.14 ghc-transformers-devel-0.1.4.0-1.12 ghc-transformers-doc-0.1.4.0-1.12 ghc-uniplate-devel-1.2.0.3-1.7 ghc-uniplate-doc-1.2.0.3-1.7 ghc-unix-compat-devel-0.1.2.1-1.14 ghc-unix-compat-doc-0.1.2.1-1.14 ghc-utf8-string-devel-0.3.4-1.14 ghc-utf8-string-doc-0.3.4-1.14 ghc-utility-ht-devel-0.0.4-1.7 ghc-utility-ht-doc-0.0.4-1.7 ghc-vty-devel-3.1.8.4-1.11 ghc-vty-doc-3.1.8.4-1.11 ghc-X11-devel-1.4.5-5.16 ghc-X11-doc-1.4.5-5.16 ghc-xmonad-contrib-devel-0.8.1-1.8 ghc-xmonad-contrib-doc-0.8.1-1.8 ghc-xmonad-devel-0.8.1-8.9 ghc-xmonad-doc-0.8.1-8.9 ghc-yi-devel-0.6.0-4.7 ghc-yi-doc-0.6.0-4.7 From dons at galois.com Mon Dec 14 00:28:19 2009 From: dons at galois.com (Don Stewart) Date: Mon Dec 14 00:02:28 2009 Subject: [Haskell-cafe] platform configure fails to find freeglut In-Reply-To: <1260768129.9206.26.camel@shevek.puuhonua.org> References: <1260768129.9206.26.camel@shevek.puuhonua.org> Message-ID: <20091214052819.GA5002@whirlpool.galois.com> jgd: > BTW - is there an official bug repository for the Haskell Platoform? > I couldn't find that either, and I think it's very important! > Yes, of course there's a bug tracker, linked from: http://hackage.haskell.org/platform/ http://trac.haskell.org/haskell-platform/report/1 From emax at chalmers.se Mon Dec 14 01:48:24 2009 From: emax at chalmers.se (Emil Axelsson) Date: Mon Dec 14 01:22:32 2009 Subject: [Haskell-cafe] writing graphs with do-notation In-Reply-To: <200912122200.40692.shahn@cs.tu-berlin.de> References: <200912122200.40692.shahn@cs.tu-berlin.de> Message-ID: <4B25DFB8.6090803@chalmers.se> Hi! This technique has been used to define netlists in hardware description languages. The original Lava [1] used a monad, but later switched to using observable sharing [2]. Wired [3] uses a monad similar to yours (but more complicated). I think it would be nice to have a single library for defining such graphs (or maybe there is one already?). The graph structure in Wired could probably be divided into a purely structural part and a hardware-specific part. [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.5221 [2] http://www.cs.chalmers.se/~dave/papers/observable-sharing.pdf [3] http://hackage.haskell.org/package/Wired / Emil Soenke Hahn skrev: > Hi! > > Some time ago, i needed to write down graphs in Haskell. I wanted to be able > to write them down without to much noise, to make them easily maintainable. I > came up with a way to define graphs using monads and the do notation. I thought > this might be interesting to someone, so i wrote a small script to illustrate > the idea. Here's an example: > > example :: Graph String > example = buildGraph $ do > a <- mkNode "A" [] > b <- mkNode "B" [a] > mkNode "C" [a, b] > > In this graph there are three nodes identified by ["A", "B", "C"] and three > edges ([("A", "B"), ("A", "C"), ("B", "C")]). Think of the variables a and b > as outputs of the nodes "A" and "B". Note that each node identifier needs to be > mentioned only once. Also the definition of edges (references to other nodes > via the outputs) can be checked at compile time. > > The attachment is a little script that defines a Graph-type (nothing > elaborate), the "buildGraph" function and an example graph that is a little > more complex than the above. The main function of the script prints the > example graph to stdout to be read by dot (or similar). > > By the way, it is possible to define cyclic graphs using mdo (RecursiveDo). > > I haven't come across something similar, so i thought, i'd share it. What do > you think? > > S?nke > From derek.a.elkins at gmail.com Mon Dec 14 01:54:49 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Dec 14 01:28:55 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> Message-ID: <61f84eff0912132254i36f41977u6ef8962f60fdd96@mail.gmail.com> > What does Haskell need to be saved from? > (Its growing popularity and mushrooming library?) Arguably John Earle's emails suggest that the answer to this is "Yes." From florbitous at gmail.com Mon Dec 14 02:21:10 2009 From: florbitous at gmail.com (Bernie Pope) Date: Mon Dec 14 01:55:16 2009 Subject: [Haskell-cafe] getting data through foreign layer without marshalling In-Reply-To: <20091214013158.738E0F3937@mail.avvanta.com> References: <20091214013158.738E0F3937@mail.avvanta.com> Message-ID: <4d8ad03a0912132321l37d2cf77lac6a9330365f617f@mail.gmail.com> 2009/12/14 Donn Cave : > I'm working with a C++ application library, of the sort where > you instantiate a subclass of the library object and it dispatches > your functions on receipt of various events. ?With multiple OS > threads, by the way. > > This works all right so far, with some C++ boilerplate and Haskell > FunPtrs created via the foreign "wrapper" option, but I am not crazy > about marshalling the application data, to get it to the C++ object > and back to my application functions. > > So, I'm wondering if the way I'm trying to thread application data > through the C++ layer is reasonably fool-proof - I mean, empirically > it works in a simple test, but are there going to be storage issues, > etc.? ?Is there a better way to do it? > > Briefly, > ?- my callbacks > ? ? ? ?AppData -> CPlusObjectPtr -> P0 ... -> IO Pn > ?- the FunPtr inserted into C++ object > ? ? ? ?FunPtr (CPlusObjectPtr -> P0 ... -> IO Pn) > ? ? ? ?... i.e, I apply the AppData parameter first > ?- I rewrite the C++ object's FunPtrs every time I update the > ? ?application data (freeHaskellFunPtr prior values.) > > I'm just not sure where AppData lives while it's referenced in a > FunPtr via partial application, if there might be multiple copies, etc. I don't fully understand what you want to do, but perhaps you can use a StablePtr: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-StablePtr.html Cheers, Bernie. From donn at avvanta.com Mon Dec 14 03:03:30 2009 From: donn at avvanta.com (Donn Cave) Date: Mon Dec 14 02:37:37 2009 Subject: [Haskell-cafe] getting data through foreign layer without marshalling References: <20091214013158.738E0F3937@mail.avvanta.com><4d8ad03a0912132321l37d2cf77lac6a9330365f617f@mail.gmail.com> Message-ID: <20091214080330.A0E1793C44@mail.avvanta.com> Quoth Bernie Pope , > 2009/12/14 Donn Cave : [...] > I don't fully understand what you want to do, but perhaps you can use > a StablePtr: > > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-StablePtr.html Yes, thank you very much, that does seem to work, and looks like it could be a better way to handle it. Donn Cave, donn@avvanta.com From martin.hofmann at uni-bamberg.de Mon Dec 14 03:34:17 2009 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Mon Dec 14 03:07:07 2009 Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows In-Reply-To: <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar> References: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de> <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar> Message-ID: <1260779657.3942.5.camel@ios.cogsys.wiai.uni-bamberg.de> Hi Daniel, > Do you have a complete example one can use to reproduce this behavior? > (preferably a short one! :P) With this code I could reproduce it in ghci. > >> runInterpreter $ loadModules [("SomeModule.hs", Nothing)] Currently I am not on a Windows machine, so I can't tell you if this only occured when trying to load a specific module. I'll try it later and if so, I'll tell you. If you need more information, just let me know. Martin > > The error message is: > > > > GHCi runtime linker: fatal error: I found a duplicate definition for > > symbol _hs_gtWord64 whilst processing object file > > C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0 > > HSghc-prim-0.1.0.o > > This could be caused by: > > * Loading two different object files which export the same symbol > > * Specifying the same object file twice on the GHCi command line > > * An incorrect `package.conf' entry, causing some object to be > > loaded twice. > > GHCi cannot safely continue in this situation. Exiting now. Sorry. > > > > The problem does not occur under Unix or with a compiled program. IMHO > > hint tries to start a second instance of GHCi which is not > > allowed/possible under Windows. If this is the case a more telling > > error > > message would be helpful. > > > > I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My > > package.conf is: > > > > C:/Programme/Haskell Platform/2009.2.0.2\package.conf: > > Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, > > HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1, > > QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0, > > ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, > > bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1, > > containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3), > > (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), > > (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, > > fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0, > > ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2, > > haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4, > > haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2, > > integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, > > old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, > > parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0, > > process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, > > regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, > > syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4, > > utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0 > > > > Thanks, > > > > Martin > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe -- --------------------------------------------------------------- Dipl.-Wirtsch.Inf. (E.M.B.Sc.) Martin Hofmann? Cognitive Systems Group Faculty Information Systems and Applied Computer Science University of Bamberg http://www.cogsys.wiai.uni-bamberg.de/members/hofmann http://www.inductive-programming.org From bulat.ziganshin at gmail.com Mon Dec 14 03:39:26 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 14 03:17:43 2009 Subject: [Haskell-cafe] getting data through foreign layer without marshalling In-Reply-To: <20091214013158.738E0F3937@mail.avvanta.com> References: <20091214013158.738E0F3937@mail.avvanta.com> Message-ID: <825852016.20091214113926@gmail.com> Hello Donn, Monday, December 14, 2009, 4:31:58 AM, you wrote: > I'm just not sure where AppData lives while it's referenced in a > FunPtr via partial application, if there might be multiple copies, etc. GHC RTS creates thunk with this partial call. this thunk references all the data used in computation. The thunk is placed in global objects table and removed from the table when you perform freeHaskellFunPtr -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Dec 14 03:44:49 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 14 03:21:07 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <20091214134422.722a9d50.mle+hs@mega-nerd.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> Message-ID: <517164288.20091214114449@gmail.com> Hello Erik, Monday, December 14, 2009, 5:44:22 AM, you wrote: >> I also pointed out that Windows NT had a fully compliant >> POSIX subsystem, by design, and that Microsoft cared at least enough >> about POSIX support to buy the company that made what is now SUA. > How does that explain things like fstat() and stat() returning different > values for the same file: POSIX is a *subsystem*. you are using Win32 subsystem. There is also OS2 subsystem for execution of 16-bit OS/2 programs partial emulation of POSIX API in C compiler libraries has nothing common with subsystem implemented as part of the OS. you have never used POSIX subsystem actually (and btw, it's absent in Win9x line) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mle+hs at mega-nerd.com Mon Dec 14 05:02:58 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon Dec 14 04:37:07 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <517164288.20091214114449@gmail.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> Message-ID: <20091214210258.a15e32de.mle+hs@mega-nerd.com> Bulat Ziganshin wrote: > POSIX is a *subsystem*. you are using Win32 subsystem. There is also > OS2 subsystem for execution of 16-bit OS/2 programs > > partial emulation of POSIX API in C compiler libraries has nothing > common with subsystem implemented as part of the OS. you have never > used POSIX subsystem actually (and btw, it's absent in Win9x line) Please enlighten me. How do I access the POSIX subsystem? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From bulat.ziganshin at gmail.com Mon Dec 14 05:16:08 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 14 04:50:23 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <20091214210258.a15e32de.mle+hs@mega-nerd.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> Message-ID: <1715450567.20091214131608@gmail.com> Hello Erik, Monday, December 14, 2009, 1:02:58 PM, you wrote: >> POSIX is a *subsystem*. you are using Win32 subsystem. There is also > Please enlighten me. How do I access the POSIX subsystem? i don't know since i never tried. it seems that this is bad idea. if you really need it, it should be better to use cygwin POSIX subsystem was implemented by MS (and other major players) only to meet some bureaucratic reqs from DoD/UsGov, and i don't know any program really using it. just don't mix C library emulation of POSIX calls on top of Win32 with POSIX subsystem (btw, both are implemented on top of native Windows API) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at googlemail.com Mon Dec 14 05:33:14 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Dec 14 05:07:23 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <20091214210258.a15e32de.mle+hs@mega-nerd.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> Message-ID: <1260786794.9220.24393.camel@localhost> On Mon, 2009-12-14 at 21:02 +1100, Erik de Castro Lopo wrote: > Bulat Ziganshin wrote: > > > POSIX is a *subsystem*. you are using Win32 subsystem. There is also > > OS2 subsystem for execution of 16-bit OS/2 programs > > > > partial emulation of POSIX API in C compiler libraries has nothing > > common with subsystem implemented as part of the OS. you have never > > used POSIX subsystem actually (and btw, it's absent in Win9x line) > > Please enlighten me. How do I access the POSIX subsystem? I'm not sure of all the details, but the program ends up getting linked differently. The GNU ld user guide says: --subsystem which:major.minor Specifies the subsystem under which your program will execute. The legal values for which are native, windows, console, posix, and xbox. You may optionally set the subsystem version also. Numeric values are also accepted for which. Duncan From bulat.ziganshin at gmail.com Mon Dec 14 05:43:28 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 14 05:17:43 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <1260786794.9220.24393.camel@localhost> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> <1260786794.9220.24393.camel@localhost> Message-ID: <157329117.20091214134328@gmail.com> Hello Duncan, Monday, December 14, 2009, 1:33:14 PM, you wrote: >> Please enlighten me. How do I access the POSIX subsystem? > I'm not sure of all the details, but the program ends up getting linked > differently. The GNU ld user guide says: yes, it should be linked to other dlls. the catch is that RTS/stdlib uses subsystem-specific calls, so you will need to write in assembler to ensure that your program don't use any Win32 calls :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Dec 14 05:39:16 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 14 05:17:51 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <20091214212712.33ff8fa9.mle+hs@mega-nerd.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> <1715450567.20091214131608@gmail.com> <20091214212712.33ff8fa9.mle+hs@mega-nerd.com> Message-ID: <10116565.20091214133916@gmail.com> Hello Erik, Monday, December 14, 2009, 1:27:12 PM, you wrote: > It seems the POSIX subsystem was POSIX.1 only and was removed completely > in windows XP. Thats not a solution. yes, i mean the same. just don't mix up fseek() in your C compiler with windows POSIX implementation >> POSIX subsystem was implemented by MS (and other major players) only >> to meet some bureaucratic reqs from DoD/UsGov, > You mean source code compatibility with dozens of UNIX variants from dozens > of UNIX vendors? You see that as a "beurocratic requirement"? i don't rememeber details. something that they buyed only hardware with POSIX-compatible OSes so MS implemented it meet reqs but really this implementation was not intended for real use :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From martin.hofmann at uni-bamberg.de Mon Dec 14 06:22:20 2009 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Mon Dec 14 05:55:17 2009 Subject: [Haskell-cafe] Hint causes GHCi linker error under Windows In-Reply-To: <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar> References: <1260525854.3934.9.camel@ios.cogsys.wiai.uni-bamberg.de> <07D4E191-06E7-49ED-A391-0DA7A31AF97D@dc.uba.ar> Message-ID: <1260789740.4819.17.camel@ios.cogsys.wiai.uni-bamberg.de> The following module reproduces the error when loaded into ghci and main is executed under Windows. It works fine when compiled. \begin{code} module Main where import Language.Haskell.Interpreter main = putStrLn "File to load: " >> getLine >>= erroneousLoad erroneousLoad :: FilePath -> IO () erroneousLoad f = do ok <- runInterpreter $ loadModules [f] case ok of Right _ -> return () Left e -> fail (show e) \end{code} However in my current program I also encounter strange behaviour when executing compiled code. I use 'haskeline' for a REP-loop. The user input is parsed and passed to a function similar to 'erroneousLoad'. When I type the path character by character, or when start with an empty line by pressing return, again everything works fine. When I use the completion function of 'haskeline' the program crashes with a segmentation fault. Changing the runInterpreter line to trace ("XXX " ++ (show f)) $ runInterpreter $ trace "YYY" $ loadModules $ trace "ZZZ" [f] I get the following output: XXX "expl\\\\Examples.hs" Igor2.exe: internal error: evacuate(static): strange closure type 1094 (GHC version 6.10.4 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way, Please contact the application's support team for more information. Sometimes I get different types of the 'strange closure', e.g. 17408 or others. I was not able to reproduce those errors on a smaller example than my whole program. Under Linux none of those errors occurs. Cheers, Martin From marlowsd at gmail.com Mon Dec 14 08:09:16 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 14 07:43:39 2009 Subject: [Haskell-cafe] Re: GHC 6.12 status and features In-Reply-To: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> References: <351ff25e0912111623j36cde361u88ba9605f9bd4304@mail.gmail.com> Message-ID: <4B2638FC.3060306@gmail.com> On 12/12/2009 00:23, Rafael Gustavo da Cunha Pereira Pinto wrote: > > > Hi folks, and specially Simon Marlow, > > > I know I should probably be asking to the GHC list, but is there any > update on 6.12 since October? Any probable release date? All going well, the 6.12.1 release should happen in the next day or so. Cheers, Simon From marlowsd at gmail.com Mon Dec 14 08:19:58 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 14 07:54:20 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: <1260727774.3898.104.camel@phil-desktop> References: <1260586642.3898.9.camel@phil-desktop> <1260612497.2575.13.camel@picard> <1260727774.3898.104.camel@phil-desktop> Message-ID: <4B263B7E.8030103@gmail.com> On 13/12/2009 18:09, Philip Beadling wrote: > I've come to the conclusion that, yep, you can't (directly) parallelise > of fold operation, as fold guarantees order of processing. True, but you can evaluate the elements in the input list to foldl' in parallel, as you were doing. Presumably this doesn't give you enough parallelism in your case, though. May I recommend that you pick up the latest parallel package: http://hackage.haskell.org/package/parallel and also the GHC 6.12.1 release (due any time now). The new parallel package in particular cures a nasty space leak when using Strategies, and the new GHC includes a host of improvements to parallel performance. If you still have trouble, then try using ThreadScope http://code.haskell.org/ThreadScope/ with GHC 6.12.1. You can use ThreadScope directly from the darcs repository on code.haskell.org, and we hope to do a proper release soon. Cheers, Simon From ekmett at gmail.com Mon Dec 14 09:43:44 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Dec 14 09:17:53 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> Message-ID: <7fb8f82f0912140643x711387bfu6e4fb476a9229c04@mail.gmail.com> On Thu, Dec 10, 2009 at 4:42 PM, Stephen Tetley wrote: > C'mon Andrew - how about some facts, references? > > 2009/12/10 Andrew Coppin : > > > > 1. Code optimisation becomes radically easier. The compiler can make very > > drastic alterations to your program, and not chance its meaning. (For > that > > matter, the programmer can more easily chop the code around too...) > > Which code optimizations? > Anything permitted by free theorems for one. That gives you a whole lot of code motion possibilities. Purity also gives the compiler freedom to increase sharing. It lets GHC rely on 'almost correct' ways to evaluate thunks on multiple cores with blackholing that has a vanishingly small but still existent race condition, which is FAR faster than the version they would have to use if they were more concerned about accidentally duplicating effects. > >From a different point of view, whole program compilation gives plenty > of opportunity for re-ordering transformations / optimization - Stalin > (now Stalinvlad) and MLton often generated the fastest code for their > respective (strict, impure) languages Scheme and Standard ML. > > Feel free to check the last page of the report here before replying > with the Shootout - (GHC still does pretty well though easily beating > Gambit and Bigloo): > http://docs.lib.purdue.edu/ecetr/367/ > > > 2. Purity leads more or less directly to laziness, which has several > > benefits: > > Other way round, no? > Laziness pushes you in the direction of purity, if only because it provides you with the freedom you need to recover usable efficiency, but I would argue that the converse is also true to some extent. When you are designing a pure language, you can't do as much in a strict setting as you can in a lazy setting. Laziness allows you to tie the knot without mutation -- or rather using only the mutation intrinsic to thunk-evaluation in call-by-need. A pure strict language is also often faced with some kind of fun/val distinction, leading to ml like syntactic warts, and eta-reduction isn't always sound, so EDSLs wind up carrying extra ()'s or need pointful plumbing ala f#'s |>. > > 2a. Unecessary work can potentially be avoided. (E.g., instead of a > function > > for getting the first solution to an equation and a seperate function to > > generate *all* the solutions, you can just write the latter and laziness > > gives you the former by magic.) > > > > Didn't someone quote Heinrich Apfelmus in this list in the last week or so: > > http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html > > "Well, it's highly unlikely that algorithms get faster by introducing > laziness. I mean, lazy evaluation means to evaluate only those things > that are really needed and any good algorithm will be formulated in a > way such that the unnecessary things have already been stripped off." > Continuing that quotation seems to say quite the opposite. > I mean, lazy evaluation means to evaluate only those things that are really needed and any good algorithm will be formulated in a way such that the unnecessary things have already been stripped off. But laziness allows to simplify and compose algorithms. Not only that but the surrounding example is the classic 'take 5 . qsort', which DOES change its asymptotics in the face of laziness. When you are writing the algorithm from scratch, I agree that it is the case that you probably derive nothing from laziness. The nice thing about laziness is that it permits you to avoid this tedium and makes it easier to grab a widget from the standard library and just have it suit your purposes. Another non-intuitive asymptotic changing difference is that laziness provides a side-effect free way to describe memoization and dynamic programming over certain domains. http://apfelmus.nfshost.com/quicksearch.html > > 2b. You can define brand new flow control constructs *inside* the > language > > itself. (E.g., in Java, a "for" loop is a built-in language construct. In > > Haskell, "for" is a function in Control.Monad. Just a plain ordinary > > function that anybody could write.) > > Psst, heard about Scheme & call/cc? > To be fair, most scheme control structures are implemented using macros, and call-by-macro-expansion is a form of call-by-name: http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_macro_expansion > > 2c. The algorithms for generating data, selecting data and processing > data > > can be seperated. (Normally you'd have to hard-wire the stopping > condition > > into the function that generates the data, but with lazy "infinite" data > > structures, you can seperate it out.) > > Granted. But some people have gone quite some way in the strict world, > e.g.: > > http://users.info.unicaen.fr/~karczma/arpap/FDPE05/f20-karczmarczuk.pdf > Given. But then people have written some amazing things in brainfuck too. That doesn't mean that I want to subject myself to working in such a sufficient computing environment :) -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/a61dc433/attachment.html From greenrd at greenrd.org Sun Dec 13 14:21:35 2009 From: greenrd at greenrd.org (Robin Green) Date: Mon Dec 14 11:00:57 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: GHC version 6.12.1 In-Reply-To: <20091214133614.GA11826@matrix.chaos.earth.li> References: <20091214133614.GA11826@matrix.chaos.earth.li> Message-ID: If you need an update of a package to make it build/run on GHC 6.12.1, or if you have modified someone else's package to do so, please feel free to use this wiki page to coordinate: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 I suggest that those who have patches to contribute add a link to their patches or forks from that page[*], *and* submit their patches to the package maintainer(s). That way, we can avoid duplication of effort, while not having to wait for package maintainers to get around to applying our patches. This may sound trivial, but it can be annoying waiting for a whole chain of packages to "catch up" before you can even build your own package. So you may end up fixing other people's packages - which can easily lead to substantial duplication of effort. [*] or you can email me links/patches and I'll add them for you From erkokl at gmail.com Mon Dec 14 12:57:26 2009 From: erkokl at gmail.com (Levent Erkok) Date: Mon Dec 14 12:31:39 2009 Subject: [Haskell-cafe] writing graphs with do-notation In-Reply-To: <4B25DFB8.6090803@chalmers.se> References: <200912122200.40692.shahn@cs.tu-berlin.de> <4B25DFB8.6090803@chalmers.se> Message-ID: <664C4719-9D3F-4207-8361-36E2D4B45D90@gmail.com> Andy Gill wrote a very nice recent paper on this topic which can serve as the basis for a generic implementation: http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09 As long as you do your "reification" in the IO monad, Andy's library gives you the graph conversion for (almost-) free. -Levent. On Dec 13, 2009, at 10:48 PM, Emil Axelsson wrote: > Hi! > > This technique has been used to define netlists in hardware > description languages. The original Lava [1] used a monad, but later > switched to using observable sharing [2]. Wired [3] uses a monad > similar to yours (but more complicated). > > I think it would be nice to have a single library for defining such > graphs (or maybe there is one already?). The graph structure in > Wired could probably be divided into a purely structural part and a > hardware-specific part. > > [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.5221 > [2] http://www.cs.chalmers.se/~dave/papers/observable-sharing.pdf > [3] http://hackage.haskell.org/package/Wired > > / Emil > > > > Soenke Hahn skrev: >> Hi! >> Some time ago, i needed to write down graphs in Haskell. I wanted >> to be able to write them down without to much noise, to make them >> easily maintainable. I came up with a way to define graphs using >> monads and the do notation. I thought this might be interesting to >> someone, so i wrote a small script to illustrate the idea. Here's >> an example: >> example :: Graph String >> example = buildGraph $ do >> a <- mkNode "A" [] >> b <- mkNode "B" [a] >> mkNode "C" [a, b] >> In this graph there are three nodes identified by ["A", "B", "C"] >> and three edges ([("A", "B"), ("A", "C"), ("B", "C")]). Think of >> the variables a and b as outputs of the nodes "A" and "B". Note >> that each node identifier needs to be mentioned only once. Also the >> definition of edges (references to other nodes via the outputs) can >> be checked at compile time. >> The attachment is a little script that defines a Graph-type >> (nothing elaborate), the "buildGraph" function and an example graph >> that is a little more complex than the above. The main function of >> the script prints the example graph to stdout to be read by dot (or >> similar). >> By the way, it is possible to define cyclic graphs using mdo >> (RecursiveDo). >> I haven't come across something similar, so i thought, i'd share >> it. What do you think? >> S?nke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery at ece.cmu.edu Mon Dec 14 13:51:53 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Dec 14 13:26:25 2009 Subject: [Haskell-cafe] platform configure fails to find freeglut In-Reply-To: <1260768129.9206.26.camel@shevek.puuhonua.org> References: <1260768129.9206.26.camel@shevek.puuhonua.org> Message-ID: <38D6DFA9-AE6D-4C48-B924-0C69007691FE@ece.cmu.edu> On Dec 14, 2009, at 00:22 , J. Greg Davidson wrote: > freeglut-080721-20.2.1 Google is telling me there's a freeglut-devel package; you probably want to install it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/628671f6/PGP.bin From jason.dusek at gmail.com Mon Dec 14 14:20:31 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Dec 14 13:54:38 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <7fb8f82f0912140643x711387bfu6e4fb476a9229c04@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7fb8f82f0912140643x711387bfu6e4fb476a9229c04@mail.gmail.com> Message-ID: <42784f260912141120o7f03b627lce23f0596c94a4e6@mail.gmail.com> 2009/12/14 Edward Kmett : > [...] That doesn't mean that I want to subject myself to working > in such a sufficient computing environment :) Sufficient? -- Jason Dusek From mle+hs at mega-nerd.com Mon Dec 14 14:43:54 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon Dec 14 14:18:04 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <9D8402C067204A889F3163029BC0FBC6@JohnPC> References: <9D8402C067204A889F3163029BC0FBC6@JohnPC> Message-ID: <20091215064354.5bce57fc.mle+hs@mega-nerd.com> All replies to the list please. John D. Earle wrote: > When I came to the Haskell mailing list I intended to advance a thought > which I never got around to and since we are on the topic. I ran into > problems building Haskell from source and I reasoned that since the build > system has a POSIX flavor it might be better to officially build Haskell on > Windows using SUA. The keyword here is "officially". There is a MinGW Linux > cross compiler that allows you to compile a program on Linux that will run > on Windows. > > A problem with using a cross compiler is you won't get to run the test > suite. The windows API reimplementation Wine is not godd for must things but should be more than adequate to run test suites. For libsndfile I release pre-compiled windows binaries that have been cross compiler from Linux to windows. I run the rather comprehensive libsndfile test suite under Wine and it works very well indeed. Unfortunately Wine currently only supports 32 bit windows. For 64 bit windows I still cross compile from Linux, but I then generate a testsuite tarball that contains all the binaries required to run the test suite. This can then be transferred to the target machine and run in a MinGW or Cygwin shell. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From brad.larsen at gmail.com Mon Dec 14 14:53:32 2009 From: brad.larsen at gmail.com (Brad Larsen) Date: Mon Dec 14 14:27:36 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays Message-ID: Is anyone working on fixing ticket #650 ? In short, STArray and the garbage collector don't play well together, resulting in array updates being non-constant time operations. This bug makes it very difficult/impossible to write efficient array algorithms that depend upon mutation in Haskell. On another note, does this (or perhaps better phrased, will this) bug also affect Data Parallel Haskell? I would really like to see highly efficient, mutable, boxed arrays in Haskell! Unfortunately, I don't have the know-how to fix Ticket 650. Sincerely, Brad From ekmett at gmail.com Mon Dec 14 14:58:11 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Dec 14 14:32:23 2009 Subject: [Haskell-cafe] Why? In-Reply-To: <42784f260912141120o7f03b627lce23f0596c94a4e6@mail.gmail.com> References: <8C98544430C04B15872766E13F8CFD13@JohnPC> <4B215EC1.6010706@btinternet.com> <5fdc56d70912101342k715a12e2p193050b36eae7f47@mail.gmail.com> <7fb8f82f0912140643x711387bfu6e4fb476a9229c04@mail.gmail.com> <42784f260912141120o7f03b627lce23f0596c94a4e6@mail.gmail.com> Message-ID: <7fb8f82f0912141158o2f9bd1ddjb1027fef82ee828e@mail.gmail.com> -Edward Kmett On Mon, Dec 14, 2009 at 2:20 PM, Jason Dusek wrote: > 2009/12/14 Edward Kmett : > > [...] That doesn't mean that I want to subject myself to working > > in such a sufficient computing environment :) > > Sufficient? > That word was meant to be surrounded by big sarcasm quotes. By sufficient I meant that it is Turing complete, and so in some sense sufficient to general purpose programming -- even if it is not a desirable environment in which to code. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/9d6d977b/attachment.html From allbery at ece.cmu.edu Mon Dec 14 15:08:30 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Dec 14 14:42:50 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <517164288.20091214114449@gmail.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> Message-ID: On Dec 14, 2009, at 03:44 , Bulat Ziganshin wrote: > POSIX is a *subsystem*. you are using Win32 subsystem. There is also > OS2 subsystem for execution of 16-bit OS/2 programs Microsoft dropped both of those some time back (specifically the "subsystem" mechanism, that is). Some parts of the subsystems migrated elsewhere, though. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/3a6b06ff/PGP.bin From agocorona at gmail.com Mon Dec 14 15:27:16 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Mon Dec 14 15:01:22 2009 Subject: Fwd: Re[4]: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> <1715450567.20091214131608@gmail.com> Message-ID: > > POSIX subsystem was implemented by MS (and other major players) only > to meet some bureaucratic reqs from DoD/UsGov, and i don't know any > program really using it. just don't mix C library emulation of POSIX > calls on top of Win32 with POSIX subsystem (btw, both are implemented > on top of native Windows API) > > True. I tested the posix subsystem in the early days of NT and I found that fork actually forked nothing:. Exec after fork simply substituted the old process with the new without creation of any new process.. Then I concluded that the Posix sybsystem was there simply to pass the government requirements for public contracts. Probably, some standard executable test. Arguably, the bugs where intentionally there just to make sure that it was useless, for reasons that anyone may guess... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/a3d90555/attachment.html From dons at galois.com Mon Dec 14 16:16:29 2009 From: dons at galois.com (Don Stewart) Date: Mon Dec 14 15:50:40 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: References: Message-ID: <20091214211629.GA8448@whirlpool.galois.com> brad.larsen: > Is anyone working on fixing ticket #650 > ? In short, STArray > and the garbage collector don't play well together, resulting in array > updates being non-constant time operations. This bug makes it very > difficult/impossible to write efficient array algorithms that depend > upon mutation in Haskell. > > On another note, does this (or perhaps better phrased, will this) bug > also affect Data Parallel Haskell? What are you using boxed arrays for? (DPH, vector, uvector, are all for unboxed arrays, which are not affected, obviously). -- Don From brad.larsen at gmail.com Mon Dec 14 16:25:10 2009 From: brad.larsen at gmail.com (Brad Larsen) Date: Mon Dec 14 15:59:15 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: <20091214211629.GA8448@whirlpool.galois.com> References: <20091214211629.GA8448@whirlpool.galois.com> Message-ID: Don, On Mon, Dec 14, 2009 at 4:16 PM, Don Stewart wrote: > brad.larsen: >> Is anyone working on fixing ticket #650 >> ? ?In short, STArray >> and the garbage collector don't play well together, resulting in array >> updates being non-constant time operations. ?This bug makes it very >> difficult/impossible to write efficient array algorithms that depend >> upon mutation in Haskell. >> >> On another note, does this (or perhaps better phrased, will this) bug >> also affect Data Parallel Haskell? > > What are you using boxed arrays for? Two immediate examples come to mind: a generic, heap-based priority queue using an array, or a generic hash table that has acceptable performance. > (DPH, vector, uvector, are all for unboxed arrays, which are not > affected, obviously). > > -- Don The vector package on haskell has boxed arrays. Is DPH *really* only for primitive, unboxed types? If so, that's unfortunate. Sincerely, Brad From dons at galois.com Mon Dec 14 16:34:01 2009 From: dons at galois.com (Don Stewart) Date: Mon Dec 14 16:08:09 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: References: <20091214211629.GA8448@whirlpool.galois.com> Message-ID: <20091214213401.GB8448@whirlpool.galois.com> brad.larsen: > The vector package on haskell has boxed arrays. Is DPH *really* only > for primitive, unboxed types? If so, that's unfortunate. No, it's not only, but all the uses I've seen have been related to numerics, represented with unboxed types. I'm just curious if you have a current use case -- since that would help get interest in the ticket. -- Don From patai_gergely at fastmail.fm Mon Dec 14 16:50:17 2009 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Mon Dec 14 16:24:23 2009 Subject: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player Message-ID: <1260827417.9948.1350084243@webmail.messagingengine.com> Hello all, I just uploaded the fruit of a little side project. Hemkay [1] is an oldschool module music [2] player that performs all the hard work in Haskell. If there was any goal, it was to express the transformation from the song structure to the output of the mixer as a series of function compositions, maintaining a style that one might call idiomatic Haskell. Considering the dirtiness of the format in question, I'm quite pleased with the initial version. Still, I'd be curious to see how the overall quality of the code could be improved. In particular, retrieving and updating record fields is somewhat inconvenient. Also, the actual mixing (limited to the mixChunk function) is embarrassingly slow, and I wonder how much it could be improved without leaving the pure world. The program uses Portaudio for playback, but that might easily change in the future. The problem is that I couldn't get sound to work smoothly when producing samples in batches, so I'm sending them off one by one (!) at the moment, which doesn't help with performance either. I'm open to suggestions as to what library to use to push data to the sound card. Gergely [1] http://hackage.haskell.org/package/hemkay [2] http://en.wikipedia.org/wiki/MOD_(file_format) -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again From bugfact at gmail.com Mon Dec 14 17:10:58 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Dec 14 16:45:02 2009 Subject: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player In-Reply-To: <1260827417.9948.1350084243@webmail.messagingengine.com> References: <1260827417.9948.1350084243@webmail.messagingengine.com> Message-ID: Nice work! Did you try the OpenAL binding? Not sure if that works. 2009/12/14 Patai Gergely : > Hello all, > > I just uploaded the fruit of a little side project. Hemkay [1] is an > oldschool module music [2] player that performs all the hard work in > Haskell. If there was any goal, it was to express the transformation > from the song structure to the output of the mixer as a series of > function compositions, maintaining a style that one might call idiomatic > Haskell. Considering the dirtiness of the format in question, I'm quite > pleased with the initial version. > > Still, I'd be curious to see how the overall quality of the code could > be improved. In particular, retrieving and updating record fields is > somewhat inconvenient. Also, the actual mixing (limited to the mixChunk > function) is embarrassingly slow, and I wonder how much it could be > improved without leaving the pure world. > > The program uses Portaudio for playback, but that might easily change in > the future. The problem is that I couldn't get sound to work smoothly > when producing samples in batches, so I'm sending them off one by one > (!) at the moment, which doesn't help with performance either. I'm open > to suggestions as to what library to use to push data to the sound card. > > Gergely > > [1] http://hackage.haskell.org/package/hemkay > [2] http://en.wikipedia.org/wiki/MOD_(file_format) > > -- > http://www.fastmail.fm - Or how I learned to stop worrying and > ? ? ? ? ? ? ? ? ? ? ? ? ?love email again > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From patai_gergely at fastmail.fm Mon Dec 14 17:31:51 2009 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Mon Dec 14 17:05:55 2009 Subject: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player In-Reply-To: References: <1260827417.9948.1350084243@webmail.messagingengine.com> Message-ID: <1260829911.16427.1350094279@webmail.messagingengine.com> > Nice work! Thanks! :) > Did you try the OpenAL binding? Not sure if that works. No, I haven't really looked hard, to be honest. Portaudio looked simple enough, so I picked it. But it could be anything, since the mixing is done on my side anyway, and all I need is a way to push (preferably Float) samples to the sound unit. I'm sure there are several viable options, so the deciding factor is rather portability, and secondly ease of use. -- http://www.fastmail.fm - The professional email service From patai_gergely at fastmail.fm Mon Dec 14 17:42:29 2009 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Mon Dec 14 17:16:33 2009 Subject: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player In-Reply-To: References: <1260827417.9948.1350084243@webmail.messagingengine.com> Message-ID: <1260830549.17818.1350095091@webmail.messagingengine.com> > The more of these I see, the more guilt I feel over the condition of the > portaudio module. There's a good chance that the performance issue you're > seeing is a bad implementation of the portaudio library. Do you have any > specific problems you ran into with portaudio? I'd love to revisit at > some point... Well, when I tried to push whole blocks instead of individual samples, it seemed to miss some of these writes. It might do the same even now, but it wouldn't be noticeable with a sample missing here and there anyway. The interface for writeStream is not very fortunate. It forces me to pack samples into lists no matter what, even if the interleaved list is actually easier to produce. So it should probably provide alternative interfaces for interleaved lists (which would actually be possible right away if writeStream didn't ignore its third argument altogether), and maybe an array interface as well. I don't know if the callback interface works better, maybe that's also worth a shot. Ultimately, it would be probably best if it gave the programmer a higher abstraction, where it is passed a potentially infinite list of samples, and takes care of all the buffering duties. Also, this could be made to play nice with stream fusion in order to get the maximum performance out of it. Gergely -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html From vanenkj at gmail.com Mon Dec 14 17:45:25 2009 From: vanenkj at gmail.com (John Van Enk) Date: Mon Dec 14 17:19:30 2009 Subject: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player In-Reply-To: <1260830549.17818.1350095091@webmail.messagingengine.com> References: <1260827417.9948.1350084243@webmail.messagingengine.com> <1260830549.17818.1350095091@webmail.messagingengine.com> Message-ID: It's been well over a year. I'll see what I can do when I get some free(er) time. 2009/12/14 Patai Gergely > > The more of these I see, the more guilt I feel over the condition of the > > portaudio module. There's a good chance that the performance issue you're > > seeing is a bad implementation of the portaudio library. Do you have any > > specific problems you ran into with portaudio? I'd love to revisit at > > some point... > Well, when I tried to push whole blocks instead of individual samples, > it seemed to miss some of these writes. It might do the same even now, > but it wouldn't be noticeable with a sample missing here and there > anyway. > > The interface for writeStream is not very fortunate. It forces me to > pack samples into lists no matter what, even if the interleaved list is > actually easier to produce. So it should probably provide alternative > interfaces for interleaved lists (which would actually be possible right > away if writeStream didn't ignore its third argument altogether), and > maybe an array interface as well. I don't know if the callback interface > works better, maybe that's also worth a shot. > > Ultimately, it would be probably best if it gave the programmer a higher > abstraction, where it is passed a potentially infinite list of samples, > and takes care of all the buffering duties. Also, this could be made to > play nice with stream fusion in order to get the maximum performance out > of it. > > Gergely > > -- > http://www.fastmail.fm - One of many happy users: > http://www.fastmail.fm/docs/quotes.html > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/a8abf869/attachment.html From functionallyharmonious at yahoo.com Mon Dec 14 17:53:07 2009 From: functionallyharmonious at yahoo.com (M Xyz) Date: Mon Dec 14 17:27:11 2009 Subject: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player Message-ID: <322325.40851.qm@web113103.mail.gq1.yahoo.com> --- On Mon, 12/14/09, M Xyz wrote: From: M Xyz Subject: Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player To: "Patai Gergely" Date: Monday, December 14, 2009, 5:50 PM --- On Mon, 12/14/09, Patai Gergely wrote: Also, the actual mixing (limited to the mixChunk function) is embarrassingly slow, and I wonder how much it could be improved without leaving the pure world. The program uses Portaudio for playback... Patai, I asked a similar question about a week ago, inquiring about efficient buffers for audio. I got a good response: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/67258/focus=67293 Working with immutable trees instead of arrays still freaks me out, but page 289 of RWH actually made me feel a little better about it. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/f0ae5739/attachment.html From brad.larsen at gmail.com Mon Dec 14 17:55:41 2009 From: brad.larsen at gmail.com (Brad Larsen) Date: Mon Dec 14 17:29:45 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: <20091214213401.GB8448@whirlpool.galois.com> References: <20091214211629.GA8448@whirlpool.galois.com> <20091214213401.GB8448@whirlpool.galois.com> Message-ID: On Mon, Dec 14, 2009 at 4:34 PM, Don Stewart wrote: > brad.larsen: >> The vector package on haskell has boxed arrays. ?Is DPH *really* only >> for primitive, unboxed types? ?If so, that's unfortunate. > > No, it's not only, but all the uses I've seen have been related to > numerics, represented with unboxed types. > > I'm just curious if you have a current use case -- since that would help > get interest in the ticket. > > -- Don > How about a fast STHashTable? Or a fast priority queue in ST where priorities are integers of a known size? Such a priority queue can be implemented as an array of sequences---int priority is array index. I want to use such data structures for research in heuristic search algorithms, to get top performance, more than from using an IntMap / Map / whatever-other-persistent-data-structure. I'm trying to at least be ballpark competitive with C implementations of certain heuristic search algorithms, which use the forbidden magic of mutable data structures. I'd prefer to work in Haskell rather than rewrite in C. Right now, in Haskell, it doesn't seem possible to write the kind of algorithms I am working with, using high-performance mutable data structures, because of the boxed array/GC bugs. Sincerely, Brad From rl at cse.unsw.edu.au Mon Dec 14 18:10:57 2009 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon Dec 14 17:45:07 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: References: Message-ID: On 15/12/2009, at 06:53, Brad Larsen wrote: > On another note, does this (or perhaps better phrased, will this) bug > also affect Data Parallel Haskell? Luckily, no. DPH represents arrays of user-defined types by unboxed arrays (that's essentially what the vectoriser does). It does use boxed arrays in a couple of places internally but they are small. Roman From v.dijk.bas at gmail.com Mon Dec 14 18:13:23 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon Dec 14 17:47:29 2009 Subject: [Haskell-cafe] ANNOUNCE: explicit-iomodes-0.1 Message-ID: Hello, I just released the small package explicit-iomodes-0.1: http://hackage.haskell.org/package/explicit-iomodes-0.1 It's a wrapper around System.IO that provides a Handle type which is parametrized with the IOMode it is in. All operations on handles specify the needed IOMode which makes it a type error if you read from a write-only handle or if you write to a read-only handle for example. Thanks to Lee Houghton, Brandon S. Allbery and Jason Dagit for providing initial feedback! regards, Bas From garious at gmail.com Mon Dec 14 18:44:37 2009 From: garious at gmail.com (Greg Fitzgerald) Date: Mon Dec 14 18:19:02 2009 Subject: [Haskell-cafe] Token parsers in parsec consume trailing whitespace In-Reply-To: <1260647846-sup-4688@ezyang> References: <1260647846-sup-4688@ezyang> Message-ID: <1f3dc80d0912141544h30b560f8i29b8edb044cfd3f5@mail.gmail.com> Hi Edward, > 1. Is there a more elegant way of doing number parsing? In > particular, are there token parsers that don't consume trailing > whitespace, or is there a better way to do this with the > primitives. Parsec defines a combinator it calls 'lexeme' which the tokenizer wraps each of its functions in. The purpose of the tokenizer is to create a set of parsing combinators that ignore whitespace, comments, and some other handy stuff like checking for collisions with reserved keywords. To consume the trailing whitespace is not a bug, it's an abstraction layer, and Parsec is consistent about only using this abstraction in the Token module. It's too bad that the 'nat' function in Token is not defined in Parsec's Char module, and because of that, you need to copy-paste that code or roll your own. > It seems that the "token" approach of parsing lends itself > to a different style of parsing than the one I'm doing That's correct. Sounds to me like you shouldn't bother creating a tokenizer. You might even be able to get away with using the regex library instead of Parsec. -Greg From gcross at phys.washington.edu Mon Dec 14 18:49:53 2009 From: gcross at phys.washington.edu (Gregory Crosswhite) Date: Mon Dec 14 18:26:21 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <1260352455.2949.7.camel@picard> <134E737E-C6E1-4C93-95AB-BD2710F146C3@cs.otago.ac.nz> <5f271a760912110237w254d8499q8a42216842a50ac@mail.gmail.com> Message-ID: Just to toss my own cents into the camelCase versus under_score discussion: I personally prefer to use camelCase for functions and types and under_score for variables and value so that the two can be easily visually distinguished. For example, callFunctionWith first_variable second_variable This is arguably either the best or the worst of both worlds. :-) Cheers, Greg From waldmann at imn.htwk-leipzig.de Mon Dec 14 18:56:19 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Dec 14 18:30:28 2009 Subject: [Haskell-cafe] fun with 6.12 Message-ID: <4B26D0A3.3030203@imn.htwk-leipzig.de> download binary distribution for ghc-6.12.1, configure, sudo make install - fine try to build some packages: cabal configure ...: cabal: This version of the cabal program is too old to work with ghc-6.12+. You will need to install the 'cabal-install' package version 0.8 or higher. If you still have an older ghc installed (eg 6.10.4), run: $ cabal install -w ghc-6.10.4 'cabal-install >= 0.8' Right - looks like a very useful error message! Then let's do it: cabal install -w ghc-6.10.4 'cabal-install >= 0.8' Resolving dependencies... cabal: There is no available version of cabal-install that satisfies >=0.8 Indeed, a package with that version does not seem to exist. darcs get --partial http://darcs.haskell.org/cabal-install/ It says 0.7.5, but let's try anyway: sudo ./bootstrap.sh --global ... Error during cabal-install bootstrap: The Haskell package 'network' is required but it is not installed. Aha. Then let's get network from hackage, as in the olden days. And parsec. And mtl. And bytesting. And syb. Well, let's try to use "cabal fetch" to avoid at least some typing. But no, cabal ist too old for 6.12 - and "cabal fetch" does not understand "-w ghc-6.10.4" Manually download HTTP and zlib, and then cabal-install really builds. Great. Try to use it to build some packages, which finally breaks at derive-2.0.1 - but it seems this page is going to be helpful (thanks, guys): http://www.haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 anyway I'm stopped now because somewhere along the way this happened: waldmann@octopus:~/software/haskell/ghc-syb$ ghc-pkg check There are problems in package ghc-binary-0.5.0.2: dependency "bytestring-0.9.1.5-01c5fa5da70289596d73fa2e44360d8a" doesn't exist best - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091214/31c6082c/signature.bin From qdunkan at gmail.com Mon Dec 14 19:08:52 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Dec 14 18:42:56 2009 Subject: [Haskell-cafe] fun with 6.12 In-Reply-To: <4B26D0A3.3030203@imn.htwk-leipzig.de> References: <4B26D0A3.3030203@imn.htwk-leipzig.de> Message-ID: <2518b95d0912141608g7de73f24u5f555c088eb35578@mail.gmail.com> I noticed noise on the cabal list about updating for 6.12, and that it was nontrivial. Also, haddock won't compile with 6.12, and I couldn't find anything about a new release. If someone else doesn't get there first, I'll add them to the wiki tonight. From qdunkan at gmail.com Mon Dec 14 19:09:40 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Dec 14 18:43:44 2009 Subject: [Haskell-cafe] fun with 6.12 In-Reply-To: <2518b95d0912141608g7de73f24u5f555c088eb35578@mail.gmail.com> References: <4B26D0A3.3030203@imn.htwk-leipzig.de> <2518b95d0912141608g7de73f24u5f555c088eb35578@mail.gmail.com> Message-ID: <2518b95d0912141609v173f3181q6b35e99310605f5@mail.gmail.com> Ohh, it's for *patches*, not just warnings. Never mind then... On Mon, Dec 14, 2009 at 4:08 PM, Evan Laforge wrote: > I noticed noise on the cabal list about updating for 6.12, and that it > was nontrivial. > > Also, haddock won't compile with 6.12, and I couldn't find anything > about a new release. > > If someone else doesn't get there first, I'll add them to the wiki tonight. > From phil at beadling.co.uk Mon Dec 14 19:37:08 2009 From: phil at beadling.co.uk (Philip Beadling) Date: Mon Dec 14 19:11:03 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: <4B263B7E.8030103@gmail.com> References: <1260586642.3898.9.camel@phil-desktop> <1260612497.2575.13.camel@picard> <1260727774.3898.104.camel@phil-desktop> <4B263B7E.8030103@gmail.com> Message-ID: <1260837428.3898.126.camel@phil-desktop> > If you still have trouble, then try using ThreadScope > > http://code.haskell.org/ThreadScope/ > > with GHC 6.12.1. You can use ThreadScope directly from the darcs > repository on code.haskell.org, and we hope to do a proper release soon. > > Cheers, > Simon Thanks for the advice, just downloaded ThreadScope and it's pretty useful (before I was using Ubuntu's System Monitor which isn't ideal). I've moved onto 6.12 and I now have my program working nicely over 2 cores - the problem was at least in part my own design - I was generating large thunks in my parallel version which was killing performance. With this solved 2 cores gives me ~50% performance increase. What I'm doing now is taking a list I am going to fold over and splitting it up so I have a list of lists, where each parent list element representing work for 1 core. I then fold lazily and only parallelise on the final sum operation which (as far as I can see) sends each chunk of folds to a different core and sums the results. Can I confirm - what you are suggesting is that although I can't parallelise fold itself, I could force evaluation on the list I am about to fold in parallel and then merely accumulate the result at the end -- thus most the donkey work is done in parallel? If this is possible, it may be more flexible then my method. I'm lucky as each fold operation will take give-or-take the same amount of time so I can just chunk up fold jobs for each core equally. If this wasn't the case (and it certainly won't always be!), parallelising on individual items would be the way to go. Thanks, Phil. From daniel.is.fischer at web.de Mon Dec 14 19:37:04 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Dec 14 19:12:36 2009 Subject: [Haskell-cafe] fun with 6.12 In-Reply-To: <4B26D0A3.3030203@imn.htwk-leipzig.de> References: <4B26D0A3.3030203@imn.htwk-leipzig.de> Message-ID: <200912150137.04359.daniel.is.fischer@web.de> Am Dienstag 15 Dezember 2009 00:56:19 schrieb Johannes Waldmann: > download binary distribution for ghc-6.12.1, > configure, sudo make install - fine > > try to build some packages: cabal configure ...: > > cabal: This version of the cabal program is too old to work with ghc-6.12+. > You will need to install the 'cabal-install' package version 0.8 or higher. > If you still have an older ghc installed (eg 6.10.4), run: > $ cabal install -w ghc-6.10.4 'cabal-install >= 0.8' > > Right - looks like a very useful error message! Then let's do it: > > cabal install -w ghc-6.10.4 'cabal-install >= 0.8' > Resolving dependencies... > cabal: There is no available version of cabal-install that satisfies >=0.8 What I wrote to ghc-users: Oh great, that's not what I expected: $ cabal install cabal-install cabal: This version of the cabal program is too old to work with ghc-6.12+. You will need to install the 'cabal-install' package version 0.8 or higher. If you still have an older ghc installed (eg 6.10.4), run: $ cabal install -w ghc-6.10.4 'cabal-install >= 0.8' $ cabal install -w ghc-6.10.3 'cabal-install >= 0.8' Resolving dependencies... cabal: There is no available version of cabal-install that satisfies >=0.8 Oops, nothing higher than 0.6.4 on Hackage, even darcs.haskell.org/cabal-install is only version 0.7.5. That seems to work, though, but I needed to manually install network, mtl and parsec before bootstrap.sh ran. So: $ darcs get http://darcs.haskell.org/cabal-install $ cabal unpack network $ cabal unpack mtl $ cabal unpack parsec -- cabal unpack and cabal update worked with my cabal-0.6.4, those commands apparently don't need ghc for p in { network, mtl, parsec } cd p ghc --make Setup.(l)hs ./Setup configure --options ./Setup build ./Setup install cd cabal-install chmod +x bootstrap.sh ./bootstrap.sh Phew, works (for me, at least) Duncan says the release of cabal-install-0.8 is near. > > Indeed, a package with that version does not seem to exist. > darcs get --partial http://darcs.haskell.org/cabal-install/ > It says 0.7.5, but let's try anyway: > > sudo ./bootstrap.sh --global > ... > Error during cabal-install bootstrap: > The Haskell package 'network' is required but it is not installed. > > Aha. Then let's get network from hackage, as in the olden days. > And parsec. And mtl. And bytesting. And syb. Well, let's try > to use "cabal fetch" to avoid at least some typing. > But no, cabal ist too old for 6.12 - > and "cabal fetch" does not understand "-w ghc-6.10.4" > > Manually download HTTP and zlib, and then cabal-install > really builds. Great. Try to use it to build some packages, > which finally breaks at derive-2.0.1 - > > but it seems this page is going to be helpful (thanks, guys): > http://www.haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 > > anyway I'm stopped now because somewhere along the way this happened: > > waldmann@octopus:~/software/haskell/ghc-syb$ ghc-pkg check > There are problems in package ghc-binary-0.5.0.2: > dependency "bytestring-0.9.1.5-01c5fa5da70289596d73fa2e44360d8a" > doesn't exist > > best - J.W. From ok at cs.otago.ac.nz Mon Dec 14 19:56:54 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 14 19:31:01 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <20091214134422.722a9d50.mle+hs@mega-nerd.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> Message-ID: <74AFF5A6-F4BE-44E8-AEFE-48906B9471A2@cs.otago.ac.nz> On Dec 14, 2009, at 3:44 PM, Erik de Castro Lopo wrote: > Richard O'Keefe wrote: > >> I also pointed out that Windows NT had a fully compliant >> POSIX subsystem, by design, and that Microsoft cared at least enough >> about POSIX support to buy the company that made what is now SUA. > > How does that explain things like fstat() and stat() returning > different > values for the same file: > > http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html > > That bug exists in windows XP, Vista and 7. I did mention the "DeathStation 9000" label it has earned. I actually got that from your web site. I got this bug report there too. I am an anti-Microsoft bigot. I go around saying that if this University were really opposed to software piracy, we'd ban all Microsoft products. But I hope you like horror stories, because in _this_ case, while all sanity and practicality are on one side, Microsoft are fully within their legal rights to be on the other. The Single Unix Specification, version 4 (POSIX.1-2008) defines what fstat(), fstatat(), stat(), and lstat() should do to st_size for - shared memory objects - typed memory objects - symbolic links For other file types, the structure members st_mode, st_ino, st_dev, st_uid, st_gid,st_atim, st_ctim, and st_mtim shall have meaningful values and the value of the member st_nlink shall be set to the number of links to the file. That is, st_size is specifically *not* defined and need *not* have "meaningful values". The description of st_size in says "For regular files, the file size in bytes", but I repeat, the specifications of fstat() and stat() do NOT say that it is given any meaningful value at all for regular files. An implementation where fstat() always fills in 0xDEAF and stat() always fills in 0xDEAD would not fail to conform to POSIX for that reason alone. By any sane or practical standard, the discrepancy between stat() and fstat() in Windows is a bug. By the standard of conformance to POSIX, it isn't. (By the way, the mention of st_[acm]tim instead of st_[acm]time is not a typo above. The old time_t members are gone. The new ones are struct timespec-s, which looks very much the 2038 bug is still with us.) Except for this change, the Single Unix Specification version 3 is not much different from V4, in particular, V3 didn't require a POSIX system to set st_size to anything useful for a regular file either. The moral of the story is - Microsoft have excellent lawyers - standards may promise far less than you think > You would think that Microsoft's much touted POSIX support would mean > that the POSIX calls I used on *nix would JustWork(tm) on windows. > Unfortunately, due to bugs in Microsoft's POSIX implementation this is > not the case. Bugs include: > > - fstat() (64 bit file length aware version) returning the wrong > file > length after a write (win9x). It doesn't have to return ANYTHING sensible, EVER, for a regular file. > > - lseek() (64 bit file length aware version) to SEEK_END not > actually > going to the end of the file (win2000 and win2003). That one looks like a real bug. Is it still there in Vista and Windows 7? > > - fstat() and stat() returning different results on the same file > (XP, > Vista and 7). They don't have to return ANYTHING sensible, EVER, for regular files, and they DON'T have to agree. You are completely absolutely 100% right that the {,f}stat() issues are deplorable and that any company having a decent respect for its customers would fix the problem. But it _is_ legal POSIX behaviour. Which is why I'm not so terribly impressed when John Earle said that about Apple and Microsoft not adopting POSIX. POSIX is fine, but it isn't perfect. Microsoft shows that "adopting" POSIX doesn't ensure producing something _good_; Apple show that not quite adopting POSIX doesn't mean what you have is necessarily _bad_. Can we get back to "How Can Haskell Be Saved" now? From ok at cs.otago.ac.nz Mon Dec 14 21:04:43 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 14 20:38:51 2009 Subject: [Haskell-cafe] Re: Allowing hyphens in identifiers In-Reply-To: <200912140511.59752.daniel.is.fischer@web.de> References: <7b501d5c0912080156l1f1e5038p96ff37adbc89e19b@mail.gmail.com> <200912121544.54220.daniel.is.fischer@web.de> <200912140511.59752.daniel.is.fischer@web.de> Message-ID: <69F305C7-DCF4-456A-9985-5A97120AC6AB@cs.otago.ac.nz> On Dec 14, 2009, at 5:11 PM, Daniel Fischer wrote: > 1. I wasn't playing in the under_score vs. camelCase game, just > proposing a possible > reason why the camelCase may have been chosen for Haskell's standard > libraries. But the insanely abbreviated example did not provide such a reason. You still haven't explained what the reason is supposed to be: it can't be that baStudlyCase salvages the readability of abbreviation because it doesn't. Indeed, it makes it worse, because you can't always tell where one abbreviation ends and another begins. In teaching an information retrieval paper, one of my favourite examples is unionised. Does it mean (union+ise)+ed "having had the workers organised into a union" or un+(ion+ised) "not having had its molecules turned into ions". When I mean the latter, I always write un-ionised. Now consider an actual Java class name, where I genuinely didn't know what the answer was. INSURL baStudlyCaps style for Java doesn't allow underscores in class names. (This is actual Sun code.) Is this something to do with insurance? Is this something to do with URLs for the US Immigration and Nationalization Service? Are Inertial Navigation Systems involved? Is the mention of 'URL' anything to do with URLs, or should this be parsed something like (I) (NSU) (RL)? With underscores, the actual parsing, INS_URL, would be unambiguous. Or take NVList, another real name. Is it an NV_List (where I don't know what NV is), an N_V_List (where I don't know what N and V are), or an N_VList (where I do know what a vlist is). In fact it's a Name_Value_List. I _might_ have had a clue with N_V_List... My point here is that if you separate words with spaces, dots, hyphens, underscores, backslashes, or almost anything, you are going to have _much_ less trouble with abbreviations than if you just jam them together baStudlyCaps-style. As for my "parody" of baStudlyCaps, thatIsExactlyHowItLooksToMe. > > I think you could find that written in many texts on aesthetic > relativism. They are empirically wrong. > Both are judgments based on their respective preferences and nothing > else I disagree. Sometimes, people can articulate _why_ they like or dislike things. For example, I like anything spacious and bright. This explains very well why I prefer landscapes (spacious) to portraits (not spacious). When it comes to depictions of plants, animals, people, and so on, I prefer healthy to unhealthy, friendly appearance to hostile/dangerous. Given that, you could probably predict my response to most paintings fairly well. If I and anyone I personally knew disagreed about which of two paintings was "better", I would expect to find that we quickly reached agreement about what features were _present_ to what _degree_ and about the technical standard of the work (on a rather coarse scale, but enough). The differences could be explained by the relative _weights_ we gave to the various features. Just as I have learned how to prepare tea and cook onions so that my wife will enjoy them, although I dislike the one and detest the other, so I would expect to be able to learn how to predict someone's aesthetic taste fairly well. Maybe we do agree. It wasn't clear whether by "preferences" you meant "weights" or "outcomes". The thing is, if "preferences" means "outcomes", there's no reason to expect that people will ever agree, whereas if it means "weights", then it should be possible to find or construct examples differing in a single feature where two people with different weights will agree on which is better. In the same way, when it comes to coding style, it may well be that we are responding to the same objective properties of styles, but weighting them differently. It appears, for example, that we both perceive abbreviation, and we both give it a negative weight. It is therefore to be expected that given two versions of a program in which the *only* thing changed is the degree and/or nature of abbreviation, we'll agree which is better and which is worse. For me to accept "personal preference" as a final explanation of something would be to accept an end to rational investigation. >> >> If it were just a matter of experience, then this experience should >> surely have taught me to love baStudlyCaps. > > No. It should have tought you to *read* camelCase - unless your > aversion is so strong that > you actively refuse to learn reading it. Where did you ever get the idea that I can't *read* baStudlyCaps? Just because I can read it doesn't mean that I can't read something else *better*. Life is hard enough without accepting unnecessary difficulties, even if they are moderately small ones. >> >>> Sourcecode is so different from ordinary text (a line of sourcecode >>> rarely >>> contains more than four or five words), I gave the wrong response to that yesterday. Later in the common room I realised what the perfect answer is: newspapers are ordinary text, newspaper columns are typically four or five words across. The number of words per line is therefore not a useful way to distinguish source code from ordinary text. >> >> baStudlyCaps doesn't read any better with short lines. > > I have no trouble reading either version. And that although this is > not what camelCase is > intended for (as far as I know, the purpose of it is to mark word > boundaries within *one > token* [identifier]). You missed the point of the example, which was that those words were joined (either by underscores or baStudlyJunctions) which formed sensible units. The junctions were not arbitrary. [1] > So? Whitespace helps tokenising and thus increases readability (for > me, at least). > [2] > What's the relation to the question whether camel case and > underscore are readable or not? In quotation [1], you concede the argument against baStudlyCaps. If white space helps finding units of meaning and thus increases readability for you, then white-or-functionally-white space should help finding units of meaning in program text, and baStudlyCaps should be less readable than separated_words. The only way to have your cake and eat it is to deny that the words making up a compound identifier _are_ units of meaning that should be perceived as such, or at least the only way that I can see. This seems an odd position to hold. >> "Persaude a man against his will, he's of the same opinion still." >> How _much_ evidence? > > Replicated studies with enough participants from enough different > environments/cultures > showing that more than 99% of the participants find it clearly more > readable. OK, there is no point in my continuing this. Such a level of study is not practically attainable. > > That's due to the *objectively*; for such a strong claim, you need > unusually strong evidence. This is NOT one of those extraordinary claims that require extraordinary evidence. It's an entirely humdrum claim that what makes ordinary text more readable makes something strongly resembling ordinary text more readable, and as such, perfectly ordinary experimental evidence should do. > > I take the widespread presence of both as an indication that the > majority isn't very > large, so you'd have a little work to do to convince me. You are making the assumption that the word separation style of programmers reflects their OWN initial preference. I am aware of no reason to believe that. People writing Pascal (which didn't _have_ an underscore because there wasn't one in the 6-bit character set it was designed for) or Smalltalk (which didn't _have_ an underscore because there wasn't one in the 7-bit character set it was designed for) simply didn't have a choice. Java's designers seem to have fairly mindlessly copied Smalltalk, and Java's users _have_ to use Java's vast range of predefined baStudlyCaps identifiers, so in effect have no choice. (Unless like me they have a preprocessor.) I dare to say that we agree that Java has many advantages over some of its rivals, so that using an uncomfortable word separation style may be compensated for by something else (such as NetBeans or Eclipse, maybe). I'm quite sure that we agree that Haskell has *huge* advantages. The unfortunate word separation style offsets that enough that it's worth programming around (using a preprocessor, for example), but not enough to make me stop using it. >> >> >> You're asking me to sacrifice readability everywhere else >> for the sake of one line in every 2850? (Not that I do >> find that line more readable in basStudlyCaps.) > > Not at all. What gave you that idea? The form of your argument. > > You prefer to read and write code in underscore style. Others prefer > camel case. > Without an easy way to convert, at least one group won't be happy. But there *IS* an easy way to convert. > If I can help improving it and making it more usable, I'd be happy > to (there are a couple of points where the transformation is not > trivial, {-# OPTIONS_GHC #-}, foreign import). Changes are not made inside {-...-} or "...", only to Haskell identifiers. There's one bug I'm aware of: -- is treated as a comment. From ok at cs.otago.ac.nz Mon Dec 14 21:59:06 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 14 21:33:21 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <1715450567.20091214131608@gmail.com> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> <1715450567.20091214131608@gmail.com> Message-ID: <7E33C0B0-60E0-4427-85B7-A33010C3198E@cs.otago.ac.nz> On Dec 14, 2009, at 11:16 PM, Bulat Ziganshin wrote: > POSIX subsystem was implemented by MS (and other major players) only > to meet some bureaucratic reqs from DoD/UsGov, and i don't know any > program really using it. There are two separate things being confused here, maybe three. (0) "POSIX" functions in the Windows C library. (1) The original POSIX subsystem in Windows NT. As far as I know it isn't shipped any more. (2) Softway Systems' "Interix"/SFU/SUA. Microsoft bought Softway. Softway wrote Interix to make money out of people who wanted a workable Unix environment on Windows. This _is_ amongst other things a "subsystem", but it's NOT the one that was originally written to let weasels tick the "POSIX" box. I was talking about (2), not (1) or (0). This does matter for Haskell people wanting to use Haskell on Windows. It would be very interesting to know whether Haskell can be built to run under Services for Unix Applications (SUA) -- after all, Qt, SSH, Apache, and so on have been. From ok at cs.otago.ac.nz Mon Dec 14 22:03:17 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Dec 14 21:37:24 2009 Subject: [Haskell-cafe] Re: How Can Haskell Be Saved? In-Reply-To: <1260786794.9220.24393.camel@localhost> References: <12303CDB02D94A86B4BDE384BA5C8B31@JohnPC> <20091214134422.722a9d50.mle+hs@mega-nerd.com> <517164288.20091214114449@gmail.com> <20091214210258.a15e32de.mle+hs@mega-nerd.com> <1260786794.9220.24393.camel@localhost> Message-ID: <4491654C-EB46-4716-9D2F-8D4F165F8A39@cs.otago.ac.nz> > On Mon, 2009-12-14 at 21:02 +1100, Erik de Castro Lopo wrote: >> Bulat Ziganshin wrote: >> >>> POSIX is a *subsystem*. you are using Win32 subsystem. There is also >>> OS2 subsystem for execution of 16-bit OS/2 programs >>> >>> partial emulation of POSIX API in C compiler libraries has nothing >>> common with subsystem implemented as part of the OS. you have never >>> used POSIX subsystem actually (and btw, it's absent in Win9x line) >> >> Please enlighten me. How do I access the POSIX subsystem? (1) Install Services for Unix. (2) Start it. You are now running bash staring at something rather like Unix. (3) Build programs using c89, which comes with it, but needs MSVC, or gcc, which you can download from http://www.suacommunity.com/tool_warehouse.htm From bulat.ziganshin at gmail.com Tue Dec 15 01:51:45 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Dec 15 01:27:21 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: References: <20091214211629.GA8448@whirlpool.galois.com> <20091214213401.GB8448@whirlpool.galois.com> Message-ID: <225100812.20091215095145@gmail.com> Hello Brad, Tuesday, December 15, 2009, 1:55:41 AM, you wrote: > How about a fast STHashTable? you can use array of arrays instead of large array -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue Dec 15 02:42:01 2009 From: dons at galois.com (Don Stewart) Date: Tue Dec 15 02:16:08 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: <225100812.20091215095145@gmail.com> References: <20091214211629.GA8448@whirlpool.galois.com> <20091214213401.GB8448@whirlpool.galois.com> <225100812.20091215095145@gmail.com> Message-ID: <20091215074201.GB10287@whirlpool.galois.com> bulat.ziganshin: > Hello Brad, > > Tuesday, December 15, 2009, 1:55:41 AM, you wrote: > > > How about a fast STHashTable? > > you can use array of arrays instead of large array Note to minmize the issue, but we get many of the same benefits via the associated type transformation (e.g. for arrays of pairs/complex/triples) -- Don From bulat.ziganshin at gmail.com Tue Dec 15 03:06:25 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Dec 15 02:40:59 2009 Subject: [Haskell-cafe] Boxed Mutable Arrays In-Reply-To: <20091215074201.GB10287@whirlpool.galois.com> References: <20091214211629.GA8448@whirlpool.galois.com> <20091214213401.GB8448@whirlpool.galois.com> <225100812.20091215095145@gmail.com> <20091215074201.GB10287@whirlpool.galois.com> Message-ID: <9210410404.20091215110625@gmail.com> Hello Don, Tuesday, December 15, 2009, 10:42:01 AM, you wrote: >> > How about a fast STHashTable? >> >> you can use array of arrays instead of large array > Note to minmize the issue, but we get many of the same benefits via the > associated type transformation (e.g. for arrays of > pairs/complex/triples) Data.HashTable uses array of lists, so it can't be unboxed -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bos at serpentine.com Tue Dec 15 03:11:14 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Dec 15 02:45:19 2009 Subject: [Haskell-cafe] [ANN] text 0.7, fast Unicode text Message-ID: The new 0.7 release of the text packageadds support for Unicode I/O, using either the new locale-aware Handle code in 6.12 or a fallback on older releases. Details: http://www.serpentine.com/blog/2009/12/15/data-text-0-7-gains-io-support/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091215/94da7757/attachment.html From dons at galois.com Tue Dec 15 03:18:07 2009 From: dons at galois.com (Don Stewart) Date: Tue Dec 15 02:52:11 2009 Subject: [Haskell-cafe] [ANN] text 0.7, fast Unicode text In-Reply-To: References: Message-ID: <20091215081807.GB10482@whirlpool.galois.com> bos: > The new 0.7 release of the text package adds support for Unicode I/O, using > either the new locale-aware Handle code in 6.12 or a fallback on older > releases. > > Details:?http://www.serpentine.com/blog/2009/12/15/ > data-text-0-7-gains-io-support/ That was ridculously fast. -- Don From emax at chalmers.se Tue Dec 15 03:19:10 2009 From: emax at chalmers.se (Emil Axelsson) Date: Tue Dec 15 02:53:16 2009 Subject: [Haskell-cafe] writing graphs with do-notation In-Reply-To: <664C4719-9D3F-4207-8361-36E2D4B45D90@gmail.com> References: <200912122200.40692.shahn@cs.tu-berlin.de> <4B25DFB8.6090803@chalmers.se> <664C4719-9D3F-4207-8361-36E2D4B45D90@gmail.com> Message-ID: <4B27467E.3060303@chalmers.se> Yes, that's probably close to what I want. It would of course be nice to also have a monadic/applicative interface for building the graphs. In libraries like Wired where you're in a monad anyway, this would get rid of the need for IO. Koen Claessen has made a sketch of a generic graph library that we were planning to use as a basis for the EDSLs at Chalmers. But as far as I remember it looked a lot like the graph in data-reify, so maybe we should just use that instead. / Emil Levent Erkok skrev: > Andy Gill wrote a very nice recent paper on this topic which can serve > as the basis for a generic implementation: > > http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09 > > As long as you do your "reification" in the IO monad, Andy's library > gives you the graph conversion for (almost-) free. > > -Levent. > > On Dec 13, 2009, at 10:48 PM, Emil Axelsson wrote: >> Hi! >> >> This technique has been used to define netlists in hardware >> description languages. The original Lava [1] used a monad, but later >> switched to using observable sharing [2]. Wired [3] uses a monad >> similar to yours (but more complicated). >> >> I think it would be nice to have a single library for defining such >> graphs (or maybe there is one already?). The graph structure in >> Wired could probably be divided into a purely structural part and a >> hardware-specific part. >> >> [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.5221 >> [2] http://www.cs.chalmers.se/~dave/papers/observable-sharing.pdf >> [3] http://hackage.haskell.org/package/Wired >> >> / Emil >> >> >> >> Soenke Hahn skrev: >>> Hi! >>> Some time ago, i needed to write down graphs in Haskell. I wanted >>> to be able to write them down without to much noise, to make them >>> easily maintainable. I came up with a way to define graphs using >>> monads and the do notation. I thought this might be interesting to >>> someone, so i wrote a small script to illustrate the idea. Here's >>> an example: >>> example :: Graph String >>> example = buildGraph $ do >>> a <- mkNode "A" [] >>> b <- mkNode "B" [a] >>> mkNode "C" [a, b] >>> In this graph there are three nodes identified by ["A", "B", "C"] >>> and three edges ([("A", "B"), ("A", "C"), ("B", "C")]). Think of >>> the variables a and b as outputs of the nodes "A" and "B". Note >>> that each node identifier needs to be mentioned only once. Also the >>> definition of edges (references to other nodes via the outputs) can >>> be checked at compile time. >>> The attachment is a little script that defines a Graph-type >>> (nothing elaborate), the "buildGraph" function and an example graph >>> that is a little more complex than the above. The main function of >>> the script prints the example graph to stdout to be read by dot (or >>> similar). >>> By the way, it is possible to define cyclic graphs using mdo >>> (RecursiveDo). >>> I haven't come across something similar, so i thought, i'd share >>> it. What do you think? >>> S?nke >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > From marlowsd at gmail.com Tue Dec 15 04:19:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Dec 15 03:53:46 2009 Subject: [Haskell-cafe] Re: Parallel foldl doesn't work correctly In-Reply-To: <1260837428.3898.126.camel@phil-desktop> References: <1260586642.3898.9.camel@phil-desktop> <1260612497.2575.13.camel@picard> <1260727774.3898.104.camel@phil-desktop> <4B263B7E.8030103@gmail.com> <1260837428.3898.126.camel@phil-desktop> Message-ID: <4B2754A8.8070103@gmail.com> On 15/12/09 00:37, Philip Beadling wrote: > >> If you still have trouble, then try using ThreadScope >> >> http://code.haskell.org/ThreadScope/ >> >> with GHC 6.12.1. You can use ThreadScope directly from the darcs >> repository on code.haskell.org, and we hope to do a proper release soon. >> >> Cheers, >> Simon > > Thanks for the advice, just downloaded ThreadScope and it's pretty > useful (before I was using Ubuntu's System Monitor which isn't ideal). > > I've moved onto 6.12 and I now have my program working nicely over 2 > cores - the problem was at least in part my own design - I was > generating large thunks in my parallel version which was killing > performance. With this solved 2 cores gives me ~50% performance > increase. > > What I'm doing now is taking a list I am going to fold over and > splitting it up so I have a list of lists, where each parent list > element representing work for 1 core. I then fold lazily and only > parallelise on the final sum operation which (as far as I can see) sends > each chunk of folds to a different core and sums the results. > > Can I confirm - what you are suggesting is that although I can't > parallelise fold itself, I could force evaluation on the list I am about > to fold in parallel and then merely accumulate the result at the end -- > thus most the donkey work is done in parallel? Yes. If it turns out that the list elements are too small to spark individually, then you may want to split the list into chunks and evaluate/sum the chunks in parallel, before summing the result. This is a typical map/reduce pattern. Cheers, Simon From qdunkan at gmail.com Tue Dec 15 05:04:18 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Dec 15 04:38:22 2009 Subject: [Haskell-cafe] Yay 6.12.1! Message-ID: <2518b95d0912150204t6bfb9d07q28fed7398f05640c@mail.gmail.com> So far, this new release has let me remove: - The new "Import of xyz is redundant" warning pointed out tons of cruft in my imports: 117 of them! Apparently it's better than the 6.10 algorithm. It's amazing how much cruft builds up in import lists over time even with -Wall. One issue is that I can still get a spurious warning from it: if I have 'import qualified Text.Read as Read' and then have some Read instances, it will think the import is redundant even though it won't compile without it (`readPrec' is not a (visible) method of class `Read'). The interesting thing is that even though I'm importing it qualified, I write the readPrec in the instance without qualification since 'instance Read X where Read.readPrec = ...' is not allowed. So maybe ghc is confused by that since it doesn't see a Read. anywhere. Importing unqualified doesn't make the warning. - I removed {-# OPTIONS_GHC -fno-warn-unused-imports #-} from a lot of files, now that the bugs that make spurious import warns are fixed. And the bogus warnings with view patterns are gone. - I removed a local version of Data.Map, now that toDescList is in. - Passing -I/path/to/ghc/include to hsc2hs to get it to include HsFFI.h seems to no longer be necessary. - The warnings "-#include is deprecated: No longer has any effect" are not quite right, because they are reuired by hsc2hs, and in fact hsc2hs is inserting {-# INCLUDE "c_