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
>> 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 defin
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
> ... "constructor Foo has the type forall a . (Show a) => a".
Eh, of course I meant "the type forall a . (Show a) => a -> Foo", but
you understood that I'm sure. :-)
Cheers,
/Niklas
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.h
> 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 alto
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 way
>> 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 synta
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
> 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.
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
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
11 matches
Mail list logo
