- Haskell-Cafe - Haskell.org

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

Re: Primitive types and Prelude shenanigans
by Ketil Malde 16 Feb '01

16 Feb '01

William Lee Irwin III <wli(a)holomorphy.com> writes: > Some analysis of the value of the literal would need to be > incorporated so that something like the following happens: > literal "0" gets mapped to zero :: AdditiveMonoid t => t > literal "1" gets mapped to one :: MultiplicativeMonoid t => t Indeed. Is it a reasonable assumption that all values of literal "0" are intended to be the additive identity element? How about "1", might we not have it as a successor element in a group, where multiplication isn't defined? I guess other behaviour (e.g. using implicit fromInteger) assumes even more about the classes that can be represented by literal numbers, so it appears this would be an improvement, if it is at all workable. > literal "5" gets mapped to (fromPositiveInteger 5) Is something like (fromInteger 5) *> one (where *> is Module scalar multiplication from the left? Could we avoid having lots and lots of from* functions? I guess having to declare any datatype as Module is as bad as the explicit conversion functions... Anyway, I like it, especially the zero and one case. > I think Dylan Thurston's proposal is probably the best starting point > for something that should really get support. Indeed. How far are we from being able to import it, e.g. with "import DTlude as Prelude" or whatever mechanism, so that we can start to play with it, and see how it works out in practice? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: need help w/ monad comprehension syntax
by Konst Sushenko 15 Feb '01

15 Feb '01

thanks, did not know that. the articles that i read are outdated in that respect... using the "do" notation is just fine. with the list notation not working i thought that i musunderstand something about monads. ;-) konst -----Original Message----- From: Tom Pledger [mailto:Tom.Pledger@peace.com] Sent: Thursday, February 15, 2001 5:22 PM To: haskell-cafe(a)haskell.org Subject: need help w/ monad comprehension syntax Konst Sushenko writes: | what am i missing? : | > --g :: State String Char | > g = [ x | x <- return 'a' ] Hi. The comprehension syntax used to be for monads in general (in Haskell 1.4-ish), but is now (Haskell 98) back to being specific to lists. Does it help if you use do-notation instead? Regards, Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

need help w/ monad comprehension syntax
by Konst Sushenko 15 Feb '01

15 Feb '01

hello, i am having trouble getting my program below to work. i think i implemented the monad methods correctly, but the function 'g' does not type as i would expect. Hugs thinks that it is just a list (if i remove the explicit typing). i want it to be functionally identical to the function 'h'. what am i missing? thanks konst > newtype State s a = ST (s -> (a,s)) > > unST (ST m) = m > > instance Functor (State s) where > fmap f m = ST (\s -> let (a,s') = unST m s in (f a, s')) > > instance Monad (State s) where > return a = ST (\s -> (a,s)) > m >>= f = ST (\s -> let (a,s') = unST m s in unST (f a) s') > > --g :: State String Char > g = [ x | x <- return 'a' ] > > h :: State String Char > h = return 'a'

2 1

Downloading Hugs
by zulf jafferi 15 Feb '01

15 Feb '01

hi, I tried to download the Hugs 98.after downloading Hugs 98,when i try to click on the Hugs icon it gives me an error saying COULD NOT LOAD PRELUDE.i am using Windows 2000. I would be much obliged if you could help me solve the problem. cheers!! _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

Re: framework for composing monads?
by Jan Kort 15 Feb '01

15 Feb '01

Andy Gill's Monad Template Library is good for that, but the link from the Haskell library page is broken: http://www.cse.ogi.edu/~andy/monads/doc.htm Jan

1 0

RE: Primitive types and Prelude shenanigans
by Simon Marlow 15 Feb '01

15 Feb '01

> (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! It's lumped in with -fno-implicit-prelude, but the extra functionality isn't supported in 4.08.2 (but hopefully will be in 5.00). Cheers, Simon

1 0

RE: Typing units correctly
by Andrew Kennedy 14 Feb '01

14 Feb '01

To be frank, the poster that you cite doesn't know what he's talking about. He makes two elementary mistakes: (a) attempting to encode dimension/unit checking in an existing type system; (b) not appreciating the need for parametric polymorphism over dimensions/units. As others have pointed out, (a) doesn't work because the algebra of units of measure is not free - units form an Abelian group (if integer exponents are used) or a vector space over the rationals (if rational exponents are used) and so it's not possible to do unit-checking by equality-on-syntax or unit-inference by ordinary syntactic unification. Furthermore, parametric polymorphism is essential for code reuse - one can't even write a generic squaring function (say) without it. Best to ignore the poster and instead read the papers that contributors to this thread have cited :-) To turn to the original question, I did once give a moment's thought to the combination of type classes and types for units-of-measure. I don't think there's any particular problem: units (or dimensions) are a new "sort" or "kind", just as "row" is in various proposals for record polymorphism in Haskell. As long as this is tracked through the type system, everything should work out fine. Of course, I may have missed something, in which case I'd be very interested to know about it. - Andrew Kennedy. > -----Original Message----- > From: andrew(a)andrewcooke.free-online.co.uk > [mailto:andrew@andrewcooke.free-online.co.uk] > Sent: Wednesday, February 14, 2001 5:02 PM > To: haskell-cafe(a)haskell.org > Subject: Re: Typing units correctly > > > > Hi, > > I don't know if this is useful, but in response to a link to that > article that I posted on Lambda, someone posted a link arguing that > such an approach (at least in Ada) was impractical. To be honest, I > don't find it very convincing, but I haven't been following this > discussion in detail. It might raise some problems you have not > considered. > > Anyway, if you are interested, it's all at > http://lambda.weblogs.com/discuss/msgReader$818 > > Apologies if it's irrelevant or you've already seen it, > Andrew > > On Mon, Feb 12, 2001 at 01:51:54PM -0500, Dylan Thurston wrote: > [...] > > The papers I could find (e.g., > > http://citeseer.nj.nec.com/kennedy94dimension.html, > "Dimension Types") > > mention extensions to ML. I wonder if it is possible to work within > > the Haskell type system, which is richer than ML's type system. > [...] > > -- > http://www.andrewcooke.free-online.co.uk/index.html >

2 1