Haskell' Status Report

2006-09-27 Thread Isaac Jones
Ravi Nanavati has very helpfully put together a status report for the
Haskell Prime process.  Please see this link, or read the pasted text
below:

http://hackage.haskell.org/trac/haskell-prime/wiki/Status'

peace,

  isaac


Summary:

Since the Haskell Workshop last year, the Haskell community has
documented (on this wiki) over 70 proposals for changes to Haskell
98. In March of this year, two subcommittees were established to focus
on concurrency and the class system - two difficult areas that are
important to the success of Haskell'. The committee has also used
StrawPolls to filter and discuss the universe of proposals that has
been gathered. Based on the most recent straw poll, 12 proposals
(listed in the table at the bottom of the page) have been identified
that are expected to get into Haskell' (over 2/3 of the committee in
favor). An additional 19 proposals seem likely to get into Haskell'
(based on slightly weaker criteria). Members of the committee conflict
on 9 of the remaining proposals, and their status will be determined
during the writing process. The remaining proposals are not expected
to be part of Haskell'.

Concurrency:

The concurrency support in Haskell' will be based on the
Control.Concurrent library, with minor modifications. There will be a
thread-safe interface for mutable state, suitable for use in library
code that does not otherwise use concurrency (though what it will be
based on is an open issue). There will also be independent FFI
annotations for specifying whether foreign calls are concurrent (with
other Haskell threads) and reentrant. Bound threads will not be
required by the concurrency standard, but they will be an allowed
extension with a specified meaning. Open issues include whether
standard will require preemptive concurrency, the syntax of the new
FFI annotations and the memory-model semantics of IORefs.

Class system:

The work on the class system has focused on resolving the
MultiParamTypeClassesDilemma. The core of the dilemma is that
multi-parameter typeclasses are a popular extension that is strongly
desired for Haskell'. However, many important uses of MPTCs (like the
monad transformer library) require additional extensions to resolve
ambiguities in their typechecking. Historically,
FunctionalDependencies have been used for this purpose, but they are
very tricky to implement and are also difficult to specify in a way
that guarantees the termination of typechecking. AssociatedTypes are a
possible replacement, but our current implementation experience with
them is very limited. The subcommittee has explored several ways to
resolve this dilemma (including restricted FDs, fast-tracked ATs and
FDs as a blessed extension), but, so far, no consensus has
emerged. Our current plan is to focus on writing other parts of the
Haskell' standard, in the hopes that additional implementation
experience with ATs will clarify the situation.

Libraries:

Thus far, libraries have been an underemphasized portion of the
Haskell' effort (only 7 of the 70+ proposals have significant library
content). However, there is a consensus that a revised standard
library is an important part of the Haskell' effort. The current plan
is to focus on starting to write the language portions of the standard
first, since we have a substantial amount of work to do there which
requires focused attention. After that effort is well underway, a
companion library effort will begin. Several members of the committee
have volunteered for this effort and additional volunteers will be
needed.


definitely-in Proposal Status:
Description (Those volunteering to write this section):
add some kind of Concurrency (IJ, SM)   
add ForeignFunctionInterface (MC, SM)   
add multi-parameter type classes (MS)   
add RankNTypes or Rank2Types (AL)
add PolymorphicComponents (AL)  
add ExistentialQuantification (existential components) (AL, MS, SJT)
add HierarchicalModules (IJ, BH, MW)
add EmptyDataDeclarations (BH, HN)  
DoAndIfThenElse (SM, HN)
fix comment syntax grammar (SM) 
add PatternGuards (RN, DS)  
add InfixTypeConstructors (BH, AL)
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Trac Ticket Component Field?

2006-09-27 Thread Ashley Yakeley
What do the various values of the Component field mean? Most issues 
have Proposal, but some have HaskellPrime.


--
Ashley Yakeley
Seattle WA

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Trac Ticket Component Field?

2006-09-27 Thread isaac jones
On Wed, 2006-09-27 at 16:27 -0700, Ashley Yakeley wrote:
 What do the various values of the Component field mean? Most issues 
 have Proposal, but some have HaskellPrime.

If it is a proposal for something to go into/be removed from the
language, then it should be listed as proposal.  If it's some task
that we have to perform (write a library API or something), then the
component might be something else.  Proposal is the main one, though.

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Trac Ticket Component Field?

2006-09-27 Thread Ashley Yakeley

isaac jones wrote:

On Wed, 2006-09-27 at 16:27 -0700, Ashley Yakeley wrote:
What do the various values of the Component field mean? Most issues 
have Proposal, but some have HaskellPrime.


If it is a proposal for something to go into/be removed from the
language, then it should be listed as proposal.  If it's some task
that we have to perform (write a library API or something), then the
component might be something else.  Proposal is the main one, though.


What does HaskellPrime mean? There are a some library proposals listed 
under Proposal, and others listed under HaskellPrime. I fear the 
latter may be falling through the cracks.


--
Ashley Yakeley
Seattle WA

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime