It appears to me that there are important questions that need to be settled, unless ghc is to become a language of its own, rather than an implementation. There's nothing wrong with having ghc specific features, but only if this is done on purpose. Lots of things can result from such a discussion. Maybe there isn't a consensus because there are really two necessary constructs rather than one. Perhaps a consensus can be reached that allows one language extension to handle the requirements that have been exposed during the process of developing the libraries. Would it not be a good idea to CC these messages onto whichever list is directly concerned with language extensions and changes? The issues may be exposed by library development, but they are clearly of interest to both the language developers and the library developers. ross@soi.city.ac.uk wrote:
On Sat, Feb 26, 2005 at 08:00:22PM -0500, ajb@spamcop.net wrote:
Quoting ross@soi.city.ac.uk:
Indeed. Of all the extensions implemented by both GHC and Hugs, the only ones that seem ready are
- rank 2 type signatures, and
- polymorphic components for data constructors (giving them rank 2 types).
Off the top of my head:
- multi-parameter type classes
Reasonable in themselves, but limited in usefulness without some scheme to deal with overlapping instances, which doesn't seem settled at this time.
- pattern guards
GHC only
True, it is ghc only. One of the advantages of developing additions to the standard that allow this usage and define it in a precise way. If pattern guards are important (I personally think they are), then they should be formally designated as either an GHC extension to the language or a valuable extension that deserves to become part of a standard that compiler developers and library developers (both GHC and non-GHC) can reach a consensus. This would, in this particular case, result in a very interesting discussion. Do they truly make the language richer, or are there other equally effective ways to do the same thing? It is evident that the GHC developers added this feature because they believe that it is an important extension to the language.
- scoped type variables
Different treatment in GHC and Hugs. Can you point at a formal calculus corresponding to the version in GHC?
- recursive "do"
The treatment of recursion isn't obviously ideal: conflicts with ordinary do, and the semantics depends on the dependency analysis.
Then this is a good opportunity to define the syntax and semantics of this facility that can be uniformly implemented in a non-ambiguous way that does not break the H98 do syntax. Since do is basically a shorthand for a more complex and unwieldy coding, it might be logical to map a typical recursive do onto syntax that does not rely on do. (In H98 everything that "do" can do can be done without "do". (That has to be a candidate for worst sentence of the year. :) ) If the semantics is not deterministic, that is an obvious case where a consensus of how recursive do works is certainly needed. I agree with Ross that this isn't a settled question; but IMHO it needs to be settled. One core principle of functional programming in general and Haskell in particular is that you _know_ what your code will do. If recursive "do" is an important feature (I believe that most Haskell people would agree that it is), then the behavior has to be consistent, or it has to be disallowed in situations where it introduces non-determinism. I'm not knowledgeable enough to know whether that can be discovered at compile time. Clearly it is a complex issue and not trivial to implement, but, also clearly, it is currently being used and the results are acceptable to the library developer. I'd be very interested to know specifically why and under what circumstances the semantics is different. Not from the compiler perspective (Ross states that the semantics depend on the dependency analysis) but from the perspective of the coder. What are the possible semantics? Is the ambiguity common or rare? What happens if the library developer assumes one interpretation and the compiler generates a different one?
- data declarations with no constructors
Minor, but harmless.
- constraints on typeclass methods
- instances on type synonyms
Yes, these two and the relaxation of polymorphic recursion should have been in H98. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
!DSPAM:4221288d198032093425033!