- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] PROPOSAL: Rename haskell@ to haskell-announce@
by Andrzej Jaworski 26 Sep '07

26 Sep '07

Flooding haskell-cafe with extra traffic from haskel@ will lead to comp.soft-sys.matlab syndrom where few people read anything but their own postings and discussion is virtually unknown. I can see only two options available to us right now to preserve readability in the fast growing Haskell community: divide haskell@ into more specific lists (haskell-cafe should preserve its right to long threads !!!) or ascribe volunteers (on monthly bases) to moderate and process haskell@ so as to receive tagged tree of links. -A.J.

3 2

Re: [Haskell-cafe] Composition Operator
by PR Stanley 26 Sep '07

26 Sep '07

Ah, I understand now. Let me get this right: The resulting (a -> c) is a kind of abstract function formed by the pairing of <a -> b) and (b -> c), hence the lambda \x -> g (f x), correct? Thanks, Paul At 05:11 22/09/2007, you wrote: >Hello, > >It's probably easiest to think of composition as a function which >takes two arguments (both functions), (g :: b -> c) and (f :: a -> b), >and returns a new function of type a -> c. We could write this >explicitly as > > composition :: (b -> c, a -> b) -> a -> c > composition (g,f) = \x -> g (f x) > >then (.) is the currying of composition: > > (.) = curry composition > >or > > (.) g f = \x -> g (f x) > >-Jeff > > >On 9/21/07, PR Stanley <prstanley(a)ntlworld.com> wrote: > > Hi > > (.) :: (b -> c) -> (a -> b) -> (a -> c) > > While I understand the purpose and the semantics of the (.) operator > > I'm not sure about the above definition. > > Is the definition interpreted sequentially - (.) is a fun taht takes > > a fun of type (b -> c) and returns another fun of type (a -> b) etc? > > Any ideas? > > Thanks, Paul > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

6 8

Re: [Haskell-cafe] Re: Very crazy
by Andrew Coppin 26 Sep '07

26 Sep '07

Chaddaï Fouché wrote: > 2007/9/25, Andrew Coppin <andrewcoppin(a)btinternet.com>: > > >> I just found it rather surprising. Every time *I* try to compose with >> functions of more than 1 argument, the type checker complains. >> > > There is no function that takes more than one argument in Haskell. ;-) > map _could_ be seen as a function with 2 arguments, but in this case > it's more useful to think of it as a function that take one argument > f, a function that turn 'a into 'b and turn it into a new function > that turn a list of 'a into a list of 'b. > This is why I found it so surprising - and annoying - that you can't use a 2-argument function in a point-free expression. For example, "zipWith (*)" expects two arguments, and yet sum . zipWith (*) fails to type-check. You just instead write \xs ys -> sum $ zipWith(*) xs ys which works as expected. I can't figure out why map . map works, but sum . zipWith (*) doesn't work. As I say, the only reason I can see is that the type checker hates me and wants to force me to write everything the long way round...

5 4

Very crazy
by Andrew Coppin 25 Sep '07

25 Sep '07

While using Haskell, I often find myself writing convoluted constructions such as this: show_system = unlines . zipWith (\l ms -> "Eq" ++ show l ++ ": " ++ (concat $ intersperse " + " $ zipWith (\n x -> x ++ " x" ++ show n) [1..] (init ms)) ++ " = " ++ last ms ) [1..] . map (map (take 8 . show)) And people complain that *Perl* is bad? This function is quite obviously absurd. I mean, it works, but can *you* figure out what it does without running it? The question is, can anybody think of a better way to write this function? (And more generally, functions like it.)

12 27

Re: [Haskell-cafe] Very crazy
by Andrew Coppin 25 Sep '07

25 Sep '07

Chaddaï Fouché wrote: > 2007/9/25, Andrew Coppin <andrewcoppin(a)btinternet.com>: > >>> printf don't always perform IO : if you ask it for a String it will >>> happily turn into sprintf for you, if you use it in the IO Monad, it >>> will indeed perform IO, but there's nothing fundamentally IO bound in >>> printf logic. >>> >>> >> That's even *more* impossible... o_O >> > > Why ? > How can one function have more than one type signature?

3 2

Re: [Haskell-cafe] Haskell Cheat Sheet?
by Ben 25 Sep '07

25 Sep '07

+1 > Message: 9 > Date: Tue, 25 Sep 2007 13:04:56 -0700 > From: Evan Klitzke <evan(a)yelp.com> > Subject: [Haskell-cafe] Haskell Cheat Sheet? > To: haskell-cafe(a)haskell.org > Message-ID: <1190750696.5459.7.camel@thinkpad> > Content-Type: text/plain > > Has anybody made (or have a link to) a Haskell reference cheat sheet? > I'm thinking of a nice LaTeXed PDF in the 1-10 page range (e.g. > something like this http://www.tug.org/texshowcase/cheat.pdf) with the > basics of the language syntax, the type declarations for the common type > classes, the type signatures of the most commonly used functions in the > Prelude and other common modules, and so forth? The Haskell standard > library is very large for a newcomer (even just the Prelude!), and as a > learner of the language I find myself spending a lot of time looking up > Prelude functions and syntax details -- having all of this in a short > PDF document that I could have offline would be very useful. > > -- > Evan Klitzke <evan(a)yelp.com> > > > > ------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > End of Haskell-Cafe Digest, Vol 49, Issue 118 > ********************************************* >

1 0

Re: [Haskell-cafe] Troubles understanding memoization in SOE
by Peter Verswyvelen 25 Sep '07

25 Sep '07

Thanks Paul & Paul for the answers. I'll certainly read the paper Paul Liu reported. I just deleted 100 lines of text which explained my problem in more detail, and while I was explaining it, I answered it myself. Typical. I thought the lambda function that memo1 returns would be called over and over again, and instead of reevaluating the stream from the beginning, it would just return the stream since it is in the cache, but actually it just gets called twice in recursive situations: the first time it evaluates y = f x, stores the thunk in the cache, and returns the thunk, the second time it finds the same thunk in the cache, and then computation of the rest of the stream continues without consulting the cache anymore right? From my clumsy explanation you can see that I'm still thinking too imperative, too eager. Haskell is more lazy than I am, which is an incredible achievement :-) It would really help if I could see the lazy computation; do you think this kind of memo code is traceable using HAT? I'll guess I'll have to check out arrows / yampa again. A year ago I did not understand a single thing in those papers, but I should try it again now I read the SOE book :-) Thanks a lot, Peter

2 2

Shouldnt this be lazy too?
by Vimal 25 Sep '07

25 Sep '07

Hi all, I was surprised to find out that the following piece of code: > length [1..] > 10 isnt lazily evaluated! I wouldnt expect this to be a bug, but in this case, shouldnt the computation end when the length function evaluation goes something like: > 10 + length [11..] ? -- -- Vimal

13 26

representing differencial equations in haskell
by Thomas Girod 25 Sep '07

25 Sep '07

Hi there. Let's say I have mathematical model composed of several differential equations, such as : di/dt = cos(i) dc/dt = alpha * (i(t) - c(t)) (sorry my maths are really bad, but I hope you get the point) I would like to approximate the evolution of such a system iteratively. How would you do that in haskell ? cheers, Thomas

4 3

Template Haskell newbie questions
by Hugo Pacheco 25 Sep '07

25 Sep '07

Hi all, I'm try to write some function in TH that I don't even know if it is possible. Consider the example from the tutorials sel 1 2 = [| \(x,_) -> x |] sel 2 2 = [| \(_,x) -> x |] If I want to write some function that will dynamically create a selection function according to its arguments and do something with it. fsel :: Int -> Int -> x fsel x y = $(sel x y) ... Imagine a stupid case for fsel :: Int -> Int -> Int fsel x y = $(sel x y) (x,y) The compiler complains that GHC stage restriction: `x' is used in a top-level splice, and must be imported, not defined locally In the first argument of `sel', namely `x' In the expression: $[splice](sel x y) (x, y) In the definition of `fsel': fsel x y = $[splice](sel x y) (x, y) what, indeed, makes sense. However, is there a possible way to generate Haskell functions from TH without having to instanciate its arguments? Thanks, hugo

3 4