Q: nounify symbols with a 'm prefix ?



Robert Dodier wrote:
> 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?

This issue is repeatable here on the unmodified maxima CVS source even on
CLISP, but does only show up the first time it is executed:

CLISP:
(%i1) (postfix ("f2"), "f2"(x));
(%o1)                                F2(x)
(%i2) (postfix ("f2"), "f2"(x));
(%o2)                                x f2

>> 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))))
...

> 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.

Yes, once &F2 has the 'OPR property a different path is taken through
'AMPERCHK and the case is preserved.

> (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.

Thank you for pointing this out - it does appear inconsistent.  One
possibility would be to call 'GETALIAS in 'AMPERCHK. For example:

(defmfun amperchk (name)
   (if (char= (getcharn name 1) #\&)
       (getalias (or (get name 'opr)
		    (implode (cons #\$ (casify-exploden name)))))
       name))

With these changes:
"sin"(1)    => sin(1)
"abs"(1)    => 1
"SIN"(1)    => SIN(1)
"ABS"(1)    => ABS(1)
?print(nounify("sin")) => %SIN
?print(verbify("sin")) => $SIN
?print(nounify("abs")) => %MABS
?print(verbify("abs")) => MABS

Regards
Douglas Crosher