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
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.
Unfortunately,
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
Why not Haskell I?
(as the first "standard" form of the language)...
--Artie
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 'Haskell
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
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 scripting
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's no module header, the
[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 the
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 +, -
The programmer who
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't
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
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 6
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
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
* 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 = Left
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 and a
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
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 approach
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 to
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
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
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
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
; 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 Haskell
References: [EMAIL
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 contains
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
monad
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
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
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
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
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 that
(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
(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
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
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, and I
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
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
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 http://www.ams.org/cml/
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
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,
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
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
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 sufficient
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 did not
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 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
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
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
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
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 directive at
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
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)
53 matches
Mail list logo
