Robert Dodier

I agree the existing built-in Boolean operators are more than a bit of a mess, although given that they are widely used and therefore baked into a lot of existing code, we would have to talk about the consequences of changing them. I am going to guess that the crucial aspect, from a user's point of view, is that and and or are noncommutative and short-circuiting. (I am also guessing that simplifying versus evaluating is less of an issue.) I will assume for now that we can't change the existing noncommutative,...

I see tex(x) produces just x as expected. Looks like TEX-ATOM looks for a REVERSEALIAS property, maybe mathml should do likewise.

Makes sense to me. We can get most or all of the way there by removing the display properties for %MTIMES. :lisp (remprop '%mtimes 'dissym) :lisp (remprop '%mtimes 'dimension) After that, I get: (%i9) '"*"(x, y); (%o9) *(x, y) (%i10) noundisp: true; (%o10) true (%i11) '"*"(x, y); (%o11) '*(x, y) (%i12) stringdisp: true; (%o12) true (%i13) '"*"(x, y); (%o13) '"*"(x, y) Is that it, or is there more that's needed? Would we want to do this for other operators?

For the record, here's what I get with ECL + current Maxima on Linux. In this case it does find mathml.lisp in one of the directories (although, by design, it searches all of the directories to see if there is another file by the same name, so it doesn't stop with the first mathml.lisp that is found). Before the run shown below, I cleared ~/.maxima/binary and ~/.maxima/test-directory-cached (the latter is maintained by the file search code). FILE-EXISTS-P is a Maxima function which calls CL:PROBE-FILE...

makelist completely fails with simp:false

Closing this ticket as fixed by commit [ 9af4f13 ].

Some math functions which are not documented

Pretty-printer slightly incorrect output for 'product(...)