what's the goal of haskell-prime?
Dear all, in the "mission statement" I read
We will strive to only include tried-and-true language features,
but the current discussion seems to have a wider focus, i. e. it is more of a wish list. Indeed I think that this is a good idea (ask (future) Haskell users what they want) but it might not be the original goal of the Haskell-Prime effort. On the other hand, design-by-committee (or by wiki, call it what you want) has its problems. Just for our enjoyment, here are two quotes from Stroustrup: Design and Evolution of C++ (1994) (ch. 12.6, p. 269f): * ... Tom Cargill got a lot of applause for the .. suggestion that anyone who proposed a new feature for C++ should also propose an old feature of similar complexity that should be removed... * Jim Waldo .. followed up with a further idea: Proposers of new features should be required to donate a kidney. That would make people think hard before proposing, and even people without any sense would propose at most two extensions. I like to stress that when discussing an extension, we should strive to clearly state the problem that it tries to solve, and we should check carefully what solutions are already known (within Haskell, or within other languages/libraries). Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Jan 25, 2006, at 9:37 AM, Johannes Waldmann wrote:
Dear all, in the "mission statement" I read
We will strive to only include tried-and-true language features,
but the current discussion seems to have a wider focus, i. e. it is more of a wish list. Indeed I think that this is a good idea (ask (future) Haskell users what they want) but it might not be the original goal of the Haskell-Prime effort.
Hello, I have been on this mailing list since yesterday, so maybe this has been addressed before. My first question is: who are the future users of Haskell? For instance: is this group homogenuous enough to define a single standard, or would it be advisable to define various layers in the language. A compiler may then choose to support up to and including a number of layers. I can imagine a compiler for students to learn functional programming with to have seriously different demands from the compiler used by researchers to do programming language research. I am usually not happy with the fact that novice programmers pay in clarity (of type error messages and diagnostics in general) for features they won't be using for a number of years. This choice can be left up the compiler builder, but I think it might have a place here too. Jurriaan Hage
jur
On Jan 25, 2006, at 9:37 AM, Johannes Waldmann wrote:
Dear all, in the "mission statement" I read
We will strive to only include tried-and-true language features,
but the current discussion seems to have a wider focus, i. e. it is more of a wish list. Indeed I think that this is a good idea (ask (future) Haskell users what they want) but it might not be the original goal of the Haskell-Prime effort.
Hello,
I have been on this mailing list since yesterday, so maybe this has been addressed before.
My first question is: who are the future users of Haskell?
For instance: is this group homogenuous enough to define a single standard, or would it be advisable to define various layers in the language.
No language can serve all of the people all of the time, but I think we should just do our best with a single standard. I think that the complexity of multiple languages / layers / standards would not be worth the payoff.
A compiler may then choose to support up to and including a number of layers. I can imagine a compiler for students to learn functional programming with to have seriously different demands from the compiler used by researchers to do programming language research. I am usually not happy with the fact that novice programmers pay in clarity (of type error messages and diagnostics in general) for features they won't be using for a number of years. This choice can be left up the compiler builder, but I think it might have a place here too.
Have you looked at the Helium language / compiler? It's a stripped-down version of Haskell for teaching. Maybe that's what you're actually suggesting? I think this is a great idea :) peace, isaac
No language can serve all of the people all of the time, but I think we should just do our best with a single standard. I think that the complexity of multiple languages / layers / standards would not be worth the payoff.
My original understanding of the Haskell' effort was that it was *not* intended as going for "Haskell 2", but rather as an update of Haskell 98. In other words, the target is Haskell 2005: - anything that was tried and tested by the end of 2005 is a potential candidate for inclusion in Haskell 2005. nothing else is. this would necessarily exclude much of the discussion here, for which I'd see only three ways out: - make an exception to rule one (bad, but occasionally needed) - ignore and leave for Haskell 2, whenever that might be (impractical) - standardise as an optional addendum to Haskell 2005, to lay the groundwork for Haskell 2010, and to narrow down on the more successful experiments (good, avoid adhoc Haskell 2 in favour of incremental approximations) and the third way seems the most likely to succeed. There'll always be Haskell xx+extensions (unless people stop experimenting) and some extensions are good enough to be standardised (perhaps with options), even if not yet good enough to be part of the current standard. Has the target changed, or was I misled to think of it this way?-) btw, I'd find it hard to track discussion on a wiki/ticket system alone. Could a member of the committee arrange for a Haskell'-weekly message, please (similar to Haskell weekly, but collecting news headers and links from haskell', wiki, track, and internal committee discussions)? cheers, claus ps. will haskell 98 support continue when the new standard comes out, or will there always be 2 languages (standard and standard+)?
"Claus Reinke"
No language can serve all of the people all of the time, but I think we should just do our best with a single standard. I think that the complexity of multiple languages / layers / standards would not be worth the payoff.
My original understanding of the Haskell' effort was that it was *not* intended as going for "Haskell 2", but rather as an update of Haskell 98.
I agree with what Simon PJ said on this subject in his followup. We will "flirt with" some largeish changes, though it's unclear whether or not we will adopt any. There's some chance we might adopt one or two; we just want to take it on a case-by-case basis. Perhaps some would like the discussion itself narrowed to tried-and-true features, but I'm hesitant to make such a mandate. I think it's healthy to put up with wide-ranging discussion, especially now. It would be a shame if we missed some opportunities here because we came in with too many preconceived notions. Hopefully we can bring threads to a close with some consensus on the wiki, and we can look at all of the proposals together objectively.
In other words, the target is Haskell 2005:
I like calling it Haskell' for now because the other names have too much baggage. Maybe when it's done, or when we make the first proposal, it'll be called Haskell06 or what-have-you.
- anything that was tried and tested by the end of 2005 is a potential candidate for inclusion in Haskell 2005. nothing else is.
this would necessarily exclude much of the discussion here, for which I'd see only three ways out:
I don't see anything wrong with discussion. The only downside is that there's a lot of email, but I'm used to it. Hopefully if there are any nuggets of gold in those big threads, someone will find them and put them on the wiki. The committee should _actively_ be mining for such nuggets. I'm going to try to close down big threads after a while with a summary on the wiki.
- make an exception to rule one (bad, but occasionally needed) - ignore and leave for Haskell 2, whenever that might be (impractical) - standardise as an optional addendum to Haskell 2005, to lay the groundwork for Haskell 2010, and to narrow down on the more successful experiments (good, avoid adhoc Haskell 2 in favour of incremental approximations)
Another advantage to putting things on the wiki is that they'll be documented for any Haskell-prime-prime to choose from. (snip)
btw, I'd find it hard to track discussion on a wiki/ticket system alone.
Yeah, the wiki is definitely not for discussion.
Could a member of the committee arrange for a Haskell'-weekly message, please (similar to Haskell weekly, but collecting news headers and links from haskell', wiki, track, and internal committee discussions)?
It would be _great_ if someone on the committee, or anyone for that matter, would summarize the discussion weekly. Perhaps Donald will do that as part of Haskell Weekly News, but I'm sure he'd be glad to have some help. Any volunteers? peace, isaac
Could a member of the committee arrange for a Haskell'-weekly message, please (similar to Haskell weekly, but collecting news headers and links from haskell', wiki, track, and internal committee discussions)?
It would be _great_ if someone on the committee, or anyone for that matter, would summarize the discussion weekly. Perhaps Donald will do that as part of Haskell Weekly News, but I'm sure he'd be glad to have some help.
Any volunteers?
Yes, I have prepared weekly summaries (for this week anyway). If someone wants to bring specific things to my attention -- even just a list of topics to include taken from the wiki and trac -- that would be helpful, and you get credit for it :) -- Don
On Jan 31, 2006, at 12:20 AM, Isaac Jones wrote:
It would be _great_ if someone on the committee, or anyone for that matter, would summarize the discussion weekly. Perhaps Donald will do that as part of Haskell Weekly News, but I'm sure he'd be glad to have some help.
Any volunteers?
I'll volunteer gladly. However, I'm not sure whether I'm qualified, since my interest in Haskell - or in any language apart from PHP, C, C++ and Perl - is almost purely theoretical, which is to say I'm more at home with Girard's F or an ordinal notation system than with space leaks. Aatu Koskensilta (aatu.koskensilta@xortec.fi) "Wovon man nicht sprechen kann, darüber muss man schweigen" - Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Am Montag, 30. Januar 2006 19:33 schrieb Isaac Jones:
[...]
Have you looked at the Helium language / compiler? It's a stripped-down version of Haskell for teaching. Maybe that's what you're actually suggesting? I think this is a great idea :)
I think the current Helium version causes too many problems because of the lack of type classes since type classes are normally used even with very fundamental things like numbers and value-to-string conversion.
peace,
isaac
Best wishes, Wolfgang
On Jan 31, 2006, at 1:50 PM, Wolfgang Jeltsch wrote:
Am Montag, 30. Januar 2006 19:33 schrieb Isaac Jones:
[...]
Have you looked at the Helium language / compiler? It's a stripped-down version of Haskell for teaching. Maybe that's what you're actually suggesting? I think this is a great idea :)
I think the current Helium version causes too many problems because of the lack of type classes since type classes are normally used even with very fundamental things like numbers and value-to-string conversion.
To be fair, the current version of Helium does support some overloading, but you cannot (easily) define new classes and instance (you'd have to compile these in, more or less). From the Helium docs: # There are five built-in type classes with the following instances: * Num: Int, Float * Eq: Bool, Char, Either a b, Float, Int, Maybe a, [a] and tuples * Ord: Bool, Char, Float, Int, [a] and tuples * Show: Bool, Char, Either a b, Float, Int, Maybe a, Ordering, [a] and tuples * Enum: Bool, Char, Float, Int and () # Instances for Show and Eq (and not for other classes) can be derived for data types. These instances are needed to use overloaded functions, such as show and (==) # There is no overloading of numerals It is high on my wishlist for Helium to have these in the language. Personally, I find the idea of a scaled down language for teaching a good one, although it would be nice to be able to integrate various versions of the compiler into a single compiler. I also think the type inference directives and class directives could go a long way in making a full-fledged compiler for Haskell, student suited. For instance, I can imagine that a a slight generalization of (our) type inference directives (using decision trees instead of simple messages) can deal with the problem of monad comprehensions versus list comprehensions at a relatively high level. But maybe I am sketching too rosy a picture here, since I almost forgot that list comprehension introduce new bindings, and at the moment type inference directives do not allow scope changes. cheers, Jurriaan Hage
peace,
isaac
Best wishes, Wolfgang _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
participants (8)
-
Aatu Koskensilta -
Claus Reinke -
dons＠cse.unsw.edu.au -
Isaac Jones -
Johannes Waldmann -
jur -
Stefan Holdermans -
Wolfgang Jeltsch