[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell
Subject:    The Revised Report
From:       Simon L Peyton Jones <simonpj () cs ! glasgow ! ac ! uk>
Date:       1991-03-29 13:10:51
Message-ID: 26091.9103291253 () tutuila ! dcs ! glasgow ! ac ! uk
[Download RAW message or body]

X-Comment1: #############################################################
X-Comment2: #     uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs     #
X-Comment3: #     If this address does not work please ask your mail    #
X-Comment4: #     administrator to update your NRS & mailer tables.     #
X-Comment5: #############################################################
To: haskell@cs.glasgow.ac.uk
Subject: The Revised Report
Date: Fri, 29 Mar 91 12:53:13 +0000
From: Simon L Peyton Jones <simonpj@cs.glasgow.ac.uk>
Sender: haskell-request@cs.glasgow.ac.uk


As you know, we are working towards a revised Haskell report.  This
message is to summarise the present position and try to get towards
closure.

I enclose a summary of (my understanding of) the current position.  
If you think there are any unresolved issues which I have not
mentioned, yell.

Joe Fasel has kindly promised the revised standard prelude by Monday April 8.
There is a meeting of IFIP WG2.8 in the week of April 15.

I PROPOSE that we try to resolve everything before April 15, and that
anything left unresolved by then will be decided by a fiat at the WG2.8 
meeting.

Thanks to all who have contributed!

Simon

	Unresolved issues for the revised Haskell Report
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(By "unresolved" I mean that I don't have CONCRETE TEXT to 
modify the Report with.)

Non-syntax issues
~~~~~~~~~~~~~~~~~
1. Simon and Phil's proposed change to the syntax of interfaces.
2. Scope of type variables.
3. Polymorphism in class declarations.


Syntax issues
~~~~~~~~~~~~~
(Perhaps some of these are resolved, but I don't have the formal text.  Or
maybe I do, but I don't know which of the 100 versions is the final answer!)

1. Precedence of lambda and other non-operators
2. Precedence on left-hand side of definitions
3. Pattern syntax

4. Yale have kindly volunteered to produce a concrete syntax so that
	various precedence decisions can be made explicit.


	Resolved issues (+summary of resolution)
	~~~~~~~~~~~~~~~
1. Unary minus.  
	NO CHANGE.

2. Contexts in @data@ and @type@.  
	No contexts allowed in @type@ decls.  
	Contexts in @data@ mean that the constructors get overloaded, and
		that is all.








[prev in list] [next in list] [prev in thread] [next in thread]