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
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
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
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
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
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.
typ
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 su
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 indentatio
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-p
-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
10 matches
Mail list logo
