February 2001 - Haskell-Cafe

FW: Announcing haskelldoc
by Simon Peyton-Jones 19 Feb '01

19 Feb '01

> In the Haskell community is there a generally accepted best way to > approach Literate Programming? The language has support for literate > comments, but it seems that many common LP tools don't respect it. I don't know whether you'd regard this as literate programming, but there's a move afoot to get a widely used Haskell documentation tool (enclosed). Simon -----Original Message----- From: Henrik Nilsson [mailto:nilsson@cs.yale.edu] Sent: 05 February 2001 22:14 To: haskell(a)haskell.org Subject: Announcing haskelldoc Dear Haskellers, At the recent Haskell Implementors' meeting in Cambridge, UK, it was decided that it would be useful to have a standard for embedded Haskell documentation. Such standards, and associated tools for extracting and formating the documentation in various ways, exists for other languages like Java and Eiffel and have proven to be very useful. Some such tools also exist (and are being actively developed) for Haskell, but there is as yet no generally agreed upon standard for the format of the embedded documentation as such. To address this, a mailing list has been started with the aim of defining a standard for embedded Haskell documentation, and possibly also related standards which would facilitate the development of various tools making use of such documentation (formatters, source code browsers, search tools, etc.). We feel that it is important to involve all who might be interested in this work at an early stage, so that as many aspects as possible can be taken into consideration, and so that the proposal for a standard which hopefully will emerge has a reasonable chance of gaining widespread support. Thus, You are hereby cordially invited to join haskelldoc(a)haskell.org. To join, just goto http://www.haskell.org/mailman/listinfo/haskelldoc. Best regards, Armin Groesslinger <groessli(a)fmi.uni-passau.de> Simon Marlow <simonmar(a)microsoft.com> Henrik Nilsson <nilsson(a)cs.yale.edu> Jan Skibinski <jans(a)numeric-quest.com> Malcolm Wallace <malcolm(a)abbess.demon.co.uk> _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [newbie] Lazy >>= ?!
by Scott Turner 18 Feb '01

18 Feb '01

Andrew Cooke wrote: >1. After digesting what you wrote I managed to make a lazy list of IO >monads containing random numbers, but couldn't make an IO monad that >contained a lazy list of random numbers. Is this intentional, me >being stupid, or just chance? I had wondered what kind of thing you were doing with the IO monad. Random numbers are an odd fit. Pseudorandom numbers can be generated in a lazy list easily; you don't need a connection with the IO monad to do it. Using the Random module of the Hugs distribution, it's for example randoms (mkStdGen 1) :: [Int] The IO monad can be brought into this picture easily. return (randoms (mkStdGen 1)) :: IO [Int] But it sounds as if you're looking for something more sophisticated. You want to use randomIO perhaps because it better matches your notion of how random numbers should be generated. Using randomIO places more restrictions on how you operate, because it forces the random numbers to be created in a particular sequence, in relation to any other IO which the program performs. Every random number that is ever accessed must be produced at a particular point in the sequence. An unbounded list of such numbers cannot be returned! That is, you are looking for randomsIO :: IO [a] which yields a lazy list, by means of repeated calls to randomIO. All such calls would have to occur _before_ randomsIO returns, and before _any_ use of the random numbers could be made. The program hangs in the process of making an infinite number of calls to randomIO. But, you may say, those infinite effects are invisible unless part of the list is referenced later in the program, so a truly lazy implementation should be able to skip past that stuff in no time. Well, that's conceivable, but (1) that's making some assumptions about the implemetation of randomIO, and (2) lazy things with no side effects can and should be handled outside of the IO monad. >Also, should I be worried about having more than one IO monad - it >seems odd encapsulating the "outside world" more than once. No. Consider the expression sequence_ [print "1", print "two", print "III"] Try executing it from the Hugs command line, and figure out the type of the list. An expression in the IO monad, such as 'print 1' makes contact with the "outside world" when it executes, but does not take over the entire outside world, even for the period of time that it's active. I moved this to haskell-cafe mailing list, because it's getting a little extended. -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

2 1

Re: Just for your fun and horror
by Ashley Yakeley 18 Feb '01

18 Feb '01

At 2001-02-17 19:50, Manuel M. T. Chakravarty wrote: >It is > > bar = 42 > >for which C has no corresponding phrase. Hmm... #define bar 42 ...although I would always do const int bar = 42 -- Ashley Yakeley, Seattle WA

2 1

Re: Just for your fun and horror
by Scott Turner 18 Feb '01

18 Feb '01

Matthias Felleisen wrote: >When a C programmer thinks about the >'return' type of a C function, he thinks about the value-return half >of a return statement's denotation. The other half, the modified store, >remains entirely implicit as far as types are concerned. Just because the type system of C keeps store implicit, it doesn't change the match between the meaning of 'return' in the two languages. The IO monad provides a refined way of typing imperative-style functions, including return statements. If you want to use a return statement in Haskell, you can, and it's called 'return'. (A reasonable alternative would be for 'return' to have second class status, as syntactic sugar for 'unit', analgous to otherwise=True). -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

4 3

Scalable and Continuous
by Ashley Yakeley 18 Feb '01

18 Feb '01

A brief idea: something like... -- class (Additive a) => Scalable a scale :: Real -> a -> a -- equivalent to * (not sure of name for Real type) class (Scalable b) => Continuous a b | a -> b add :: b -> a -> a difference :: a -> a -> b -- Vectors, for instance, are Scalable. You can multiply them by any real number to get another vector. Num would also be Scalable. An example of Continuous would be time, e.g. "Continuous Time Interval". There's no zero time, although there is a zero interval. Space too: "Continuous Position Displacement", since there's no "zero position". -- Ashley Yakeley, Seattle WA

5 6

Re: [newbie] Lazy >>= ?!
by Scott Turner 17 Feb '01

17 Feb '01

Andrew Cooke wrote: >2. Why does the following break finite lists? Wouldn't they just >become lazy lists that evaluate to finite lists once map or length or >whatever is applied? > >> Now, if this were changed to >> ~(x:xs) >>= f = f x ++ (xs >>= f) >> (a lazy pattern match) then your listList2 would work, but finite >> lists would stop working. They wouldn't just become lazy lists. A "lazy" pattern match isn't about removing unnecessary strictness. It removes strictness that's necessary for the program to function normally. A normal pattern match involves selecting among various patterns to find the one which matches; so it evaluates the expression far enough to match patterns. In the case of (x:xs) it must evaluate the list sufficiently to know that it is not an empty list. A lazy pattern match gives up the ability to select which pattern matches. For the sake of less evaluation, it opens up the possibility of a runtime error, when a reference to a named variable won't have anything to bind to. The list monad is most often used with complete finite lists, not just their initial portions. The lazy pattern match shown above breaks this because as it operates on the list, it assumes that the list is non-empty, which is not the case when the end of the list is reached. A runtime error is inevitable. -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

1 0

Revised numerical prelude, version 0.02
by Dylan Thurston 17 Feb '01

17 Feb '01

Here's a revision of the numerical prelude. Many thanks to all who helped. Changes include: * Removed "Powerful", replacing it with (^) in Num and (**) in Real. * Fixed numerous typos * Removed gcd and co. from Integral * Added shortcomings & limitation of scope * Added SmallIntegral, SmallReal * wrote skeleton VectorSpace, PowerSeries * Added framework to make it run under hugs. There are some usability issues. Any comments welcome! Best, Dylan Thurston

10 12

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 16 Feb '01

16 Feb '01

| On Mon, Feb 12, 2001 at 02:38:25PM -0800, William Lee Irwin III wrote: | > I had in mind looking within the compiler, actually. Where in the | > compiler? It's a big program, it might take me a while to do an | > uninformed search. I've peeked around a little bit and not gotten | > anywhere. | | If anyone else is pursuing thoughts along the same lines as I | am (and I | have suspicions), TysWiredIn.lhs appears quite relevant to the set of | primitive data types, though there is no obvious connection to the | module issue (PrelBase.Bool vs. Foo.Bool). PrelMods.lhs | appears to shed | more light on that issue in particular. $TOP/ghc/compiler/prelude/ was | the gold mine I encountered. Perhaps I should add something here. I'm very sympathetic to the idea of making it possible to do entirely without the standard Prelude, and to substitute a Prelude of one's own. The most immediate and painful stumbling block in Haskell 98 is that numeric literals, like 3, turn into (Prelude.fromInt 3), where "Prelude.fromInt" really means "the fromInt from the standard Prelude" regardless of whether the standard Prelude is imported scope. Some while ago I modified GHC to have an extra runtime flag to let you change this behaviour. The effect was that 3 turns into simply (fromInt 3), and the "fromInt" means "whatever fromInt is in scope". The same thing happens for - numeric patterns - n+k patterns (the subtraction is whatever is in scope) - negation (you get whatever "negate" is in scope, not Prelude.negate) (Of course, this is not Haskell 98 behaviour.) I think I managed to forget to tell anyone of this flag. And to my surprise I can't find it any more! But several changes I made to make it easy are still there, so I'll reinstate it shortly. That should make it easy to define a new numeric class structure. So much for numerics. It's much less obvious what to do about booleans. Of course, you can always define your own Bool type. But we're going to have to change the type that if-then-else uses, and presumably guards too. Take if-then-else. Currently it desugars to case e of True -> then-expr False -> else-expr but your new boolean might not have two constructors. So maybe we should simply assume a function if :: Bool -> a -> a -> a and use that for both if-then-else and guards.... I wonder what else? For example, can we assume that f x | otherwise = e is equivalent to f x = e That is, "otherwise" is a guard that is equivalent to the boolean "true" value. ("otherwise" might be bound to something else if you import a non-std Prelude.) If we don't assume this, we may generate rather bizarre code: f x y | x==y = e1 | otherwise = e2 ===> f x y = if (x==y) e1 (if otherwise e2 (error "non-exhaustive patterns for f")) And we'll get warnings from the pattern-match compiler. So perhaps we should guarantee that (if otherwise e1 e2) = e1. You may say that's obvious, but the point is that we have to specify what can be assumed about an alien Prelude. Matters get even more tricky if you want to define your own lists. There's quite a lot of built-in syntax for lists, and type checking that goes with it. Last time I thought about it, it made my head hurt. Tuples are even worse, because they constitute an infinite family. The bottom line is this. a) It's desirable to be able to substitute a new prelude b) It's not obvious exactly what that should mean c) And it may not be straightforward to implement It's always hard to know how to deploy finite design-and-implementation resources. Is this stuff important to a lot of people? If you guys can come up with a precise specification for (b), I'll think hard about how hard (c) really is. Simon

5 9

Re: Just for your fun and horror
by C.Reinke 16 Feb '01

16 Feb '01

> `return' in Haskell vs `return' in C,... Unless you're one of Asimov's technicians of eternity, it is a bit difficult to change the history of programming languages, and assuming that the students pay for the opportunity to learn, you can't really fire them either.. but I agree with Mathias' suggestion to go from the specific to the general. Before anyone complains that abstract and generalised concepts are so much more important and powerful that specific and simplified instances - if you believe this, you will also agree that giving students a chance to learn the general process of abstraction for themselves is more important and empowering than teaching them some specific abstractions. (I'm not sure whether it is even possible to reach all students in a course, but I will certainly not recommend to give up trying;-) One way to look at the problem is that some of your students have concrete experience with `return' in different contexts, and that Haskell tries to make different things look similar here. You say "we worked with monads for several weeks" but, you being yourself, this was probably at a fairly abstract and general level, right? My suggestion is to give your students some concrete experience to counter the one they bring into your course, by introducing the abstract monads via an intermediate step of concrete representations. As you're teaching programming language implementation anyway, why not have an algebraic datatype with return and bind *constructors*, together with some explicit *interpreters* (plural) for the language of structures built from those constructors (even as student exercises)? Perhaps we can gain a better understanding of the student perspective if we compare the situation with lists or other data structures: do we start teaching their folds and the fold-representation of data structures right away, or do we start with concrete intermediate structures, and move on to folds and deforestation later? Of course, with a concrete representation of monads, it is difficult to hold up the law, so after this intermediate step (in which students get their hands on `return' et.al., and in which interpreters can interpret `return a' in any way they please), one can move on to an abstract data type of monads. After all, that's what abstract data types are there for. Hth, Claus

1 0

Re: Just for your fun and horror
by Steinitz, Dominic J 16 Feb '01

16 Feb '01

I always liked unit rather than return. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0