atom feed20 messages in org.haskell.haskell-primeRe: Proposal: Deprecate ExistentialQu...
FromSent OnAttachments
Niklas BrobergJun 27, 2009 3:44 am 
Isaac DupreeJun 27, 2009 7:51 am 
Malcolm WallaceJun 27, 2009 11:55 am 
Niklas BrobergJun 27, 2009 12:37 pm 
Stefan HoldermansJun 28, 2009 12:43 am 
John MeachamJun 28, 2009 1:35 am 
Niklas BrobergJun 28, 2009 3:17 am 
Stefan HoldermansJun 28, 2009 3:23 am 
Niklas BrobergJun 28, 2009 3:32 am 
Stefan HoldermansJun 28, 2009 3:47 am 
Niklas BrobergJun 28, 2009 4:17 am 
Niklas BrobergJun 28, 2009 4:19 am 
Stefan HoldermansJun 28, 2009 4:24 am 
Niklas BrobergJun 28, 2009 4:31 am 
Svein Ove AasJun 28, 2009 2:21 pm 
Simon Peyton-JonesJun 29, 2009 12:42 am 
Niklas BrobergJul 23, 2009 4:47 am 
Iavor DiatchkiJul 23, 2009 9:25 am 
Sittampalam, GaneshJul 23, 2009 9:36 am 
Iavor DiatchkiJul 23, 2009 3:27 pm 
Subject:Re: Proposal: Deprecate ExistentialQuantification
From:Stefan Holdermans (ste@cs.uu.nl)
Date:Jun 28, 2009 12:43:16 am
List:org.haskell.haskell-prime

Niklas,

My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. The GADTs way fits better syntactically with Haskell's other syntactic constructs, in all ways. The general style is (somewhat simplified) "keyword type 'where' decls", where keyword can in Haskell 98 be class or instance, but with GADTs also data. The old simple way of defining data types is the odd one out. It certainly has its uses though, in particular when defining some simple (but possibly large) enum-like datatype (like cabal's Extension type incidentally), then it obviously becomes tedious to have to restate the trivial type signature for each constructor.

That's why one should really be allowed to group constructor's in a type's definition:

data Colour :: * where Red, Green, Blue :: Colour

This is consistent with what is allowed for type signatures for functions.

More general, whatever way your proposal is going, I think you should have it reflect that there are two, more or less unrelated, issues here:

1. The expressiveness of data types: algebraic data types < existential data types < GADTs. 2. The syntax of type definitions: the classic, Haskell 98 syntax and the new, cool listings-of-constructor-signature syntax. (Don't call the latter NewTypeSyntax or anything similar in a LANGUAGE pragma; choose something descriptive.)

These are really orthogonal issues: all three levels of expressiveness of types can be expressed in either syntax. Therefore: keep these issues separated in your proposal.

Just my two cents,

Stefan