| On Friday 10 July 2009 5:03:00 am Wolfgang Jeltsch wrote:
| Isn’t ExistentialQuantification more powerful than using GADTs for
| emulating existential quantification? To my knowledge, it is possible to
| use lazy patterns with existential types but not with GADTs.
|
| 6.10.4 doesn't allow
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
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,
On Friday 10 July 2009 5:03:00 am Wolfgang Jeltsch wrote:
Isn’t ExistentialQuantification more powerful than using GADTs for
emulating existential quantification? To my knowledge, it is possible to
use lazy patterns with existential types but not with GADTs.
6.10.4 doesn't allow you to use ~
Am Samstag, 27. Juni 2009 12:44 schrieb Niklas Broberg:
Hi all,
Following the discussion on the use of 'forall' and extensions that
use it [1], I would hereby like to propose that the
ExistentialQuantification extension is deprecated.
My rationale is as follows. With the introduction of
| 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
___
Glasgow-haskell-users
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
On Sat, Jun 27, 2009 at 10:51:12AM -0400, Isaac Dupree wrote:
Niklas Broberg wrote:
data Foo =
forall a . Show a = Foo a
which uses ExistentialQuantification syntax, could be written as
data Foo where
Foo :: forall a . Show a = a - Foo
The downside is that we lose one level
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.
Totally agreed, and that should be rather trivial to implement too.
More
Niklas,
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
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
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
Niklas,
What you really want or mean when you use
the classic syntax with existential quantification is
data Foo = Foo (exists a . (Show a) = a)
Having that would make a lot more sense, and would fit well together
with the intuition of the classic syntax.
How would you then define
data
What you really want or mean when you use
the classic syntax with existential quantification is
data Foo = Foo (exists a . (Show a) = a)
Having that would make a lot more sense, and would fit well together
with the intuition of the classic syntax.
How would you then define
data Foo ::
Hi all,
Following the discussion on the use of 'forall' and extensions that
use it [1], I would hereby like to propose that the
ExistentialQuantification extension is deprecated.
My rationale is as follows. With the introduction of GADTs, we now
have two ways to write datatype declarations, the
On Sat, Jun 27, 2009 at 5:44 AM, Niklas Brobergniklas.brob...@gmail.com wrote:
Hi all,
Following the discussion on the use of 'forall' and extensions that
use it [1], I would hereby like to propose that the
ExistentialQuantification extension is deprecated.
My rationale is as follows. With
Niklas Broberg wrote:
data Foo =
forall a . Show a = Foo a
which uses ExistentialQuantification syntax, could be written as
data Foo where
Foo :: forall a . Show a = a - Foo
The downside is that we lose one level of granularity in the type
system. GADTs enables a lot more
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
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
On Jun 27, 2009, at 15:37 , Niklas Broberg wrote:
* NewConstructorSyntax: Lets the programmer write data types using the
GADTs *syntax*, but doesn't add any type-level power (and no forall
syntax). Could probably use a better name (bikeshed warning).
GeneralizedTypeSyntax occurs to me.
--
20 matches
Mail list logo
