The Haskell 1.3 compiler NHC13 is now available

1996-11-09 Thread Thomas Hallgren at home
Version 0.0 of NHC13, Nearly a Haskell 1.3 Compiler, by Niklas Rojemo, is now available for download from ftp://ftp.cs.chalmers.se/pub/haskell/nhc13 It has the following features - Compiles Haskell 1.3 - Supports Fudgets - Supports several kind of heap profiles

ANNOUNCE: Glasgow Haskell 2.01 release (for Haskell 1.3)

1996-07-26 Thread Simon L Peyton Jones
The Glasgow Haskell Compiler -- version 2.01 We are pleased to announce the first release of the Glasgow Haskell Compiler (GHC, version 2.01) for *Haskell 1.3*. Sources and binaries are freely available by anonymous FTP

Haskell 1.3 - what's it all about?

1996-05-16 Thread Magnus Carlsson
Maybe you have seen some mail lately on this list about something called "Haskell 1.3", and wondered What is this "Haskell 1.3" anyway?, Can I buy it?, or Do I have it? By compiling and running the following two-module Haskell program, you will at least get a

Haskell 1.3 Report is finished!

1996-05-15 Thread peterson-john
The Haskell 1.3 Report is now complete. A web page with the entire report and other related information is at: http://haskell.cs.yale.edu/haskell-report/haskell-report.html This new report adds many new features to Haskell, including monadic I/O, standard libraries, constructor classes, labeled

Status of Haskell 1.3

1996-05-07 Thread peterson-john
The Haskell 1.3 report is nearly done. The text of the report is complete - I'm working on indexing and web pages. We also have an initial cut at the Library Report. If you are interested in seeing the new report on the web, look at http://haskell.cs.yale.edu/haskell-report/haskell

Haskell 1.3

1996-04-22 Thread Frank Christoph
I thought there was an April 19 deadline...? Have there been some last-minute problems? -- Frank Christoph Next Solution Co. Tel: 0424-98-1811 [EMAIL PROTECTED] Fax:

Re: Preliminary Haskell 1.3 report now available

1996-03-08 Thread Fergus Henderson
Thomas Hallgren [EMAIL PROTECTED] writes: In the syntax for labeled fields (records) the symbol - is chosen as the operator used to associate a label with a value in constructions and patterns: [...] According to a committee member, there were no convincing reasons why - was chosen. Other

Re: Haskell 1.3

1996-03-08 Thread Philip Wadler
It looks ugly, but we could say that a data declaration does not have to have any constructors: data Empty = -- Lennart I agree that the best way to fix this is to have a form of data declaration with no constructors, but I'm not keen on the syntax you propose. How about if

Re: Haskell 1.3

1996-03-08 Thread Ron Wichers Schreur
Lennart Augustsson wrote: It looks ugly, but we could say that a data declaration does not have to have any constructors: data Empty = Philip Wadler responded: I'm not keen on the syntax you propose. How about if we allow the rhs of a data declaration to be just `empty', where

Haskell 1.3, monad expressions

1996-03-08 Thread smk
Suggestion: add another form of statement for monad expressions: stmts - ... if exp which is defined for MonadZero as follows: do {if exp ; stmts} = if exp then do {stmts} else zero Based on this, one can define list comprehensions by

Re: Preliminary Haskell 1.3 report now available

1996-03-07 Thread Lennart Augustsson
I always favoured `=' over `-', but I don't care much. -- Lennart

Haskell 1.3

1996-03-07 Thread Philip Wadler
Congratulations to all involved on Haskell 1.3! I especially like the introduction of qualified names and the attendant simplifications. Here are some small suggestions for further improvement. Interfaces ~~ Suggestion: the introduction should draw attention to the fact that interface

Re: Preliminary Haskell 1.3 report now available

1996-03-07 Thread alms
Thomas Hallgren [EMAIL PROTECTED] writes: In the syntax for labeled fields (records) the symbol - is chosen as the operator used to associate a label with a value in constructions and patterns: [...] According to a committee member, there were no convincing reasons why - was

Preliminary Haskell 1.3 report now available

1996-03-06 Thread peterson-john
Announcing a preliminary version of the Haskell 1.3 report. The Haskell 1.3 report is nearly complete. All technical issues appear to be resolved and the report is nearly ready. The report will be finalized April 19. Any comments must be submitted by April 15. We do not anticipate making

Haskell 1.3?

1996-03-05 Thread Tommy Thorn
Quoting from "Introducing Haskell 1.3" (http://www.cs.yale.edu/ HTML/YALE/CS/haskell/haskell13.html): "The final version of the Haskell 1.3 is expected to be complete in January, 1996." Does anyone know what happens? Regards, Tommy -- "When privacy is outlawe

Haskell 1.3 nearly ready

1995-12-12 Thread peterson-john
The Haskell 1.3 effort is nearly complete. Although a new report is not yet complete, all proposed changes to the language as well as the new Prelude are now available for public comment. These documents are available on the web at http://www.cs.yale.edu/HTML/YALE/CS/haskell/haskell13.html

Re: Haskell 1.3: modules module categories

1995-10-02 Thread Johannes Waldmann
With present Haskell modules, it seems that `with' automatically comes with `use' and clutters up your namespace. That's why you sometimes need re-naming when importing. Sorry, I missed that one. Manuel pointed out that with/use is already contained in the `qualified names'-proposal.

Haskell 1.3: modules module categories

1995-09-30 Thread Manuel Chakravarty
Hi! Talking to a friend, who is project manager in a software company, about modules for Haskell, he made two comments that may be of interest to the current discussion. (1) With regard to the idea of 99% hand-written interfaces (just mark everthing that should go into the interface in a

Re: Haskell 1.3 (newtype)

1995-09-19 Thread wadler
Sebastian suggests using some syntax other than pattern matching to express the isomorphism involved in a newtype. I can't see any advantage in this. Further, Simon PJ claims that if someone has written data Age = Age Int foo (Age n) = (n, Age (n+1)) that we want to be able to

Re: Haskell 1.3 (newtype)

1995-09-13 Thread wadler
Well, I'm glad to see I provoked some discussion! Simon writes: Lennart writes: | So if we had | |data Age = Age !Int |foo (Age n) = (n, Age (n+1)) | | it would translate to | |foo (MakeAge n) = (n, seq MakeAge (n+1)) | | [makeAge is the

Re: Haskell 1.3 (newtype)

1995-09-13 Thread Simon L Peyton Jones
Lennart writes: | So if we had | | data Age = Age !Int | foo (Age n) = (n, Age (n+1)) | | it would translate to | | foo (MakeAge n) = (n, seq MakeAge (n+1)) | | [makeAge is the "real" constructor of Age] | | Now, surely, seq does not evaluate its first argument when the

Re: Haskell 1.3 (Bounded;fromEnum;type class synonyms)

1995-09-12 Thread reid
minVal = T1 There was a proposal to make this legal. As far as I know, there's no technical problems here - I guess it just got forgotten about (or the proposer decided that Haskell 1.3 had too many changes in it already!) * Should Bounded be derived from Ord? The Bounded class that w

Re: Haskell 1.3 (newtype)

1995-09-12 Thread Sebastian Hunt
On Tue, 12 Sep 1995, Lennart Augustsson wrote: The posted semantics for strict constructors, illustrated by this example from the Haskell 1.3 post, is to insert seq. data R = R !Int !Int R x y = seq x (seq y (makeR x y)) -- just to show the semantics of R So if we had

Re: Haskell 1.3 (lifted vs unlifted)

1995-09-12 Thread smk
John Hughes mentioned a deficiency of Haskell: OK, so it's not the exponential of a CCC --- but Haskell's tuples aren't the product either, and I note the proposal to change that has fallen by the wayside. and Phil Wadler urged to either lift BOTH products and functions, or none of

Re: Haskell 1.3 (Bounded;fromEnum;type class synonyms)

1995-09-12 Thread Sverker Nilsson
* Playing around, learning the basics, reinventing the wheel... I had been playing around with some classes, primarily to learn for myself, being new to the Haskell language, when I got the report on the current status of Haskell 1.3. The classes I had played with had some similarities to some

Re: Haskell 1.3 (newtype)

1995-09-12 Thread wadler
The design of newtype appears to me incorrect. The WWW page says that declaring newtype Foo = Foo Int is distinct from declaring data Foo = Foo !Int (where ! is a strictness annotation) because the former gives case Foo undefined of Foo _ - True = True and the

Re: Haskell 1.3

1995-09-11 Thread John Launchbury
`Introducing Haskell 1.3', Every data type, except -, is a member of the Data class. In other words, in Haskell 1.3 FUNCTIONS ARE NOT FIRST-CLASS CITIZENS I cannot agree here. Functions are not members of the equality class either, but that does not demote them to second class

Re: Haskell 1.3

1995-09-11 Thread John Hughes
types. And this is where I disagree with the committee. To quote `Introducing Haskell 1.3', Every data type, except -, is a member of the Data class. In other words, in Haskell 1.3 FUNCTIONS ARE NOT FIRST-CLASS CITIZENS To design a functional language today, in which this is true

Haskell 1.3 Prelude changes

1995-09-09 Thread John C. Peterson
Changes to the Haskell 1.3 Prelude The following changes have been proposed (or accepted) for Haskell 1.3. * Reorganize the Ord class * Add succ and diff to Enum * Add new class "Bounded" * Add strictness annotation to Complex

Changes in Haskell 1.3

1995-09-09 Thread John C. Peterson
Introducing Haskell 1.3 This new version of the Haskell Report adds many new features to the Haskell language. In the five years since Haskell has been available to the functional programming community, Haskell programmers have requested a number of new language features. Most

Re: Haskell 1.3 Draft Report

1995-05-19 Thread David Bakin
Hi. For the TeX-impaired, is there any chance of sticking postscript files on an ftp site? Thanks! -- Dave A draft of the Haskell 1.3 report is available by FTP from ftp.dcs.glasgow.ac.uk [130.209.240.50] in pub/haskell/report/draft-report-1.3.dvi.gz [Report] pub/haskell

Haskell 1.3 Draft Report

1995-05-19 Thread kh
A draft of the Haskell 1.3 report is available by FTP from ftp.dcs.glasgow.ac.uk [130.209.240.50] in pub/haskell/report/draft-report-1.3.dvi.gz [Report] pub/haskell/report/draft-libraries-1.3.dvi.gz [Libraries] Highlights include: Monadic I/O A split

Prelude and Library Issues in Haskell 1.3

1995-02-09 Thread Alastair Reid
Currently, the Haskell language does not mention any libraries or facilities for using them. The standard prelude is meant to serve as a library but it lacks many important features. All Haskell implementations have begun to haphazardly include various libraries. However, these libraries have

Re: New Haskell 1.3 I/O Definition

1994-12-16 Thread Will Partain
Kevin Hammond writes: "We have attempted ... to consider portability issues very carefully." But we may have missed something. For example, I don't think anyone has actually *seen* a "Win32 Programmer's Reference Manual" -- i.e., the programming interface for most of the world's computers :-(

Re: Haskell 1.3

1993-11-23 Thread kh
Ian Holyer writes: To go back to the debate on instances, here is a concrete proposal for handling instances in Haskell 1.3: I can see what you're doing, but I dislike the idea of no longer being able to define instances local to a module. This limits my choice of class and type names

Haskell 1.3

1993-11-11 Thread ian
Here is another suggestion for Haskell 1.3. The current restriction that instances must be defined either in the class module or the type module is painful. If a module defining an abstract type contains a class definition, it may be impossible to define an instance in the module defining

Re: Haskell 1.3 [instances]

1993-11-11 Thread Will Partain
Ian Holyer writes: The current restriction that instances must be defined either in the class module or the type module is painful. LISTEN TO THIS MAN! Trying to use the module system in (what we imagined to be) a sensible way on the Glasgow Haskell compiler [which is written in

Wishlist for Haskell 1.3

1993-10-27 Thread Van Snyder
I would like to put two rather prosaic things into Haskell 1.3. They almost fall into the "syntactic sugar" class, but they would make my life easier. The first is that I would like to see arrays be a class instead of whatever they are. I wanted to construct a subclass of arrays

Haskell 1.3 (n+k patterns)

1993-10-12 Thread John Launchbury
I feel the need to be inflamatory: I believe n+k should go. There are lots of good reasons why they should go, of course. The question is: are there any good reasons why they should stay? My understanding is that the only reason they are advocated is that they make teaching induction easier.

Re: Haskell 1.3 (n+k patterns)

1993-10-12 Thread Lennart Augustsson
jl writes: I feel the need to be inflamatory: I believe n+k should go. Again, I agree completely. Let's get rid of this horrible wart once and for all. It's a special case that makes the language more difficult to explain and implement. I've hardly seen any programs using it so I don't

Haskell 1.3

1993-10-12 Thread ian
I hope that Haskell 1.3 will clean up the report, and maybe even the language, and not just add features. Recent work at Bristol has raised the following points; I apologise for any which are well known already. o The layout rule that says that an implicit block can be terminated

Re: Defining Haskell 1.3 - Committee volunteers wanted

1993-09-27 Thread wadler
Three cheers for Brian, for his work to keep Haskell a living and growing entity. I propose as a touchstone for 1.3 that they should only look at extensions that have been incorporated in one or more Haskell implementations. Hence the following are all good candidates for 1.3's scrutiny:

Defining Haskell 1.3 - Committee volunteers wanted

1993-09-20 Thread Brian Boutel
ambitious, and produce a definition of Haskell 1.3. Topics on the agenda include: Monadic IO Strict data constructors Records (naming field components) Prelude hacking Standardizing annotation syntax We think the best way to proceed is to call for volunteers

Re: Defining Haskell 1.3 - Committee volunteers wanted

1993-09-19 Thread A.
I'm probably not expert enough to be on the committee. However, I have a suggestion. The syntax description of Haskell is hard to read. One reason is that one repeatedly has to look in the index to find out where some nonterminal is defined. If the page number of the definition of each