Sebastian Sylvan wrote:

I'm wondering what "incremental and moderate" extension means?

I don't know what others mean by it, but for me, it implies standardizing existing practice, with possibly some conservative redesign to get rid of any hysterical warts. This is, BTW, what the C89 standard did for C, and it was a highly successful standard. -- Antti-Juhani

Well, what we already have is a lot of language extensions with varying degrees of support across implementations. GHC is somewhat of a standard in and of itself, and one thing that standardisation efforts bring is a record of what exactly GHC is doing, thus allowing for more and better implementations. Also, Haskell is only as good as it is now because it has been changing, and many options and smart ideas have been explored at each step. I'd personally like to see Haskell grow in all directions - both in practicality and in language features/abstraction. Not every change has to break everything, but sometimes breaking things is worth it if the language comes out better. In basically every case, implementations will almost certainly be able to provide backwards compatibility modes for incompatible changes, at least until things are largely switched over. There are a variety of unsatisfying things about the H98 standard which should be dealt with if Haskell is to be the best language it can be. Dealing with them is a good idea in my opinion (though in many cases it might be better to do this with Haskell 2, depending on what people think). There are some potential extensions I've been discussing lately with Stefan Ljungstrand, one of which is for fixing the issue that, for example Set cannot be made an instance of Functor or Monad, which may turn into concrete proposals sometime soon. Other proposals, like John Meacham's recent class aliasing proposal would be useful in cleaning up the class hierarchy in the Prelude, and making it feel less like all the good infix identifiers are stolen. Also, many people have complained, myself included, about Functor not being a superclass of Monad, and join not being included as a class method of Monad (with default instances going between join and bind). Future proposals aside, the language that people are programming in today is not Haskell 98. Multiparameter typeclasses and functional dependencies are common. I use newtype deriving fairly often (together with monad transformers), and that's not standard. Class methods are not allowed to have types which are typeclass restricted in H98, which, regardless of how often it's actually used, is kind of silly not to allow. Arbitrary rank polymorphism isn't in Haskell 98, which means that things like Control.Monad.ST aren't possible. GADTs are new, but they're a great idea and already in use in major projects such as Pugs. Concurrent and Parallel Haskell aren't standard. I'm sure I've missed things too. Standardising these extensions which people use will help document them in one place rather than a variety of papers, and will help existing code be more portable. If done right, there's no reason that Haskell has to lose users over further standardisation, and cleaning up of previous standards. Transitions can be made smoother by providing backwards compatibility in the implementations for at least a limited amount of time, with warnings to note deprecated usage of the language. New standards shouldn't serve as forks of the language, but as continuations of it. - Cale Gibbard On 13/10/05, Stephane Bortzmeyer wrote:

On Wed, Oct 12, 2005 at 03:39:34PM -0700, Isaac Jones wrote a message of 30 lines which said:

...

One of the main topics was the perceived need of a new standard,

As someone who is not an academic researcher and not a student in CS, I would like to express a personal opinion; we don't need a new standard. To me, Haskell needs more libraries, more users (which means more debugging and more documentations), more implementations, of course more real applications (darcs did a lot of the success of Haskell), so we can read their code, push sysadmins to install Haskell, etc.

Most functional programming languages have been killed by the "CS effect": the fact that most users are more interested in exploring new areas of computer science than in producing code. Lisp and ML were killed by the explosion of many different and incompatible versions. I am not interested in Haskell++ or OOHaskell or anything like that.

If people want to standardize things, their time could be, IMHO, best spent by standardizing libraries (I just recently discovered that Text.Regex is not standard and my programs do not run under hugs).

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello Stephane, Thursday, October 13, 2005, 11:24:30 AM, you wrote: SB> As someone who is not an academic researcher and not a student in CS, SB> I would like to express a personal opinion; we don't need a new SB> standard. To me, Haskell needs more libraries, more users (which means SB> more debugging and more documentations), more implementations, of SB> course more real applications (darcs did a lot of the success of SB> Haskell), so we can read their code, push sysadmins to install SB> Haskell, etc. i put just the same opinion 1-2 months ago :))) but i got answer that current Haskell standard are too restrictive and ALL real programs use extensions. we need to standartize these de facto used extensions in order to simplify constructing of libraries and teaching language in universities/courses. we must explicitly declare the language really used in 2005, which is far away from the language used in 1998 -- Best regards, Bulat mailto:bulatz@HotPOP.com