- Haskell - Haskell.org

Explicit Universal Quantification Bug?
by Jay Cox 24 Jan '02

24 Jan '02

I'm trying to learn more about Explicit Universal Quantification so I decide to run the following supposedly correct code from the ghc user guide: >module Dummy where > >import ST > >newtype TIM s a = TIM (ST s (Maybe a)) > >runTIM :: (forall s. TIM s a) -> Maybe a >runTIM t = case t of {TIM l -> runST l} however when i try to actually compile it with ghc 5.02.1 it gives this error ... C:\exp>ghc -fglasgow-exts -package lang x.lhs ~ x.lhs:8: Inferred type is less polymorphic than expected Quantified type variable `s' escapes It unifies with `s1', which is mentioned in the environment The following variables in the environment mention `s1' l :: ST s1 (Maybe a) Signature type: forall s. ST s a1 Type to generalise: ST s1 (Maybe a) When checking an expression type signature In the first argument of `runST', namely `l' In a case alternative: runST l C:\exp> ... so, is this a bug? I noticed also the following code compiles fine. (slightly modified from a message on this list titled "Re: Type problem with ST monad" dating April 23, 1999 >module Dummy where > >import ST > >newtype TIM s a = TIM (ST s (Maybe a)) > >runTIM :: (forall s. TIM s a) -> Maybe a >runTIM t = runST (deTIM t) > >deTIM (TIM t) = t so, is using a pattern matching function the truly accepted way instead of using the case statement mentioned in the docs? Is the ghc manual outdated? Thanks Jay Cox

1 0

Re: Instance contexts constraining only type variables?
by Wolfgang Jeltsch 24 Jan '02

24 Jan '02

Wolfgang Lux wrote: > Wolfgang Jeltsch wrote > > > Hello, > > say I have a type T defined the follwing way: > > newtype T a b = T (a b) > > Now I want to make every T a b with a b beeing an instance of Eq also an > > instance of Eq where (==) just test for equality of the encapsulated values. > > I > > try this > > instance Eq (a b) => Eq (T a b) where > > (T x) == (T x') = x == x' > > but it seems that this is not Haskell 98 conformant. > > You probably meant a and b being an instance of Eq, No! Look at the definition of T. Right to the equals sign there is T (a b) which implies that a b has kind * and therefore kind (a) = kind (b) -> * if for any type t kind (t) is the kind of t. So a can never be an instance of Eq because it doesn't have kind *. Every value of type T encapsulates exactly one value which is of type a b. I want to test for equality of these values wherefore a b has to be an instance of Eq. By the way, why is (* -> *) -> * -> * the infered kind of T and not for instance ((* -> *) -> *) -> (* -> *) -> *? > so you should write it > down the same way :-) > > instance (Eq a,Eq b) => Eq (T a b) where > ... > > Wolfgang > > -- > Wolfgang Lux Phone: +49-251-83-38263 > Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 > Universitaet Muenster Email: wlux(a)uni-muenster.de Wolfgang

1 0

RE: H98 Report: semantics of pattern matching
by Simon Peyton-Jones 24 Jan '02

24 Jan '02

| From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 21 January 2002 17:20 | To: haskell(a)haskell.org | Subject: H98 Report: semantics of pattern matching | | | In section 3.17 Pattern Matching, there are some | inconsistencies between the informal and formal semantics: Tbanks very much Ross. I agree with all your suggestions and will implement them. Simon

1 0

Make Lots of $$$$$$$$$$$$$$$$
by ky_1064＠yahoo.com 24 Jan '02

24 Jan '02

1 0

Re: type class VS struct/functor
by Mike Gunter 24 Jan '02

24 Jan '02

You can also export the type without exporting the constructors. That way "import"ers can use the type in type signatures and instance declarations while still not being able to use anything but the exported interface. E.g. instead of Module Set ( emptySet , makeSet , firstOfSet ) where use Module Set ( Set -- <=========== , emptySet , makeSet , firstOfSet ) where . (The non-hiding export is Module Set ( Set(..) -- <=========== , emptySet , makeSet , firstOfSet ) where .) This is covered in the Haskell report; see: http://www.haskell.org/onlinereport/modules.html#abstract-types . mike > At 13:15 2002-01-22 -0500, Hongwei Xi wrote: > ><...> > >In Haskell, I guess that the one implemented later is always chosen. > >Why can't I have two different implementations for an interface? > > Actually, I can't think of situations where I would desire this. > Could you please give an example? > > >Another problem with Haskell classes is that there is currently > >no way of hiding type information. For instance, suppose that > >I want to implement a module for operations on sets but I do > >not want to reveal what data representation I use for sets. Is > >there a way of doing this in Haskell? > > > >--Hongwei > > There is: Use restricted exports. Only export functions on the > datatype, and don't export the datatype itself. For example: > > ----------------------- > Module Set > ( emptySet > , makeSet > , firstOfSet > ) where > > -- Not exported, only locally visible > data Set a = EmptySet | OneElementSet a > > -- Using these functions, everyone can > -- make, change and read Set's > emptySet :: Set a > emptySet = EmptySet > > makeSet :: a -> Set a > makeSet x = OneElementSet x > > firstOfSet :: Set a -> a > firstOfSet EmptySet = error "Set.firstOfSet: Empty set" > firstOfSet (OneElementSet x) = x > ----------------------- > > Regards, > > Rijk-Jan van Haaften > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

type class VS struct/functor
by 안기영 23 Jan '02

23 Jan '02

I prefer Haskell style type classes because using them one can overload functions. e.g. \begin{code} class Container a where celem :: Eq b => b -> a b -> Bool cmap :: (Eq b, Eq c) => (b->c) -> a b -> a c data MyList a = MyList [a] deriving Show instance Container MyList where celem x (MyList l) = elem x l cmap f (MyList l) = MyList (map f l) \end{code} What does ML struct/functor have anything better than type classes ? For the user type classes feels like implicit functor istantiations to specific sturucture, and struct/functor seems just bugglling the user to do more typing which can be automated by using type classes. Type classes are more than automatic functor instantiation since it can construct hierarcy between types and you can implement implicit type conversoins. I think ML, especially nML - the Korean dialact of ML being developed in ROPAS(http://ropas.kaist.ac.kr/) - should throw away struct/functor or deprecate them and move to type classes. p.s. Am I asking ML to metamorph into eager Haskell ? :-)

3 2

Re: Translation of SML into Haskell
by Ashley Yakeley 23 Jan '02

23 Jan '02

At 2002-01-23 08:35, Till Mossakowski wrote: >Is there any tool for translating SML into Haskell? >(say, a suitable subset, i.e. just pure > features, and no functors) Oh you can do modules and functors too, can't you? See for instance: ML <http://haskell.org/pipermail/haskell-cafe/2002-January/001258.html> Haskell <http://haskell.org/pipermail/haskell-cafe/2002-January/001261.html> I'd be interested if this really is always possible, or whether someone has an ML structures/functors example that can't be straightforwardly converted into Haskell. -- Ashley Yakeley, Seattle WA

1 0

Instance contexts constraining only type variables?
by Wolfgang Jeltsch 23 Jan '02

23 Jan '02

Hello, say I have a type T defined the follwing way: newtype T a b = T (a b) Now I want to make every T a b with a b beeing an instance of Eq also an instance of Eq where (==) just test for equality of the encapsulated values. I try this instance Eq (a b) => Eq (T a b) where (T x) == (T x') = x == x' but it seems that this is not Haskell 98 conformant. How do I implement this in Haskell 98? Wolfgang

1 0

Translation of SML into Haskell
by Till Mossakowski 23 Jan '02

23 Jan '02

Is there any tool for translating SML into Haskell? (say, a suitable subset, i.e. just pure features, and no functors) -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

1 0

ITRS'02 call for papers
by Steffen van Bakel 23 Jan '02

23 Jan '02

(Apologies for multiple copies) Call for Papers Workshop on Intersection Types and Related Systems (ITRS '02) Copenhagen, Denmark Friday, July 26 2002 http://www.doc.ic.ac.uk/~itrs02/ Co-located with FLoC '02, the third Federated Logic Conference to be held in Copenhagen, Denmark (July 22 to August 1 2002) http://floc02.diku.dk/ IMPORTANT DATES/DEADLINES: Submission of papers: Sunday, April 7 2002 Notification of acceptance: Thursday, April 25 2002 Workshop: Friday, July 26 2002 OVERALL TOPIC AND FORMAT OF WORKSHOP: Intersection type disciplines originated in 1980 to overcome the limitations of Curry's type assignment system and to provide a characterisation of the strongly normalising terms of the Lambda Calculus. Since then, intersection types disciplines were used in a series of papers for characterising evaluation properties and semantics. Types also support reliable reasoning in many areas such as logic, programming languages, linguistics, etc. A _polymorphic_ type stands for some number of instance types, and the use of type systems for non-trivial purposes generally requires polymorphic types. In this context, roughly speaking, intersection types could be seen as to provide type polymorphism by listing type instances. This differs from the more widely used ("forall") quantified types, which provide type polymorphism by giving a type scheme that can be instantiated into various type instances. (A similar relationship holds between union types and existential types, the duals of intersection types and universal types.) Although intersection types were initially intended for use in analyzing and/or synthesizing lambda models as well as in analyzing normalization properties, over the last twenty years the scope of theoretical research on intersection types has broadened. Recently, there have been a number of breakthroughs in the use of intersection types (and similar technology) for practical purposes such as program analysis. The ITRS '02 workshop will be held to bring together researchers working on both the theory and practice of systems with intersection types and related systems (e.g., union types, refinement types, etc.). The workshop will last one full day and will contain a long talk by each invited speaker, a panel discussion, and a short (approx. 25 minutes) talk for each accepted paper. POSSIBLE TOPICS FOR SUBMITTED PAPERS: Researchers are invited to submit original papers on topics in the spirit of the workshop. Possible topics for submitted papers include, but are not limited to: * Formal properties of systems with intersection types: principal typings, normalization properties (for normal forms, head-normal forms, weak head-normal forms, etc.), type inference algorithms. * Results for clearly related systems, e.g., systems with union types, refinement types, or singleton types. * Connections with not-so-clearly related approaches such as abstract interpretation and constraints. * Applications to lambda calculus and similar systems, e.g., denotational semantics, analysis/synthesis of lambda models (domains), characterization of operational properties, etc. * Applications for programming languages, e.g., program analysis (flow, strictness, totality, etc.), accurate type error messages, increased flexibility with static typing, separate compilation and modularity, optimizing transformations, types for objects, etc. * Applications for other areas, e.g., database query languages, program extraction from proofs, type systems for natural languages. PROGRAM COMMITTEE: Steffen van Bakel (Chair) (Imperial College, London, UK) Franco Barbanera (Universita` di Catania, Italia) Mario Coppo (Universita` di Torino, Italia) Luca Roversi (Universita` di Torino, Italia) Lyn Turbak (Wellesley College (MA) USA) Pawel Urzyczyn (Uniwersytet Warszawski, Polska) Joe Wells (Heriot-Watt University, Edinburgh, Scotland) SUBMISSION INSTRUCTIONS: TOPIC: A submitted paper must describe work that does not substantially overlap with work that has been previously published or is currently being considered elsewhere (e.g., another workshop, conference, or journal). Feel free to consult the program chair on the appropriateness of a topic or the possibility of conflict with another publication. PRINTED APPEARANCE: The paper must be written in English. The paper (including bibliography) should not exceed 15 pages. The paper should a font size no smaller than 11pt and standard TeX spacing. It is recommended to include full proofs of any theorems in appendices if they will not fit in 15 pages. However, any appendices beyond the 15-page limit should not be needed for judging the paper and will not be included in the proceedings. PAPER ELECTRONIC FORMAT: The paper should be in PostScript or PDF. Every effort should be made to ensure that only portable PostScript features are used (e.g., avoid using non-standard built-in fonts). For other formats, ask the program chair well in advance of the deadline. For TeX, the class file itrspaper.cls is recommended for use (available at http://www.doc.ic.ac.uk/~itrs02/itrspaper.cls) ADMINISTRATIVE INFORMATION: The first page of the paper should include (1) the title, (2) the list of authors, (3) a brief abstract (fewer than 200 words), (4) a short list of key words/topics, and (5) the name, e-mail address, and postal address of the corresponding author. This information should be repeated at the Paper Submission Page available at the workshop's website (http://www.doc.ic.ac.uk/~itrs02/) SUBMISSION: Papers can be submitted electronically via the Paper Submission Page available at the workshop's website (http://www.doc.ic.ac.uk/~itrs02/) VENUE: The workshop is colocated with the FLoC '02 conference, which will be held in Copenhagen, Denmark. CONTACT INFORMATION: Web: http://www.doc.ic.ac.uk/~itrs02/ Program chair: Steffen van Bakel e-mail: itrs02@doc.ic.ac..uk telephone: +44 20 7495 8263 fax: +44 20 7581 8024 postal: Department of Computing Imperial College 180 Queens's Gate London SW7 2BZ, UK

1 0