> I would prefer to take an existing design, so far as it works,
> and use it. Thus the first thing that came to my mind was not
> 'let's make up additional stuff for the Maxima command set.'
> but 'what does common lisp have that we could just import. In
> fact we could name my function f of the previous message, to
> be SUBSEQ. Then the documentation could be "same as Common Lisp
> SUBSEQ"
I agree with the general principle of not reinventing the wheel. In
fact, Last with a second argument (as I proposed) is basically the same
as Common Lisp's last with a second argument (though not exactly). That
said...
Common Lisp was designed by a bunch of very smart Lisp people who did a
lot of good work. However, it was designed for professional Lisp
programmers, who have different background knowledge and expectations
from the scientists and engineers who are typical users of Maxima. For
the vast majority of Maxima users, documenting something as "same as
Common Lisp SUBSEQ" would be useless.
For that matter, the semantics of Subseq are I suspect quite foreign to
the expectations of Maxima users. First of all, indexing is zero-based.
I know that many mathematicians promote zero-based indexing, but it
seems to me that one-based remains the norm and it is what Maxima uses.
Suppose s=[1,2,3,4]. Since s[1] is 1, shouldn't subseq(s,1,2) be [1,2]?
In Common Lisp semantics, it is not. In fact, it isn't even [2,3],
because in Common Lisp, subseq(s,m,n) selects element m through the
element *before* element n (so n-m is ht length of the result):
subseq(s,1,1) is the empty sequence. The first two elements of s are
denoted subseq(s,0,2) in Common Lisp. I think most Maxima users would
prefer to stick with s[1..2] or first(s,2) -- or subseq(s,1,2) if we're
going to use the subseq name.
Now let's look at what subseq does on the left-hand side of an
assignment (setf) in Common Lisp. E.g.
s: [a,b,c,d]
t: [w,x,y,z]
subseq(s,1,3) => [b,c]
subseq(t,2,3) => [y]
subseq(s,1,3): subseq(t,2,3) => ???
You might expect an error, since the two are of different lengths. Or
perhaps you expect splicing behavior, that is that the new value of s
will be [a,y,d]. But no. In Common Lisp, the new value of s will be
[a,y,c,d]. I really don't think that's a reasonable result in a Maxima
context (it strikes me as peculiar in a Lisp context, too, but that's
neither here nor there).
So to answer your question, of course I would do something different
from Common Lisp. Maxima users' expectations are *not* set by Common
Lisp, and the design goals of the two languages are very different.
Maxima users are familiar with other languages they use, including
conventional mathematical notation, other symbolic systems (Mathematica,
Maple), and numeric systems (Fortran, Matlab, Java, Perl, Python, Excel
(!), etc.). If we're going to introduce new notations, we should look
at these and other languages as a model, not at Common Lisp.
-s