Hi,
>>>>> "S" == S D Mechveliani <[EMAIL PROTECTED]> writes:
S> Concerning 'rapid access' you found in docs - it is hard to
S> believe this access is as fast as in C array - i mean changing
S> X[i] in array X. Because when this change is done fast, it is a
S> side effect, breaks functionality.
if the compiler can be sure that only a single copy of the array is
needed any further, it should be possible in principle instead of
making a modified copy of the array, just to change the old version.
S> I always thought that this is
S> the main cost the functional world pays for the nice functional
S> principles
It should not be necessary to *pay* for it more than perhaps loosing
laziness for a small part of the program. Consider that in the
imperative style you also have to carry copies if you
need different modifications of an array. The questions is how can
the compiler of a functional language be sure that you don't use
different modifications? At least a compiler implementation can
invite the programmer to help by providing an array monad together
with an interface that cuts off the array monad from the rest of the
program (a way to get out of the monad in a secure way).
S> to think of how to avoid indice in the critical
S> parts of the algorithm.
(1) Sometimes you don't want to because you are short on time
and have an algorithm based on indexing available already.
(2) Let's assume that array accesses can be performed in constant
time (which is an unrealistic, but frequently made assumption).
I'm not sure if graph algorithms can always be translated to an
equivalent which has the same asymptotical time complexity without
using marking. If you spend a logarithm, OK.
-----------------------------------------------------------------------------
Christoph Herrmann
E-mail: [EMAIL PROTECTED]
WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
