matrix implementation, was: patch for $addrow needed?



> I'm quite optimistic that we can clean up messy stuff
> in Maxima. We have a lot of talented developers and
> there are a lot of interested outsiders.

I certainly agree that it would be a *good thing* to clean up messy
stuff. Some of that is fairly straightforward -- e.g. make sure that
all functions treat CREs and aggregates (lists and sets) in reasonable
ways.  In this particular case, the issue is not just implementation;
it is mostly specification.

> There are some simple things we can do right away.
> Specifically addrow should copy its input data.
> There may be a couple of other functions which can be
> fixed in a similar way.

That may well be a reasonable specification.  But I disagree with your
characterization of it as a "fix", as though the current behavior were
a bug.  The proposed behavior is different, and perhaps better, but
not a "fix".

> > I am not sure what the right answer is, but I hope I've shown that
> > "just" making everything immutable, or "just" using deep value copies
> > rather than reference
>
> I haven't advocated immutable objects, and I don't
> think deep copy implies immutable, so I don't understand
> why you're arguing against immutable objects.

If I understood the earlier emails correctly, there were two
alternatives being proposed: immutability and deep-copy.  I did not
say that one implies the other.  In fact, quite the contrary: I said
that immutability would make deep-copy unnecessary, and vice versa.

The goal was apparently to avoid the situation where assigning to part
of one list or array changes the value of another list or array
(anti-aliasing).  My main problem with that is that side-effect
semantics may be *desirable*, at least for some applications.  My
secondary problem is that it is not clear how you would implement both
mutable arrays (where you can modify elements or subarrays) and
anti-aliasing in an efficient way.

> As an implementation detail, I would certainly want to
> optimize copy semantics so that the copying happens only
> when needed. This addresses efficiency problems
> to some extent.

Well, let's hear your proposals for (a) the user-visible semantics you
want and (b) the efficient implementation mechanism to support them.

            -s