Re: Proposal: Deprecate ExistentialQuantification

2009-07-23 Thread Niklas Broberg
 Discussion period: 2 weeks

Returning to this discussion, I'm surprised that so few people have
actually commented yea or nay. Seems to me though that...
* Some people are clearly in favor of a move in this direction, as
seen both by their replies here and discussion over other channels.
* Others are wary of deprecating anything of this magnitude for
practical reasons.
* No one has commented in true support of the classic existential
syntax, only wanting to keep it for legacy reasons.

I'm in no particular hurry to see this deprecation implemented, and I
certainly understand the practical concerns, but I would still very
much like us to make a statement that this is the direction we intend
to go in the longer run. I'm not sure what the best procedure for
doing so would be, but some sort of soft deprecation seems reasonable
to me.

Further thoughts?

Cheers,

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


Re: Proposal: Deprecate ExistentialQuantification

2009-07-23 Thread Iavor Diatchki
Hello,

Sorry for responding so late---I just saw the thread.  I don't think
that we should deprecate the usual way to define existentials.  While
the GADT syntax is nice in some cases, there are also examples when it
is quite verbose. For example, there is a lot of repetition in
datatypes that have many constructors, especially if the datatype has
parameters and a slightly longer name.  Furthermore, I find the type
variables in the declaration of the type quite confusing because they
have no relation to the type variables in the constructors.  Finally,
there is quite a lot of literature about the semantics of existential
types, while the semantics of GADTs seems quite complex, so it seems a
bit risky to mix up the two.

-Iavor





On Thu, Jul 23, 2009 at 2:47 PM, Niklas Brobergniklas.brob...@gmail.com wrote:
 Discussion period: 2 weeks

 Returning to this discussion, I'm surprised that so few people have
 actually commented yea or nay. Seems to me though that...
 * Some people are clearly in favor of a move in this direction, as
 seen both by their replies here and discussion over other channels.
 * Others are wary of deprecating anything of this magnitude for
 practical reasons.
 * No one has commented in true support of the classic existential
 syntax, only wanting to keep it for legacy reasons.

 I'm in no particular hurry to see this deprecation implemented, and I
 certainly understand the practical concerns, but I would still very
 much like us to make a statement that this is the direction we intend
 to go in the longer run. I'm not sure what the best procedure for
 doing so would be, but some sort of soft deprecation seems reasonable
 to me.

 Further thoughts?

 Cheers,

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

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


RE: Proposal: Deprecate ExistentialQuantification

2009-07-23 Thread Sittampalam, Ganesh
One can use the following style of GADT definition, which avoids the
type variables in the declaration:

{-# LANGUAGE GADTs, KindSignatures #-}
module GADT where

data Foo :: * - * where
  Foo :: Int - Foo Int

Iavor Diatchki wrote:
 Hello,
 
 Sorry for responding so late---I just saw the thread.  I don't think
 that we should deprecate the usual way to define existentials.  While
 the GADT syntax is nice in some cases, there are also examples when
 it is quite verbose. For example, there is a lot of repetition in
 datatypes that have many constructors, especially if the datatype has
 parameters and a slightly longer name.  Furthermore, I find the type
 variables in the declaration of the type quite confusing because they
 have no relation to the type variables in the constructors.  Finally,
 there is quite a lot of literature about the semantics of existential
 types, while the semantics of GADTs seems quite complex, so it seems
 a bit risky to mix up the two.  
 
 -Iavor
 
 
 
 
 
 On Thu, Jul 23, 2009 at 2:47 PM, Niklas
 Brobergniklas.brob...@gmail.com wrote: 
 Discussion period: 2 weeks
 
 Returning to this discussion, I'm surprised that so few people have
 actually commented yea or nay. Seems to me though that...
 * Some people are clearly in favor of a move in this direction, as
 seen both by their replies here and discussion over other channels.
 * Others are wary of deprecating anything of this magnitude for
 practical reasons. 
 * No one has commented in true support of the classic existential
 syntax, only wanting to keep it for legacy reasons.
 
 I'm in no particular hurry to see this deprecation implemented, and I
 certainly understand the practical concerns, but I would still very
 much like us to make a statement that this is the direction we intend
 to go in the longer run. I'm not sure what the best procedure for
 doing so would be, but some sort of soft deprecation seems
 reasonable to me. 
 
 Further thoughts?
 
 Cheers,
 
 /Niklas
 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime
 
 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Proposal: Deprecate ExistentialQuantification

2009-07-23 Thread Iavor Diatchki
Hi,
True, but then you have to declare the kind manually.
-Iavor

On Thu, Jul 23, 2009 at 7:36 PM, Sittampalam,
Ganeshganesh.sittampa...@credit-suisse.com wrote:
 One can use the following style of GADT definition, which avoids the
 type variables in the declaration:

 {-# LANGUAGE GADTs, KindSignatures #-}
 module GADT where

 data Foo :: * - * where
  Foo :: Int - Foo Int

 Iavor Diatchki wrote:
 Hello,

 Sorry for responding so late---I just saw the thread.  I don't think
 that we should deprecate the usual way to define existentials.  While
 the GADT syntax is nice in some cases, there are also examples when
 it is quite verbose. For example, there is a lot of repetition in
 datatypes that have many constructors, especially if the datatype has
 parameters and a slightly longer name.  Furthermore, I find the type
 variables in the declaration of the type quite confusing because they
 have no relation to the type variables in the constructors.  Finally,
 there is quite a lot of literature about the semantics of existential
 types, while the semantics of GADTs seems quite complex, so it seems
 a bit risky to mix up the two.

 -Iavor





 On Thu, Jul 23, 2009 at 2:47 PM, Niklas
 Brobergniklas.brob...@gmail.com wrote:
 Discussion period: 2 weeks

 Returning to this discussion, I'm surprised that so few people have
 actually commented yea or nay. Seems to me though that...
 * Some people are clearly in favor of a move in this direction, as
 seen both by their replies here and discussion over other channels.
 * Others are wary of deprecating anything of this magnitude for
 practical reasons.
 * No one has commented in true support of the classic existential
 syntax, only wanting to keep it for legacy reasons.

 I'm in no particular hurry to see this deprecation implemented, and I
 certainly understand the practical concerns, but I would still very
 much like us to make a statement that this is the direction we intend
 to go in the longer run. I'm not sure what the best procedure for
 doing so would be, but some sort of soft deprecation seems
 reasonable to me.

 Further thoughts?

 Cheers,

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

 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


 ===
  Please access the attached hyperlink for an important electronic 
 communications disclaimer:
  http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
  ===


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


RE: Proposal: Deprecate ExistentialQuantification

2009-06-29 Thread Simon Peyton-Jones
| That's why one should really be allowed to group constructor's in a
| type's definition:
| 
|data Colour :: * where
|  Red, Green, Blue :: Colour

Indeed.  GHC allows this now.  (HEAD only; will be in 6.12.)

Simon

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


Re: Proposal: Deprecate ExistentialQuantification

2009-06-28 Thread Stefan Holdermans

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Proposal: Deprecate ExistentialQuantification

2009-06-28 Thread Niklas Broberg
 In other words, in your 2x3 grid of syntactic x expressiveness, I want
 the two points corresponding to classic syntax x {existential
 quantification, GADTs} to be removed from the language. My second
 semi-proposal also makes each of the three points corresponding to the
 new cool syntax a separate extension.

 I see, but why are you opposed to have the classic syntax still support
 existentials (though foralls) and GADTs (through equality constraints). I
 would make sense to me to keep this support around.

I am opposed since
a) it requires the addition of extra syntax to the language, and
b) we have another, better, way to do it.

Somewhat pointed, I don't think the C++ way of putting all imaginable
ways to do the same thing into the language is a sound design
principle. If we have two ways to do the same thing, and one of them
is considered prefered, then I see no reason at all to keep the other
around. What I'm arguing here is that the GADT style syntax is truly
preferable, and thus the other should be removed.

Cheers,

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


Re: Proposal: Deprecate ExistentialQuantification

2009-06-28 Thread Stefan Holdermans

Niklas,


I am opposed since
a) it requires the addition of extra syntax to the language, and
b) we have another, better, way to do it.

Somewhat pointed, I don't think the C++ way of putting all imaginable
ways to do the same thing into the language is a sound design
principle. If we have two ways to do the same thing, and one of them
is considered prefered, then I see no reason at all to keep the other
around. What I'm arguing here is that the GADT style syntax is truly
preferable, and thus the other should be removed.


I agree. But ;-) since it's obvious not possible to get rid of the  
classic syntax completely, I see no harm in having it support  
existentials and GADTs as well. In an ideal word, in which there  
wasn't a single Haskell program written yet, I'd indeed like to throw  
the classic syntax out altogether.


Cheers,

  Stefan

On Jun 28, 2009, at 12:32 PM, Niklas Broberg wrote:

In other words, in your 2x3 grid of syntactic x expressiveness, I  
want

the two points corresponding to classic syntax x {existential
quantification, GADTs} to be removed from the language. My second
semi-proposal also makes each of the three points corresponding to  
the

new cool syntax a separate extension.


I see, but why are you opposed to have the classic syntax still  
support
existentials (though foralls) and GADTs (through equality  
constraints). I

would make sense to me to keep this support around.


I am opposed since
a) it requires the addition of extra syntax to the language, and
b) we have another, better, way to do it.

Somewhat pointed, I don't think the C++ way of putting all imaginable
ways to do the same thing into the language is a sound design
principle. If we have two ways to do the same thing, and one of them
is considered prefered, then I see no reason at all to keep the other
around. What I'm arguing here is that the GADT style syntax is truly
preferable, and thus the other should be removed.

Cheers,

/Niklas


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


Re: Proposal: Deprecate ExistentialQuantification

2009-06-28 Thread Svein Ove Aas
While I agree in principle that GADTs are the way forward, I have to
vote against deprecating anything using the existing syntax in any
kind of a hurry.

There are syntactic extensions which don't (yet?) work with GADTs that
I am loathe to lose, even if they do leave a lot to be desired. Not
that I have any real suggestions on what to replace them with, but I
think it'd be a good idea to settle that now, before implementing the
code that would anyhow need to handle it in half a dozen Haskell
implementations.

Well, I suppose that's my cue to start noting down ideas. Such a
fascinating topic, theorizing about language extensions...

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


Re: Proposal: Deprecate ExistentialQuantification

2009-06-27 Thread Malcolm Wallace

I would hereby like to propose that the
ExistentialQuantification extension is deprecated.


It is worth pointing out that all current Haskell implementations (to  
my knowledge) have ExistentialQuantification, whilst there is only one  
Haskell implementation that has the proposed replacement feature, GADTs.


Of course, that in itself is not an argument to avoid desirable change  
to the language, but it is one factor to consider.


Regards,
Malcolm

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