- Haskell-Cafe - Haskell.org

Is there any way to parametrize a value update using record syntax?
by Poprádi Árpád 08 Sep '11

08 Sep '11

Hi all, i have a record with a lot of items used in a state monad. data BigData = BigData { data1 :: X , data2 :: X -- and so on } type MonadicEnv a = State BigData a I updates the fields in the computation with such functions: updateData1 :: X -> MonadicEnv() updateData1 d = do; env <- get; put env {data1 = d} updateData2 :: X -> MonadicEnv() updateData2 d = do; env <- get; put env {data2 = d} But it's ugly. Always the same, only the record selector has another name. Is it possible to generalize it? Thanks, Árpád

5 5

Data.IArray rant
by Evan Laforge 07 Sep '11

07 Sep '11

I never liked Data.IArray. Recently I had to deal with it again and it kind of touched off a bit of a rant: Array bounds are an inclusive range, which runs counter to almost all other uses of ranges, and for good reason. Length of an array is (high - low + 1). If you want to convert a list to an array it's 'IArray.listArray (0, length xs - 1) xs'. And if you forget to subtract one or add one it's likely to be a runtime crash. Off-by-one errors and runtime crashes... I've gotten accustomed to not having those in haskell! The vast majority of data types have their own set of monomorphic fuctions, and yet array all of the sudden wants to be an interface. That's nice and all, but who actually uses that interface? I recall there used to be a DiffArray and some other variants, but they were decried as being slow and appear to be gone now. So it appears that there's a complexity price paid to support different array types under the same interface, namely giant class contexts that can't be abstracted away and dependence on MPTCs... and appears to be unused. And then another price paid to support arbitrary indices... which I at least have never used. Maybe there is a field where arrays with strange index ranges like 5--20 are useful, but I always just want 0--length-1. Meanwhile, they lack basic features like concatenation. No Monoid instance. In fact, hardly any useful instances. The result is that my first contact with haskell arrays left me with the impression that they were complicated, hard to use, and designed for someone with different priorities than me. Of course, Data.Vector didn't exist back then, but if someone were new to haskell now I would recommend they skip Data.IArray and head straight for vector. If they wanted 2 dimensional arrays then I know there are some matrix libraries. Of course, sometimes IArray is hard to avoid, e.g. Data.Graph is just a type synonym for an array. I wrote a small library of graph utilities, and dealing with the arrays was back to awkward land. So... am I alone in this dislike of IArray? Or maybe someone can explain why it's actually a very useful interface? Admittedly vector is a mere 'cabal install' away, but array has a blessed status as a ghc bundled library and is likely to be the first place people will look, as well as the natural base for other data types that want an array, like Data.Graph. I know it's not as simple as "just debundle IArray" because it's a bootlib and presumably used in ghc itself, though I know there is support for reducing the set of bootlibs. There's also the whole mutable interface, which I haven't used, but maybe I'd like it more. I know the array stuff winds up integrated fairly deeply with ghc's unboxed arrays and whatnot, so there's a lot of detail I don't understand. I just know I dread going back to array using code while I tend to enjoy working with vector, bytestring, text, storablevector, etc.

7 10

Memoization of functions
by Michael Orlitzky 07 Sep '11

07 Sep '11

I'm working on a program where I need to compute a gajillion (171442176) polynomials and evaluate them more than once. This is the definition of the polynomial, and it is expensive to compute: > polynomial :: Tetrahedron -> (RealFunction Point) > polynomial t = > sum [ (c t i j k l) `cmult` (beta t i j k l) | i <- [0..3], > j <- [0..3], > k <- [0..3], > l <- [0..3], > i + j + k + l == 3] Currently, I'm storing the polynomials in an array, which is quickly devoured by the OOM killer. This makes me wonder: how much memory can I expect to use storing a function in an array? Is it possible to save some space through strictness? Does that question even make sense?

2 1

Re: [Haskell-cafe] Configuration Problem and Plugins
by M. George Hansen 07 Sep '11

07 Sep '11

On Sat, Sep 3, 2011 at 12:33 AM, Max Rabkin <max.rabkin(a)gmail.com> wrote: > On Sat, Sep 3, 2011 at 03:15, M. George Hansen <technopolitica(a)gmail.com> wrote: >> Greetings, >> >> I'm a Python programmer who is relatively new to Haskell, so go easy on me :) >> >> I have a program that uses (or will use) plugins to render output to >> the user in a generic way. I'm basing the design of the plugin >> infrastructure on the Plugins library, and have the following >> interface: >> >> data Renderer = Renderer { >> initialize :: IO (), >> destroy :: IO (), >> render :: SystemOutput -> IO () >> } > > How about having initialize return the render (and destroy, if > necessary) functions: > > initialize :: IO (SystemOutput -> IO ()) > > or > > initialize :: IO (SystemOutput -> IO (), IO()) > Thanks for your reply. That does seem like the best solution, I'll give it a try. -- M. George Hansen

2 1

EclipseFP fails to install
by Henk-Jan van Tuyl 06 Sep '11

06 Sep '11

L.S., I have installed Eclipse 3.7 and EclipseFP 2.1.0 on my Windows XP computer After trying to install EclipseFP in Eclipse, I got the following message: C:\Programs\Haskell Platform\2011.2.0.1\bin\ghc-pkg.exe dump --global cabal.0.6.0.exe: failed to parse output of 'ghc-pkg dump' What can I do about this? Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

2 1

ANN: Netwire 1.2.0
by Ertugrul Soeylemez 06 Sep '11

06 Sep '11

Hello there, version 1.2.1 of netwire is out. New features include: * Completely reworked event system. Events are now solely based on signal inhibition, which turns out to be much more convenient and faster than AFRP's traditional approach using Maybe-wrapped values. Now instead of checking for the presence of an event, you simply assume that it happened. If it didn't happen, then the signal is inhibited and your wire is not run. This makes your code much simpler, because you get along almost entirely without switches. Example displaying a discrete clock updated at intervals of half a second: system :: forall m. Monad m => Wire m () String system = proc _ -> printf "%8.2f" ^<< hold discreteClock -< () where discreteClock :: Wire m () Double discreteClock = proc _ -> do t <- time -< () repeatedly -< (0.5, t) By using ArrowPlus or Alternative, you can handle the case, where the event did not happen, listening for alternative events or simply having a fallback. By using the various wire combinators you can hold, sample, keep or exhibit event values as shown above. * Lots and lots of Haddock documentation improvements. Now the inhibition and feedback behaviour of every builtin wire is documented. * Apropos feedback: Finally added an ArrowLoop instance, so you can now have recursive values in your wires. There is a catch though: Right now wires which produce values used recursively must not inhibit. There is an inherent problem handling the inhibition case, which you will observe as a pattern match error. Right now I don't have a solution for this problem, but I'm working on it. However, it may well be that it simply cannot be solved with my current internal wire representation. This is the price to pay for signal inhibition. To prevent (or rather catch) inhibition you can use the 'exhibit' or 'event' combinators. * Many small performance improvements. Simple signal networks go well beyond 35000 frames per second on my mobile Intel i7 with 1.7 GHz and their executables cost well less than 5 MiB RAM. The performance passes the 50k FPS mark on my i5 with 2.8 GHz at home. This is more than a 10x speedup compared to my last benchmark on the initial release of version 1.0.0 * Removed some of variations of existing wires and replaced them by wire combinators instead. For example 'executeOnce' and 'executeEvery' are gone. Instead you should use the normal 'execute' wire together with 'swallow', 'sample', 'hold' or other combinators. * Changed the semantics of all wires to support feedback. Now some wires support feedback right away, while for others you need a one-instant delay. The feedback behaviour of all wires is Haddock-documented, as noted. Enjoy and please give me as much feedback as possible. =) Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

1 1

GHC/Cabal on AFS
by Tristan Ravitch 06 Sep '11

06 Sep '11

I have the Haskell Platform (and my home directory with my cabal-installed packages) installed on an AFS (a network filesystem) volume and have been noticing a strange issue. Whenever I install a package using cabal-install and it gets to a phase of the build where it needs to load a bunch of packages, the build fails without a useful error. Example: cabal-dev install yesod Resolving dependencies... Configuring yesod-core-0.9.1.1... Preprocessing library yesod-core-0.9.1.1... Preprocessing test suites for yesod-core-0.9.1.1... Building yesod-core-0.9.1.1... [ 1 of 15] Compiling Yesod.Internal.Session ( Yesod/Internal/Session.hs, dist/build/Yesod/Internal/Session.o ) [ 2 of 15] Compiling Paths_yesod_core (dist/build/autogen/Paths_yesod_core.hs, dist/build/Paths_yesod_core.o) [ 3 of 15] Compiling Yesod.Logger (Yesod/Logger.hs,dist/build/Yesod/Logger.o ) [ 4 of 15] Compiling Yesod.Internal.RouteParsing(Yesod/Internal/RouteParsing.hs,dist/build/Yesod/Internal/RouteParsing.o) [ 5 of 15] Compiling Yesod.Internal (Yesod/Internal.hs,dist/build/Yesod/Internal.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package bytestring-0.9.1.10 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package text-0.11.0.5 ... cabal: Error: some packages failed to install: yesod-0.9.1.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-auth-0.7.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-core-0.9.1.1 failed during the building phase. The exception was: ExitFailure 7 yesod-form-0.3.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-json-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-persistent-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. If I keep re-running it, it will eventually succeed. It also always makes forward progress (the next attempt will get past text and a few more packages). It seems to be related to the state of the AFS cache; if all of the required packages are in the local AFS cache it usually just works. If the cache has just been flushed (due to other FS operations), this failure pretty much always shows up. Has anyone else experienced anything like this? Alternatively, does anyone have ideas on getting a more useful error message/tracking it down? I didn't see any relevant bugs filed yet, but I wanted to get more information before adding a report.

3 2

Smarter do notation
by Daniel Peebles 06 Sep '11

06 Sep '11

Hi all, I was wondering what people thought of a smarter do notation. Currently, there's an almost trivial desugaring of do notation into (>>=), (>>), and fail (grr!) which seem to naturally imply Monads (although oddly enough, return is never used in the desugaring). The simplicity of the desugaring is nice, but in many cases people write monadic code that could easily have been Applicative. For example, if I write in a do block: x <- action1 y <- action2 z <- action3 return (f x y z) that doesn't require any of the context-sensitivty that Monads give you, and could be processed a lot more efficiently by a clever Applicative instance (a parser, for instance). Furthermore, if return values are ignored, we could use the (<$), (<*), or (*>) operators which could make the whole thing even more efficient in some instances. Of course, the fact that the return method is explicitly mentioned in my example suggests that unless we do some real voodoo, Applicative would have to be a superclass of Monad for this to make sense. But with the new default superclass instances people are talking about in GHC, that doesn't seem too unlikely in the near future. On the implementation side, it seems fairly straightforward to determine whether Applicative is enough for a given do block. Does anyone have any opinions on whether this would be a worthwhile change? The downsides seem to be a more complex desugaring pass (although still something most people could perform in their heads), and some instability with making small changes to the code in a do block. If you make a small change to use a variable before the return, you instantly jump from Applicative to Monad and might break types in your program. I'm not convinced that's necessary a bad thing, though. Any thoughts? Thanks, Dan

11 21

The maximum/minimum asymmetry
by Mario Blažević 06 Sep '11

06 Sep '11

I was recently surprised to discover that the maximum and maximumBy functions always return the *last* maximum, while minimum and minimumBy return the *first* minimum in the list. The following GHCi session demonstrates this: $ ghci GHCi, version 7.2.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> :module +Data.List Data.Ord Prelude Data.List Data.Ord> let list = [(1, 'B'), (1, 'A')] Prelude Data.List Data.Ord> maximumBy (comparing fst) list (1,'A') Prelude Data.List Data.Ord> minimumBy (comparing fst) list (1,'B') I would normally consider this kind of gratuitous asymmetry a bug, but seeing that these functions' implementations have been specified in the Haskell 98 Library Report, I guess they are now a permanent feature of the language. Can anybody explain the reason for this behaviour?

5 5

Idiomatic usage of the fixpoint library
by Roman Cheplyaka 05 Sep '11

05 Sep '11

Hi, I'm looking for an example of idiomatic usage of the fixpoint library[1]. [1]: http://hackage.haskell.org/package/fixpoint-0.1.1 Here's what I managed to get: {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances, FlexibleInstances #-} import Data.Fixpoint newtype Expr = Expr { unExpr :: Pre Expr Expr } instance Functor (Pre Expr) => Fixpoint Expr where data Pre Expr a = Add a a | Const Int project = unExpr inject = Expr instance Functor (Pre Expr) where fmap f (Const x) = Const x fmap f (Add x1 x2) = Add (f x1) (f x2) eval = cata eval' where eval' (Const x) = x eval' (Add x1 x2) = x1 + x2 There are some issues with this code, compared to simply using newtype Fix f = In { out :: f (Fix f) } to build an Expr. 1. Since 'Pre' is a data (not type) family, we cannot simply make use of a functor defined elsewhere. We need to define the functor inside the instance declaration (or at least wrap an existing functor). 2. I wasn't able to derive the Functor instance, getting an error Derived instance `Functor (Pre Expr)' requires illegal partial application of data type family Pre In the data type instance declaration for `Pre' 3. Having to use UndecidableInstances makes me feel a bit uncomfortable. This makes me think that the intended usage is somewhat different. So, could someone give an example? -- Roman I. Cheplyaka :: http://ro-che.info/

3 4