Help me, please!
I'm trying to install the binary distribution of happy 1.5 on SunOS 5.5.1.
I've done: ./configure --prefix=/usr/local/ghc-3.02
and it seems OK.
Now I do: make install SHELL=/usr/local/bin/bash
and make outputs a string of commands that look perfectly reasonable.
However,
I have noted that C++ exceptions (Exception(a), where a is any piece of
data) can be used to implement dynamic versions of C++ constructs such as
``return'' and ``break'' (because I have done it).
So exceptions are certainly more general than function returns, at least
in this context.
x= 1/0 - NaN
(I guess the - is supposed to be a --)
Actually, IEC 559 (a.k.a. IEEE 754, commonly referred to as 'IEEE
floating point') specifies that 1 floating point divided by (positive) 0
shall have the 'continuation value' of *positive infinity*, and (if
trapping is off) one shall record
On Tue, 9 Jun 1998, Mariano Suarez Alvarez wrote:
In a typed language, a function *cannot* be applied to something outside
its domain. That's the whole point!
That represents a certain degree of idealisation though? E.g., sqrt _as a
(single valued) mathematical function_ has domain R^{=0}.
Hans Aberg writes:
I have noted that C++ exceptions (Exception(a), where a is any piece of
data) can be used to implement dynamic versions of C++ constructs such as
``return'' and ``break'' (because I have done it).
So exceptions are certainly more general than function returns, at
Alastair Reid has been very quiet, so I'll pipe up for him.
Here's a reasonable design for exceptions in Haskell:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
* raise :: String - a
* handle :: (String - IO a) - IO a - IO a
I'd be interested to know what people think of this.
I like the trick of handle being in the IO monad to avoid
problems with evaluation order. As usual though, it can be a
high price to pay if all you wanted was a little local
I'd be interested to know what people think of this.
Here's a reasonable design for exceptions in Haskell:
...
The neat thing about this is that the exceptions can
be *raised* in arbitrary purely functional code, without
violating referential transparency. The question of
which exception
Thats a wonderful idea. With that it will be so much easier to write
robust code without bloating the code with error checks.
I've always been annoyed that I couldn't trap arbitrary errors, say to
close down the application cleanly.
Now, we only need extendible data types, and then we have an
I have noted that C++ exceptions (Exception(a), where a is any piece
of data) can be used to implement dynamic versions of C++ constructs
such as ``return'' and ``break'' (because I have done it).
So exceptions are certainly more general than function returns, at
least in this
Simon and Alastair,
This sounds like what I wanted. Just a few questions:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
OR it can be a set of exceptional values.
At 01:09 +1000 98/06/11, Fergus Henderson wrote:
There's little point trying to implement C++-like so-called "zero-overhead"
exceptions in any language with garbage collection. It would
probably result in a performance loss.
This is good indeed.
But I think the C++ exceptions have another
On Wed, 10 Jun 1998, Simon L Peyton Jones wrote:
| We're implementing an experimental version of this
| in GHC, integrated with the IO monad exceptions, so that
|
| handle :: (IOError - IO a) - IO a - IO a
|
| and we add an extra constructor (UserError String) to the
| IOError type
It's nice to have SOME way of handling exceptions, but...
The implementation does not keep sets of exceptional values,
of course. It simply propagates the first one it trips
over to the nearest enclosing handler.
One argument that can be made in favour of a generalised more IEEE-like
At 2:40 pm 10/6/98, Simon L Peyton Jones wrote:
Here's a reasonable design for exceptions in Haskell:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
OR it can be a
On Thu, 11 Jun 1998, Fergus Henderson wrote:
It would make debugging easier if the exception picked was consistent
accross implementations. It doesn't matter which one, but it does matter
that it is the same. (maybe you require that Exceptions implement Ord,
or sort based on the
16 matches
Mail list logo
