- Beginners - Haskell.org

Help with Why Do Monads Matter blog post understanding
by Matt Ford 04 Jul '12

04 Jul '12

Hi, I've been reading the following blog post https://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/ And I think I like it. But there's a part that I don't get. "For a set A, we will define the set Pref(A) to be the set of functions from application settings to the set A. Now watch closely: a function in context from A to B is just an ordinary function from A to Pref(B). In other words, you give it a value from the set A, and it gives you back another function that maps from application settings to the set B." This is in the "functioning with dependency" section and is talking about a procedure that uses outside info from preferences or application settings. If I set my prefs as follows configvar = 3 and define a function as follows add x = configvar + 6 So add’s signature is add: int -> int What does prefs(int) look like? Is that even the right thing to ask? What happens to the add function? By substituting the B for Prefs(B) and returning now only functions from Pref(B) don't we lose the rest of the mapping for add i.e., " + 6"? Matt.

3 4

FRP and a set of pairwise interacting (colliding) objects
by Nathan Hüsken 02 Jul '12

02 Jul '12

Hi, I want to simulate as set of 2D objects, which can collide pairs wise with each other. In an OOP language, I would do this: for (o1 in objects) { for (o2 in objets) { if (testCollision(o1, o2)) { CollData cd = getCollisionData(o1,o2); o1.reactToCollision(cd); o2.reactToCollision(cd): } } } Now I want to do the same thing in Haskell with FRP. Normally in FRP (correct me if I am wrong) I have for my objects a Signal (or whatever it is called in the specific library), which gets as input the collision events for this object (and probably more data, but let's assume collision events are enough): object :: Signal (Event CollData) ObjectState The CollData events themself are generated at another place: collisions :: Signal [ObjectState] (Event CollData) But now the collisions are generated at one place, and processed at another. This means that CollData must be somehow tagged to the objects it belongs to (an ID for example). This again means that some function must take the pool of all collision datas and distribute them to the "object" Signals. When I have a lot of objects, this means a significant overhead! Now I am wondering if there is a nicer approach which avoids this overhead. Thanks! Nathan

2 3

Improving Performance
by Robert Heumüller 02 Jul '12

02 Jul '12

Hello, in order to tune my brain to "functional thinking" I've decided to start writing some "real" programs. After having spent a couple of days figuring out how to translate an imperative algorithm into stateless haskell I beleive I've now managed a simple implementation of the DBSCAN clustering algorithm. http://privatepaste.com/e6bb4fb665 This code has several drawbacks (and probably it doesn't work correctly after all) but I would like to tune its performance. Obviously the code calls several functions multiply with the same arguments. Haskell, being stateless should thus always yield the same resuts, correct? In this case performing the same calculations multiply seems pointless. My question: How would you go about improving this code? In any imperative language I would simply cache distances/neighborhoods in a matrix. Obviously this is not what the way to go in haskell? Thank you very much

3 7

Re: [Haskell-beginners] test-framework
by Mateusz Neumann 30 Jun '12

30 Jun '12

On Fri, 29 Jun 2012 08:43:33 +0100 Lorenzo Bolla <lbolla(a)gmail.com> wrote: > Are the examples in the package distribution of any help? > https://github.com/batterseapower/test-framework/blob/master/example/Test/F… > > L. I was thinking more about parametres set in Haskell code itself. There is something like TestOptions (http://hackage.haskell.org/packages/archive/test-framework/0.6/doc/html/Tes…) and RunnerOptions (http://hackage.haskell.org/packages/archive/test-framework/0.6/doc/html/Tes…) but I do not find any examples of using them. Similarly, I do not know how to set them up. > On Fri, Jun 29, 2012 at 6:30 AM, Mateusz Neumann > <mateusz(a)neumanny.net>wrote: > > > Hi, > > > > I am currently writing testing routines for my project. I have came > > across an interesting test-framework > > (http://hackage.haskell.org/package/test-framework-0.6) Do you > > know it? I use QuickCheck2 provider > > (Test.Framework.Providers.QuickCheck2) to property tests. And here > > is my problem: I find configuring the provider very confusing, I > > cannot set (in Haskell code) for example number of tests to run or > > other QuickCheck parameters. Could you please help? > > > > Thanks > > > > -- > > Mateusz > > > > _______________________________________________ > > Beginners mailing list > > Beginners(a)haskell.org > > http://www.haskell.org/mailman/listinfo/beginners > > > > -- Mateusz

2 2

test-framework
by Mateusz Neumann 29 Jun '12

29 Jun '12

Hi, I am currently writing testing routines for my project. I have came across an interesting test-framework (http://hackage.haskell.org/package/test-framework-0.6) Do you know it? I use QuickCheck2 provider (Test.Framework.Providers.QuickCheck2) to property tests. And here is my problem: I find configuring the provider very confusing, I cannot set (in Haskell code) for example number of tests to run or other QuickCheck parameters. Could you please help? Thanks -- Mateusz

1 0

No accumulation of partially applied functions allowed?
by Obscaenvs 28 Jun '12

28 Jun '12

Sorry if this is a less than stellar question. The problem: Given a function f :: a -> a -> a -> b, make it work on a list instead: f `applyTo`[x,y,z] where [x,y,z] :: [a]. My stab at a general solution was ` applyTo f [] = error "no arg" applyTo f (x:xs) = go (f x) xs where go acc [] = acc go acc (y:[]) = acc y go acc (y:ys) = go (acc $ y) ys ` I thought this would work, functions being "first class citizens" but ghci complains: "Occurs check: cannot construct the infinite type: t1 = t0 -> t1 In the return type of a call of `acc' Probable cause: `acc' is applied to too many arguments In the expression: acc y In an equation for `go': go acc (y : []) = acc y" The 'probable cause' isn't the real cause here, but something to do with the fact that it's impossible to accumulate functions in this way... Or am I just too tired too make it work? I can see that the type of `go` could be a problem, but is it insurmountable? /F

4 5

Re: [Haskell-beginners] No accumulation of partially applied functions allowed?
by ARJANEN Loïc Jean David 27 Jun '12

27 Jun '12

It is easy, but inconvenient to define applyTo on tuples, which are Haskell's standard container for heterogeneous collections (that would basically be an extension of Prelude's uncurry), but they would be inconvenient to define and quite unwieldy to use. If you limit yourself to homogeneous collections (that is, lists), it's possible but using typeclass hackery and you shouldn't do so unless you need to. for an example of such techniques, see HaXR<http://www.haskell.org/haskellwiki/HaXR> or hs-json-rpc <http://hackage.haskell.org/package/hs-json-rpc> where this kind of tricks are used to implement remote calls. 2012/6/27 Jay Sulzberger: > > On Tue, 26 Jun 2012, Alec Story <avs38(a)cornell.edu> wrote: > >> Because of Haskell's type system, there are some expressions that you >> simply cannot compile. Most of them you don't *want* to compile because >> they do bad things (like add two strings, for example). Some things are >> legal in Lisp but don't typecheck in Haskell for exactly the reasons that >> Brent pointed out. They might make sense in some contexts, but the >> compiler isn't able to reason about them. > > > Thanks, Alec. > > What is a formalized version of > > It is not possible in Haskell to define `applyTo`.* > * At least not without crazy type class hackery. > > I think the difficulty must arise mainly from the *, meaning I > think, "any type" in the above `applyTo`.*. Would it be > easy/convenient to define `applyTo`.(a, b, c) where a is a "type > variable"? In general can we, for any finite number n, where n > 2, > easily/conveniently define `applyTo`.(a1, a2, ..., an) ? > > Ah, I see that the problem is for lists of length 3, so for the > type, if it be such, that I might write as [a, a, a], ah, OK, I > will fire up GHCi and have a look. > > oo--JS. > > >> >> On Tue, Jun 26, 2012 at 5:19 PM, Jay Sulzberger <jays(a)panix.com> wrote: >> >>> >>> >>> On Tue, 26 Jun 2012, Brent Yorgey <byorgey(a)seas.upenn.edu> wrote: >>> >>> On Tue, Jun 26, 2012 at 10:08:49PM +0200, Obscaenvs wrote: >>>> >>>> >>>>> Sorry if this is a less than stellar question. >>>>> >>>>> The problem: >>>>> Given a function f :: a -> a -> a -> b, make it work on a list >>>>> instead: f `applyTo`[x,y,z] where [x,y,z] :: [a]. >>>>> My stab at a general solution was >>>>> ` >>>>> applyTo f [] = error "no arg" >>>>> applyTo f (x:xs) = go (f x) xs >>>>> where >>>>> go acc [] = acc >>>>> go acc (y:[]) = acc y >>>>> go acc (y:ys) = go (acc $ y) ys >>>>> ` >>>>> >>>>> I thought this would work, functions being "first class citizens" but >>>>> ghci complains: >>>>> "Occurs check: cannot construct the infinite type: t1 = t0 -> t1 >>>>> In the return type of a call of `acc' >>>>> Probable cause: `acc' is applied to too many arguments >>>>> In the expression: acc y >>>>> In an equation for `go': go acc (y : []) = acc y" >>>>> >>>>> The 'probable cause' isn't the real cause here, but something to do >>>>> with the fact that it's impossible to accumulate functions in this >>>>> way... >>>>> Or am I just too tired too make it work? I can see that the type of >>>>> `go` could be a problem, but is it insurmountable? >>>>> >>>> >>>> The type of `go` is exactly the problem. In particular, the type of >>>> acc's first parameter. In the third clause of go's definition, we can >>>> see that `acc` and (acc $ y) are both used as the first argument to >>>> go, hence they must have the same type. However, this is impossible >>>> -- if acc has type (t0 -> t1), then y must have type t0, and (acc $ y) >>>> has type t1, so it would have to be the case that t1 = t0 -> t1 -- >>>> hence the error message. >>>> >>>> It is not possible in Haskell to define `applyTo`.* I know this >>>> function gets used a lot in lisp/scheme, but Haskell style is >>>> different. If you explain the context in which you wanted this >>>> function, perhaps we can help you figure out a better way to structure >>>> things so it is not needed. >>>> >>>> -Brent >>>> >>>> * At least not without crazy type class hackery. >>>> >>> >>> What is the difficulty? >>> >>> Is the difficulty at the level of "syntax"? >>> >>> Or is it that the type "Haskell expression", perhaps "Haskell >>> form", to use an old and often confusing Lisp term, does not >>> exist in the Haskell System of Expression? Here "exist" should be >>> read as "exist at the right level", right level for attaining >>> some objective. >>> >>> These alternatives, I think, need not be disjoint. >>> >>> I am ignorant of Haskell, but sometimes I write Perl in Lisp, and >>> the blurb for my last public rant mentioned a specific lambda >>> expression: >>> >>> http://lists.gnu.org/archive/**html/gnu-misc-discuss/2012-03/** >>> msg00036.html< http://lists.gnu.org/archive/html/gnu-misc-discuss/2012-03/msg00036.html> >>> >>> oo--JS. >>> >>> >>> ______________________________**_________________ >>> Beginners mailing list >>> Beginners(a)haskell.org >>> http://www.haskell.org/**mailman/listinfo/beginners< http://www.haskell.org/mailman/listinfo/beginners> >>> >> >> >> >> -- >> Alec Story >> Cornell University >> Biological Sciences, Computer Science 2012 >> > > > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -- ARJANEN Loïc Jean David http://blog.luigiscorner.com --- "Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do." Michael R. Fellows and Ian Parberry

1 0

darcsden
by Rui Barreiro 26 Jun '12

26 Jun '12

I would like to install darcsden on my machine, but I am having some difficulties. When I make cabal install I get this message: cabal: The following packages are likely to be broken by the reinstalls: bin-package-db-0.0.0.0 ghc-7.4.1 Use --force-reinstalls if you want to install anyway. what should I do? and why? Thanks

2 2

Function application versus function composition performance
by Matt Ford 20 Jun '12

20 Jun '12

Hi All, My last question got me thinking (always dangerous): an expression that doubles a list and takes the 2nd element (index 1), I assume, goes through the following steps. double (double [1,2,3,4]) !! 1 double ( 1*2 : double [2,3,4]) !! 1 1*2*2 : double ( double [2,3,4] ) !! 1 1*2*2 : double ( 2*2 : double [3,4] ) !! 1 1*2*2 : 2*2*2 : double ( double [3,4] ) !! 1 2*2*2 8 Up until the element requested all the proceeding elements have to have the expression formed as Haskell process the calculation. Now, I want to compare this to using function composition ( double . double ) [ 1 ,2, 3, 4 ] !! 1 This is the bit I'm unsure of - what does the composition look like. It is easy to see that it could be simplified to something like: ( double . double) (x:xs) = x*4 : (double . double) xs This would mean the steps could be written (double . double) [ 1,2,3,4 ] !! 1 (1*4 : (double.double) [2,3,4]) !! 1 (1*4 : 2*4 : (double.double) [ 3,4 ]) !! 1 2*4 8 Ignoring the start and end steps, it will be half the number of steps compared to the application version. Significant then, over long lists. So is this true, are composite functions simplified in Haskell in general so that they may have improved performance over function application? I've seen posts on the internet that say it's a matter of style only: http://stackoverflow.com/questions/3030675/haskell-function-composition-and…. But my reasoning suggests it could be more than that. Perhaps, function application is similarly optimised - maybe by replacing all functions applications with composition and then simplifying? Or maybe the simplifying/optimisation step never happens? As you can see I'm just guessing at things :-) But it's nice to wonder. Many thanks for any pointers, Matt.

3 2

Understanding how laziness works
by Matt Ford 20 Jun '12

20 Jun '12

Apologies for the maybe double post (no subject and hadn't confirmed the mailing list first time I sent this). Hi, Here's a simple expression double ( double [1,2,3,4] ) !! 0 The 1st element of a list is double ( 1*2 : double [2,3,4] ) !! 0 1*2*2 : double ( double [2,3,4 ] ) !! 0 1*2*2 4 calculated without having to traverse the rest of the list due to laziness. But how far does the laziness extend? For example, if I take the 2nd element double (double [1,2,3,4]) !! 1 Do we have 1*2*2 : double ( 2*2 : double [3,4] ) !! 1 1*2*2 : 2*2*2 : double ( double [3,4] ) !! 1 2*2*2 8 Resulting in 8. I assume that the 1st list entry 1*2*2 doesn't actually get calculated, but the expression does get formed? The second element (index 1) gets formed, isolated (by !!) and calculated as the return value. And then things can happily stop. What I'm checking is that the laziness doesn't some how magically extend to not having to form the preceding expressions that make up the resulting list? Or can Haskell recognize that this is like doing function composition i.e., (double . double) [ 1 2, 3, 4 ] !! 1 Thanks for any answer. Cheers, Matt. p.s, I kinda hope things are how I've assumed as the example finally shows me some concrete benefit of function composition which has never seemed important given it's so easily re-written as application.

2 1