David Carlisle wrote:
I don't have that luxury,
Sometimes (like here) it's tempting (or even from a performance point of
view perhaps a requirement) to say you need an imperative assignment
with side effects and guaranteed execution order, but in a strong sense
that is not true. That's Turing's (standing on Church and Godel and
others) main insight: Any machine (or programming language) that can
compute anything intersting at all can compute exactly the same
algorithms as every other one. So no algorithm _requires_ state to be
mantained as a side effect, it's _always_ possible to rewrite the
algorithm so that any state required is explictly passed from function
to function.
Nice to see Turing coming along here. You have a clear point and you are
right, of course. I just don't often look at the language in such a way.
Now it may be that in practical cases the amount of state
that would be required to be passed is large and you don't want to pass
it through a function call interface, but well, that's the job of the
optimising complier to sort out. Saying that the _end user_ has to
rewrite the algorithm in an imperative style in order to get an
effective computation is just so 1960's:-)
and man, do I love the sixties!
But what I really meant was: if you have some function library, it's
just easier to have something like "get-uuid()", instead of
"get-uuid(get-uuid(get-uuid()))". But I understand (I think) your point
in how it can be done with functional programming. I've just lingered
too long in the imperative world and sometimes I just can't resist to
try to bridge the two.
Thanks for your insights,
Cheers,
-- Abel
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--