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
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
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
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 i
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
lan
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
> is a snapshot of a continually developing environment, such as Office,
> which gains
iate in the light of Year 2000
problems.
b) Dating product names like this tends to give the impression that this
is a snapshot of a continually developing environment, such as Office,
which gains bells and whistles every year.
However, Standard Haskell is to be a s
> 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
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
Why not Haskell I?
(as the first "standard" form of the language)...
--Artie
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
give the impression that this
is a snapshot of a continually developing environment, such as Office,
which gains bells and whistles every year.
However, Standard Haskell is to be a solid specification, which will
be largely unchanging. Couldn't this just be named 'Haskel
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
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
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 import and
fixity declarations wou
"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
"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
[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
> th
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
>>>>> "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 amb
* 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
Jeffrey R. Lewis wrote:
> [EMAIL PROTECTED] wrote:
>
> > * import and infix declarations anywhere in a module?
> It would seem that if we allow infix decls anywhere, shouldn't we be
> loosening up the location of import decls also?
>
Umm... you probably already figured out that my above comment
ISWIM motivation for
> having layout rules at all?
>
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 t
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 s
On 04-Aug-1998, Hans Aberg <[EMAIL PROTECTED]> wrote:
>
> I should note that if one want the programs of an earlier version of a
> computer language should be able top run on a later version, that can be
> described by a monad. So why not implement an upgrade monad in Haskell? --
> It would sol
;that was less grand and final-sounding 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 no
find a name
> that was less grand 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 a
On 4 Aug, Philip Wadler wrote:
> 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'.
>
> Actually, Haskell 1.5 sounds exactly like what you want: halfwa
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 tw
Scott Turner wrote:
>At 18:08 1998-08-04 +0900, Frank A. Christoph wrote:
>>>[...] 'Standard Haskell' [...] 'Haskell 1.5'.
>>[...] Haskell--? [...] (-1) Haskell [...] Pre-Haskell
>
>Others wrote "Haskell 98" and "Teaching Haskell&
Folks,
I'm writing to say how I hope to progress the Standard Haskell
process. I have updated the 'State of play' page
http://www.dcs.gla.ac.uk/~simonpj/std-haskell.html
It now lists every change that I propose to make for Standard
Haskell. I now propose the
At 21:01 +1000 98/08/04, Fergus Henderson wrote:
>On 04-Aug-1998, Hans Aberg <[EMAIL PROTECTED]> wrote:
>>
>> I should note that if one want the programs of an earlier version of a
>> computer language should be able top run on a later version, that can be
>> described by a monad. So why not imp
About the Great Debate on the name of Standard Haskell:
Simon PJ wrote:
> 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'.
That expresses something I disliked
along. Indeed, I fear that the existence of Standard
Haskell might impede the urgency to develop Haskell 2. And while the
process meanders, most people will use the latest version of Hugs or GHC
or whatever that supports MPC's, and ignore standard Haskell.
Someone expressed the opinion (I thi
> I think Standard Haskell is a good thing since it opens up
> the possibility of making non-compatible changes in Haskell 2.
What will you do with your old programs once you start writing programs
in Haskell 2?
It would be really great if implementations could support BOTH Standard
Haske
> >That said, the more I think about it, I don't really believe that
> >"Standard Haskell" will accomplish much.
>
> I feel that way, but I think that Richard Bird and other people using
> Haskell in teaching may disagree. (Come to think of it, wouldn&#x
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
>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 compl
uld 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'.
`Teaching Haskell' is an obvious option, but might put too many
non-academics off.
So, considering its purpose, what about
a name
>that was less grand 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 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 probab
grand and final-sounding than 'Standard Haskell' though;
but more final sounding than 'Haskell 1.5'.
Actually, Haskell 1.5 sounds exactly like what you want: halfway
between the first draft and the next edition. It also resonates
with those of use who remember Lisp 1.5, whi
> 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 Hask
nd a name
> that was less grand 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
At 18:08 1998-08-04 +0900, Frank A. Christoph wrote:
>>[...] 'Standard Haskell' [...] 'Haskell 1.5'.
>[...] Haskell--? [...] (-1) Haskell [...] Pre-Haskell
Others wrote "Haskell 98" and "Teaching Haskell".
"Haskell 2000" uses a ni
Phil Wadler writes:
I bumped into Matthias Felleisen at ECOOP, and he offered the
following advice regarding Standard Haskell, based on his
experience with Scheme:
1. Don't standardize Haskell until it is useful to the
run-of-the-mill programmer. A minimum set of libr
I bumped into Matthias Felleisen at ECOOP, and he offered the
following advice regarding Standard Haskell, based on his experience
with Scheme:
1. Don't standardize Haskell until it is useful to the
run-of-the-mill programmer. A minimum set of libraries should include
- URLs [
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
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
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
ven if the number is specified explicitly,
>> I would *still* have to look up the precedence table in the report,
>> or at least grep 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 thi
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 dig
> 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'
>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
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:
>
> Le
> not include the module name (Main) in the error messages.
That's be nice AS WELL but why not simplify the report by removing
pointless defaults.
There's an argument going around that it must be possible teach Haskell
without having to mention the word "module" in the first m
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 su
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 fun
>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
> | s
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 =
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 Collectio
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
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)
...
&g
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.
s being unrealistic about being able to turn out a good,
stable, well-tested product so soon after so many 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 o
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
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
.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
h may be more of a problem if you'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 resp
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
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
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
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
http://www.cs.chalmers.se/~rjmh/Haskell/Message
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
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
comprehension always
include a '|'.
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!
I agree that monad comprehension troubles a bit, and that is confusing.
It certai
> 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.
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
examples raised at the Haskell workshop, that motivated
>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
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 of
`ambiguous t
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
Apologies: I mistyped the URL for the Standard Haskell
web pages in my last message. The correct URL is
http://www.cs.chalmers.se/~rjmh/Haskell/
>From this page the discussion so far is accessible by following
the link `Questions on the table'.
John Hughes
> 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
(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
(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
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.
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:
matters in a restrictive spirit. The last thing we want
>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 t
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 wou
not ruled out: nevertheless I think it's right that we
>should approach such matters in a restrictive spirit. The last thing we want
>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 t
revision --- call 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 w
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? Hec
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.
ndardizing of Java, and I 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 gai
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
s (look at C++).
>
>If Haskell still lacks important features it is no use to
>make a Standard Haskell now.
It certainly so that Standard Haskell is going to need the features being
developed in Research Haskell, as I see it, and some of those features have
been mentioned here: Better (more g
1 - 100 of 117 matches
Mail list logo
