[no subject]

[haskell-request@cs.glasgow.ac.uk]

Date: 30 May 91 16:44
From: haskell-request@cs.glasgow.ac.uk
Sender: colin@minster.york.ac.uk
To: haskell@cs.glasgow.ac.uk

Original-Via: uk.ac.york.minster; Thu, 30 May 91 15:36:22 BST

On some recent proposals:

pat = exp in comprehensions
---------------------------

Backus pointed out the detrimental division in conventional programming
systems between the world of statements and the world of expressions.
Each world has different mechanisms - but often for the same things.
In Haskell, we have at least THREE worlds: applicative expressions,
comprehensions and definitions.  Comprehensions started out modestly,
as attractive notations to ease the expression of certain kinds of
binding in the construction of lists.  But now there are grander
schemes: little by little, they are gaining the power to express
whatever can be expressed in either of the other worlds - formulated a
little differently, of course!

I OPPOSE the proposal to allow pat = exp among the qualifiers
in a comprehension.  All the more so in view of the "= or ==" pitfall. 

let besides where
-----------------

Viewed positively, as has been pointed out, this proposal trims
the balance between expressions and definitions.  Parity at last.
But, as has also been pointed out, it means we have two languages
for the two worlds.

Only English reserve restrains me from "yells of dismay".

However, even King Canute could not hold back the tide.  Maybe "let
besides where" is the best option in the circumstances.  At least we
can make a nice pattern with all the jetsam on the beach.

sections
--------

I still SUPPORT this idea.  Lambda belongs to definition world,
combinators to implementation world, and ((op) arg) requires mental
gymnastics for a non-commuting op.

full original names
-------------------

Of course, there are also the worlds of modules and types.
These are not really concerned with the programming of computations,
so greed for expressive power is not the same sort of problem here.
But power to mangle or complicate bindings is still dangerous.

Hence, I SUPPORT the proposal to do away with REnaming, and
the attendant special rules, in favour of FULL-naming.

abbreviations in export lists
-----------------------------

Avoiding long lists enumerating exports seems like a good idea.
But what if the "natural" division yields 90% exported definitions
and 10% for domestic consumption only?  The 100% abbreviation will
be very tempting.  How about a syntactic partition between
exported and domestic definitions, or per-definition annotations?

Colin R
30/5/91
----------------------------------------------------------------
Dr Colin Runciman		Telephone +44 904 432740
Department of Computer Science	
University of York		JANET:	colin@uk.ac.york.minster
YORK YO1 5DD
United Kingdom			UUNET:	uucp!ukc!minster!colin
----------------------------------------------------------------