Personal tools

Future of Haskell

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m (Updating a broken link to the Views Proposal, adding a new link on views and mentioning its relatedness to dependent types. Adding an IMHO-phrase to the section on dependent types and Illative CL)
(The concept of views provided by dependent types are not-forgetful: they ,,cannot lie'')
Line 46: Line 46:
 
<li>A [http://www.haskell.org/development/views.html views proposal] has been submitted for consideration in
 
<li>A [http://www.haskell.org/development/views.html views proposal] has been submitted for consideration in
 
future Haskell reports. Implemented in hbc (?)</li>
 
future Haskell reports. Implemented in hbc (?)</li>
<li>see also HaWiki's [http://haskell.org/hawiki/Views Views]</li>
+
<li>See also HaWiki's [http://haskell.org/hawiki/Views Views]</li>
<li>Another concept called dependent types generalizes the concept of views. See it more below here in the Haskell Future page.
+
<li>''Dependent types'' provide a way for not-forgetful views: views who cannot lie. There are materials on dependent types below here in the Haskell Future page.
 
</ul>
 
</ul>
 
<li><b>Pattern Guards</b> by Simon Peyton-Jones is a proposal
 
<li><b>Pattern Guards</b> by Simon Peyton-Jones is a proposal
Line 145: Line 145:
 
<dt>Dependent types</dt>
 
<dt>Dependent types</dt>
 
<dd>
 
<dd>
[http://www.e-pig.org/ Epigram] is a full dependently typed programming language (see [http://www.e-pig.org/downloads/epigram-notes.pdf Epigram Tutorial] by Conor McBride and [http://www.e-pig.org/downloads/ydtm.pdf Why dependent types matter] by Thorsten Altenkirch, Conor McBride and James McKinna). Dependent types (of this language) also provide a powerful generalization of '''views''' (already mentioned above here in the Haskell Future Page).
+
[http://www.e-pig.org/ Epigram] is a full dependently typed programming language (see [http://www.e-pig.org/downloads/epigram-notes.pdf Epigram Tutorial] by Conor McBride and [http://www.e-pig.org/downloads/ydtm.pdf Why dependent types matter] by Thorsten Altenkirch, Conor McBride and James McKinna). Dependent types (of this language) also provide a not-forgetful concept of '''views''' (already mentioned above here in the Haskell Future Page); the connection between these concept is described in p. 32 of Epigram Tutorial (section ''4.6 Patterns Forget; Matching Is Remembering'').
   
 
John Hughes: [http://www.coverproject.org/TalksUntilSpring2004/DependentTypesInHaskell.pdf Dependent Types in Haskell (some ideas)].
 
John Hughes: [http://www.coverproject.org/TalksUntilSpring2004/DependentTypesInHaskell.pdf Dependent Types in Haskell (some ideas)].

Revision as of 16:10, 28 February 2006

1 Future development of Haskell

Haskell 98 is complete. It is the current official definition of Haskell (modulo some minor fixes, as detailed on the Haskell 98 bug page). We expect that this language will be supported in the long term even as new extensions are added to Haskell; compilers will continue to support Haskell 98 (via a special flag).

The process of defining a successor to Haskell 98 has started. All information about this is on

The Haskell' Wiki

The language evolves and numerous extensions have been proposed and many of them have been implemented in some Haskell systems; for example pattern guards, scoped type variables, multi-parameter type classes, local universal and existential quantification. The Haskell mailing lists are a forum for discussing new language features. People proposing an additional language feature should implement the new feature or convince the developers of one of the Haskell systems to do so. Then many people can test the practical usefulness of the extension. Finally, the people seriously interested in the new feature should define the new feature with respect to Haskell 98 in a document (a new mailing list can be set up for this purpose). This kind of addendum to the Haskell 98 report clearifies the details and can be used for adding the feature to other Haskell systems. The definition of the foreign function interface (FFI) for Haskell is a good example for this process.

On a rather longer time schedule a committee lead by John Launchbury may develop Haskell II. Obviously well-tested and well-described extension proposals will have a higher chance of being adopted.


1.1 Extensions of Haskell

A Wiki page
collects all kinds of extensions proposed for the language, libraries and specific implementations.

Below we present some of the various extensions that have been implemented or proposed. See also the Haskell mailing lists.

  • Views allow multiple `logical' constructors to match against real constructors in patterns.
    • A views proposal has been submitted for consideration in future Haskell reports. Implemented in hbc (?)
    • See also HaWiki's Views
    • Dependent types provide a way for not-forgetful views: views who cannot lie. There are materials on dependent types below here in the Haskell Future page.
  • Pattern Guards by Simon Peyton-Jones is a proposal to generalize guards used in function definitions. See the proposal for further details. Implemented in GHC, proposed for Haskell 2.
  • Basic algebra proposal. In particular: Reformulating numeric classes, instance ruled type and domain conversion.
  • Haskell Proposal: Syntactic Sugar for Arrows

1.2 Variations of Haskell

Chameleon
Chameleon is a Haskell-style language which provides a flexible overloading mechanism based on Constraint Handling Rules (CHRs). The user can impose conditions on overloaded identifiers via CHRs.

Gofer
Gofer is a small interpreter by Mark Jones supporting a language based on the Haskell report version 1.2. Gofer is intended as an experimental language, particularly where type classes are involved. Although Haskell has adopted a number of ideas from Gofer, the Gofer type class system is still more flexible than the Haskell one. Available for all Unix platforms including Linux, DOS, and Macs. Hugs is the successor to Gofer and Gofer is no longer supported.
Html-version of the Gofer manual

GPH, Glasgow Parallel Haskell
is an extension of Haskell for parallel programming. It adds just two new primitives to the language, namely, a form of parallel composition par, and sequential composition seq. With judicious use of par and seq it is possible to express how a program should be evaluated in parallel.

pH - a parallel Haskell
The pH language is is a parallel, eagerly-evaluated variant of Haskell with syntactic provisions for loops, barriers, and I- and M- structure storage. The eager evaluation model of pH is similar to that of Id; the current version of the pH compiler shares a back end with the Id compiler, producing code for the Monsoon dataflow machine. The front end of the pH compiler is a modification of hbc.

Goffin
A Haskell extension for parallel and distributed programming.


Mondrian

Mondrian is evolving from "just" an internet scripting language to a "functional language for OO environments". Mondrian is a non-strict functional language with threads, exceptions and interlanguage working - a Haskell "light" with extras.


PolyP - a polytypic programming language
PolyP extends a functional language (a subset of Haskell) with a construct for writing polytypic functions. A polytypic function is a function that is defined by induction on the structure of user-defined datatypes.

O'Haskell
O'Haskell is an object-oriented extension to Haskell developed at Chalmers. O'Haskell conservatively adds two major features to the Haskell core: a monad of concurrent, state-encapsulating reactive objects, and a type system with subtyping between records as well as datatypes. An implementation is available, O'Hugs, which is a derivative of Hugs 1.3b.

Eden
Eden is a parallel functional language that provides a new perspective on parallel programming. It gives programmers enough control to implement their parallel algorithms efficiently (including granularity issues) and at the same time frees them from the low level details of process management. Eden is explicit about processes and their incoming and outgoing data, but abstracts from the transfer of these data between processes and the necessary synchronisation. Eden extends the Haskell but overrules lazy evaluation whenever it is necessary to support parallelism.

Curry
Curry combines in a seamless way features from functional programming (nested expressions, higher-order functions, lazy evaluation), logic programming (logical variables, partial data structures, built-in search), and concurrent programming (concurrent evaluation of expressions with synchronization on logical variables). Many Haskell programs are also valid Curry programs.

Data Field Haskell
Data Field Haskell implements an instance of Data Fields, a generalization of arrays. The purpose is to support generic array- and data parallel programming on a very high level, for rapid prototyping of parallel algorithms. The most important language extension to Haskell is the forall-construct, which allows convenient definitions of data fields.

Template Haskell
Template Haskell is an extension to Haskell 98 that allows you to do type-safe compile-time meta-programming, with Haskell both as the manipulating language and the language being manipulated.

Dependent types</dt>
Epigram is a full dependently typed programming language (see Epigram Tutorial by Conor McBride and Why dependent types matter by Thorsten Altenkirch, Conor McBride and James McKinna). Dependent types (of this language) also provide a not-forgetful concept of views (already mentioned above here in the Haskell Future Page); the connection between these concept is described in p. 32 of Epigram Tutorial (section 4.6 Patterns Forget; Matching Is Remembering).

John Hughes: Dependent Types in Haskell (some ideas).

To see how Illative Combinatory Logic deals with dependent types, see combinator G described in Systems of Illative Combinatory Logic complete for first-order propositional and predicate calculus by Henk Barendregt, Martin Bunder, Wil Dekkers. It seems to me that the dependent type construct \forall x : S \Rightarrow T of Epigram corresponds to \mathbf G\;S\;(\lambda x . T) in Illative Combinatory Logic. I think e.g. the followings should correspond to each other:

  • \mathrm{realNullvector} :\;\;\;\forall n: \mathrm{Nat} \Rightarrow \mathrm{RealVector}\;n
  • \mathbf G\;\,\mathrm{Nat}\;\,\mathrm{RealVector}\;\,\mathrm{realNullvector}

</dd>