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
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.
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
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
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
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
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
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]
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
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
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
17 matches
Mail list logo
