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 current draft of the Haskell 1.3 Libraries is now available for public
comment at
ftp://ftp.dcs.st-and.ac.uk/pub/haskell/lib-28-Oct-96.{ps,dvi}
in either PostScript or DVI format (HTML will follow).
The document defines the required libraries for conforming Haskell 1.3
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 and
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
> No implementations of 1.3 are available yet, but we expect all the
> major Haskell systems to conform to the new report soon.
While this strictly true, hbc 0..0 (announced in comp.lang.functional
a few days ago) is almost Haskell 1.3, the only difference is some
minor Prelude and L
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/ha
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: 0424-
We are still in the middle of a bunch of minor last-minute changes.
While the technical aspects of Haskell 1.3 are stable, we're still
fiddling with the prelude and the wording of the report. We've now
set a `final' final release date at May 1. As before, the working
version o
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
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', wh
Philip Wadler writes:
>
> > 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
> 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
> Suggestion: Include among the basic types of Haskell a type `Empty'
> that contains no value except bottom.
Absolutely! But I don't think it should be built in
(unless absolutely necessary).
It looks ugly, but we could say that a data declaration does not
have to have any constructors:
> Suggestion: Include among the basic types of Haskell a type `Empty'
> that contains no value except bottom.
Absolutely! But I don't think it should be built in
(unless absolutely necessary).
It looks ugly, but we could say that a data declaration does not
have to have any constructors:
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
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
I always favoured `=' over `<-', but I don't care much.
-- Lennart
I always favoured `=' over `<-', but I don't care much.
-- Lennart
> 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
> >
First, I am happy to see that Haskell 1.3, with its many valuable
improvements over Haskell 1.2, is finally getting ready,
but I also have a comment:
In the syntax for labeled fields (records) the symbol <- is chosen
as the operator used to associate a label with a value in
constructions
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
If you have looked at the Haskell 1.3 material previously, the main
difference is that all issues regarding records have finally been
resolved. In addition, a number of smaller changes have been made:
`module M' is used in export lists instead of `M..'
The text of the new Prel
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
t get the mail I
responded to, I CC this to the whole mailing list. Sorry, for any
duplicates.
---
Date: Sat, 30 Sep 1995 10:09:08 -0700
From: [EMAIL PROTECTED] (Jeff Prothero)
To: [EMAIL PROTECTED]
Subject: Re: Haskell 1.3: modules & module categories
odule will benefit significantly from the addition of
records (and may well benefit from the addition of strictness
annotations).
We could omit LibTime from Haskell 1.3 and produce Haskell 1.4
sometime next year with records and LibTime - but we'd rather
get all the changes over with in one
Date: Mon, 2 Oct 1995 05:53:44 -0400
Reply-To: [EMAIL PROTECTED]
From: Manuel Chakravarty <[EMAIL PROTECTED]>
> To me, one of the most regrettable characteristics of
> the Algolic family of languages is the tendency of the
> compiler to turn into a giant black box of faciliti
> > 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
Has the Ada solution been properly considered? What I really like about
Ada packages is that you have `with' and `use' as separate operations
(on namespaces). Typical (simplified) examples are:
Put_Line ("Foo."); -- won't work
with Text_Io; Text_Io.Put_Line ("Foo."); -- will wor
> To me, one of the most regrettable characteristics of
> the Algolic family of languages is the tendency of the
> compiler to turn into a giant black box of facilities
> open only to an elite minority of compiler hackers, which
> then begins inexorably sucking the entire programming
> support en
If you could email me the piece of code you are having this
problem, I can look at it and try to see what is wrong.
-- Ming
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 co
JL writes,
A formal treatment of parametricity in the presence of overloading
has not been written up (Eric Meijer has talked of doing so). The
problem with writing it up is that it's too simple: it reduces to a
single observation, namely that the parametricity theorem coming
from
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
7;t like neither 'newtype' nor the records of Haskell 1.3. Both mean a
lot of syntax with little semantics. Even if Mark's ideas seem premature at
this stage it's worth working on them and not introducing some bad syntax
to be withdrawn from the language later. Removing even the wors
The proposed change should not break too much code. The `.' is only
treated specially after a constructor. This will break:
tstpatp9= (P_cons P_write.P_cons P_read) P_empty_list
because of the P in P_write but this will be fine:
proc_emulator f = prm_em.f
Since constructors appear r
I think that the following points have emerged from the recent discussion
about the proposed newtype declaration:
1) Pattern matching against strict constructors will result in
functions which are strict in the annotated constructor argument. For
example:
data T = A !Int
I just had a look in the proposed changes for Haskell 1.3 again, being
stuck in what I was otherwise trying to do, (more of that later maybe)
when I found the Qualified names:
> Qualified names are defined in the lexical syntax. Thus,
> `Foo.a' and `Foo . a' are quit
Phil says:
| I think its vital that users know how to declare a new isomorphic
| datatype; it is not vital that they understand strictness declarations.
| Hence, I favor that
|
| newtype Age = Age Int
| data Age = Age !Int
|
| be synonyms, but that both syntaxes exist.
|
| This i
Hi all,
I'd like to make a few comments on the proposal for simple records in
Haskell 1.3.
* The possibility of having polymorphic field types has been left out
of the proposal. Polymorphic field types essentially bring second
order polymorphism into the language, by allowing fun
On Wed, 13 Sep 1995 [EMAIL PROTECTED] wrote:
> Well, I'm glad to see I provoked some discussion!
...
> Why should foo evaluate its argument? It sounds to me like
> Lennart is right, and I should not have let Simon lead me astray!
...
> This is assuming I have understood Lennart correctly, and
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 "rea
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
|
class (MinVal a, MaxVal a)=>Bounded a
>
> instance Bounded T where
>maxVal = T3
>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 t
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 seman
* 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
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 them
s just a
> strict data constructor, then it *is* strict in n.
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
On Tue, 12 Sep 1995, Simon L Peyton Jones wrote:
>
>
> Phil writes:
>
> | Make newtype equivalent to a datatype with one strict constructor.
> | Smaller language, more equivalences, simpler semantics, simpler
> | implementation. An all around win!
>
> I believe it would be a mistake to d
In a recent message Phil Wadler argues:
> ...
> Make newtype equivalent to a datatype with one strict constructor.
> Smaller language, more equivalences, simpler semantics, simpler
> implementation. An all around win!
I strongly agree with Phil and suggest that because of the equivalences
the
Simon offers a compelling reason to make newtype distinct from a strict
datatype with one constructor. And a semantics to boot! I withdraw my
objection. -- P
PS. The informal explanation might be modified to explain why
newtype must be distinct from a strict datatype.
strict datatype
Phil writes:
| By the way, with `newtype', what is the intended meaning of
|
| case undefined of Foo _ -> True ?
|
| I cannot tell from the summary on the WWW page. Defining `newtype'
| in terms of `datatype' and strictness avoids any ambiguity here.
|
| Make newtype equivalent to a
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 la
To the Haskell 1.3 committee,
Two choices in the design of Haskell are:
Should products be lifted?
Should functions be lifted?
Currently, the answer to the first is yes, and to the second is no.
This is ad hoc in the extreme, and I am severely embarrassed that I did
not
ction 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
ttee. 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
I cannot agree here. Functions are not members of the equality class either,
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 of these
Presenting Haskell 1.3
Haskell is a general purpose, purely functional programming language
incorporating many recent innovations in programming language
research, including higher-order functions, non-strict semantics,
static polymorphic typing, user-defined algebraic datatypes,
pattern
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
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]
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 :-( -
most programmers most of the basic I/O functionality
they need.
The definition has been implemented in the Glasgow Haskell compiler,
and the new version should be released before the end of the year.
Unless major problems are identified, we intend this to be the final
definition of I/O for Haskell 1.3.
Some quick comments on the Haskell 1.3 proposal.
(1) In the design of Haskell 1.0, the type IOError was a bit of a
guess. It wasn't clear whether it defined too many or too few error
classes; it might even have been better to just replace IOError by type
string. By now, we have
, but in any case by OCTOBER 16,
to
[EMAIL PROTECTED]
If you send a comment we will log it at URL
http://www.cl.cam.ac.uk/users/adg/IO-Comments/io-comments.html
Thanks for your help,
Andy Gordon (for Haskell 1.3 Committee)
Phone: (+44) 223 334411University of Cambridge
Recently David Goblirsch asked the following on the Haskell
mailing list:
>What is the status of the Haskell 1.3 and pH efforts announced in this
>group several months ago? Are there separate mailing lists for these
>efforts?
pH development has been continuing both at MIT (in my g
David Goblirsch writes:
> What is the status of the Haskell 1.3 and pH efforts announced in this
> group several months ago?
We're considering a concrete proposal for Haskell 1.3 I/O at the moment.
We plan to make this public once the committee has had time to comment.
I haven'
What is the status of the Haskell 1.3 and pH efforts announced in this
group several months ago? Are there separate mailing lists for these
efforts?
david goblirsch
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
To go back to the debate on instances, here is a concrete proposal for handling
instances in Haskell 1.3:
1) A C-T instance can be defined in any module in which C and T are in scope.
2) A C-T instance defined in module M is in scope in every module which
imports from M, directly or
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 Haske
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 the
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
> How about removing the `where' from `module...where' and
> `interface...where' ...
>
> The reason we used the "module...where" convention is to allow for
> multiple modules to be included in one "file". Your proposal is
> workable, but requires saying something extra about what terminate
A couple of miniscule suggestions for Haskell 1.3:
How about removing the `where' from `module...where' and `interface...where'
so that these become ordinary topdecls like the rest. This would mean that
the convention about topdecls not having to be indented would no lo
How about removing the `where' from `module...where' and
`interface...where' so that these become ordinary topdecls like
the rest. This would mean that the convention about topdecls
not having to be indented would no longer be an ugly exception,
it would be more consistent with implici
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
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.
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 by the
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
nonte
84 matches
Mail list logo
