On 10-Jun-1998, Hans Aberg <[EMAIL PROTECTED]> wrote:
> 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.
>
>
On 10-Jun-1998, Hans Aberg <[EMAIL PROTECTED]> wrote:
> I think that experts on implementing lazy languages can tell you about
> the problems of implementing C++ "zero-overhead" exceptions (though
> logically equivalent to an exception monad) into a lazy language like
> Haskell.
There's little
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 anothe
At 12:35 +0200 98/06/10, Jerzy Karczmarczuk wrote:
>Now, I do not understand that. Certainly one may say that *all* imperative
>constructs are more general than "ordinary" function returns (trivial
>Monad...), and in particular with the 'C' longjump you may do horrible
>things, but if the environm
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
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.
Han
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.
