Updating the Haskell Standard
There was a brief discussion on #haskell today about the Haskell standard. I'd like to get opinions from more people, and ask if there is any effort being done in this direction presently. I think an updated standard is overdue. I find it difficult anymore to write any but the most trivial of programs using pure Haskell 98. Some notable, and widely-used, features developed since then include: * Overlapping instances * FFI * Hierarchical namespace * Undecidable instances * All sorts of updates to the standard library It has been awhile since I wrote a Haskell program that can compile in pure Haskell 98 mode. I think it would benefit everyone if a more up-to-date standard were made available. I know that some people would like to hold off on such a process until their favorite feature (we'll call it feature X) is finished. I would argue that incremental addendums to the standard should be made more frequently, so that new features can be standardized more easily. Thoughts? Who organized the standardization effort last time?
John Goerzen writes:
There was a brief discussion on #haskell today about the Haskell standard. I'd like to get opinions from more people, and ask if there is any effort being done in this direction presently.
<snip>
I know that some people would like to hold off on such a process until their favorite feature (we'll call it feature X) is finished. I would argue that incremental addendums to the standard should be made more frequently, so that new features can be standardized more easily.
Thoughts?
I can contribute some experience from commercial standardization efforts. ANSI, IEEE, and ISO standards require re-ballotting every five years, otherwise the standards lapse. Reballotting may or may not be accompanied by changes in the standard; for a standard as complex as a language, new versions at least every five years seems to be fairly common with "newer" standards (ANSI C has not changed in newer standardization ballots as far as I know). The trade-off for standards is between stability for tool developers and learners and stagnation. If the standard changes too often, there will be only one developer (the one effectively "in charge" of the standard) and it will tend to not be taught anywhere (because what students learn is obsolete too quickly). If the standard is unchanged too long, it becomes irrelevant and obsolete and no one pays attention to it. Five years is what the general industry seems to have settled on as a good average, but it may or may not apply here; the circumstances are different. Developers of Haskell are pretty much volunteers and academics; that changes things. On the other hand, it is a rapidly developing field. How all this shakes out is something for the community at large to decide; however, that is what happens in other standards bodies. Dave Barton EDAptive Computing
On 20-Jul-2005, David Barton
I can contribute some experience from commercial standardization efforts. ANSI, IEEE, and ISO standards require re-ballotting every five years, otherwise the standards lapse. Reballotting may or may not be accompanied by changes in the standard; for a standard as complex as a language, new versions at least every five years seems to be fairly common with "newer" standards [...] Five years is what the general industry seems to have settled on as a good average, but it may or may not apply here; the circumstances are different.
ANSI/ISO programming language standards typically undergo major updates every 10 years or so: Fortran 66, 77, 95, 2003; COBOL 68, 74, 85, 2002; Ada 83, 95, 2005; C 89, 99; C++ 98, 200x (for some x >= 5).
(ANSI C has not changed in newer standardization ballots as far as I know).
A major new update to the ANSI/ISO C standard was issued in 1999. -- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp.
Hello John, Wednesday, July 20, 2005, 10:14:23 PM, you wrote: JG> It has been awhile since I wrote a Haskell program that can compile in JG> pure Haskell 98 mode. I think it would benefit everyone if a more JG> up-to-date standard were made available. imho, there is an unofficial standard made by common GHC/Hugs features. afaik, other two Haskell compilers are not evolve any more. so that really you want to standartize? :) i think, the standartization process will help only in situations when there is several fast-grown and uncompatible realizations question in that i really agree - that documentation about all extra-Haskell98 features are spread here and there. it will be great if we will add, for example, addendum to "gentle introduction" where new language features and libs will be covered. of course, much of this can be borrowed from Hugs/GHC docs and articles, written by its developers -- Best regards, Bulat mailto:bulatz@HotPOP.com
(oops, forgot to cc to the list) Bulat Ziganshin wrote:
Hello John,
Wednesday, July 20, 2005, 10:14:23 PM, you wrote:
JG> It has been awhile since I wrote a Haskell program that can compile in JG> pure Haskell 98 mode. I think it would benefit everyone if a more JG> up-to-date standard were made available.
imho, there is an unofficial standard made by common GHC/Hugs features. afaik, other two Haskell compilers are not evolve any more. so that really you want to standartize? :) i think, the standartization process will help only in situations when there is several fast-grown and uncompatible realizations
Standardizing now-extensions to Haskell will let them permeate through the entire standard library. The hardest part in the standardization process wouldn't be choosing _what_ to include, but researching the effects on the current Haskell implementation itself.
question in that i really agree - that documentation about all extra-Haskell98 features are spread here and there. it will be great if we will add, for example, addendum to "gentle introduction" where new language features and libs will be covered. of course, much of this can be borrowed from Hugs/GHC docs and articles, written by its developers
I think it would be a good idea to take this page (http://haskell.org/hawiki/HaskellTwo) and, ignoring the "definitely," "possibly," etc., make sure that all the extensions people want in go to pages which are written in a Gentle Introduction-kind of way. - Sam (first post)
On 2005-07-21, Bulat Ziganshin
JG> It has been awhile since I wrote a Haskell program that can compile in JG> pure Haskell 98 mode. I think it would benefit everyone if a more JG> up-to-date standard were made available.
imho, there is an unofficial standard made by common GHC/Hugs features. afaik, other two Haskell compilers are not evolve any more. so that really you want to standartize? :) i think, the
Yes, that's true.
standartization process will help only in situations when there is several fast-grown and uncompatible realizations
I think that often there is resistance to use these optional features, even though they've been around for awhile. Not only that, but Haskell 98 source parsers won't work with those programs. I think it would be good to have an up-to-date, documented standard, that reflects what is really being used out there.
On 7/20/05, John Goerzen
There was a brief discussion on #haskell today about the Haskell standard. I'd like to get opinions from more people, and ask if there is any effort being done in this direction presently.
I think an updated standard is overdue. I find it difficult anymore to write any but the most trivial of programs using pure Haskell 98. Some notable, and widely-used, features developed since then include:
* Overlapping instances * FFI * Hierarchical namespace * Undecidable instances
Even if "undecidable instances" was standardized, would we want it turned on by default? I am trying to write "real" programs in Haskell and I have never even comtemplated using undecidable instances. My understanding is that they can be unintuitve, and they can cause typechecking to fail to halt. So, it seems reasonable to require that undecidable instances require some kind of option to be present. Thus, there would be a standard "undecidable instances" option or pragma. Now, it seems reasonable that, if we can standardize the option for undecidable instances, we could do the same thing for all new features we wish to add to Haskell 2. This is basically what the Cabal {-# LANGUAGE UndecidableInstances CPP PatternGuards ... #-} pragma does. Each implementation would have a set of pragmas that it supports. It would be best if the implementors agree on a specification for each feature, so that, e.g. "-# LANGUAGE UndecidableInstances #-} works identically wherever it is supported. Eventually, we would all look around at each other and realize "hey, GHC, Hugs, and NHC all support pragmas A, B, C, ... and these pragmas are so useful they should be available by default" Then, we could make a new option: {-# LANGUAGE Haskell 2005 #-} This would be equivalent to {-# LANGUAGE A B C ... #-}. Then, we would say that, if {-# LANGUAGE Haskell x #-} is omitted, then x defaults to "98." Note that this works for deletions too {-# LANGUAGE No<DeletedFeature> #-}. I imagine something similar would work for libraries: every implementation would build up a set of libraries its supports by default. We would recognize the common set of packages supported and say "this set of packages is the Haskell 2005 standard library." The bad thing about this is that "Hellow World, Haskell 2005" would become kind of ugly: {-# LANGUAGE Haskell 2005 #-} main = putStrLn "Hello, World!" But, of course, Haskell 2005 would be backwards compatible enough to support the 98 version: main = putStrLn "Hello, World!" I guess there must be some reason that this scheme is really horrible because I don't know of any language that has ever done things this way. But, it seems to make sense to me... - Brian
G'day all.
Quoting Brian Smith
Even if "undecidable instances" was standardized, would we want it turned on by default? I am trying to write "real" programs in Haskell and I have never even comtemplated using undecidable instances.
There's only one situation where I've found it necessary, and I think it's due to a missing feature in Haskell. Sometimes when I'm doing generic programming, I need a function to have some group of typeclass constraints: foo :: (MonadIO m, Ord k, Foo k v) => k -> m v And sometimes these constraints appear in more than one function. For brevity, I want a "typeclass synonym". The only way I've found to do this is: class (Monad m, Ord k, Foo k v) => MyCtx m k v instance (Monad m, Ord k, Foo k v) => MyCtx m k v which now requires undecidable instances. Cheers, Andrew Bromage
On 7/20/05, John Goerzen
There was a brief discussion on #haskell today about the Haskell standard. I'd like to get opinions from more people, and ask if there is any effort being done in this direction presently.
I think an updated standard is overdue. I find it difficult anymore to write any but the most trivial of programs using pure Haskell 98. Some notable, and widely-used, features developed since then include:
* Overlapping instances
* FFI
* Hierarchical namespace
* Undecidable instances
* All sorts of updates to the standard library
It has been awhile since I wrote a Haskell program that can compile in pure Haskell 98 mode. I think it would benefit everyone if a more up-to-date standard were made available.
I know that some people would like to hold off on such a process until their favorite feature (we'll call it feature X) is finished. I would argue that incremental addendums to the standard should be made more frequently, so that new features can be standardized more easily.
Thoughts?
Who organized the standardization effort last time?
I agree. In fact I think a Haskell 2.0 standard should be decided upon. The benefit of making a full version change like that instead of just adding to the current H98 standard is that there is less pressure to be backwards-compatible. Haskell is beautiful, but it does have its warts. A Haskell 2.0 could incorporate some non-backwards-compatible changes which would make things a bit nicer. There are tons of useful extensions in GHC which should be included.
From my perspective, someone who rarely uses the more exotic extensions, the two main warts is the module system (I would like to be able to "re-export modules qualified", so the user could import MyGraphicsLib and then have access to, say, Button.new and Window.close which would normally reside under MyGraphicsLib.Button and MyGraphicsLib.Window) and also the record system which I'm sure you'll all agree is quite inconvenient (this may suffice: http://research.microsoft.com/~simonpj/Haskell/records.html).
Also, the name "Haskell '98" probably sounded new and fresh back in '97, but it just sounds old and stale now. Version numbers is the way to go, IMO. Like someone pointed out, there is no official committe to decide these things. I suspect that if the GHC folks incorporated a "Haskell 2.0 Proposal"-mode in a future version, which includes the current glasgow-exts along with better module and record systems, consesus could be reached pretty fast. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
On Fri, 2005-07-22 at 15:36 +0200, Sebastian Sylvan wrote:
Haskell is beautiful, but it does have its warts. A Haskell 2.0 could incorporate some non-backwards-compatible changes which would make things a bit nicer. There are tons of useful extensions in GHC which should be included.
From my perspective, someone who rarely uses the more exotic extensions, the two main warts is the module system (I would like to be able to "re-export modules qualified", so the user could import MyGraphicsLib and then have access to, say, Button.new and Window.close which would normally reside under MyGraphicsLib.Button and MyGraphicsLib.Window)
This has been discussed on the libraries list once or twice with a rough consensus but without any further detailed analysis to make sure it really works. It doesn't look as though it's a backwards incompatible change however which is nice. Duncan
On 7/23/05, Duncan Coutts
On Fri, 2005-07-22 at 15:36 +0200, Sebastian Sylvan wrote:
Haskell is beautiful, but it does have its warts. A Haskell 2.0 could incorporate some non-backwards-compatible changes which would make things a bit nicer. There are tons of useful extensions in GHC which should be included.
From my perspective, someone who rarely uses the more exotic extensions, the two main warts is the module system (I would like to be able to "re-export modules qualified", so the user could import MyGraphicsLib and then have access to, say, Button.new and Window.close which would normally reside under MyGraphicsLib.Button and MyGraphicsLib.Window)
This has been discussed on the libraries list once or twice with a rough consensus but without any further detailed analysis to make sure it really works. It doesn't look as though it's a backwards incompatible change however which is nice.
Yes. I recall something along the lines of putting a "qualified" in the export list of MyGraphicsLib when re-exporting the Button and Window modules. Seems pretty simple and straightforward. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
John Goerzen wrote:
There was a brief discussion on #haskell today about the Haskell standard. I'd like to get opinions from more people, and ask if there is any effort being done in this direction presently.
I think an updated standard is overdue. I find it difficult anymore to write any but the most trivial of programs using pure Haskell 98.
[snip] This is perhaps a minor point, but if a serious new standardization effort were to emerge, I would like to see the formal semantics of Haskell firmed up a little. The Haskell 98 report does a pretty good job, but it fails to specify an explicit abstract term language for the Haskell kernel, and doesn't (in my opinion) do a satisfactory job of supplying formal semantics for the IO monad (this one's tough; perhaps via a transform to the pi-calculus?). It obviously doesn't even touch the semantics of extensions like implicit parameters, multi-parameter typeclasses (straightforward, but...), existential types or the STM monad. A serious effort in this area might allow practical interoperability between pluggable Haskell frontends (parsing, typechecking, desugaring, template expansion) and backends (optimization, code gen, linking) which interface via something that looks a lot like external core, as well as making Haskell more amenable to formal verification. Robert Dockins
participants (10)
-
ajb＠spamcop.net -
Brian Smith -
Bulat Ziganshin -
David Barton -
Duncan Coutts -
Fergus Henderson -
John Goerzen -
robert dockins -
Sam Goldman -
Sebastian Sylvan