- Haskell-Cafe - Haskell.org

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 06 Sep '11

06 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 05 Sep '11

05 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ć 05 Sep '11

05 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

Lens with merge (Semigroup)
by Tony Morris 05 Sep '11

05 Sep '11

A regular Lens can be represented as follows: data CoState a = CoState (a -> b) a newtype Lens a b = Lens (a -> CoState b a) I once read about a lens representation that permits a general "merge" operation. I forget where I read it -- I think it was #haskell IRC. However, as I recall, perhaps incorrectly, the merge operation involves a Semigroup[1] and helps to overcome the fact that Lens is not an Arrow and so does not have a (&&&) operation. I am interested to know what this Lens operation is and the associated merge operation. [1] -- Approximate data SemigroupT f a = SemigroupT (a -> a -> f a) -- Tony Morris http://tmorris.net/

1 0

Call for papers: Programming languages meets program verification
by Nikhil Swamy 04 Sep '11

04 Sep '11

PLPV 2012 The Sixth ACM SIGPLAN Workshop Programming Languages meets Program Verification 24th January, 2012 Philadelphia, USA (Affiliated with POPL 2012) http://research.microsoft.com/en-us/um/people/nswamy/plpv12 -------------------------------------------------------------------------------- Overview The goal of PLPV is to foster and stimulate research at the intersection of programming languages and program verification, by bringing together experts from diverse areas like types, contracts, interactive theorem proving, model checking and program analysis. Work in this area typically attempts to reduce the burden of program verification by taking advantage of particular semantic or structural properties of the programming language. Examples include dependently typed programming languages, which leverage a language's type system to specify and check richer than usual specifications or extended static checking systems which incorporate contracts with either static or dynamic contract checking. We invite submissions on all aspects, both theoretical and practical, of the integration of programming language and program verification technology. To encourage cross-pollination between different communities, we seek a broad scope for PLPV. In particular, submissions may have diverse foundations for verification (Type-based, Hoare-logic-based, Abstract Interpretation-based, etc.), target different kinds of programming languages (functional, imperative, object-oriented, etc.), and apply to diverse kinds of program properties (data structure invariants, security properties, temporal protocols, resource constraints, etc.). -------------------------------------------------------------------------------- Important Dates: Submission: 11th October, 2011 Notification: 8th November, 2011 Final Version: 15th November, 2011 Workshop: 24th January, 2012 -------------------------------------------------------------------------------- Submissions We seek submissions of up to 12 pages related to the above topics---shorter submissions are also welcome. Submissions may describe new work, propose new challenge problems for language-based verification techniques, or present a known idea in an elegant way (i.e., a pearl). Submissions should be prepared with SIGPLAN two-column conference format (http://www.sigplan.org/authorInformation.htm) Submitted papers must adhere to the SIGPLAN republication policy (http://www.sigplan.org/republicationpolicy.htm) Concurrent submissions to other workshops, conferences, journals, or similar forums of publication are not allowed. To submit a paper, access the submission site at http://www.easychair.org/conferences/?conf=plpv2012. -------------------------------------------------------------------------------- Publication Accepted papers will be published by the ACM and will appear in the ACM Digital library. -------------------------------------------------------------------------------- Program Committee Amal Ahmed Indiana University Lennart Augustsson Standard Chartered Koen Claessen Chalmers (co-chair) Martin Giese University of Oslo Daniel Licata Carnegie Mellon University Peter MÃ¼ller ETH Zurich Aleksandar Nanevski IMDEA Matthieu Sozeau INRIA Nikhil Swamy Microsoft Research (co-chair) David Walker Princeton University Dana Xu INRIA -------------------------------------------------------------------------------- Previous PLPVs: http://plpv.org

1 0