[
Lists Home |
Date Index |
Thread Index
]
I think we are going off-topic for the list.
> > Throwing it back, so to speak - cool!
> >
> > <snip good stuff/>
> >
> > Thanks for taking the time to write such a detailed reply!
>
> Wierd languages are my hobby ;-)
Would be mine too, if I had a C/S background. Ever heard of BETA?
http://www.mjolner.com . Pretty much dead by now, but interesting.
> > The question is: at what cost does on get efficient exception handling?
> > Are continuation languages slower and/or more complex to implement?
>
> The main cost is that you can't use a stack, it has to be a linked list
> instead, with garbage collection.
Looks like you always pay for what you get.
> Well C kind of had a limited form of continuations in setjmp / longjmp...
> just you could mess the stack up with them. You could only ever jump *up* the
> stack, never down, so you could use them to escape to an error handler but
> they couldn't handle such continuation tricks as nondeterminstic algorithms.
Is that legal in C++ too? Never used it - not being a C/C++ specialist.
> Nondeterministic algorithms, I hear you ask? Well...
>
> Imagine a function like 'square root'. Mathematicall, every number has two
> square roots; 2*2 = 4, (-2)*(-2)=4, so sqrt(4) = 2 and -2.
>
> Needless to say, you can't really express that easily in software. You could
> have sqrt return a list of two numbers, but that's missing the point in a way.
>
> What you could do, in C for example, is to have the sqrt function call fork()
> and return a different number in each fork. If this were part of an equation
> solver, you would have to try both possible return values every time you got
> to sqrt() or a similar function; some branches would return no solutions and
> thus would give up, others would yield results.
>
> But doing it with lots of forks can consume an exponentially growing number
> of OS resources. What you can do instead is to, every time you encounter a
> sqrt(), preserve a 'retry continuation' in a global list that, if invoked,
> will restart execution from the sqrt but return the negative root. Having
> saved that continuation, return the positive root.
>
> Then you can define the 'abort' function (called when a line of enquiry
> fails) to pop the top off of the list of retry continuations and invoke it.
>
> When the computation returns with an actual value, if there are still untried
> retry continuations, then there may be more solutions available, so you can
> output the solution you have found and try another retry.
>
> In a way, you are modelling the many worlds interpretation of quantum
> mechanics...
I can see that this make it simpler to iterate over the set of solutions
for your problem. But that may depend on the problem. In other cases
a simple list of (complex number) solutions may be better.
You could probably model this also with classes that have an interator
over a result set, preserving state of which result was last used.
> Don't get me started on how different programming languages model time! C has
> time implicitly handled by an advancing instruction pointer and a mutable
> world-state, whereas Concurrent Clean programs model time by having a World
> object and methods such as 'sleep' that accepts a World and a number of
> seconds, and returns a World like the one passed in except that many seconds
> have passed...
Reminds me of Simula. Back when I was studying Physics (which I never practised
professionally), I used to spend some time in the library reading through
C/S books and magazines, since somehow that fascinated me.
So, one day I came across a book about Simula, and this was actually
my first real intro into a programming language (except for a basic
Fortran course).
Karl
|
