I think we all agree that in general, we should focus on existing
language extensions that have an implementation, and expect language
extensions to be implemented for them to be seriously considered for
inclusion in the standard.
But I think it would be wrong to turn this into a hard rule.
Hi.
Just to add a few general points. There are different dimensions to
evaluate GHC extensions for inclusion in the standard, and just making
lists does not really reflect that. The two most important ones, I
think, are:
1. Whether we think they're actually a good idea or not.
2. Whether we
Hi.
I'm ok with the general proposals made by Herbert. I'm not a huge fan
of github myself, but it seems like the most pragmatic choice right
now, and I wouldn't know anything else that is clearly better, so I'm
in favour. I'd somewhat prefer to have everything (wiki etc) in one
place then, but I
Hi.
I've been talking to Herbert from time to time, and I know he's having
a draft announcement lying around, and is still planning on properly
starting the process soon, and has (this is my opinion, not his) just
been falling into the trap of waiting for a "good moment" which then
never comes.
Just a little remark on the side: 'If' and 'case' demand exactly one
expression. In such cases allowing zero expressions is not a
generalization but an unnecessary complication. 'Let' and 'where'
allow any number of bindings, so allowing zero bindings (instead of
demanding at least one) is a
The only reasons that I could see in favor of allowing empty foralls
is that it might be easier to automatically generate code. Haskell
seems to be a bit inconsistent in how it treats empty constructs. For
example, empty let and empty where seems to be allowed, but not an
empty case?
I cannot see how an empty list of tyvars is useful or desirable in
practice:
data Foo = Foo (forall . Int)
is equivalent to just
data Foo = Foo Int
so why bother to permit the former? It probably indicates some error in
the thinking of the programmer, so the compiler should bring
I have fiddled with the build system, to enable the current state of the
Report in the darcs repository to be generated into (at least) HTML,
(hopefully also PDF and PS soon) automatically as every patch is checked
do we still need PS?
in. In theory, the following link should always give
Would anyone else like to volunteer to write a section of the report for
specific proposals below?
In
==
#74: add some kind of concurrency: SM, HN, IJ
#35: add ForeignFunctionInterface: MC, SM
#49: add multi parameter type classes: MS
#60: add RankNTypes or Rank2Types: AL
#57:
Hi Ashley.
Thanks for your interest in open data types. As one of the authors of
the open data types paper, I'd like to comment on the current
discussion.
You comment Simon's upcoming HW paper on extensible exceptions:
You write:
Compared to our approach, theirs requires new extensions to
I noticed ticket #55--add parallel list comprehensions--which according to
the ticket, will probably be adopted. I would argue against.
[Several good points removed.]
I agree.
Cheers,
Andres
___
Haskell-prime mailing list
Haskell-prime@haskell.org
11 matches
Mail list logo
