The lack of side effects is for you of interest for parallel computing or just for theoretical studies?

Much more egoistic: It's for ease of debugging ;-) It is easier to analyze a program, and consequently to debug it, if you don't have to care about state.

First of all I have to say that LISP doesn't normally use arrays, the normal approach are linked lists, replacing an element is simply done by manipulating the chain, so no big copies needed.

It depends what you want to do. All LISPs I came accross so far provide arrays (for instance, using make-array in Common LISP), and whether I use an array or a linked list or a property list or what else, depends on what I want to do with it. This is not different from Perl (or Ruby, or nearly anything else).

Then, the default for passing arrays in perl is by copy, so calling f(@$ar) will not effect the original array.

Actually, Perl passes by reference, i.e. f *can* modify the original array; only that most people write their functions in a way that they just affect a copy - but the copying happens at the called side, not at the caller side.

If you want linked lists and FP mechanisms I strongly recommend reading "Higher Order Perl"!

Interesting reading indeed. Also has a small chapter about delayed evaluation.

The functionality of splice may be of further interest for you.

Not really. Although it does aggreagate update, it (naturally, since it uses eager evaluation) has to make a copy of the whole array....