Re: Status of Haskell'?
Simon wrote: > I’m sure that any solution will involve (as it did in earlier stages) > motivated individuals who are willing to take up leadership roles in > developing Haskell’s language definition. I’m copying this to the main > Haskell list, in the hope of attracting volunteers! I, for one, would love to help out! Cheers, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: Deprecate ExistentialQuantification
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 Foo :: * where Foo :: forall a. a -> a -> Foo in which the scope of existentially quantified type variable spans more than one field? Cheers, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: Deprecate ExistentialQuantification
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
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 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.
Cheers,
Stefan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: Deprecate ExistentialQuantification
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: type aliases and Id
Ian, Mmm... * Allow "type Id =" (I prefer this to "type Id" as I think we are more likely to want to use the latter syntax for something else later on). Looks kind of funny; I'm not too thrilled. * Implementations should eta-reduce all type synonyms as much as possible, e.g. type T a b c d = X a b Int c d is equivalent to type T a b = X a b Int and type Id a = a is equivalent to a type that cannot be expressed directly. I like this alternatie a bit better, but I can also see how it introduces a lot of potential confusing, especially for novice Haskell programmers. You write something and the compiler goes along with something else... Maybe this will serve as a source of inspiration: http:// portal.acm.org/citation.cfm?doid=581478.581496 [1]. Cheers, Stefan [1] Matthias Neubauer and Peter Thiemann. Type classes with more higher-order poly- morphism. In Proceedings of the Seventh ACM SIGPLAN International Conference on Functional Programming (ICFP ’02), Pittsburgh, Pennsylvania, USA, October 4–-6, 2002, pages 179–-190. ACM Press, 2002. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: small extension to `...` notation
Ben, xs `zipWith (+)` ys Another problem is that it's not clear how to declare the fixity of these things. Should they always have the default fixity? Should they be required to have the form ` ` and use the fixity of `ident`? Neither approach seems very clean. Following Philippa's suggestion to handle nesting, one could again treat `` and `` differently and always assume the latter is given infix 9. Regards, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the dreaded offside rule
Neil, 1) it is impossible to explain the precise workings of the rule to a class of first years undergraduates Then don't explain it to them. At York in the 3rd year Haskell course it is never explained in detail, I think it might be briefly mentioned in passing that some kind of indentation thing is used, but not focused on. I certainly don't have a clue what the rule is. Well, that of course only works out well if students don't violate the offside rule. As soon as they do (for instance, because they use tabs instead of spaces to lay out their code), they want to know why the compiler rejects their programs. For students that have the right attitude, you can't just say that "it has something to do with indentation" then, because those will want to know the details then. Regards, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: what's the goal of haskell-prime?
Wolfgang, To be fair, the current version of Helium does support some overloading, Really? Are you talking about version 1.5? No, version 1.6, which was released just last week. See http:// www.cs.uu.nl/helium/. Cheers, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Parallel list comprehensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed ticket #55--add parallel list comprehensions--which according to the ticket, will probably be adopted. I would argue against. [...] For what's it worth: I totally agree with John. Not only does this seems to me like a feature that'll be so little used to justify the introduction of special syntax, I also it'll make the language far less accessible for newbies. Just my $ .02, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD5PybX0lh0JDNIpwRAvq6AKCo0iB5GQioWEvAdeJEp2V2ZHvZgwCdEnv6 U4X5NgQzv7bAHZdqcHUd5dE= =IjMp -END PGP SIGNATURE- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
