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 Lennart Augustsson
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:

Re: Haskell 1.3

1996-03-08 Thread Magnus Carlsson
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 I'm not keen on

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

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.

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
Dear Sverker Nilsson, Thanks for your message - interesting ideas and interesting questions. [I'm copying the reply to the Haskell mailing list in case anyone wishes to support your suggestions.] First, one of Haskell's annoying features is that the scope of a type variable in a type

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 Simon L Peyton Jones
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

Re: Haskell 1.3 (lifted vs unlifted)

1995-09-12 Thread wadler
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

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
I would like to respond to John's note. My response is largely positive, though I disagree with a couple of points. However, it is an independent question whether or not strictness annotations should be applicable to function types. And this is where I disagree with the committee. To quote

Re: Haskell 1.3

1995-09-11 Thread John Hughes
Let me make one more attempt to persuade the committee to change the way strictness annotations are to be introduced. First of all, let's recognise that strictness annotations and the seq function are of enormous importance; this is a vital extension to the language, not a small detail. Space

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]

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, and

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

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