- Haskell-Cafe - Haskell.org

re: Biggest Haskell unit in the world
by Bernard James POPE 28 Jun '01

28 Jun '01

> If any of you antipodeans feel like sharing tales of Haskellisation, I can > guarantee you an eager audience of at least 1. > Cheers, > --Ham Hi folks, What follows is just my own view of the situation, other people from this department may think differently: At Melbourne we moved from Miranda to Haskell about 2 years ago. I think Miranda replaced Pascal as the first language taught to students, but that was a long time ago and I wasn't here at the time. Miranda was very successful as a first language. However, it suffered from some problems which ultimately led us to look for a replacement: - it was a bit of a toy language, and didn't scale well to use in later year subjects. - it wasn't open, which made it difficult for students to use at home. - it was being overtaken by languages like Haskell in the research community We considered a few languages to replace Miranda. Haskell was the most obvious candidate. One of the main reasons for choosing Haskell was the quality of Hugs. Having such a large body of students really requires that they be able to do a lot of their work at home. Without Hugs, I dare say we would have been looking more seriously at other languages. The transfer from Miranda to Haskell was quite straightforward. Training staff was not a big problem. Type classes and monadic programming being the only tricky topics for people with Miranda experience. You can find our paper on "Haskell for Miranda Programmers" on http://www.haskell.org/bookshelf/ We still tend to teach the Miranda "subset" of Haskell, which is a bit of a pity. It is the overall intention of our first subject to introduce problem solving and algorithms to students. In some ways the language is a secondary issue, however, we believe that functional languages are a good setting for this. The use of Haskell is filtering up through the later-year subjects, as both staff and students become more comfortable with it. I think that many of our students do not appreciate some of the strong features of declarative programming until third or fourth year when they are faced with larger (more difficult) programming tasks. There is still a conception amongst some of the students that FP is not really part of "Real World" programming, and that it is merely of interest to academics. We try hard to refute this notion. Regards, Bernie.

5 4

Re: Haskell-Cafe digest, Vol 1 #154 - 8 msgs
by Mark Wotton 25 Jun '01

25 Jun '01

On Mon, 25 Jun 2001 haskell-cafe-request(a)haskell.org wrote: > Message: 8 > To: haskell-cafe(a)haskell.org > Subject: re: Biggest Haskell unit in the world > Reply-To: chak(a)cse.unsw.edu.au > Date: Mon, 25 Jun 2001 21:47:37 +1000 > From: "Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> > > Bernard James POPE <bjpop(a)cs.mu.OZ.AU> wrote, > > > Lyndon While writes: > > > > > So how about it? Can anyone beat 298 for a Haskell programming unit? > > > For the record, I teach more advanced aspects of FP to (this year) 38 > > > students, too. > > > > Sorry Lyndon, we (melbourne uni) had 767 students sit our first year > > subject which teaches Haskell. We teach it again in second semester too, > > with over a hundred students. > > Computing 1A (taught in Haskell) at Uni of New South Wales > has two streams with 731 + 247 students (the second stream > is for good students who want some more challenge). In > second semester, we have about 600 students in that course. > > Lyndon While <lyndon(a)cs.uwa.edu.au> wrote, > > > Maybe together we can make Australia the most Haskellised > > country in the world! > > We stand a good chance, I would say. It's a small contribution, I know, but can I throw in 90 students at Sydney Uni? Admittedly, most of the course was Prolog this year, much to my chagrin: I'd much rather be marking Haskell scripts. mrak

1 0

RE: Haskell report typo (bad law for readsPrec)
by Simon Peyton-Jones 25 Jun '01

25 Jun '01

The Haskell report is far from a precise document, and now is not the time to make it so. Nevertheless, Wolfgang has a point, and I have slid a little way into this tar pit by making a change at all. OK, I think I buy this formulation: head (readsPrec d (showsPrec d x "")) == (x,"") (I suppose I might say "provided x is a total value"). Simon "desperately trying to freeze the report" PJ | -----Original Message----- | From: Wolfgang Lux [mailto:lux@wi.uni-muenster.de] | Sent: 20 June 2001 10:30 | To: Patrik Jansson | Cc: haskell-cafe(a)haskell.org | Subject: Re: Haskell report typo (bad law for readsPrec) | | | Patrik Jansson wrote | | > [Typo - you mean:] | > head (readsPrec d (showsPrec d x "")) == (x,"") | | Yes. | | > Both formulations look OK to me, but neither is an essential change | > and there are many other small variations possible with slight | > semantical differences. One example is | > | > (x,"") `elem` readsPrec d (showsPrec d x "") | > | > And already the current (proposed) formulation is most likely | > impossible to satisfy if the element x contains bottoms somewhere | > inside. (Example: try to show and read the string (undefined : | > "hello").) | | True, but in any case it seems sensible to me to require that | readsPrec should actually process the input string. With your proposal | | > > | fst (head (readsPrec d (showsPrec d x ""))) == x | | it would be possible to return [(42,"42")] for the expression | readsPrec 0 (showsPrec 0 42 ""). | | Wolfgang | | | | -- | Wolfgang Lux Phone: +49-251-83-38263 | Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 | Universitaet Muenster Email: wlux(a)uni-muenster.de | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

1 0

(no subject)
by Manjula Iyer 25 Jun '01

25 Jun '01

1 0

Re: hbc
by Patrik Jansson 25 Jun '01

25 Jun '01

On Wed, 20 Jun 2001, John Meacham wrote: > you forget one other essential quality of hbc. > As far as I know it is the only compiler that even has a chance of > compiling Fudgets, and hence programs dependent on them such as > the very cool (IMHO) Alfa proof editor > (http://www.cs.chalmers.se/~hallgren/Alfa/) > and its assosiated improvments to Fudgets. If there is any effort to > port these tools to a modern haskell system then I cheer you on. Fudgets and Alfa compiles with ghc already. (But I haven't seen a release of that.) Ask Hallgren (nicely) for an unofficial release/snapshot! /Patrik

2 1

Re: Haskell report typo (bad law for readsPrec)
by Wolfgang Lux 20 Jun '01

20 Jun '01

Patrik Jansson wrote > [Typo - you mean:] > head (readsPrec d (showsPrec d x "")) == (x,"") Yes. > Both formulations look OK to me, but neither is an essential change and > there are many other small variations possible with slight semantical > differences. One example is > > (x,"") `elem` readsPrec d (showsPrec d x "") > > And already the current (proposed) formulation is most likely impossible > to satisfy if the element x contains bottoms somewhere inside. (Example: > try to show and read the string (undefined : "hello").) True, but in any case it seems sensible to me to require that readsPrec should actually process the input string. With your proposal > > | fst (head (readsPrec d (showsPrec d x ""))) == x it would be possible to return [(42,"42")] for the expression readsPrec 0 (showsPrec 0 42 ""). Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

1 0

Re: Haskell report typo (bad law for readsPrec)
by Patrik Jansson 20 Jun '01

20 Jun '01

On Tue, 19 Jun 2001, Wolfgang Lux wrote: > > > | Another simple alternative is to weaken the the equation by > > > | replacing the variable r by the empty string: [Alternative B:] > > > | > > > | ... > > > | should be the case that > > > | > > > | fst (head (readsPrec d (showsPrec d x ""))) == x > > > > > > Yes, I like this alternative too. I'll implement it. > > > > Why not require > > > > readsPrec d (showPrec d x "") == [(x,"")] > > > > in this case? At least it should be > > > > head (readsPrec d x "") == (x,"") [Typo - you mean:] head (readsPrec d (showsPrec d x "")) == (x,"") Both formulations look OK to me, but neither is an essential change and there are many other small variations possible with slight semantical differences. One example is (x,"") `elem` readsPrec d (showsPrec d x "") And already the current (proposed) formulation is most likely impossible to satisfy if the element x contains bottoms somewhere inside. (Example: try to show and read the string (undefined : "hello").) I think we'll have to accept that Show and Read are to be used mainly for presentation, and not when real uniquely invertible behaviour is desired. I think a separate Serializable class designed for correct and portable (and efficient?) data transmission is necessary anyway. In that design process the laws would have to be thought through much more carefully. (There are suggestions for a library already - see below.) /Patrik A quick search: http://www.cs.york.ac.uk/fp/nhc98/libs/Binary.html The Bits Between The Lambdas: Binary Data in a Lazy Functional Language (1998) Malcolm Wallace Colin Runciman http://citeseer.nj.nec.com/260182.html Heap Compression and Binary I/O in Haskell Malcolm Wallace Colin Runciman http://citeseer.nj.nec.com/68962.html

1 0

Re: Stack leak... (?)
by Juan Carlos Arevalo Baeza 11 Jun '01

11 Jun '01

At 11:20 AM 6/11/2001 -0600, Alastair David Reid wrote: > > The problem is that my test program runs out of stack > > (not heap) on both GHC and Hugs when parsing a large-enough > > file (about 150K for GHC, a lot less for Hugs). > >The classic cause of this problem in parsers is tracking line numbers. >The problem is that line numbers have to be built but rarely get >observed. This means that a line number like 33 will be represented >by a thunk like this: > > 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1 > >This uses a lot of heap space (though it may not be too bad because of >sharing) but, more seriously, it takes stack space proportional to the >line number - hence the stack overflows you've been seeing. Thanx! That makes sense, kind of. I'm still not sure why the hit is in the stack. I guess the stack must be used in a different manner than in the lazy evaluator I programmed not long ago in C++ (it was a learning experience). In that evaluator, a line number represented like that would be just one more heap token/pointer stored in the stack, regardless of the internal complexity of the expression. Unless the stack overflow happens on evaluating the line number for printing it out. But then, in my evaluator, it would have been the previous line number plus one, and the previous line number would have been computed already when printing the previous line of code. Hmmm... Do you think I have to re-evaluate what I know of the internals of how Haskell works? Thanx for your help. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html

1 0

Re: Why is there a space leak here?
by Ketil Malde 11 Jun '01

11 Jun '01

Fergus Henderson <fjh(a)cs.mu.oz.au> writes: > If experts like Alastair Reid > have trouble understanding the operational behaviour of simplified > examples like this one, how are ordinary programmers to cope with > complicated programs? Is lazy functional programming too difficult for > ordinary mortals? Of course, you can just go the strict route, and generate the whole list before processing it. Which will blow up (since it requires an equal amount of space), but do so in a more predictable and comprehensible way. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

3 2

my MutableList module (If anybody cares)
by Jay Cox 08 Jun '01

08 Jun '01

Attached is my first attempt at a library containing functions for the construction and modification of "imperative lists". Such can allow for the replacement of nodes, appending, truncation, etc in constant time. (of course, all this is done through the IO or ST monad). Basically, anything you could do with lists in C (without modifying the actual node values) you can do with these lists. I'm not sure if this would be useful to anybody, (indeed I thought the idea of functional programming was to get away from this stuff!) but I would like some input as to the design of this module or other comments before I continue developing it. Could a refined version of this module (perhaps with more abstraction, name changes, and name hiding) be beneficial to the development of haskell? (Perhaps in the very least does anybody think it as a tutorial for a non-trivial use of IORef or STRef?) Thanks for your reply, Jay Cox module MutList where import IOExts import ST data S m a = Nil | Cons a (m (S m a)) class Monad m => MyRef m f where newRef :: a -> m (f a) readRef :: f a -> m a writeRef :: f a -> a -> m () -- modifyRef :: f a -> (a -> a) -> m () instance MyRef IO IORef where newRef = newIORef readRef = readIORef writeRef = writeIORef -- modifyRef = modifyIORef instance MyRef (ST s) (STRef s) where newRef = newSTRef readRef = readSTRef writeRef = writeSTRef --modifyRef = modifySTRef mkempty :: MyRef m myref => m (myref (S myref a)) mkempty = newRef Nil push ref val = newRef (Cons val ref); mpush ref val = do x<-readRef ref y<-newRef x writeRef ref (Cons val y) pop ref = do x <- readRef ref case x of (Cons _ ls) -> return ls _ -> error "empty list" mpop ref = do x<-pop ref; y<-readRef x writeRef ref y top ref = do x <- readRef ref case x of (Cons value _) -> return value _ -> error "empty list" safepop ref = do x <- readRef ref case x of (Cons _ ls) -> return (Just ls) _ -> return Nothing safempop ref = do x<-safepop ref y<-result x writeRef ref y where result Nothing = return Nil result (Just ls) = readRef ls safetop ref = do x <- readRef ref case x of (Cons value _) -> return (Just value) _ -> return Nothing -- the above could easily be replaced with versions -- which use the maybe datatype --printM :: (MyRef m myref,Show a) => (myref (S myref a)) -> m () printM x = (readRef x) >>= printM1 where printM1 Nil = print "Nil" printM1 (Cons a x) = do print "Cons " print (show a) y <- readRef x printM1 y -- this might be doable with foldM or somesuch makeM :: MyRef m myref => [a] -> m ( myref (S myref a)) makeM x = (makeM' x)>>= newRef makeM' :: MyRef m myref => [a] -> m (S myref a) makeM' [] = return Nil makeM' (x:xs) = do rest <- makeM' xs refrest <- newRef rest return (Cons x refrest) makeM1 refmaker arry = (makeM' arry) >>= refmaker makeIORefM :: [a] -> IO (IORef (S IORef a)) makeIORefM = makeM --or makeIORefM = makeM1 newIORef makeSTRefM :: [a] -> ST s (STRef s (S (STRef s) a)) makeSTRefM = makeM --or makeSTRefM = makeM1 newSTRef unmakeM :: MyRef m myref => myref (S myref a) -> m [a] unmakeM = foldrM (:) [] foldrM :: MyRef m myref => (a->b->b)->b->myref(S myref a)-> m (b) foldrM f init ref = do x<-readRef ref case x of Nil -> return init (Cons val rest) -> do value <- foldrM f init rest return (f val value) foldlM :: MyRef m myref => (b->a->b) -> b -> myref (S myref a) -> m (b) foldlM f acc ref = do x<-readRef ref case x of Nil -> return acc (Cons val rest) -> foldlM f (f acc val) rest -- cut off part of a list and replace part with another list replaceM ::MyRef m myref => myref (S myref a) -> Int -> myref (S myref a) -> m () replaceM x n y = do z <-readRef y; replaceM1 x n z replaceM1 ::MyRef m myref => myref (S myref a) -> Int -> (S myref a) -> m () replaceM1 x 0 y = writeRef x y replaceM1 x n y = do z <- readRef x case z of Nil -> do --print "cannot replace list part" writeRef x Nil (Cons a ls)-> replaceM1 ls (n-1) y truncateM x n = replaceM1 x n Nil splitwhere:: MyRef m myref => (a-> Bool) ->myref (S myref a) -> m (myref (S myref a),myref (S myref a)) splitwhere f original = something original where something l = do z <- readRef l case z of Nil -> do x1 <-newRef Nil return (original,x1) (Cons val ls) -> if (f val) then do x1 <- newRef z writeRef l Nil return(original,x1) else something ls mymapM :: MyRef m myref => (a->b) -> myref (S myref a) -> m ( myref (S myref b)) mymapM f ls = readRef ls >>= mymapM1 f where mymapM1 :: MyRef m myref => (a->b) -> (S myref a) -> m ( myref (S myref b)) mymapM1 f Nil = newRef Nil mymapM1 f (Cons x ls) = do y <-readRef ls zs <- (mymapM1 f y) newRef (Cons (f x) zs) duplicateM :: MyRef m myref => myref (S myref a) -> m (myref (S myref a)) duplicateM = mymapM id -- The following could go into another file and make another module -- data MyRef m myref => O1appendList m myref a = Lt{list::myref(S myref a),butt::myref(myref(S myref a))} makelist:: MyRef m myref => [a] -> m (O1appendList m myref a) makelist ls = do x<-mkempty t<- newRef x let p = Lt x t in m ls p where m [] p = return p m (h:t) p = do x <- m t p y<- push (list x) h return (x {list=y}) makeSTReflist :: [a] -> ST s (O1appendList (ST s) (STRef s) a) makeSTReflist = makelist makeIOReflist :: [a] -> IO (O1appendList IO IORef a) makeIOReflist = makelist listappend :: MyRef m myref => (O1appendList m myref a) -> (O1appendList m myref a) -> m () listappend l1 l2 = do end<- readRef (butt l2) middle <- readRef (butt l1) beginl2 <-readRef (list l2) writeRef middle beginl2 writeRef (butt l1) end printlist x = printM (list x) --the following function is good to get out of the state world. unmakelist x = unmakeM (list x)

1 0