- Haskell - Haskell.org

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

RE: BAL paper available
by Conal Elliott 15 May '01

15 May '01

Small comment. Marcin wrote: > About program transformation possibility: I don't see how it would > be applied in practice. There is no use of associativity of (+) for > the compiler. It can do many optimizations, but it won't rewrite > x+(y+z) to (x+y)+z nor vice versa. Associativity and commutativity (AC) are not optimizations in themselves, but rather enable optimizations if you have an AC matcher in your rewriting system (as, for instance, in Mathematica). - Conal

1 0

Ix class
by Matt Harden 15 May '01

15 May '01

Hello, I am working on an Ix instance for one of my types and finding it rather restrictive. For me it would be useful to have rangeSize be defined in the Ix class (with a default definition of course), so that it can be overridden. Also, does anybody know why Ix derives from Ord? It seems to me this is an unnecessary limitation on the types that can be instances of Ix. I cannot think of a reason why the implementation of anything in the Ix or Array modules would require that every Ix be an Ord (with a minor exception -- see below). If an implementation is using a comparison on an Ix type, chances are it should be using inRange or comparing (index bnds x) with (index bnds y) instead. One change would have to be made in the Array module if Ord is removed from Ix: instance (Ix a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' would become: instance (Ix a, Eq a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' As I said, I think this is a very minor issue. I believe that making these changes in the standard would not impact existing programs in any way. Could these changes be considered as a possible "typo" to be fixed in the Library Report? P.S. In case anybody's interested, here's why I want to override rangeSize: > newtype Honeycomb = Hx (Int,Int) deriving (Eq,Show,Ord) > > indexError = error "Index out of range" > > instance Ix Honeycomb where > range (Hx b1, Hx b2) = > [Hx x | x <- range (b1,b2), isHexIx x] > inRange (Hx b1, Hx b2) (Hx x) = > inRange (b1,b2) x && isHexIx x > index (Hx b1, Hx b2) (Hx x) = > let i = index (b1,b2) x in > if isHexIx x then i `div` 2 else indexError > > isHexIx :: (Int,Int) -> Bool > isHexIx (x,y) = x `mod` 2 == y `mod` 2 This implements a honeycomb or hexagonal tiling for a maze generating program. The honeycomb is superimposed on a grid such that only every other square is "active", corresponding to a particular hexagon in the honeycomb. It's similar to a checkers game, where only the dark squares are used. I would like _any_ pair of Ints to be an acceptable boundary for the honeycomb, not just the ones that represent valid indexes. For example, (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current definition of rangeSize makes this impossible, which is why I would like to override it. By the way, the Library Report does not explicitly say that the bounds have to both be valid indexes, though it does imply this with the sample definition of rangeSize. Thanks, Matt Harden

2 1