Hi,
I would like to take some time to study Haskell properly, so
that I could help others and pay my debt for the many times
I had to bother with my syntax questions. And, of course,
make better use of the language.
My first attempt was to read the syntax description in
Haskell 98 report, and
-prime is the best guiding line now
historically, this pretty standard Haskell is a common subset of
hugs and ghc extensions. but even this subset is a bit too large,
containing some temporary and not much beloved extensions (parallel
comprehensions, fundeps...)
--
Best regards,
Bulat
briqueabraque:
Hi,
I would like to take some time to study Haskell properly, so
that I could help others and pay my debt for the many times
I had to bother with my syntax questions. And, of course,
make better use of the language.
My first attempt was to read the syntax description in
I am pleased to announce the first release of package strict which
provides strict versions of standard Haskell types. At the moment,
pairs, Maybe and Either are defined. For instance, strict Maybe is
defined as
data Maybe a = Nothing | Just !a
Package homepage:
http://www.cse.unsw.edu.au
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
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.
Unf
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
Folks, and esp. the Std Haskell committee,
This is to remind you about the state of play for Standard Haskell.
* There is a complete summary of the changes to Haskell that I propose
to make, including the Prelude and Libraries, at
http://www.dcs.gla.ac.uk/~simonpj/std-haskell.html
Yes, I think it's a fine idea to loosen up the syntax and allow import and
infix anywhere. But could someone clarify what the intent is with regards to
the scoping of liberally sprinkled imports/infixes?
I've added a clarification; my intent was that all ttimport/tt and tt
fixity/tt
"Jeffrey R. Lewis" [EMAIL PROTECTED] writes:
I thought the if-the-else proposal seemed odd until I followed the link
and read the exact proposal. Simon: your if-then-else example on the
Standard Haskell page seems at odds with the actual proposal (e.g. isn't
the point that the `el
"Jeffrey R. Lewis" [EMAIL PROTECTED] writes:
Yes, I think it's a fine idea to loosen up the syntax and allow import and
infix anywhere. But could someone clarify what the intent is with regards to
the scoping of liberally sprinkled imports/infixes?
Sorry - we should have made this clear.
* the name!
Names including a date, like Haskell 98, or a specific use,
like Teaching Haskell, could mislead. Standard Haskell 1 is
rather long (and ambiguous). The reasons why Haskell 1.5
suggests greater stability than Haskell 1.4 are too obscure.
So if Standard Haskell says too
"Colin" == Colin Runciman [EMAIL PROTECTED] writes:
Colin * the name!
Colin Names including a date, like Haskell 98, or a specific use,
Colin like Teaching Haskell, could mislead. Standard Haskell 1 is
Colin rather long (and ambiguous). The reasons why Haskell 1.5
Colin
On 7 Aug, [EMAIL PROTECTED] wrote:
* maximal munch and comments
Explicitly allowing operators such as --- and -- is not just
a clarification; it is a change in the comment convention. (cf. p8 of
the 1.4 report `The sequence -- immediately terminates a symbol ...')
right, and a
proposal seemed odd until I followed the link
and read the exact proposal. Simon: your if-then-else example on the
Standard Haskell page seems at odds with the actual proposal (e.g. isn't
the point that the `else' itself needn't be indented?)
* monomorphism restriction
(Last but hardly least
[EMAIL PROTECTED] writes:
* import and infix declarations anywhere in a module?
I am against this proposal. Collecting all such declarations
at the head of the module is better for human readers. Allowing
them anywhere would also complicate and slow down program analysis
that
In respone to:
? From: Simon L Peyton Jones [EMAIL PROTECTED]
? Subject: Re: Felleisen on Standard Haskell
? Date: Tue, 04 Aug 98 08:54:48 +0100
I would be happy to find a name
that was less grand and final-sounding than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5
In any case, I hope that Simon will follow his urge to get Standard
Haskell done with Real Soon Now, even if there is no overwhelming
consensus on certain issues, so that we can then concentrate on Haskell
2.
That's just what I intend to do. I don't see Std Haskell as a big
deal, but even
That said, the more I think about it, I don't really believe that
"Standard Haskell" will accomplish much. The fact is that everyone
wants many of the features in Haskell 2, and so even today would prefer
using an implementation that is probably not fully compliant with
and final-sounding than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5'.
What about "Haskell 98" ?
Sounds more final as 1.5 but less final as a Standard :-)
-- Daan
that was less grand and final-sounding than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5'.
`Teaching Haskell' is an obvious option, but might put too many
non-academics off.
So, considering its purpose, what about `Stable Haskell'?
(The main drawback is, of course
At 10:12 +0200 98/08/04, Lennart Augustsson wrote:
It's not only people who use Haskell for teaching that want stability.
If you've used Haskell for some real project where the current Haskell
is adequate
...
I think Standard Haskell is a good thing since it opens up
the possibility of making
than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5'.
That sounds like a good idea. But why don't we just be honest and call it
Haskell--? (Or maybe "(-1) Haskell"? :) Unfortunately, that's not even a
legal section because of the funny rules for unary minus...)
Lennart wrote:
It's not only people who use Haskell for teaching that want stability.
If you've used Haskell for some real project where the current Haskell
is adequate (which, IMHO, is quite a few) you may not want to rewrite
gazillion lines of code.
I'd like to second that. I have two
and final-sounding than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5'.
Given the comments we have seen so far, there seem to be two major
issues at the heart of this `XX Haskell YY' business. Some may argue
they are just two aspects of the same issue, but separating them
and final-sounding than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5'.
Let's drop the name Standard Haskell for now. I think Haskell 1.5 sounds
just fine, and is much truer to what's actually going on, given Haskell 2
on the horizon. The name doesn't even need to sound
Folks
This message is to update you on the state of play so far
as Standard Haskell is concerned. I'm circulating to three
Haskell-related mailing lists; in future I'll mail only
the "haskell" list, so pls subscribe to it if you want to
see anything more.
You may remember that John
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
the source for the standard prelude, because
I don't know what the precedence of the other operators is.
I was surprised to learn that this kind of declaration is possible. It's a
safe bet that most other people would be too. Standard Haskell is supposed
to be Haskell 1.4, but streamlined
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
eexporting all kinds of rubbish
from the Prelude (and is something I have argued against in the Standard
Haskell discussion).
[I know Fergus didn't make this argument - but it is related and it
irritates me enough that I'll answer it anyway.]
I think this argument is complete nonsense. When
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. For instance, head and tail
should appear in the List module. I doubt I'm the only one who can't
remember if a particular list function
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
Alex Ferguson wrote:
| 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
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
Hi all,
I just read the "Standard Haskell Decisions" at
http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decisions.cgi
I would like to say a few things about it.
* First of all, compare the decisions "Pattern match failure in do will
cause an error" and "Add patte
I've just played a bit with Hugs 1.3c which implements the type system that is
proposed for Standard Haskell. I came accross a limitation compared to Gofer
which I find quite unfortunate.
As an example for the advantages of multiple parameter classes Mark Jones gives:
class Collection c
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 http://www.cs.chalmers.se/~rjmh
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
ny changes. In particular,
as more than one of the members has mentioned, multi-parameter classes appear
to present a very complex design space, and even the experts (Mark Jones, et
al.) have overlooked some difficulties in their paper on the subject.
With all these extensions, can we reall
Many thanks to everyone who has registered their opinion on
strict vs lazy pattern matching in the poll I'm conducting.
If you plan to do so but haven't yet, there's still time:
I shall freeze the results tomorrow.
For more information see
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
u're sitting in Australia than it is here
in Sweden.
The software that manages the Standard Haskell pages isn't necessarily
fixed. It's a collection of small Haskell programs which I have constructed
myself. I do occasionally enhance it in response to suggestions from the
committee -- for e
; 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
Some months ago I announced the formation of the `Standard Haskell
committee' at the Haskell workshop, to make one final revision of
Haskell which would become a stable, and hopefully simpler, language.
At that time I said we were aiming to complete tidying up the design
in October. Now it's
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
I agree that monad comprehension troubles a bit, and that is confusing.
It certainly should not be in Standard Haskell!
n.
-[ norpan ]-[ [EMAIL PROTECTED] ][ martin norb{ck ]-
-[ please be noted that the { is really a swedish letter but it is ]-
-[ unrepresentable
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
to design Standard Haskell.
The problem is that if list operations, and especially list comprehensions, are
overloaded,
then in some programs the overloading will be ambiguous. In those cases the compiler
rejects the program, with an error message along the lines of
`ambiguous type variable
the
decision to design Standard Haskell.
The problem is that if list operations, and especially list comprehensions, are
overloaded,
then in some programs the overloading will be ambiguous. In those cases the compiler
rejects the program, with an error message along the lines
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
think Java is younger than
Haskell. So I think the question should at least be investigated;
perhaps it is the developed Standard Haskell that should be made
ISO/ANSI.
I think you really have to stop and think very carefully about
what you would gain from an ISO/ANSI standard for Haskell
it Haskell 1.5 if
you like --- and then not to make any more. It's nothing to do with standards
bodies, government contracts or whatever. The problem `Standard Haskell' is
trying to address isn't to attract new industrial/government users who won't
touch anything without an ANSI stamp on it. It's to make
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.
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
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 ht
to do is add experimental features to `Standard Haskell', only to find out in
a year's time that we got the design wrong. It seems to me that the three
points above probably are sufficiently well understood for us to get the
design right now; other ideas like interaction with other programming
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 yo
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
personally I am dead against designing a `Noddy Haskell' which is clean enough
for teaching; let Standard Haskell be clean instead!
Standardizing a language tends to make it obsolete, due to lack of
creativity. Perhaps it is time to start discussing the successor of
Haskell t
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 user
at least be investigated; perhaps it is the developed Standard
Haskell that should be made ISO/ANSI.
Students believe functional
languages are good for toy programs because they learned them when they could
only write toy programs.
I would rather think that the reason that functional languages
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,
would be a significant hurdle to
overcome.
Agreed; perhaps impossible.
In any case, I agree with Dave Barton that ISO standardization for
Haskell should not be considered until after the current effort
at defining "Standard Haskell" is complete.
Even if then.
Haskell. So I think the question should at least be investigated;
perhaps it is the developed Standard Haskell that should be made
ISO/ANSI.
Having been through the standardization wars many times, perhaps I
should interject here. Virtually all of my experience has been within
the IEEE
with new concepts (look at C++).
If Haskell still lacks important features it is no use to
make a Standard Haskell now.
Wolfgang Beck
Standard Haskell
You may well know already that 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
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
.
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 time the
lessons f
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)
85 matches
Mail list logo
