- Haskell - Haskell.org

cabal/haddock
by Johannes Waldmann 21 Sep '05

21 Sep '05

What's the current story on cabal and haddock? I need to run my sources through ghc -cpp before giving them to haddock. Does cabal support this (e. g. by directing the ghc -cpp output to dist/src )? Thanks, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

ANNOUNCE: ghc-api 0.1.0
by Lemmih 20 Sep '05

20 Sep '05

I'm pleased to announce ghc-api 0.1.0, a cabalization of the ghc api, plucked from ghc 6.5, making the api available for stable versions of ghc. The ghc-api 0.1.0 has been developed as a part of the running hIDE project, and has so far been succesfully built with ghc 6.4 and 6.4.1. [1] ghc-api: http://scannedinavian.org/~lemmih/ghc-api [2] hIDE: http://haskell.org/hawiki/hIDE -- Friendly, Lemmih

1 0

Re: [Haskell-cafe] Haskell versus Lisp
by Wolfgang Jeltsch 20 Sep '05

20 Sep '05

Am Freitag, 16. September 2005 15:29 schrieb Glynn Clements: > David Roundy wrote: > > > Bearing this in mind, and hoping you can see where I'm coming from, I > > > think my question is: shouldn't you guys be using Lisp? > > > > Lisp is impure, weakly typed and has way too many parentheses. Why would > > we use lisp? It seems to be lacking almost all the advantages of Haskell, > > and have an ugly, inflexible syntax to boot. > > The ability to dynamically generate, manipulate and analyse code in a > structured manner provides a flexibility which is unmatched by any > other language I know of. > > A good example is Emacs; lisp is entirely the right language for that, > IMHO. Could you explain this a bit more, please? To the moment, I cannot imagine cases where you need LISP's way of code analysis and manipulation because Haskell's capabilities are not sufficient. In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them. But you can use your do expressions etc. to construct action descriptions with a more general type like MonadIO m => m a. Then you can instantiate m with a monad whose values store part of the action's structure so that this information can be used later. Or you use a monad which doesn't keep structural information to use it for later processing but which does the processing upon construction. Best wishes, Wolfgang

8 10

monadic where
by John Meacham 20 Sep '05

20 Sep '05

All the talk of automatic monad lifting has reminded me of an extension I have wanted on several occasions. f x y = z where a = ... b <- ... c <- ... translates too f x y = do let a = .. b <- ... c <- ... z now, this doesn't seem that worth it until you consider guards in which case it becomes _very_ nice compared to the alternative. f x y | b > c = ... | c <= 0 && a > b = ... where a = ... b <- ... c <- ... f x y = ... there is really no clean (IMHO) way to express this idiom otherwise, and the benefits are even greater when you consider pattern guards. Manually you end up with a lot of strange nested cases or spurious subfunctions and generally hard to read and write code. Ideally, it would translate to an 'mdo' rather than a 'do', but not every monad is an instance of MonadFix and although that would be nice to have, it is not really vital since 'mdo', although indispensable sometimes, is not generally needed except in a few special cases so I'd stick to the standard 'do' translation. John -- John Meacham - ⑆repetae.net⑆john⑈

2 2

Haskell Weekly News: September 20, 2005
by John Goerzen 20 Sep '05

20 Sep '05

Haskell Weekly News: September 20, 2005 Greetings, and thanks for reading the eighth issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * GHC 6.4.1. According to Simon Marlow's [3]announcement, GHC 6.4.1 is out and is mainly a bugfix release. No library APIs have changed, so code working with GHC 6.4 should continue to work. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12158 * Visual Haskell 0.0. Simon Marlow [4]announced Visual Haskell 0.0, a Haskell development environment for the Microsoft Visual Studio platform. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12161 Discussion Autrijus Tang interviewed at perl.com. Autrijus Tang is a Perl hacker and developer of the first working Perl 6 [5]interpreter, which is written in Haskell. On Page 2 of an [6]interview on perl.com, he explained Haskell in glowing terms to the Perl audience. Favorite quote: "Haskell . . . is faster than C++, more concise than Perl, more regular than Python, more flexible than Ruby, more typeful than C#, more robust than Java, and has absolutely nothing in common with PHP." Thanks to metaperl for [7]mentioning this on the Haskell Sequence. There was als a small [8]thread about this. 5. http://www.pugscode.com/ 6. http://www.perl.com/pub/a/2005/09/08/autrijus-tang.html?page=2 7. http://sequence.complete.org/node/98 8. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8288 Overloading (==). In an interesting [9]thread, Tom Hawkins asked if it was possible to overload (==) to return something other than a Bool. The answer was no, but the discussion led to comments about using typeclasses instead of a simple Bool type in certain situations. 9. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8346 Haskell vs. Lisp. This [10]discussion began with a post from Mark Carter, who is considering Haskell and wondering what advantages it might have over Lisp. Many perspectives were discussed, especially relating to metaprogramming (Lisp macros and Template Haskell). David F. Place had an interesting [11]post. As someone with experience with both Haskell and Lisp, he commented that Haskell's "lazy evaluation eliminates 99% of the need for macros in Lisp." There were also posts by [12]Tomasz Zielonka, [13]Cale Gibbard were also insightful. 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8309 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8342 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8356 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8316 Network Parsing and Parsec. John Goerzen posed a [14]question about using Parsec to parse network streams such as IMAP, where the results of the parsing itself determine how much data should be read, and reading too much data results in deadlock. Some solutions offered included a separate tokenizer phase and the use of the Parsec state to help. 14. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8293 Haskell Toolchain The Big News this week is, of course, the new release of GHC. A big thanks to everyone on the GHC team for this. Cabal du jour. Cabal keeps coming up on the libraries list. This week's [15]discussion revolves around whether or not a --package-db option is wise. 15. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3729 Quotes of the Week "Learning Haskell requires some brain rewiring, so the best way to learn it is by coding something in it for real. Yuval, a fellow "lambdacamel," learned Haskell from scratch by coding up a Forth parser, interpreter, and runtime all within a few days." -- Autrijus Tang Corrections Two typos in last week's HWN. In the web applications story, "S. Alexander Jacobsen" should have been "S. Alexander Jacobson". In the binary pasrser combinators story, "Malcolm Wallac" should have been "Malcolm Wallace". Sorry about that. About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [16]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 16. http://sequence.complete.org/hwn-contrib

1 0

RE: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
by Simon Peyton-Jones 19 Sep '05

19 Sep '05

This would be a great discussion for the haskell-café list, but perhaps it's less appropriate on the low-bandwidth Haskell list. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Michael Vanier | Sent: 16 September 2005 22:37 | To: tomasz.zielonka(a)gmail.com | Cc: haskell(a)haskell.org; glynn(a)gclements.plus.com | Subject: Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp | | | > Date: Fri, 16 Sep 2005 23:33:46 +0200 | > From: Tomasz Zielonka <tomasz.zielonka(a)gmail.com> | > | > On Fri, Sep 16, 2005 at 05:40:04PM +0100, Glynn Clements wrote: | > > | > > Every other language (including Haskell) tends to have the problem | > > that eventually you will encounter a situation where the language's | > > own worldview gets in the way. | > | > Are you sure that lisp's worldview never gets in the way? | > | > > Or, to put it another way: if Haskell is so flexible, why do we need | > > Template Haskell? | > | > It's nice to have Template Haskell, but saying that we need it is a bit | > of an overstatement. In the GHC Survey 2005 only 9% of people said it's | > essential. Well, OK, I was one of them, but I think you know what I | > mean. | > | > > I can't imagine a "Template Lisp"; it would just be Lisp. | > | > The power of lisp macros is often overrated. I remember a long | > discussion crossposted on comp.lang.lisp an comp.lang.functional. The | > lisp advocates gave examples for how macros allow to do things | > supposedly unavailable in other languages. Surprisingly, most of these | > things were equally easy to do with higher-order functions and closures | > in Haskell. | > | | But were they as efficient? The beauty of macros is that a lot of things | can be done with no run-time overhead at all. Not that I'm taking a stand | on the Haskell-vs-Lisp argument; I think everyone should learn both | languages. | | Mike | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Mixing monadic and non-monadic functions
by Sean E. Russell 18 Sep '05

18 Sep '05

Hello, I posted this question to comp.lang.functional, and someone suggested that I try this group instead. I'm struggling with monads. Well, not monads themselves, but mixing them with non-monadic functions. Here's my base case: someFunc :: String -> IO [a] ... ax <- someFunc a bx <- someFunc b assertBool "fail" $ length ax == length bx I don't like the assignments; the typing is redundant, if I have a lot of asserts like this, and the "variables" are temporary. What I'd much rather have is: ... assertBool "fail" $ (length $ someFunc a) == (length $ someFunc b) which is more readable, to my eye. The only solution which has been suggested that may work is liberal use of the liftM variants, but this gets *really* tedious and obtuse. Is there an elegant way to do what I want to do, or am I stuck with procedural-style assignments and bunches of temp vars? Thanks! -- ### SER ### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg

23 37

implicit responses/values
by S. Alexander Jacobson 17 Sep '05

17 Sep '05

I am now using implicit parameters quite happily. But I also feel the need for the reverse. There are occasions where I want to pass a value back through the set of calling functions e.g. produce HTTP cache header info through functions that are not really about that. I am not sure how this would work, but it strikes me as useful. Anything like that in the offing? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

2 1

Re: [Haskell-cafe] Basic Haskell Types Question
by Wolfgang Jeltsch 16 Sep '05

16 Sep '05

Am Freitag, 16. September 2005 14:19 schrieb Adam Wyner: > [...] > But, what I don't understand or like is that the type of the whole > is given as [[Char]], not what I thought it would be, namely PropList. > Nor is it [String]. These three are essentially the same type. So a Haskell system may use whatever representation the developer of it thought is the best one. > [...] > Am I supposed to be using newtype or data declarations here? How would > I do this? I looked around for information in the usual sources, > but haven't found an answer. You should use newtype declarations since they introduce a truely new type. Apart from solving your problem, this has further advantages. A list of complex numbers may, for example, denote a polynomial or a digital filter. If you use type synonyms, as you did so far, you could use a digital filter where a polynomial is needed or vica versa. With newtype declarations you couldn't confuse these two different things. In addition, you could restrict instance declarations to just polynomials or digital filters and implement the methods so that they are meaningful for just this particular kind of thing. > Thanks, > Adam Wyner Best wishes, Wolfgang

1 0

Re: [Haskell] Mixing monadic and non-monadic functions
by Scherrer, Chad 16 Sep '05

16 Sep '05

One of Mark Jones's articles suggests something like class Plus a b c | a b -> c where (+) :: a -> b -> c Would instance (Plus a b c, Monad m) => Plus (m a) (m b) (m c) where mx + my = do x <- mx y <- my return (x + y) do what you're looking for? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx ------------------------------------------------------------------ Original message: Hi, Sean's comment (yeah, it was like a billion years ago, just catching up) is something that I've often thought myself. I want the type system to be able to do "automatic lifting" of monads, i.e., since [] is a monad, I should be able to write the following: [1,2]+[3,4] and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". Also, I would have Reader (+1) + Reader (+4) == Reader (\x -> 2*x+5) The point I want to make is that this is much more general than IO or monads! I think we all understand intuitively what mathematicians mean when they add two sets {1,2}+{3,4} (i.e. { x+y | x\in {1,2}, y\in {3,4}}) or when they add functions (f+g)(x) where f(x)=x+1 and g(x)=x+4 So "automatic lifting" is a feature which is very simple to describe, but which gives both of these notations their intuitive mathematical meaning - not to mention making monadic code much tidier (who wants to spend their time naming variables which are only used once?). I think it deserves more attention. I agree that in its simplest incarnation, there is some ugliness: the order in which the values in the arguments are extracted from their monads could be said to be arbitrary. Personally, I do not think that this in itself is a reason to reject the concept. Because of currying, the order of function arguments is already important in Haskell. If you think of the proposed operation not as lifting, but as inserting `ap`s: return f `ap` x1 `ap` ... `ap` xn then the ordering problem doesn't seem like such a big deal. I mean, what other order does one expect, than one in which the arguments are read in the same order that 'f' is applied to them? Although it is true that in most of the instances where this feature would be used, the order in which arguments are read from their monads will not matter; yet that does not change the fact that in cases where order *does* matter it's pretty damn easy to figure out what it will be. For instance, in print ("a: " ++ readLn ++ "\nb: " ++ readLn) two lines are read and then printed. Does anybody for a moment question what order the lines should be read in? Frederik

12 20