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 environment trapping is just used to implement "return",
>then I believe that all that can be "functionalized" through continuations.
This is a statement similar to that of "all Turing machines are
equivalent". However, that equivalence does not preserve the structure one
wants to describe, and so the real implementation problem (taking that
structure into account) is unsolved.
If one wants to use C++ exceptions to make a dynamic return, one writes
try { ... throw Return a; ... }
catch (Return& x) { ... }
and it is possible to do away with the C++ construct "return" altogether if
one only has the exception construct (disregarding the fact that this
becomes slow).
Vice versa, suppose that one has the access to a monad construct, then
one just makes an exception monad, which will make functions to return
monad exception values, and from the logical point this will compute
exactly as in C++ (even though in standard functional implementations, the
exception value propagates through the code excepted, instead of just being
killed off as in C++).
So in that situation, exceptions can be derived from function returns
plus monads.
>With -- quite functional -- call/cc in Scheme (or other mechanisms
>dealing with first class continuations) you may implement even more exotic
>control constructs, coroutines, asynchronous message dispatching, etc.
>They are still functional, but they include the hidden state transformation.
The word "functional" needs some interpretation in a computer context,
but I think that those constructs are not to be considered functional, but
imperative constructs which have been added ad hoc (that is, there is no
known general theory justifying it) in order to augment the otherwise
purely functional language.
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.
Hans Aberg
* Email: Hans Aberg <mailto:[EMAIL PROTECTED]>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
