Re: Ada functions versus arrays (i.e. () vs [] )

[firth@sei.cmu.edu (Robert Firth)]

In article <608@software.software.org> blakemor@software.org (Alex Blakemore) writes:

>I agree that side effects are best avoided - they definitely mess up this
>scheme.  I assume the language designers left them in for the 
>very few times when they are justifiable (e.g. next_random_number).
>Quite possibly a language design error forced on them by C programmers :-)

As I recall, we left them in for the same reason Algol-60 did: it is
impossible to rule out the bad uses without also ruling out the good
ones.  It is the responsibility of the programmer not to employ the
bad uses.

Let me give you a couple of examples that fall within the present
discussion.  You have to implement a mapping of some kind - call
it M.  The user then writes M(I) to apply the mapping to object I
in the domain of M.

Initially, this domain is small and compact, so you implement M
as an array.  During subsequent maintenance, it becomes rather
large, so you implement M as a virtual array, ie an array that is
held on backing store.  M is now a function that - shock! horror!
keeps an internal buffer cache and does some hairy I/O periodically.

This is a side effect that any rule would prohibit.  But it is a
good one: M appears to the user as a pure function; its implementation
is of no consequence and should not be visible to the invoker.  To
force M to be rewritten as a procedure pollutes the use context with
information about the implementation.

As a second example, consider a dictionary used by a spelling checker.
There is a function Check(W) that checks whether W is in the dictionary.
Many implementations of this function are adaptive: they use a temporary
cache of some kind that is dynamically reorganised so that words
occurring frequently in the document in question float to the front.
Over a long document, this can substantially speed the checking process.
Again, this is a benign and proper use of side effects within a function.

Robert Firth