It might help to step back a bit and look at the origins of some of the
conventions.
Mplus mtimes etc happened because it was necessary to distinguish the lisp
functions plus, times etc from their macsyma versions.
Why didn't we use msin, mcos, mtan, but instead $sin, $cos, $tan? No good
reason. We could have used $plus, $times, etc, as an alternative, too.
That was in 1967.
In a system with packages, one can use the same names, but qualified in
different packages.
Hence maxima:+ instead of mplus. Or maybe m:+ could be used. Maybe even
mnoun:sin and mverb:sin.
Why are strings converted into atoms? Because maclisp originally did not
have strings except as the print-names of atoms.
What about case? Macsyma was written initially on a system that did not
support lower case. There was only UPPER CASE. The Common Lisp standard
made this even worse, in my opinion. Some lisps, Allegro and Scieneer among
them, have a mode in which x means x and X means X. To the extent that
maxima source code "fixes" the bad design of ANSI standard CL with respect
to case, this source has to be examined (again) to see if it breaks Allegro.
Right now I generally compile/run Maxima in
Allegro-ANSI-standard-stupid-CASE-mode because I don't want to look at this
stuff (But Doug C fixed it and it ran in bothcase mode at least once
recently).
Operations should have property lists. Strings do not. Should there be a
string data type in Maxima? Probably not a bad idea for documentation
strings, for example.
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu [mailto:maxima-
> bounces at math.utexas.edu] On Behalf Of Robert Dodier
> Sent: Saturday, February 17, 2007 9:37 AM
> To: Douglas Crosher
> Cc: Stavros Macrakis; maxima at math.utexas.edu
> Subject: Re: [Maxima] Q: nounify symbols with a 'm prefix ?
>
> On 2/15/07, Douglas Crosher <dtc at scieneer.com> wrote:
>
> > The use of strings to name operations currently seems problematic
> because
> > 'amperchk (in suprv1.lisp) converts maxima strings into symbol names by
> > effectively downcasing all characters. For example: neither "sin"(1) or
> > or "SIN"(1) are equivalent to sin(1).
> >
> > (%i1) (postfix ("f2"), "f2"(x));
> > (%o1) F2(x)
>
> Trying this with Clisp, GCL, & SBCL, I see x f2 here.
> Is the above result from a case-sensitive Lisp?
>
> > (%i2) "sin"(1);
> > (%o2) SIN(1)
> > (%i3) "SIN"(1);
> > (%o3) SIN(1)
> >
> >
> > Would there be any objections to modifying 'amperchk to use the case
> flipping
> > rules that are used for unquoted names?
> >
> > The proposed change is to 'casify-exploden:
> > (defun casify-exploden (x)
> > (cond ((char= (getcharn x 1) #\&)
> > (cdr (exploden (maybe-invert-string-case (string x)))))
> > (t (exploden x))))
> >
> > With this change:
> >
> > (%i1) (postfix ("f2"), "f2"(x));
> > (%o1) x f2
> > (%i2) "sin"(1);
> > (%o2) .8414709848078965
> > (%i3) "SIN"(1);
> > (%o3) SIN(1)
>
> The proposed change to CASIFY-EXPLODEN is OK by me.
> That said, there are a couple of even-more-obscure points here.
>
> (1) Maxima recognizes "f2"(x) as x f2 because &f2 has the OPR property.
> (The operator-declaring functions postfix prefix etc assign OPR.)
> &sin doesn't have OPR by default -- after (PUTPROP '&SIN '$SIN 'OPR)
> I find "sin"(1) => 0.84147.
>
> (2) The proposed change to CASIFY-EXPLODEN makes "sin" act
> like $SIN instead of %SIN. That's OK by me although it might be
> surprising because sin(1) => sin(1) (i.e. operator is a noun) unless
> the user goes to some trouble to cause it to evaluate numerically.
> There was some discussion recently on the mailing list about the
> "verb implies numerical evaluation" policy.
>
> best
> Robert
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima