January 2002 - Haskell

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

input of type String -> String
by S.D.Mechveliani 23 Jan '02

23 Jan '02

I asked recently whether reading from file can be made of type String -> String. I thought "If Haskell is non-functional, probably, this would be possible, and I would try this in certain small example. Otherwise, this is impossible, and I would be satisfied with readFile name >>= putStr " Thanks to people who explained me that the former case is impossible. So, Haskell is more functional than I thought. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: newtype pattern matching
by D. Tweed 23 Jan '02

23 Jan '02

(extra > because I initially sent this just Martin by mistake... oops) > On 22 Jan 2002, Martin [ISO-8859-1] Norb�ck wrote: > > > tis 2002-01-22 klockan 15.52 skrev Feuer: > > > Why is pattern matching on newtypes lazy? Does this add to efficiency > > > somehow? If not, it seems to be just another rule to keep straight. > > > > That's the difference between newtype and data. Newtypes are unboxed, so > > there is no constructor to match on. Pattern matching on newtypes is > > only a type-checker thing, the constructor doesn't exist. > > I don't know if this helps or confuses, but I think of it as newtype using > a `constructor' purely as a particular choice of syntax so that it looks > similar to the more general constructor syntax. But you could imagine a > different language design decision where instead of being written to look > like a constructor, for the declaration > > newtype M a = M [a] > > a new syntax ::: was introduced where e:::M means `expression e can only > be matched with the approriate type M a' (so for a concrete example, if > e :: [Int], then e ::: M means e can only be matched with newtype > M Int). Because of the similarity to the :: notation, which we're used to > seeing as `typechecker glue' that is only there to inform compilation, it > would be more intuitive that all the newtype stuff vanishes during > compilation. However, I think this syntax falls down in actually > constructing the raw values in the first place, e.g., > > f x = M (x++x) > > is easier to understand than > > f x = (x++x):::M > > so I can see why the constructor syntax was chosen.

1 0

String vs IO ()
by S.D.Mechveliani 23 Jan '02

23 Jan '02

I am sorry for, maybe, a silly question. f name = readFile name >>= putStr has the type String -> IO () And I need String -> String, so that (f name) is a string contained in the given file. I never learned such things in Haskell because they are rather non-functional. Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

thanks for readFile
by S.D.Mechveliani 23 Jan '02

23 Jan '02

Thanks to people, who answered my question on readFile. It helped. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ideas for compiler project
by Hal Daume III 23 Jan '02

23 Jan '02

Hi All, I'm currently taking a class in compiler optimization for high performance computing (i.e., parallel architectures, including VLIW, FPGA, multimedia extension architectures, systems-on-a-chip, etc). It's the second of two graduate level compiler courses, and it purely project based. And the project is of our choosing. The professor has made some suggested projects, which I could do, but none of them are really FP specific. I'm curious if anyone has any ideas of a project I could do. I'm looking for something that's open, yet constrained, etc (standard semester-long-project-course stuff), hopefully having to do with optimizations specifically for FPLs, or at least ones that would benefit them. I'm open to all ideas... - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

3 2

reading from file
by S.D.Mechveliani 22 Jan '02

22 Jan '02

Who would tell me, please, what is the simplest way to read a string from a file? Namely, what has one to set in place of `...' in the program main = putStr (...) to obtain instead of `...' a string contained in the file "foo.txt" ? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1