GADT: call for proper terminology
Niklas Broberg wrote:
Annotate the data type using a GADT: data MyData a where MyCon :: MyData a
The range of the data constructor MyCon is the entire type MyData a -- so the above data type is the regular algebraic data type, and can be written just as data MyData a = MyCon which, some say, makes the fact 'a' is phantom, and the overall intent clearer. One may hear phrases how generally awesome and indispensable GADT are; it is distressing to realize then that sometimes (often?) one is talking about regular algebraic data types, only in the `where' syntax. It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types.
On 10/11/06, oleg@pobox.com <oleg@pobox.com> wrote:
Niklas Broberg wrote:
Annotate the data type using a GADT: data MyData a where MyCon :: MyData a
The range of the data constructor MyCon is the entire type MyData a -- so the above data type is the regular algebraic data type, and can be written just as data MyData a = MyCon which, some say, makes the fact 'a' is phantom, and the overall intent clearer.
One may hear phrases how generally awesome and indispensable GADT are; it is distressing to realize then that sometimes (often?) one is talking about regular algebraic data types, only in the `where' syntax.
It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types.
Right you are, I stand corrected. /Niklas
Hello oleg, Wednesday, October 11, 2006, 6:12:23 AM, you wrote:
Annotate the data type using a GADT: data MyData a where MyCon :: MyData a
It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types.
imho, the error was inventing new syntax for GADTs instead of just adding type guards to the old one -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Oct 11, 2006, at 03:58 , Bulat Ziganshin wrote:
Hello oleg,
Wednesday, October 11, 2006, 6:12:23 AM, you wrote:
Annotate the data type using a GADT: data MyData a where MyCon :: MyData a
It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types.
imho, the error was inventing new syntax for GADTs instead of just adding type guards to the old one
Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart
Lennart Augustsson wrote:
Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart
I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, "It really means this: ..." and then I write out a syntax more like GADT's. I also think that if we had adopted this syntax from the beginning, GADT's would have been "discovered" far sooner than now. -Paul
Well, Kent Petersson and I proposed them as an addition to Haskell in 1994, so they are not that new. :) -- Lennart http://web.cecs.pdx.edu/~sheard/papers/silly.pdf On Oct 11, 2006, at 09:47 , Paul Hudak wrote:
Lennart Augustsson wrote:
Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart
I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, "It really means this: ..." and then I write out a syntax more like GADT's.
I also think that if we had adopted this syntax from the beginning, GADT's would have been "discovered" far sooner than now.
-Paul
I would prefer notation like: data Parser a | Alt (Parser a) (Parser a) | Map ( b -> a) (Parser b) | Succ a Parser (a,b) | Seq (Parser a) (Parser b) Parser String | Lit (String -> Bool) Parser [a] | Many (Parser a) This takes away the noise in the heading of the current GHC notation (which is just plain confusing), and enables e.g. grouping of common alternatives, Doaitse Swierstra On Oct 11, 2006, at 11:42 PM, Lennart Augustsson wrote:
Well, Kent Petersson and I proposed them as an addition to Haskell in 1994, so they are not that new. :)
-- Lennart
http://web.cecs.pdx.edu/~sheard/papers/silly.pdf
On Oct 11, 2006, at 09:47 , Paul Hudak wrote:
Lennart Augustsson wrote:
Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart
I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, "It really means this: ..." and then I write out a syntax more like GADT's.
I also think that if we had adopted this syntax from the beginning, GADT's would have been "discovered" far sooner than now.
-Paul
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Doaitse Swierstra wrote:
I would prefer notation like:
data Parser a | Alt (Parser a) (Parser a) | Map ( b -> a) (Parser b) | Succ a Parser (a,b) | Seq (Parser a) (Parser b) Parser String | Lit (String -> Bool) Parser [a] | Many (Parser a)
This takes away the noise in the heading of the current GHC notation (which is just plain confusing), and enables e.g. grouping of common alternatives,
The above is very similar to Bulat's proposal http://www.haskell.org/pipermail/haskell/2006-September/018466.html ie (adding the idea of using another layout block to group alternatives on the rhs): data Parser a = Alt (Parser a) (Parser a) Map ( b -> a) (Parser b) Succ a Parser (a,b) = Seq (Parser a) (Parser b) Parser String = Lit (String -> Bool) Parser [a] = Many (Parser a) I don't think there's a good reason to use | to separate alternatives when we've already got {;} to form blocks of things, and to put things on the same line you'd just use: data {Hi Int = {One; Two; Three}; Hi a = Foo a} This would also make it easier to replace the => syntax at some future point with the "guard-like" | syntax used in Clean (also suggested by Bulat in the above post). Regards, Brian -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com
Hello Brian, Thursday, October 12, 2006, 3:35:34 AM, you wrote:
data Parser a | Alt (Parser a) (Parser a) | Map ( b -> a) (Parser b) | Succ a data Parser a = Alt (Parser a) (Parser a) Map ( b -> a) (Parser b) Succ a
I don't think there's a good reason to use | to separate alternatives when
don't forget that some definitions may be long enough. on the other side, we can apply layout rule again: data Parser a = Alt (Parser a) (Parser a) Map (b -> a) (Parser b) Succ a Parser (a,b) = Seq (Parser a) (Parser b) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (7)
-
Brian Hulley -
Bulat Ziganshin -
Doaitse Swierstra -
Lennart Augustsson -
Niklas Broberg -
oleg＠pobox.com -
Paul Hudak