- Haskell - Haskell.org

RE: Implict parameters and monomorphism
by Simon Peyton-Jones 07 May '01

07 May '01

Now that is a *really* amazing example. I had no idea that polymorphic recursion would do this. I withdraw my claim that a type signature can't change the answer. But I'm worried. Simon | -----Original Message----- | From: Lennart Augustsson [mailto:augustss@augustsson.net] | Sent: 03 May 2001 15:24 | To: C.Reinke(a)ukc.ac.uk; qrczak(a)knm.org.pl | Cc: haskell(a)haskell.org | Subject: Re: Implict parameters and monomorphism | | | OK, so since noone liked my original example here's another | one. It involves no defaulting and no classes in the funny | function definition. | | -- Here's the type signature that makes a difference. | --fun :: a -> Char | fun x = const (fun x) (fun True) | | fix f = let x = f x in x | | class C a where | m :: a -> String | | instance C Char where | m _ = "has signature" | | instance C Bool where | m _ = "no signature" | | main = putStrLn (m (fix fun)) | | | It is not at all surprising that you can write this. | Originally type signatures only allowed you to put a | signature that was | more specific. | Polymorhic recursion on the other hand allows you to make the | type more general by putting a type signature on a | definition. Combining these you can make the signature be | incomparable to the deduced type. Using the class system you | can then dispatch on the type and get different behaviour. | | -- Lennart | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

3 3

Haskell Simulator of Quantum Computer
by Jan Skibinski 05 May '01

05 May '01

Hoping to get some early feedback I am posting this very preliminary version: http://www.numeric-quest.com/haskell/QuantumComputer.html Jan

1 1

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 05 May '01

05 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