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
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
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
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
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
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:
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
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
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
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
I always favoured `=' over `-', but I don't care much.
-- Lennart
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
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
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
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
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
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.
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
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
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
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
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
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
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
* 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
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
`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
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
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
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
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
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
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
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 :-(
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
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
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
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
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.
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
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
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:
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
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
44 matches
Mail list logo