- Haskell - Haskell.org

Re: Anomalous Class Fundep Inference
by Ashley Yakeley 05 May '01

05 May '01

At 2001-05-05 03:21, Jon Fairbairn wrote: >Ashley Yakeley <ashley(a)semantic.org> wrote >> OK, I understand it a bit better now. This code does not compile: >> -- >> class X a >> instance X Bool >> instance (Num a) => X a >> -- >> Can someone explain why the two instances overlap, given that Bool is not >> an instance of Num? >> >> Would it be possible for Haskell to figure out this sort of thing and not >> complain about it, or would that lead to nasty problems? > >Think what would happen if someone had a module that did define >Bool as an instance of Num Should give an error. >and imported the class X. Curiously, whereas Hugs -98 rejects this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x instance (Num a) => X a a where x = 0 -- line A -- ...it accepts this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x module P where import M instance (Num a) => X a a where x = 0 -- line A -- i.e., simply moving line A to a different module. In the latter case it claims these: x :: X a a => a y :: Y a a => a -- Ashley Yakeley, Seattle WA

1 0

RE: Anomalous Class Fundep Inference
by Ashley Yakeley 05 May '01

05 May '01

At 2001-05-03 01:42, Simon Peyton-Jones wrote: >Quite right too! OK, I understand it a bit better now. This code does not compile: -- class X a instance X Bool instance (Num a) => X a -- Can someone explain why the two instances overlap, given that Bool is not an instance of Num? Would it be possible for Haskell to figure out this sort of thing and not complain about it, or would that lead to nasty problems? -- Ashley Yakeley, Seattle WA

3 2

User defined Ix instances potentially unsafe
by Matt Harden 05 May '01

05 May '01

Sorry if this has been reported before. I shouldn't be able to crash ghc or hugs without using any "unsafe" features, right? Well, here 'tis: > module CrashArray where > > import Array > import Ix > > newtype CrashIx = CrashIx Int deriving (Ord, Eq, Show) > > instance Enum CrashIx where > toEnum x = (CrashIx x) > fromEnum (CrashIx x) = x > > instance Ix CrashIx where > inRange (_,_) _ = True > index (_,_) (CrashIx x) = x > range (x,y) = [x..y] > > myArray = listArray (CrashIx 0, CrashIx 0) [0] > crash = myArray ! (CrashIx maxBound) In ghci-5.00, I get a segfault and hugs-feb-2000 says: INTERNAL ERROR: Error in graph Now, admittedly my Ix instance is broken, but I don't think I should be able to segfault the interpreter. Unfortunately, I think the only way to fix this without changing the Library Report would be to add another layer of range checking to the array implementation. Bleh. Note also that the (inefficient) implementation in the report wouldn't crash, but would get the "wrong" error: "Undefined array element" instead of "Index out of range". I think we might describe this as a bug in the Library Report, rather than in any particular Haskell implementation. Enjoy! Matt Harden

2 2

Question: Hugs as Browser Plug In
by Michae Fliegner 04 May '01

04 May '01

I have - or at least dreamt I had - read about using Hugs as a Netscape Plug In, but can't find that anymore. Any hints - positive or negative? thanks in advance Michael FLiegner

2 1

Help wanted with hugs error message
by Norman Ramsey 04 May '01

04 May '01

I am compiling the following inoffensive source file, dubbed finterp.lhs: '''Interpreter for factors''' > module FactorInterp where > import Ast (Sym) > import Value () > import Factor > result = "*" > exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Hugs reports: ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import But there is no explicit `exp' in any of my other modules: : nr@labrador 1337 ; grep -w exp *.lhs finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Can anyone help me to find an expunge this error? Thanks, Norman

3 2

Re: Implict parameters and monomorphism
by John Hughes 04 May '01

04 May '01

> Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. This is a matter of taste, and Haskell deliberately supports both a style with and without type signatures on top-level bindings. I'd be sorry to see that change. One good reason for NOT giving inferrable type signatures is that including them makes programs less modifiable: a small local change, such as adding a parameter to a type, may force a large number of consequential changes to type signatures. I've seen cases where programmers refrained from a significant improvement, because of the labour required to update type signatures (which had been included, ironically, to disable the monomorphism restriction!). I'm not saying it's bad to give type signatures, just that there are arguments for both styles, and the language ought not to make either one difficult to use. John

4 5

MERLIN Call for Participation
by Roy L. Crole 04 May '01

04 May '01

CALL FOR PARTICIPATION Workshop on MEchanized Reasoning about Languages with variable bINding (MERLIN 2001) Siena, Italy, June 18-19, 2001 in connection with IJCAR 2001 ********************************** * http://www.mcs.le.ac.uk/merlin * ********************************** **** Early registration: May 15, 2001 **** ********************************** Currently, there is considerable interest in the use of computers to encode (operational) semantic descriptions of programming languages. Such encodings are often done within the metalanguage of a theorem prover or related system. The encodings may require the use of variable binding constructs, inductive definitions, coinductive definitions, and associated schemes of (co)recursion. The aim of this workshop is to provide researchers with a forum to review state of the art results and techniques, and to present recent and new progress in the areas of: + The automation of the metatheory of programming languages, particularly work which involves variable binding. + Theoretical and practical problems of encoding variable binding, especially the representation of, and reasoning about, datatypes defined from binding signatures. IMPORTANT DATES Early registration: **** May 15, 2001 **** MERLIN workshop: June 18, 2001 IJCAR 2001: June 20-23, 2001 REGISTRATION For details of registration, please see the IJCAR 2001 website at http://www.dii.unisi.it/~ijcar/ INVITED TALK Andrew Pitts, University of Cambridge, has agreed to give an invited talk on "A First Order Theory of Names and Binding". ACCEPTED PAPERS Andreas Abel (Carnegie Mellon, USA). A Third-Order Encoding of the Lambda-Mu-Calculus. Gilles Dowek (INRIA, France), Therese Hardin (LIP6, UPMC, France) and Claude Kirchner (LORIA & INRIA, France). A Completeness Theorem for an Extension of First-Order Logic with Binders. Marino Miculan (Udine, Italy). Developing (Meta)Theory of Lambda-Calculus in the Theory of Contexts. Dale Miller (Pennsylvania State, USA). Encoding Generic Judgements. Christine Roeckl (LAMP-DI-EPFL, Switzerland). A First-Order Syntax for the Pi-Calculus in Isabelle/HOL using Permutations. Carsten Schurmann, Dachuan Yu and Zhaozhong Ni (Yale, USA). Case Study: Formal Development of Safe Intermediate Languages. Rene Vestergaard (CNRS-IML, France) and James Brotherston (Edinburgh, UK). The Mechanisation of Barendregt-Style Equational Proofs (the Residual Perspective). PROGRAMME COMMITTEE Simon Ambler (University of Leicester) Roy Crole (Chair; University of Leicester) Amy Felty (University of Ottawa) Andrew Gordon (Microsoft Research, Cambridge) Furio Honsell (University of Udine) Tom Melham (University of Glasgow) Frank Pfenning (Carnegie Mellon University) FURTHER DETAILS For further details about the Workshop, please contact one of + Roy L. Crole, email: R.Crole(a)mcs.le.ac.uk + Simon J. Ambler, email: S.Ambler(a)mcs.le.ac.uk + Alberto Momigliano (Local Organizer), email: A.Momigliano(a)mcs.le.ac.uk at postal address: Department of Mathematics and Computer Science, University of Leicester, University Road, LEICESTER, LE1 7RH, United Kingdom.

1 0

Unicode and is*
by Ian Lynagh 04 May '01

04 May '01

Hi all Is there a reason why isUpper and isLower include all unicode characters of the appropriate class but isDigit is only 0..9? Are there any Haskell unicode libraries around? And is the implementation of unicode support for GHC being discussed/developed anywhere? BTW, The comments in the report (primUnicodeIsUpper -- 'A'..'Z') are also misleading. Thanks Ian

2 1

Re: Implict parameters and monomorphism
by John Hughes 03 May '01

03 May '01

(B) Monomorphism restriction "wins" Bindings that fall under the monomorphism restriction can't be generalised Always generalise over implicit parameters *except* for bindings that fall under the monomorphism restriction Consequences * Inlining isn't valid in general * No unexpected loss of sharing * Simple bindings like z = ?y + 1 accepted (get value of ?y from binding site) (C) Always generalise over implicit parameters Bindings that fall under the monomorphism restriction can't be generalised, EXCEPT for implicit parameters Consequences * Inlining remains valid * Unexpected loss of sharing (from the extra generalisation) * Simple bindings like z = ?y + 1 accepted (get value of ?y from occurrence sites) Discussion ~~~~~~~~~~ None of these choices seems very satisfactory. But at least we should decide which we want to do. It's really not clear what is the Right Thing To Do. If you see z = (x::Int) + ?y would you expect the value of ?y to be got from the *occurrence sites* of 'z', or from the valuue of ?y at the *definition* of 'z'? In the case of function definitions, the answer is clearly the former, but less so in the case of non-fucntion definitions. On the other hand, if we say that we get the value of ?y from the definition site of 'z', then inlining 'z' might change the semantics of the program. Choice (C) really says "the monomorphism restriction doesn't apply to implicit parameters". Which is fine, but remember that every innocent binding 'x = ...' that mentions an implicit parameter in the RHS becomes a *function* of that parameter, called at each use of 'x'. Now, the chances are that there are no intervening 'with' clauses that bind ?y, so a decent compiler should common up all those function calls. So I think I strongly favour (C). Indeed, one could make a similar argument for abolishing the monomorphism restriction altogether. I disagree. I think it's important to have a simple model of how many times expressions are evaluated. Function bodies are clearly evaluated many times, once for each call, but non-function bindings should be evaluated at most once to respect call-by-need semantics. Breaking the monomorphism restriction in ANY case makes both space and time cost of evaluation unpredictable, and brittle when program changes elsewhere introduce or remove an implicit parameter. It isn't good enough to say `the chances are' that a program has, for example, linear time and constant space complexity: the programmer should be able to convince himself of such properties. As far as what one would `expect', it's in the very nature of dynamic binding that it makes the meaning of an expression depend on its context. I for one would certainly not expect that inlining a definition bound to such an expression should preserve its meaning! Inlining changes the context, so `of course' can change the meaning. So I strongly prefer (B)! John Hughes

6 6

Re: Implict parameters and monomorphism
by John Hughes 03 May '01

03 May '01

Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. Well, the Haskell Report may not require call-by-need semantics, but it permits it at least. Without the MR that would not be the case: some programs would *require* call-by-name. Actually I would prefer the report to be much more explicit about both sharing and evaluation order, to enable compiler-independent reasoning about time and space behaviour. As it stands, compilers do in fact implement call-by-need, and so one can in practice reason fairly safely about time behaviour, but they vary in the choice of evaluation order, which makes space leaks come and go on different compilers. In any case, I don't buy the argument that because reasoning about costs is already problematic in Haskell, it doesn't matter if we make it even harder...! > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. I have no faith in compiler warnings. For one thing, they're irritating. For another, you don't see them when it matters -- when you *read* the code. I'd far rather explicitly distinguish call-by-name and call-by-value in the source code (and made a suggestion along these lines some time ago), so that the semantics is visible to all. Of course, we can't forbid the programmer to write inefficient programs. But we can make gross inefficiencies easier or harder to find. Haskell just can't be used in practice unless one tracks down and fixes space leaks. I don't want to be debugging "time leaks" caused by unexpected call-by-name as well! -- Andreas Rossberg, rossberg(a)ps.uni-sb.de John Hughes

2 1