February 2002 - Haskell

mailing list trouble
by David Feuer 04 Feb '02

04 Feb '02

There seems to be something wrong with the February archives for several of the haskell.org mailing lists (in short, they have vanished....). I tried to send a message about this to owner-haskell(a)haskell.org, but the message was rejected by the mailer daemon. Anyone here know anything about this? David Feuer

4 3

Summer School on Generic Programming
by Johan Jeuring 04 Feb '02

04 Feb '02

Summer School and Workshop on Generic Programming St Anne's College, Oxford, UK 26th to 30th August 2002 In conjunction with Summer School and Workshop on Advanced Functional Programming This school is a successor to the Summer School and Workshop on Algebraic and Coalgebraic Methods in the Mathematics of Program Construction, held in Oxford in April 2000 and with lecture notes shortly to appear as LNCS 2297. For this school we have recruited an excellent group of lecturers on generic programming, that is, the construction of programs that work on different datatypes and yet may exploit the structure of that data. ************ Lecturers ************ * Roland Backhouse (University of Nottingham): A Generic Theory of Datatypes * Peter Buneman (University of Edinburgh): Semi-Structured Data * Roy Crole (University of Leicester): Categories and Types * Jose Luiz Fiadeiro (University of Lisbon and ATX Software): Theory and Practice of Software Architecture * Ralf Hinze (University of Bonn) and Johan Jeuring (University of Utrecht): Generic Haskell * Martin Odersky (Ecole Polytechnique Federale de Lausanne): Object-Oriented and Functional Approaches to Compositional Programming ************ Deadlines ************ For registration with an early-bird discount: 17th May 2002 For late registration: 12th July 2002 ************ Organizers ************ Roland Backhouse (University of Nottingham) Jeremy Gibbons (University of Oxford) ************ Further information ************ Web: http://www.comlab.ox.ac.uk/oucl/research/areas/ap/ssgp/info.html PDF poster: http://www.comlab.ox.ac.uk/oucl/research/areas/ap/ssgp/ssgp-poster.pdf Email: ssgp-info(a)comlab.ox.ac.uk Post: SSGP, c/o Jane Ellory, Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford OX1 3QD, United Kingdom. Fax: +44 1865 273839; mark "fao SSGP (Jane Ellory)"

1 0

RE: Non-determinism in newline in the Haskell report
by Simon Peyton-Jones 04 Feb '02

04 Feb '02

2 1

RE: Implicit Parameters
by Chris Angus 04 Feb '02

04 Feb '02

I'm obviously missing something here. I dont understand what monomorphism has to do with the given example as the implicit parameter would be the same type [a] for some type a in each case. If we made the parameter explicit then removing the type definition would not cause this problem. Are implicit parameters not simply made explict by the compiler? -----Original Message----- From: John Hughes [mailto:rjmh@cs.chalmers.se] Sent: 04 February 2002 10:26 To: haskell(a)haskell.org; koen(a)cs.chalmers.se Subject: Re: Implicit Parameters Suppose I have the following function definition: app :: (?ys :: [a]) => [a] -> [a] app xs = case ?ys of [] -> xs (y:ys') -> y : (app xs with ?ys = ys') This function appends its argument to its implicit argument, by recursively changing the implicit argument. For example: Hugs> app [1,2] with ?ys = [3,4] [3,4,1,2] So far so good! Now, since Haskell has type inference, we can leave out the type signature: -- app :: (?ys :: [a]) => [a] -> [a] app xs = case ?ys of [] -> xs (y:ys') -> y : (app xs with ?ys = ys') Let us check if it still works again: Hugs> app [1,2] with ?ys = [3,4] [3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,{Interrupted!} And, stunningly, it doesn't! Why doesn't this work? That is because type inference assumes that the body of `app' is monomorphic, i.e. has no context in its type. Therefore, the recursive call to app where ?ys is changed, had no effect at all. It works with the type signature there, because in order to implement type checking (note: not type inference) with polymorphic recursion demands to use the stated type in checking the body of the function. Mark Shields, Simon Peyton-Jones, and I, and also Jörgen Gustavsson have been discussing several modest solutions to this (we believe it is not needed to do full type inference that can deal with polymorphic recursion to solve this problem). Not so fast! Proposing a "solution" means this is regarded as a "problem"! But what is to say that the first behaviour is "right" in any general sense? The important thing is that the language semantics is clear, and this is a semantic question. The static semantics of Haskell *is* clear: recursive calls are monomorphic unless a type signature is given; this is the basis for understanding the behaviour above. When implicit parameters are used, it's very important to be aware whether a binding is monomorphic or not (can't resist plugging := again!). Will your "solution" make understanding when a binding is monomorphic simpler? If not, it could be worse than the "problem" -- and the fact that it makes this one example behave as you want is no justification. John _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: Another Implicit Parameter Infelicity
by Simon Peyton-Jones 04 Feb '02

04 Feb '02

| p :: Maybe ((?param :: a) => a) | p = return g; Neither GHC nor Hugs allow a polymorphic type variable (the argument of Maybe) to be instantiated to a polymorphic type. Systems which do are called 'impredicative' (or is it the other way around?). Going impredicative has big negative implications for type inference, and I have always steered well clear! | Not only that, but they both complain about this: | | q :: b -> ((?param :: a) => a) | | ...even though it can only mean this: | | q :: (?param :: a) => b -> a Hmm. GHC is supposed to "hoist" for-alls that occur at the right hand end of function arrows (yet another non-std extension), but it obviously isn't quite working right. I'll look into that. Simon

1 0

RE: Implicit Parameter Bug?
by Simon Peyton-Jones 04 Feb '02

04 Feb '02

This bug is already fixed in 5.02.2, which is available now. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 04 February 2002 02:23 | To: Haskell List | Subject: Implicit Parameter Bug? | | | What's wrong with this? | | f :: ((?param :: a) => b) -> a -> b | f foo a = foo with ?param=a | | g :: (?param :: a) => a | g = ?param | | h :: a -> a | h = f g | | 'ghci -fglasgow-exts' (5.02) gives this error: | | Could not deduce (?param :: a) from the context () | Probable fix: | Add (?param :: a) to the type signature(s) for h | arising from use of `g' at Implicit.hs:10 | In the first argument of `f', namely `g' | In the definition of `h': f g | | 'hugs -98' (Feb 2000) gets as far as this: | | Reading file "/usr/share/hugs98/lib/Prelude.hs": | Reading file "Implicit.hs": | Type checking | | ...and spins there. | | There's a workaround for ghci, but it doesn't help hugs: | | h :: a -> a | h = f (g with ?param = ?param) | | This is very odd, as surely the type of (g with ?param = | ?param) is the | same as the type of g? | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

Re: RFC: Syntax for implicit parameter bindings
by Ashley Yakeley 04 Feb '02

04 Feb '02

At 2002-02-03 15:34, Manuel M. T. Chakravarty wrote: > The main disadvantage of this solution is that, in > Haskell, some keywords (`let', `case', `where', and `do') > trigger the layout rule and now `dynamic' or `nonrec' > would have to trigger the layout rule, but *only* when > appearing after a `let'. *urgh* Am I the only one who uses braces/semicolons? Anyway, I would be using this under [Just use let]: let { ?base = 10; } in addBase 5 If I read you correctly, under [Add a special identifier], I'd have to do this: let { nonrec { ?base = 10; } } in addBase 5 ...which is just ugly. >[Use a special binding operator] My preference, with ':='. But yes, it does mean some code will have to be rewritten. Not mine. >There was also a mention of extending the implicit parameter >story to work as recursive bindings, but I don't know any >details here. Even if this happens, we can still hold onto := for explicit value bindings, if that's a useful feature. -- Ashley Yakeley, Seattle WA Never trust whitespace.

2 1

Another Implicit Parameter Infelicity
by Ashley Yakeley 04 Feb '02

04 Feb '02

Neither ghci nor hugs like this: g :: (?param :: a) => a g = ?param p :: Maybe ((?param :: a) => a) p = return g; 'ghci -fglasgow-exts' (5.02) says: Illegal constraint ?param :: a In the type: forall a. Maybe ({?param :: a} => a) While checking the type signature for `p' 'hugs -98' (Feb 2000) says: ERROR "Implicit.hs" (line 12): Syntax error in type expression (unexpected implicit parameter "?param") Not only that, but they both complain about this: q :: b -> ((?param :: a) => a) q b = g ...even though it can only mean this: q :: (?param :: a) => b -> a q b = g (which works fine with both). However, this _does_ work, but only in ghci: f :: ((?param :: a) => b) -> a -> b f foo a = foo with ?param=a Hugs just spins trying to do 'Type checking'. -- Ashley Yakeley, Seattle WA

1 0

Implicit Parameter Bug?
by Ashley Yakeley 04 Feb '02

04 Feb '02

What's wrong with this? f :: ((?param :: a) => b) -> a -> b f foo a = foo with ?param=a g :: (?param :: a) => a g = ?param h :: a -> a h = f g 'ghci -fglasgow-exts' (5.02) gives this error: Could not deduce (?param :: a) from the context () Probable fix: Add (?param :: a) to the type signature(s) for h arising from use of `g' at Implicit.hs:10 In the first argument of `f', namely `g' In the definition of `h': f g 'hugs -98' (Feb 2000) gets as far as this: Reading file "/usr/share/hugs98/lib/Prelude.hs": Reading file "Implicit.hs": Type checking ...and spins there. There's a workaround for ghci, but it doesn't help hugs: h :: a -> a h = f (g with ?param = ?param) This is very odd, as surely the type of (g with ?param = ?param) is the same as the type of g? -- Ashley Yakeley, Seattle WA

1 0

Re: Compiler problem or dumb error?
by mgross＠dorsai.org 04 Feb '02

04 Feb '02

On Sun, 3 Feb 2002, Jay Cox wrote: > If checkWid is never invoked, then possibly it is never forced to begin > with, which I think means the bug is elsewhere in your code (or > elsewhere). > Which turns out to be the case, although I haven't pinned it down completely--please see my follow-up post on the same subject. > > btw, your original map function could possibly be better written as a > zipWith as in.. > > > zipWith (\w s -> checkWid ShowList w s) widNodes [0..] > > > zipWith is mentioned in the Prelude and is a fairly widely used > higher-order function. > Neater than what I have, but not quite as obvious as documentation to me (since I have not frequently used zipWith). I will probably replace my code with your suggested code when I remove the scaffolding (read crutches) from my half-built program. Thanks for the hint. Best, Murray Gross mgross(a)dorsai.org

1 0