aldor build fails

[Ralf Hemmecke]

Commit 92d33b9bf046eb33c00d6614cbd3bc822732714c failed with the build of
libaldor.al. The problem seems to be the function name Pi in
MathematicalSymbols.

When I change for debugging in src/interp/ax.boot to

axOpTran(name) ==
FORMAT(true,'"axOpTran [~S]~%", name)
ATOM name =>
name = 'elt => 'apply
name = "setelt!" => "set!"
name = 'SEGMENT => ".."
name = 1 => '_1
name = 0 => '_0
name
opOf name = 'Zero => '_0
opOf name = 'One => '_1
error '"bad op name"

then

)lisp (|makeAxExportForm| "UnusedArgument" (list '|MathematicalSymbols|))

results in

(1) -> )lisp (|makeAxExportForm| "UnusedArgument" (list
'|MathematicalSymbols|))
CONSTRUCTOR: [(|MathematicalSymbols|)]
axOpTran [|newGreek|]
axOpTran [|resetNewGreek|]
axOpTran [|partial|]
axOpTran [|alpha|]
axOpTran [|beta|]
axOpTran [|gamma|]
axOpTran [|delta|]
axOpTran [|epsilon|]
axOpTran [|zeta|]
axOpTran [|eta|]
axOpTran [|theta|]
axOpTran [|iota|]
axOpTran [|kappa|]
axOpTran [|lambda|]
axOpTran [|mu|]
axOpTran [|nu|]
axOpTran [|xi|]
axOpTran [|omicron|]
axOpTran [|pi|]
axOpTran [|rho|]
axOpTran [|sigma|]
axOpTran [|tau|]
axOpTran [|upsilon|]
axOpTran [|phi|]
axOpTran [|chi|]
axOpTran [|psi|]
axOpTran [|omega|]
axOpTran [|Alpha|]
axOpTran [|Beta|]
axOpTran [|Gamma|]
axOpTran [|Delta|]
axOpTran [|Epsilon|]
axOpTran [|Zeta|]
axOpTran [|Eta|]
axOpTran [|Theta|]
axOpTran [|Iota|]
axOpTran [|Kappa|]
axOpTran [|Lambda|]
axOpTran [|Mu|]
axOpTran [|Nu|]
axOpTran [|Xi|]
axOpTran [|Omicron|]
axOpTran [(|Pi|)]

>> Error detected within library code:
bad op name


Well, there is certainly a reason why |Pi| gives these extra
parentheses, but I do not know what to do here. My guess is that the
other problem will be |Sigma|. Perhaps it interferes with operators that
we already have for OutputForm. I have, however no simple idea how to
trace this further.

Any ideas?

Ralf

[Waldek Hebisch]

On Wed, Nov 29, 2023 at 10:05:41AM +0100, Ralf Hemmecke wrote:
> Commit 92d33b9bf046eb33c00d6614cbd3bc822732714c failed with the build of
> libaldor.al. The problem seems to be the function name Pi in
> MathematicalSymbols.
>

> then
>
> )lisp (|makeAxExportForm| "UnusedArgument" (list '|MathematicalSymbols|))
>
> results in

<snip>

>
> axOpTran [(|Pi|)]
>
> >> Error detected within library code:
> bad op name
>
>
> Well, there is certainly a reason why |Pi| gives these extra parentheses,
> but I do not know what to do here. My guess is that the other problem will
> be |Sigma|. Perhaps it interferes with operators that we already have for
> OutputForm. I have, however no simple idea how to trace this further.

This is a name clash: Pi is a type and for that reasons gets parentheses
around. Interpreter somewhat copes with this:

(7) -> )expose MATHSYM
(7) -> Pi

(7) Pi
Type: Type
(8) -> Pi()

(8) Π
Type: Symbol
but this is really not supported and may cause trouble in many
places.

So we need to rename something. Either type Pi to say HackPi or
function Pi to say Pi_sym. Probably the first, so Pi as type
name is quite intrusive.

--
Waldek Hebisch

[Ralf Hemmecke]

>> Well, there is certainly a reason why |Pi| gives these extra parentheses,
>> but I do not know what to do here.

> This is a name clash: Pi is a type and for that reasons gets parentheses
> around.

Oh, uh, so my suggestion with staying with the convention was not so
bad, after all.

> Interpreter somewhat copes with this:
>
> (7) -> )expose MATHSYM
> (7) -> Pi
>
> (7) Pi
> Type: Type
> (8) -> Pi()
>
> (8) Π
> Type: Symbol
> but this is really not supported and may cause trouble in many
> places.

Clear.
Different from Aldor, FriCAS does not distinguish between constants of
type X, i.e.

foo: Integer := 1

and nullary functions

foo(): Integer == -1

So I am surprised that (7) and (8) from above seem to give something
different. However, due to the fact that the type Pi is defined as

https://github.com/fricas/fricas/blob/master/src/algebra/expr.spad#L1079

Pi() : Exports == Implementation where ...

users have to learn another convention (that types behave more like
constants than ordinary nullary functions).

> So we need to rename something. Either type Pi to say HackPi or
> function Pi to say Pi_sym. Probably the first, so Pi as type
> name is quite intrusive.

My wish is/was clear. Lower case initial letter for any ordinary
function, capital initial letter only for constructors and no exceptions.

But if you insist on leaving MathematicalSymbols as is, then I can live
with renaming the type Pi to HackPi.

Ralf