- Haskell - Haskell.org

Hugs
by Krprtn＠aol.com 10 Jan '01

10 Jan '01

I've currently installed Hugs on my PC, could you tell me how I can configure Hugs to use an editor. The editor I have got installed on my computer is winedt.

1 0

ANNOUNCE: Draft TOC of Haskell in a Nutshell
by Brook Conner 10 Jan '01

10 Jan '01

Inspired by the recent discussions of what kinds of books would encourage the spread of Haskell, I whipped up a draft table of contents for "Haskell in a Nutshell." You can find it in PDF form at http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts embedded - OReilly uses a couple of oddballs) and in ASCII text at http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt. While there are page numbers attached, you should simply ignore those for the moment :-) Rather, I'd be interested in feedback on the structure etc. Oh, and please don't just rip it off and write it yourself :-) Like "Java in a Nutshell", the first part is a firehose description of the language. As Haskell is somewhat different from what most OReilly readers are used to, I've included a bit more about different ways you can run Haskell (which, incidentally, points out that it runs *everywhere*). Also like "Java in a Nutshell", the last part is a reference to common packages. The middle part is a bit different - a short "cookbook" of semi-practical programs addressing fairly common programming tasks - some of the kinds of things you'd typically do with Perl or C++. I think it needs more "recipes" of course, but I'd like to know if the general idea is working. Brook ps - for the curious, I have in fact written a textbook before (object-oriented programming for a first-semester course, from 1994...). And I'm using O'Reilly's FrameMaker templates, so the draft is "camera-ready" (hence the page numbers - the TOC is automatically generated).

4 4

About fundeps
by Anton Moscal 10 Jan '01

10 Jan '01

Hello! When I apply hugs to the following program: import Char (ord) class Conv a b | a -> b where conv:: a -> b instance Conv Char Int where conv = ord instance (Conv a b, Conv b c) => Conv a c where conv = conv . conv Hugs reports: ERROR "fdep.hs" (line 4): Instances are not consistent with dependencies *** This instance : Conv a b *** Conflicts with : Conv Char Int *** For class : Conv a b *** Under dependency : a -> b But why? Regards, Anton Moscal

2 1

Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
by Ketil Malde 10 Jan '01

10 Jan '01

Brook Conner <nellardo(a)concentric.net> writes: > Do you think the cookbook would be better as its own book? Perhaps it could? I think it's a natural component in a "nutshell" book, but it seems clear that there's tons of example programs that would be immensely useful as well-documented howtos. [Cool graphics hacks] > I figured those kinds of examples showed off the power of Haskell. Sounds good to me. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Haskell 98 (Library) Report: contradiction about fail :: String -> IO a
by qrczak＠knm.org.pl 09 Jan '01

09 Jan '01

The Haskell 98 Report says that fail in instance Monad IO invokes error. The Library Report says that fail in instance Monad IO raises a user error. I would let it raise a user error, to be able to use fail in exception monads where strings suffice as the error type. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Just for fun
by Anton Moscal 09 Jan '01

09 Jan '01

Hello! This is well-known definition of the existential quantification through universal: (E x.P(x)) <=> A y.(A x.P (x) => y) => y I try to translate in to Haskell. The following program can be compiled by "ghc -fglasgow-exts ..." and works correctly: ---------------------------------------- import Char type E a = forall t . (forall x . a x -> t) -> t newtype Pair a b = MkPair (b, (b -> a)) newtype App a = MkApp (E (Pair a)) mk_app :: (a -> b) -> a -> App b mk_app f v = MkApp (\g -> g (MkPair (v, f))) app_s = mk_app Char.ord '1' app_id = mk_app (\x->x) 239 eval :: App a -> a eval (MkApp g) = g (\(MkPair (x, f)) -> f x) main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1']) --------------------------------------- Regards, Anton Moscal

2 1

Defaults in datatype definitions
by Johannes Waldmann 09 Jan '01

09 Jan '01

Below are some suggestions for extensions to Haskell records. These are just naive ideas. Of course the extensions should integrate nicely w.r.t. the existing syntax, type system, and module system. Perhaps you can point me to opinions and research on what has already been done, or to why it should not, or can not. 1) I would like to write down default values for record components data Foo = Foo { x :: Bar; y :: Baz; x = some_expression } We can do this for methods in type classes, so why not here. 2) With classes, we can do even more: in the default method, we can access other methods. This suggests that the above example should in fact read data Foo = Foo { x :: Bar; y :: Baz; x = \ self -> some_expression } where `self' might occur in some_expression. that is, the default value of `me.x ' gets computed by applying a function to `me'. 3) I want to be able, in modules that use the type, to add more components (with defaults) to the type: This would avoid lengthy recomputations (at the cost of additional space). Imagine the difference between data Tree a = Node { key :: a, children :: [ Tree a ] } size t = 1 + sum (map size (children t)) and data Tree a = Node { key :: a, children :: [ Tree a ] , size :: Integer , size = \ self -> 1 + sum (map size (children self)) } when you have one large tree and frequently need sizes of subtrees. (by the way, what type does `size' have now - do we write `Integer' or `Tree a -> Integer'?) yes, I can do this manually, replacing `Node' by a smart constructor that computes and stores the size. What I don't like about this is that I have to know in advance (i. e. at the moment I define the type) what functions I want to be "cached" this way. Imagine `size' as some more complicated function, only defined many modules later. Of course I see that this would be difficult to implement w.r.t. separate compilation. But I would be happy with a compiler that ignores the "cache" specs during single-module compilations, but honors them when doing a full rebuild of a set of modules. I imagine that inter-module inlining behaves similar. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

2 1

Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
by Ketil Malde 09 Jan '01

09 Jan '01

Brook Conner <nellardo(a)concentric.net> writes: > Inspired by the recent discussions of what kinds of books would encourage the > spread of Haskell, I whipped up a draft table of contents for "Haskell in a > Nutshell." Let's see. It all depends on what you put into the chapters, of course, but you seem to jump directly from simple concepts into Haskell for web servers. Wouldn't it be better to push this further out, until at least some of the syntax has been explored? >From the headlines, one might get the impression that type declarations are only important when the compiler can't figure it out itself - I'm sure the actual text will give a different view, no? The cookbook looks great, and it's certainly something I'd buy the book for. I can, of course, think of many kinds of example programs I'd like to see - how about a GUI oriented program, for instance? Perhaps you could finish it off with a "real" application, say a GUIed JPEG viewer, where you sort of string it all (the JPEG codec, a C library interface for something or other, and GUI stuff, etc.) together into a whole? On the whole, I think it looks good. Best of luck! -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
by Bill Halchin 09 Jan '01

09 Jan '01

Yes! I agree with Manuel about the IO. It looks bad being towards the end. Regards, Bill Halchin >From: "Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> >Reply-To: chak(a)cse.unsw.edu.au >To: nellardo(a)concentric.net >CC: haskell(a)haskell.org >Subject: Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell >Date: Tue, 09 Jan 2001 13:43:59 +1100 > >Brook Conner <nellardo(a)concentric.net> wrote, > > > You can find it in PDF form at > > http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts > > embedded - OReilly uses a couple of oddballs) and in ASCII text at > > http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt. > >Makes sense to me. However, I would move IO further to the >front. For any "real life" programming, IO is essential >and, I think, it is bad for the image of Haskell to treat it >as something dirty that is relegated to end of every (at >least, many) introduction of Haskell. > >I have just given an Introduction to Computing course using >Haskell and written a set of lecture notes, which introduce >a couple of concepts (including IO) differently than >commonly done. The whole stuff is at > > http://www.cse.unsw.edu.au/~cs1011/lectures/index.html > >Feel free to get inspiration from the material (except Weeks >8 - 10, which weren't given by me). You will find IO in >Week 5. Note that I haven't used the word monad a single >time. IMHO, monads are an advanced concept, IO is not. >It's like you can introduce recursion without discussing >stacks. If you understand stacks, you can gain a deeper >understanding of recursion, but if you hear about recursion >for the first time, the mention of stacks will only distract >the average student. > > > The middle part is a bit different - a short "cookbook" of > > semi-practical programs addressing fairly common programming tasks - > > some of the kinds of things you'd typically do with Perl or C++. I think > > it needs more "recipes" of course, but I'd like to know if the general > > idea is working. > >I think, that this is a good idea. > >Cheers, >Manuel > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: Extending the do-notation
by Sebastien Carlier 08 Jan '01

08 Jan '01

> import Monad > ... > do y <- liftM unzip m1 Thanks. I'm constantly amazed by the number of tricks one has to know before he can write concise code using the do-notation (among other things, I used to write "x <- return $ m" instead of "let x = m"). Is there a paper demonstrating the most common coding styles for do-notation ? Another question concerning the do-notation: I noticed that most parts of ghc do not use it. Is it because the code was written before the notation was available, because the do-notation is too weak to express these parts, or for another fundamental reason ?

3 2