- Haskell - Haskell.org

Monads
by Mads Skagen 17 May '01

17 May '01

Hi I'v currently working on a school-project where I have to describe the Haskell programming language. I've been looking through Monads and especially the IO monad, the Maybe monad and the list monad My question is why are monads necessary in the language ? Is it not possible to construct the features provided by Monads using basic functional constructs ? What do I gain using Monads ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com

1 0

RE: BAL paper available
by Simon Marlow 16 May '01

16 May '01

> > I don't like the idea of a program working which compiles only under > compilers which have certain language extensions built in. > > If I understand things correctly, there is a list of language > extensions > (FFI for example), which has been accepted by all Haskell > compilers developers. If > multiparameter type classes were in that list, I would agree. > > Besides, MArray.lhs uses ST and ST requires not only > multiparameter type > classes, but also explicit universal quantification. ST doesn't require multiparameter type classes (although MArray does). It also doesn't require full support for explicit universal quantification, if runST is known to the compiler. Also, the ST array types are really an optional part of the MArray interface - it works perfectly well with just the IO array types. > I don't like ST and the idea that someone who wants to use arrays > outside of IO has to use ST gives me creeps. What would you suggest as an alternative? I suppose you could have a monad which just supported a single array, but special-purpose monads tend to be a pain in practice (eg. what happens when you want two arrays?). > By the way, I'm really surprised by the lack of time > complexity information > in MArray. I mean, that's the most important thing in arrays > - that one can > update/read a data in O(1). Point taken, I'll update the documentation to include more of this info. Cheers, Simon

2 1

RE: Scoped type variables
by Simon Peyton-Jones 16 May '01

16 May '01

| | When you say there's a good theoretical foundation (typed lambda | | calcului) I think you are imagining that when we say | | | | f (x::a) = e | | | | we are saying "There's a /\a as well as a \x::a in this definition". | | No, that's not what I'm thinking. OK, let me try to give some type rules for what I have in mind. In these rules, I'm going to have an environment, T, that binds user type variables to types. (A "user type variable" is a type variable that appears in the program text.) There is still a conventional type environment, G (usually written Greek Gamma), that associates user term variables with their types. I'll just deal with type variables in lambda patterns, like \ (x::a) -> E Here's the rule: x_i = free-term-vars(pat) a_i = free-type-vars(pat) \ T (T, a_i=taua_i); (G, x_i:taux_i) |- pat : tau_1 (T, a_i=taua_i); (G, x_i:taux_i) |-- E : tau_2 ------------------------------------------------------- T;G |- \pat -> E : tau_1 -> tau_2 The a_i are the type variables brought into scope by the pattern; namely the free type variable of the pattern which are not already in scope (hence the \ T). The T environment is extended by binding each user type variable a_i to a type taua_i that is gotten out of thin air (as is common in type rules). This new T env is used when typechecking the pattern itself and the body E. The intereesting bit is how to typecheck patterns, and type inside them: T;G |- pat : tau T |- ty : tau ----------------- T;G |- pat::ty : tau That is, to typecheck the pattern (pat::ty), typecheck pat and typecheck ty. The judgement T |- ty : tau checks that the user type ty is well formed with type tau. The key rule of this judgement looks up a type variable in T: ----------------- T |- a : T(a) OK, that's it. The point is simply that the user type variables are regarded as the name of a type; the programmer doesn't specify just what that type is. The type rules just 'inline' the type wherever the name is used. All this translates into completely unmodified System F. | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view | | I hope the answer to (a) is yes, but I realise that opinions may | differ about (b). This message is really just a second attempt at (a) Simon

1 0

Re: Integers to Ints
by Fergus Henderson 16 May '01

16 May '01

On 16-May-2001, Steinitz, Dominic J <Dominic.J.Steinitz(a)BritishAirways.com> wrote: > Can someone explain the following behaviour? Or is it a bug in hugs? It looks to me very much like it is a bug in Hugs. ghc 4.04 does not suffer from this bug. It's easy to make mistakes like this, which can often arise from forgetting the assymetric nature of twos-complement signed integers, which have more negative numbers than positive numbers. We once had a similar kind of bug in the Mercury standard library implementation, where string__to_int was not handling the most negative integer correctly. We fixed that one in March 1998. -- Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

1 0

Re: Integers to Ints
by Rijk-Jan van Haaften 16 May '01

16 May '01

Hello, >Can someone explain the following behaviour? Or is it a bug in hugs? I can not explain it. Rather strange is that even this is allowed: (fromIntegral (toInteger (minBound::Int) + 1) -1) :: Int yielding -2147483648 > > (fromIntegral(toInteger(minBound::Int))::Int) > >Program error: {primIntegerToInt (-2147483648)} >(15 reductions, 70 cells) > > > (fromIntegral(toInteger((minBound::Int)+1))::Int) >-2147483647 >(21 reductions, 29 cells) > > > minBound::Int >-2147483648 >(9 reductions, 19 cells)

1 0

Integers to Ints
by Steinitz, Dominic J 16 May '01

16 May '01

Can someone explain the following behaviour? Or is it a bug in hugs? X690v5> (fromIntegral(toInteger(minBound::Int))::Int) Program error: {primIntegerToInt (-2147483648)} (15 reductions, 70 cells) X690v5> (fromIntegral(toInteger((minBound::Int)+1))::Int) -2147483647 (21 reductions, 29 cells) X690v5> minBound::Int -2147483648 (9 reductions, 19 cells) Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

RE: BAL paper available
by Simon Peyton-Jones 16 May '01

16 May '01

| Despite my extremely deep respect for all people contributing | to Haskell, despite my love for the language etc. I begin to | suspect that it has been standardized too early, and if we | (Sergey, other people interested in math, | as Dylan Thurston, myself, etc., as well as people who want | to do *serious* graphics in a functional way) want an adapted | functional language, either we will have to wait quite long, | or perhaps it is the time to invent another language, with a | more dynamic type system, with intrinsic graphic utilities, | and other goodies. For the moment - this is my personal | viewpoint - it might be better to write concrete | applications, and papers describing those applications. Then | we shall perhaps know better what kind of structures, | algorithms, representations, genericities, etc. we REALLY | need for practical purposes. H98 is standardised, but Haskell certainly isn't. GHC and Hugs both have numerous extensions. So I don't think standardisation is a difficulty. The availability of implemention effort certainly is. But even before that, to implement something one needs a good clear specification, and preferably one that several people subscribe to (i.e. agree with the need and the design of the extension to meet that need). My guess is that the lacks you allude are due not to standardisation, nor to implementation effort, but rather to the lack of design/specfication. If there are things you want, perhaps you can contribute to a design for that thing? (Of course, the existence of a design doesn't guarantee an implementation; implementation effort is certainly an issue. But the absence of a design more or less guarantees the absence of an implementation.) I too have a great respect for the work that Sergey, Jerzy and others have been doing. Indeed I don't understand the half of it. I hope I don't even need to understand it because it's a Haskell library. But not understanding it leaves me badly placed to know what the language difficulties are and maybe there are others in my position. Simon

1 0

Book reviewers for Journal of Functional Programming
by S.J.Thompson 16 May '01

16 May '01

I am looking for book reviewers for the Journal of Functional Programming. Book reviews provide a service to the functional programming community by critically appraising many of the key books coming out in the field. If you are interested in becoming a reviewer, please send me an email with - A two sentence biography. - Your particular reviewing interests (e.g. teaching texts, books on ML, etc.) Current books up for review include Trends in Functional Programming edited by Greg Michaelson, et al Intellect Books, 1999 Trends in Functional Programming vol 2 edited by Stephen Gilmore Intellect Books, 2000 How to Design Programs by Felleisen et al MIT Press, 2001 Objective Caml Pascal Manoury and Bruno Pagano O'Reilly, 2000 Principles of Programming Languages Bruce Maclennan Oxford University Press, 1999 so let me know if you are interested in reviewing one of these, or indeed please make any suggestions about books you would like to see reviewed. You can find guidelines for writing JFP book reviews at http://www.dcs.gla.ac.uk/jfp/guidelines.html Thanks very much, Simon Thompson s.j.thompson(a)ukc.ac.uk

1 0

Re: BAL paper available
by Ashley Yakeley 16 May '01

16 May '01

At 2001-05-16 00:18, Wojciech Moczydlowski, Jr wrote: >> I think multiparameter type classes or other extensions to Haskell 98 are >> really needed to solve these kinds of problems in a simple and elegant way. >> >> The right solution, IMHO, is to extend nhc and other Haskell compilers >> to support multiparameter type classes, not to try to shoehorn things >> that don't fit into Haskell 98. >I don't like the idea of a program working which compiles only under >compilers which have certain language extensions built in. > >If I understand things correctly, there is a list of language extensions >(FFI for example), which has been accepted by all Haskell compilers >developers. If >multiparameter type classes were in that list, I would agree. I tend to share Fergus Henderson's viewpoint. I see a Haskell with multiparameter type classes as a language I want to work with, and it would be great to have libraries written for that. I'm less interested in Haskell 98, since it means muckier solutions to the same problems. -- Ashley Yakeley, Seattle WA

1 0

WFLP 2001 deadline extension to May 22, 2001
by Frank Steiner 16 May '01

16 May '01

Due to various requests, the DEADLINE FOR SUBMISSIONS to WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming Kiel, Germany, September 13-15, 2001 http://www.informatik.uni-kiel.de/~wflp2001 has been EXTENDED TO MAY 22, 2001.

1 0