Haskell implementation status summary
Here, for your interest, is a freshly-updated summary of the current state of Haskell implementations, at least those known to us. Simon Peyton Jones, Glasgow University. Haskell: Current status [Simon Peyton Jones wrote the original version of this document, and he still maintains it. Many others, including all the main implementors, have helped. Please send corrections/comments to [EMAIL PROTECTED] Original version: April 1991; last checked: February 1993] The Haskell language In the mid-1980s, there was no "standard" non-strict, purely-functional programming language. A language-design committee was set up in 1987, and the Haskell language is the result. The Haskell committee released its report on 1 April 1990. A revised "Version 1.2" appeared in SIGPLAN Notices 27(5) (May 1992), along with a tutorial on Haskell by Hudak and Fasel. There is no further language development happening right now. You may learn more about the development of Haskell by consulting the "haskell" mailing-list archive, in pub/haskell/list-archive (at least at the Glasgow archive site). The Haskell mailing list There is an electronic mailing list to discuss technical issues related to Haskell. To join this list, send your request to "[EMAIL PROTECTED]" (Europe and Australasia) or "[EMAIL PROTECTED]" (rest of world) as appropriate. Standard archive sites for Haskell stuff You can use anonymous FTP (username: anonymous; password: your e-mail address) to the following hosts, where you will find things in "pub/haskell" and its subdirectories. Site Host name Raw IP#s (these can change) Chalmers ftp.cs.chalmers.se 129.16.225.66 Glasgow ftp.dcs.glasgow.ac.uk 130.209.240.50 Yale nebula.cs.yale.edu 128.36.13.1 UKUUGsrc.doc.ic.ac.uk 146.169.2.1 (languages/haskell mirrors Glasgow) Note: Specialised material related to a specific implementation (e.g., HBC binaries for the Obscuro 1000) may only be at the implementation's "home site". Freely-available implementations of Haskell ~~~ This information was mostly supplied by the implementors. All of the systems are provided with sources, and often with pre-built binaries for popular machines. It will be obvious if you peer into one of the FTP sites... The Glasgow Haskell compiler The Glasgow compiler has the following attributes: * A batch compiler that runs under Unix. The current version is 0.10, released in December, 1992 (the first usable public release). * Known to work on Sun3s and Sun4s. * Almost all of Haskell is implemented. In particular, the full range of data types is supported: arbitrary precision integers, rationals, double-precision floats, and "real" arrays with O(1) access time. (The release notes list all unimplemented language features.) * Written in Haskell, generates C as its target code -- hence some chance of wide portability. * Specifically designed to act as a "motherboard" into which others can "plug in" their own strictness analyser, profiler, front end, back end, or other special pass. * An extensible I/O system is provided, based on a "monad". (The standard Haskell I/O system is built on this foundation.) * A number of significant language extensions are implemented: - Fully fledged unboxed data types. - Ability to write arbitrary in-line C-language code, using the I/O monad to retain referential transparency. - Incrementally-updatable arrays, also embedded in a monad. - Mutable reference types. * By default, the system uses a generational garbage collector which lets you run programs whose live data is significantly larger than the physical memory size before thrashing occurs. (Conventional 2-space GC starts thrashing when the live data gets to about half the physical memory size.) * A new profiling system is supplied, which enables you to find out which bits of your program are eating both *time* and *space*. * Good error messages. Well, fairly good error messages. Line numbers are pretty accurate, and during type checking you get several (accurate) error reports rather than just one. * Execution performance: similar to Chalmers hbc. * We have a pretty good test suite, and the current version (0.10) passes practically all of it. (Yes, it can compile itself, too.) We hope you will find the system to be robust. * Highly configurable runtime system. Heavy use of C macros means that you can modify much of the storage representation without telling the compiler. For example, the system comes with 4 different garbage collectors! (all working) * Internals: extensive use of the second-order lambda calculus as an intermediate code; the
Re: Stupid Haskell question
Guy S., Phil W.,... I ran into exactly this problem in two different applications. The first was the same that Guy S. points out, namely adding arbtrirary but well-typed annotations to a parse-tree. The solution I eventually ended up using (after discussing it with John Hughes) was the following: data FooTree a b = Leaf b | Node (AnnotFooTree a b) (AnnotFooTree a b) type AnnotFooTree a b = (a, FooTree a b) originally I'd tried: data FooTree a b = Leaf a | Node (a (FooTree b)) (a (FooTree b)) which was of course rejected by the Hindley-Milner typechecker. I recall David Murphy saying that I could have done that in Isabelle but it involved a much more powerful type-checker. BTW, Simon PJ and David Lester hit on exactly the same solution in their paper on fully lazy lambda-lifting so presumably they'd given this problem some thought too. The other application was Tries. Imagine we have some type: data Assoc a b = ... which maps objects of type a to objects of type b. We don't care if it's implemented as a tree, list, array or whatever provided there's a standard interface. Now imagine that our applications involves keys which are variable length lists/strings of as. Using the above type instantiating a as [a] will cause increasingly costly comparisons as the search gets closer to its goal. Trie structures avoid this by matching one segment of the key at a time. For instance rather than storing the following "guy argo" | "guy steele" it's stored as: 'g' - 'u' - 'y' - ' ' - 'a' - 'r' - 'g' - 'o' | 's' - 't' - 'e' - 'e' - 'l' - 'e' (n.b. Compressed tries go one step further by collapsing the one-way branching to give: "guy " - "argo" | "steele") Anyway, given the above Assoc type a very natural encoding of tries is: type Trie a b = Assoc a (Trie a b) The operations on Tries can now be built out of the Assoc operations which allows the lookup structure used at each level to be altered without painful recoding merely by substituting a different Assoc ADT. I mention this to support Guy S.'s point that there might be gains from going to a more expressive type system than Hindley-Milner. I don't know what that might be - I just know that the things that I mentioned aren't handled as elegantly as I'd like. My $0.02 Guy Argo
Final CFP - SIGPLAN Workshop on State in Programming Languages
Final Call for Papers SIGPLAN Workshop on STATE in Programming Languages (SIPL) June 12, 1993 Copenhagen, Denmark Held in conjunction with FPCA and PEPM This workshop will address the fundamental issues of expressing, manipulating, and reasoning about state in high-level programming languages. The range of topics includes operational and denotational models of state, assignment and references, semantics of object- oriented programming, linear type systems, effect systems, monads, calculi of state and methods to reason about state. Formal presentations of results, research in progress, tutorials, and topical discussions are among the possible venues for interaction. Program Committee: Matthias Felleisen, Rice University Paul Hudak, Yale University (Chair) Ian Mason, Stanford University Torben Mogensen, University of Copenhagen Martin Odersky, Yale University Uday Reddy, University of Illinois Robert Tennent, University of Edinburgh Philip Wadler, University of Glasgow Authors should submit 8 copies of a detailed summary (10 pages maximum) to the program chair by March 15, 1993. Authors will be notified of acceptance of their paper by May 1st, 1993. Final versions of accepted papers are due on May 21, 1993. Accepted papers will appear in a technical report to be distributed at the workshop. Correspondence should be sent to: Prof. Paul Hudak State Workshop '93 Department of Computer Science Yale University 51 Prospect Street New Haven, CT 06520-2158, U.S.A. E-mail: [EMAIL PROTECTED]
Re: Stupid Haskell question
Given your correction, I think that the type declaration data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b) will handle things only a little less neatly than the use of wrappers, and will allow you to use type inference in much the way you wish. What do you think? Cheers, -- P
Stupid Haskell question
Date: Tue, 23 Feb 93 17:18:19 GMT From: wadler [EMAIL PROTECTED] ... I don't understand. Can't you handle this is as follows? data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b) data Annote a b c = MkAnnote Info (FooTree (Annote a b c) b) c and then infer that what you are acting on is a FooTree (Annote a b c) b. The c field can be omitted, or it can be instantiated to additional annotation information later on. I'm sure you can hack around the problem, but it's not yet clear to me that there isn't an elegant solution. Cheers, -- P This looks promising. I'll have to ponder it some. (Don't worry if you don't hear more from me for a while-- I'm out of town for a couple of weeks soon.) --Guy
Stupid Haskell question
Date: Tue, 23 Feb 93 10:16:58 GMT From: wadler [EMAIL PROTECTED] Given your correction, I think that the type declaration data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b) will handle things only a little less neatly than the use of wrappers, and will allow you to use type inference in much the way you wish. What do you think? Cheers, -- P You're right! That does solve the problem as I have stated it. But now suppose that some of the annotations refer to FooTree items (another thing I forgot to say). I suppose I could do data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b) [FooTree a b] including a list of goodies that the annotations could then refer to, but I'm quickly losing my abstractions--the annotations are spread out rather than being single items. Well, I'll manage to hack around it somehow. Thanks for helping! --Guy
Re: Stupid Haskell question
Guy, You write, But now suppose that some of the annotations refer to FooTree items (another thing I forgot to say). I suppose I could do data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b) [FooTree a b] including a list of goodies that the annotations could then refer to, but I'm quickly losing my abstractions--the annotations are spread out rather than being single items. I don't understand. Can't you handle this is as follows? data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b) data Annote a b c = MkAnnote Info (FooTree (Annote a b c) b) c and then infer that what you are acting on is a FooTree (Annote a b c) b. The c field can be omitted, or it can be instantiated to additional annotation information later on. I'm sure you can hack around the problem, but it's not yet clear to me that there isn't an elegant solution. Cheers, -- P
