#4097 Bad string representation of integers in the first argument of `save`

[Andrii Sokolov]

When save evaluates the filename passed, string representation of integers picks up "." in the end:

(%i1) a : 5;
(%o1)                                  5
(%i2) concat("foo", a, ".lisp");
(%o2)                              foo5.lisp
(%i3) save(concat("foo", a, ".lisp"), a);
(%o3)             /home/andsokol/foo5..lisp
(%i4) filename : concat("foo", a, ".lisp");
(%o4)                              foo5.lisp
(%i5) save(filename, a);
(%o5)              /home/andsokol/foo5.lisp
(%i6) save(concat("foo", a, "oof", ".lisp"), a);
(%o6)            /home/andsokol/foo5.oof.lisp
(%i8) save(string(a), a);
(%o8)                 /home/andsokol/5.
(%i10) save(string(1), a);
(%o10)                /home/andsokol/1.
(%i12) save(string(str), a);
(%o12)                /home/andsokol/str
(%i13) save(string(3.14), a);
(%o13)               /home/andsokol/3.14

Curiously, load does not have this bug

(%i17) load(string(1));

file_search1: 1 not found in file_search_maxima,file_search_lisp.
 -- an error. To debug this try: debugmode(true);

5.46.0 GCL 2.6.12 x86_64-redhat-linux-gnu

[Gunter Königsmann]

If we make string() punt to sconcat() in order to remove string() ideosyncrasies: Would that resolve the problem?

[Stavros Macrakis]

No, the string() idiosyncracies are unrelated.

[Stavros Macrakis]

The problem is that save uses with-maxima-io-syntax, which among other things binds *print-radix* to t. It does this so that the Lisp code outputs integers with a trailing "." to force interpretation as decimal when the code is read in. Unfortunately, since $save is an mspec, the first argument (the filename) is also evaluated in that scope by dsksetup. Pretty easy fix, since dsksetup is only called by $save.

The input radix of Lisp was formerly (very formerly :-) ) 8 (octal) by default, so the "." was useful to ensure correct reading. Since the input radix default is now decimal, binding *print-radix* seems unnecessary.

This is not a problem with $string and sconcat has exactly the same behavior.

Until this is fixed in dskfn, the workaround is to rewrite save(string(...),val) => fn:string(...); save(fn,val).

[Robert Dodier]

Fixed by commit [a1ee2b0]. In save, I moved the evaluation of the filename argument outside WITH-MAXIMA-IO-SYNTAX.