Re: Standard Haskell

John Launchbury: > I think I favor "20th century Haskell" myself :-) I forsee legal wrangles with one R. Murdoch -- though on the plus side, he might buy us all out for half a billion quid or so, perhaps. [ soccer econo-political reference for those not up on the latest NewsMegaCorp shenaniga

Re: Standard Haskell

John Launchbury wrote: > > I think I favor "20th century Haskell" myself :-) > Shouldn't that be "21st Century Haskell"? :-) > Hassett wrote: > > > > On 9/8/98 5:10 PM, Andrew Rock wrote > > > > >If Standard Haskell is meant to be a stable target for texts and the like, > > >why not Haskell-

Re: Standard Haskell

I think I favor "20th century Haskell" myself :-) Hassett wrote: > > On 9/8/98 5:10 PM, Andrew Rock wrote > > >If Standard Haskell is meant to be a stable target for texts and the like, > >why not Haskell-Ed (for Education), perhaps with a version indication like > >Haskell-Ed-98. > > Unfortun

Re: Standard Haskell

On 9/8/98 5:10 PM, Andrew Rock wrote >If Standard Haskell is meant to be a stable target for texts and the like, >why not Haskell-Ed (for Education), perhaps with a version indication like >Haskell-Ed-98. Unfortunately, this carries the risk that the uninformed may think that the language was

Re: Standard Haskell

> Date: Tue, 8 Sep 1998 12:00:43 +0100 (BST) > From: "Stephen H. Price" <[EMAIL PROTECTED]> > > On Mon, 7 Sep 1998, Simon Peyton-Jones wrote: > > > > * Incidentally, I'm leaning towards 'Haskell 98' as the name. > > > A couple of minor points: > a) Haskell 1998 would be more appropriate in the

Re: Standard Haskell

On Tue, 8 Sep 1998, Stephen H. Price <[EMAIL PROTECTED]> wrote: On Mon, 7 Sep 1998, Simon Peyton-Jones wrote: > > * Incidentally, I'm leaning towards 'Haskell 98' as the name. > A couple of minor points: a) Haskell 1998 would be more appropriate in the light of Year 2000

Re: Standard Haskell

> People seem to be forgetting the long-standing tradition of Algol (60), > Fortran (66, 77, 90) ...not to mention Algol W, S-algol, PS-algol and H Level FORTRAN... If Simon worked for IBM he could call it FP/I, in the tradition of PL/I. So why not Haskell-1, to be followed by Haskell-2, or even

Re: Standard Haskell

People seem to be forgetting the long-standing tradition of Algol (60), Fortran (66, 77, 90) and, no doubt, many other fine languages in their use of 2-digit year qualifiers. 98/99 sounds good to me. >On Mon, 7 Sep 1998, Simon Peyton-Jones wrote: >> >> * Incidentally, I'm leaning towards 'Haske

Re: Standard Haskell

Why not Haskell I? (as the first "standard" form of the language)... --Artie

Re: Standard Haskell

On Mon, 7 Sep 1998, Simon Peyton-Jones wrote: > > * Incidentally, I'm leaning towards 'Haskell 98' as the name. Was it Bill Gates that suggested this to you? :-) At 12:00 +0100 98/09/08, Stephen H. Price wrote: > a) Haskell 1998 would be more appropriate in the light of Year 2000 >problems

Re: Standard Haskell

On Mon, 7 Sep 1998, Simon Peyton-Jones wrote: > > * Incidentally, I'm leaning towards 'Haskell 98' as the name. > A couple of minor points: a) Haskell 1998 would be more appropriate in the light of Year 2000 problems. b) Dating product names like this tends to give the impression that this

Re: Standard Haskell

Haskell 98 (or 99) sounds just right to me. Please, don't fix on a name that doesn't have a number attached to it -- for example, realistically, this version will ultimately not really be "standard"; we'll most likely want to settle on a new version in a few more years. -Paul

Re: Standard Haskell

Naw. Let's go for "Haskell 00". ;-) --Joe Joseph H. Fasel, Ph.D. email: [EMAIL PROTECTED] Technology Modeling and Analysisphone: +1 505 667 7158 University of Californiafax:+1 505 667 2960 Los Alamos National Laboratory postal: TSA-7 MS F609

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

On 24-Jun-1998, Frank A. Christoph <[EMAIL PROTECTED]> wrote: > >> > 4) Module headers can be omitted. > >> >If the module leaves out the module header, the header > >> > module Main(main) where > >> >is assumed. > >> >[and that's a mistake] > >> > >> Fix the compilers. If there

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

Frank A. Christoph wrote: >If you want a functional scripting language with H-M type inference and type >classes and monads, that's great, but maybe it should be something separate >from Haskell. Haskell is, according to my experiences with tool integration, the ultimate scripting language arou

RE: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[I'm replying to both Fergus and Alastair in this message.] >This is a reply to Fergus Henderson's comments on my proposal. > >My answer to all his comments is that consistent languages are >easier to learn than languages littered with exceptions, special cases >and random default behaviour. On

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

Fergus Henderson <[EMAIL PROTECTED]> writes: > On the Standard Haskell site, > Alastair Reid wrote: > > > > 1) Fixity declarations usually look like this: > > > > infixl 6 +, - > > > >but you can omit the precedence digit and write this instead: > > > > infixl +, - > > > >

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

> I think you're missing the point. Omitting the precedence digit is > important because it allows the programmer to avoid making a decision > about something he doesn't really care about. Most of the time, > you're not interested in the relative precedence of `thenP` vs. (+), > since it doesn'

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

>If you want a functional scripting language with H-M type inference and type >classes and monads, that's great, but maybe it should be something separate >from Haskell. I have been promoting Haskell exactly for this purpose for some time now, and I don't buy your points, e.g that > in a script

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

On the Standard Haskell site, Alastair Reid wrote: > One of the goals of Standard Haskell was to simplify the language > - removing traps and making it easier to teach/learn. We've seen > very little work on this, so I'd like to make the following proposal: > > Let's remove all the little synt

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

This is a reply to Fergus Henderson's comments on my proposal. My answer to all his comments is that consistent languages are easier to learn than languages littered with exceptions, special cases and random default behaviour. > > 1) Fixity declarations usually look like this: > > infixl

Re: Standard Haskell Libraries

On 24 Apr, Frank A. Christoph wrote: > Suggestion for Standard Haskell: > > Copy all the stuff in the Prelude to the standard libraries, at least when > there is an obvious module for them to go to. Hear here! (or is that here, here or hear hear?) That was on my list to suggest to the standard

RE: Standard Haskell

Frank A. Christoph: > I hope that Either will be renamed to (+), or at > least deprecated in favor of (+). I'd basically agree with Frank here, though presumably for consistency with Koen's (very reasonable) proposals, this would need to be the symbol (:+:) -- or characters to that effect -- for

RE: Standard Haskell

> * Secondly, "Restrictions on name spaces removed". As an addition to >this, I would like to propose the following modest extension to Haskell. >Why don't we allow type constructors with more than one argument to be >written as operators? An obvious example to define would be: > > data a :+: b =

Re: Standard Haskell: Typecasts (Another message from Alastair)

On 10-Mar-1998, Alastair Reid <[EMAIL PROTECTED]> wrote: > > I don't think it's as simple as you suggest: Probably not, but as you say > Issues 1 and 2 can be solved with sufficient effort. In fact, you > can probably go a long, long way to solving them by implementing > cross-module inlining

Re: Standard Haskell: Typecasts (Another message from Alastair)

This mail is in reply to something posted to the Standard Haskell WWW page / mailing list. If this is not the best forum for such responses, please let me know what is. The quoted material following is drastically elided. > John Peterson: Typecasts (Another message from Alastair) ... > The Prob

Re: Standard Haskell: Typecasts (Another message from Alastair)

Fergus Henderson <[EMAIL PROTECTED]> writes: > This mail is in reply to something posted to the Standard Haskell > WWW page / mailing list. If this is not the best forum for such > responses, please let me know what is. I think it's the only forum available. In http://www.cs.chalmers.se/~rjmh/

Re: standard Haskell

> But it is difficult to track the ongoing discussion, because > - the interface is slowww (they don't call it the "World Wide Wait" > for nothing) > - it is difficult to keep track of which parts you have read already > and which parts are new > - unlike say a mailing list, those wishing

Re: standard Haskell

On 11-Dec-1997, Paul Hudak <[EMAIL PROTECTED]> wrote: > Having participated in many previous Haskell design efforts, I must say > that John's WWW-based system is MUCH better than straight email. With > email you have 16 different threads that are really hard to keep track > of; the tree-based app

Re: standard Haskell

On 24-Aug-1997, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > You can see the ongoing discussion on > > http://www.cs.chalmers.se/~rjmh/Haskell/Display.cgi?id=0 Actually it is at http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=0 But it is difficult to track th

Re: standard Haskell

.5/8.7.3) id DAA18741; Fri, 12 Dec 1997 03:23:06 +1100 (EST) Message-Id: <[EMAIL PROTECTED]> Date: Fri, 12 Dec 1997 03:23:05 +1100 From: Fergus Henderson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: standard Ha

Re: standard Haskell

Fergus Henderson says: But it is difficult to track the ongoing discussion, because - the interface is slowww (they don't call it the "World Wide Wait" for nothing) - it is difficult to keep track of which parts you have read already and which parts

Re: standard Haskell

Fergus Henderson wrote (to the Haskell Mailing List): > [..] > But it is difficult to track the ongoing discussion, because > - the interface is slowww (they don't call it the "World Wide Wait" > for nothing) I tried it yesterday and had no complaints about the performance. > - it is diff

Re: standard Haskell

On 11 Dec, Paul Hudak wrote: > I suppose that one improvement that you'd like and that I agree would be > an improvement is the ability to mark messages as read. With Netscape Navigator (at least on Linux) you can set an option not to expire visited links. This means they change colour and stay

Re: standard Haskell

Having participated in many previous Haskell design efforts, I must say that John's WWW-based system is MUCH better than straight email. With email you have 16 different threads that are really hard to keep track of; the tree-based approach keeps things better organized. A newsgroup isn't as goo

Re: Standard Haskell and Monad Comprehensions

On Tue, 2 Sep 1997, Martin Nor{ick wrote, > Regarding comprehensions: hugs gives me an error for: > [a | a <- [10], b <- getLine ] > and says that getLine must be of type [a], but why? b is not used! Since [10] is a list, this comprehension is used to generate a list, and therefore b must take i

Re: Standard Haskell and Monad Comprehensions

On Thu, 28 Aug 1997, Johannes Waldmann wrote: > If comprehensions are allowed for arbitrary monads, > then [x] as an expression means "return, in some monad" > while [x] as a type expression means "the list type". I think this is a nuicanse too, I really haven't grasped the advantages of the mon

Re: Standard Haskell

> Nothing to do with the content of the language (Standard) Haskell per > se, but if the next revision is going to be the final product of the > Haskell Committee, I'd like to encourage its members to at some stage > write something up about the decade-long design process. The paper below contain

Re: Standard Haskell and Monad Comprehensions

I'd like to throw in an optical consideration on comprehensions for lists vs. monads: If comprehensions are allowed for arbitrary monads, then [x] as an expression means "return, in some monad" while [x] as a type expression means "the list type". This is a discrepancy. I think it looks confusin

Re: Standard Haskell and Monad Comprehensions

rjmh wrote: > > This is in response to your message about removing the overloading of list > operations in ``Questions on the Table''---actually it more in response to >the > message about removing monad comprehension. I'm pretty new to Haskell (and > functional

Re: Standard Haskell web pages

This is in response to your message about removing the overloading of list operations in ``Questions on the Table''---actually it more in response to the message about removing monad comprehension. I'm pretty new to Haskell (and functional programming in general),

Re: Standard Haskell web pages

This is in response to your message about removing the overloading of list operations in ``Questions on the Table''---actually it more in response to the message about removing monad comprehension. I'm pretty new to Haskell (and functional programming in general), but my understanding is that the

Re: Standard Haskell

> In fact, I would like to hear what all the major implementors have as their > picture of a final version of Haskell. You've all been pretty quiet. > I assume you've all already aired your opinions at the workshop, but it would > be nice to see them here as well. Reasonable request. I hope tha

Re: Standard Haskell

(This is a follow-up to my last message regarding the rushing of the final version of Haskell.) Incidentally, with regard to features appropriate for Standard Haskell, I would say that explicit quantification (which someone mentioned) and first-class modules should be left out. Not because I don

Re: Standard Haskell

(On a more serious note,) I agree with the numerous people who support the inclusion of (in order from most essential to least) multi-parameter classes, state threads, standardization of concurrency features and foreign language interfaces. For at least the first three of these, I think they shou

Re: Standard Haskell

Sigbjorn Finne wrote: [in connection with the Standard Haskell discussion] > If nothing else, it could force people to think twice about designing > a new language :-) Yeah, we don't need anything new. In fact, I've been thinking of an alternate way of standardizing Haskell. It is described bel

Re: Standard Haskell

At 07:10 97/08/22, David Barton wrote: >Let's not even *talk* about "official" standardization until we get >Haskell 1.5 (nominally, "Standard" Haskell) done. I believe we should keep the First Amendment. :-) Hans Aberg * AMS member: Listing

Re: Standard Haskell

John said: > >The point has also been made that Haskell 1.4 lacks some features that are >already quite well understood and will be sorely missed for serious >applications --- multi-parameter classes, state threads, existential and >universal types. If this is the last revision then the most impo

Re: Standard Haskell

Nothing to do with the content of the language (Standard) Haskell per se, but if the next revision is going to be the final product of the Haskell Committee, I'd like to encourage its members to at some stage write something up about the decade-long design process. A design rationale would be gr

Re: Standard Haskell

At 10:37 97/08/22, John Hughes wrote: > What >we're proposing is simple to make one more revision --- call it Haskell 1.5 if >you like --- and then not to make any more. ... >The point has also been made that Haskell 1.4 lacks some features that are >already quite well understood and will be sorel

Re: Standard Haskell

Hans Aberg writes: At 07:10 97/08/22, David Barton wrote: >Let's not even *talk* about "official" standardization until we get >Haskell 1.5 (nominally, "Standard" Haskell) done. I believe we should keep the First Amendment. :-) First Amendment? Heck, if you even *think* about it,

Re: Standard Haskell

I *strongly* agree with John. Let's not even *talk* about "official" standardization until we get Haskell 1.5 (nominally, "Standard" Haskell) done. Then, and only then, will the question of "official" standardization become (perhaps!) relevant. Dave Barto

Re: Standard Haskell

David Barton wrote: > Hans Aberg writes: > >I do not think that the Pascal standardizing model is being used >anymore; instead one schedules a new revision, say every five years >(this is used for C++). There is already an application put in for >ISO/ANSI standardizing of Java, an

Re: Standard Haskell

Hans Aberg, you wrote: > I would rather think that the reason that functional languages are not > used is the lack of an ISO/ANSI standard, plus the lack of standard ways of > making cooperation with other, imperative languages. Of these two reasons, I don't think the first has much weight at a

Re: Standard Haskell

At 17:24 97/08/21, Wolfgang Beck wrote: >Does Haskell really need the features that will be part of >a Research Haskell? Or is it better to freeze Haskell development >now and start developing systems u s i n g Haskell? Languages look >very ugly if too overloaded with new concepts (look at C++). >

Re: Standard Haskell

> >> Standardizing a language tends to make it obsolete, due to lack of > >>creativity. Perhaps it is time to start discussing the successor of > >>Haskell then. > > > >Please not yet! Let us finish Haskell first! > > Well, what I tried to say is that once one starts to standardize

Re: Standard Haskell

Hans Aberg writes: > > I would rather think that the reason that functional languages are not > used is the lack of an ISO/ANSI standard, plus the lack of standard ways of > making cooperation with other, imperative languages. > This is true. The Haskell community has to decide wether Haskell

Re: Standard Haskell

At 11:54 97/08/21, John Hughes wrote: >>Is it not possible to make the versions upwards compatible, so that >> Haskell 1.4 code somehow can be run on Haskell 1.5? Does "being stable" >> need to mean unchangeable? > >Well, that's really been the aim all along, but things haven't t

Re: Standard Haskell

Please pardon me if I come across as a smug outsider, but it seems like a Catch-22 situation: 1. Designers would like more people to program in Haskell. 2. The industry prefers to use standards. 3. Designers realize that a standard will more or less put them out of business. This is

Re: Standard Haskell

John Hughes writes: >> If now the language should be standardized, why not make it an >>ISO/ANSI standard? >> >I don't think this is the time. Look at Pascal. After the revised definition >was published many years passed before it became an ISO standard, during which >the language

Re: Standard Haskell

At 17:26 97/08/20, John Whitley wrote: >Perhaps what is needed are two tracks of language development, >"Standard Haskell" and "Research Haskell". The research community >continues to develop, distribute, and test new language concepts with >less fear of disrupting existing users. After sufficien

Re: Standard Haskell

Let me try to give my answers to some of the points that have come up since yesterday. Hans Aberg says: If now the language should be standardized, why not make it an ISO/ANSI standard? I don't think this is the time. Look at Pascal. After the revised definition was publishe

Re: Standard Haskell

Fergus Henderson writes: ISO is the same. But standards don't get updated every five years. Rather, each standard must be _reconsidered_ every five years. One of the possible results is for the standard to be reapproved unchanged. If the standards committee does decide that the stan

Re: Standard Haskell

Hans Aberg writes: I do not think that the Pascal standardizing model is being used anymore; instead one schedules a new revision, say every five years (this is used for C++). There is already an application put in for ISO/ANSI standardizing of Java, and I think Java is younger than

Re: Standard Haskell

At 17:25 97/08/20, [EMAIL PROTECTED] wrote: >On 20 Aug, Hans Aberg wrote: >> Is it not possible to make the versions upwards compatible, so that >> Haskell 1.4 code somehow can be run on Haskell 1.5? Does "being stable" >> need to mean unchangeable? > >Well, one way would be to require a directi

Re: Standard Haskell

Hans Aberg writes: > After all, a lot of work has been spent making personal computers > upwards compatible, so why not computer languages? The (perhaps obvious) reason to make anything backwards compatible is to support a legacy user base. Clearly, there is a tension between freezing the lang

Re: Standard Haskell

On 20 Aug, Hans Aberg wrote: > Is it not possible to make the versions upwards compatible, so that > Haskell 1.4 code somehow can be run on Haskell 1.5? Does "being stable" > need to mean unchangeable? Well, one way would be to require a directive at the head of every file saying (for example)

Re: Standard Haskell

At 14:34 97/08/20, John Hughes wrote: >Standard Haskell >...there was a lively discussion at the Haskell >Workshop in Amsterdam this year about the future of the language. To >summarise, despite the useful extensions in versions 1.3 and 1.4, many people >feel quite serious concern about the recent

Re: Standard Haskell

> After all, a lot of work has been spent making personal computers upwards > compatible, so why not computer languages? > As a user I find this VERY appealing. It can be very discouraging developing in a new language, if the definition is changing so that your code needs to be regularly upgr