Convertion of types to OutputFrom

[Waldek Hebisch]

Currently coercion of types to OutputForm is fake: it uses
an interpreter function to produce a string and this string
serves as OutputForm. This is problematic because:
- resulting OutputForm has no structure
- interpreter has limited understanding of types and may
produce wrong results or crash on some types.

Attached is my attempt to do proper coercion. 'nformat.boot'
contains main new function, that is 'constructor_to_OutputForm'
and patch to 'i-output.boot' uses this function.

The patch couses significant change to how types are output.
For example instead of:

Record(svz: Symbol,sm: U32Vector,sp: Integer)

we get

Record(svz:Symbol,sm:U32Vector,sp:Integer)

that is there are no spaces after ":" (that is default behaviour
of our formatters). Insteread of:

ModularAlgebraicGcd(PrimitiveArray(U32Vector),Record(svz: Symbol,sm: U32Vecto
r,sp: Integer),ModularAlgebraicGcdTools2)

(that is single string which is broken between lines by output
formatter) we get:

ModularAlgebraicGcd
PrimitiveArray(U32Vector)
,
Record(svz:Symbol,sm:U32Vector,sp:Integer)
,
ModularAlgebraicGcdTools2

which is default handling of compound forms that are too big to fit on
a single line.

Instead of

IndexedMatrix(Polynomial(Integer),7,-3)

we get

IndexedMatrix(Polynomial(Integer),7,- 3)

that is minus sign is separated from the number.

Instead of

DeRhamComplex(Integer,[x,y,z])

we get

DeRhamComplex(Integer,[x, y, z])

Currently the code for handling categories is fake (throws error).
It seems that currently there is no way to have cateries coerced
to OutputForm, so corresponging code is not needed and
untestable.

--
Waldek Hebisch

[Martin Baker]

It seems a bit sad that your effort needs to be spent on boot code
rather than converting it to SPAD?

Martin

[Waldek Hebisch]

On Wed, Oct 18, 2023 at 10:16:11AM +0100, Martin Baker wrote:
> It seems a bit sad that your effort needs to be spent on boot code rather
> than converting it to SPAD?

Well, Spad code should do things differently than Boot, in particular
at least try to respect type rules. New code is restructured,
I view this as first stage of convertion to Spad. OTOH to
verify that new code is working as expected it is useful to
do realatively small change, in particular still keeping it
as Boot.

In general, when converting Boot to Spad it is expected that
substantial part of work will be at Boot level.

--
Waldek Hebisch

[Qian Yun]

On 10/18/23 08:05, Waldek Hebisch wrote:
> Currently coercion of types to OutputForm is fake: it uses
> an interpreter function to produce a string and this string
> serves as OutputForm. This is problematic because:
> - resulting OutputForm has no structure

Is there a way to get such OutputForm object from interpreter?

>
> ModularAlgebraicGcd(PrimitiveArray(U32Vector),Record(svz: Symbol,sm: U32Vecto
> r,sp: Integer),ModularAlgebraicGcdTools2)
>
> (that is single string which is broken between lines by output
> formatter) we get:
>
> ModularAlgebraicGcd
> PrimitiveArray(U32Vector)
> ,
> Record(svz:Symbol,sm:U32Vector,sp:Integer)
> ,
> ModularAlgebraicGcdTools2
>
> which is default handling of compound forms that are too big to fit on
> a single line.

About this multi-line output, I wonder if there's a way to get one line
string, so that it can be copy-pasted to recreate that type.
(By using Format1D?)

- Qian

[Waldek Hebisch]

On Wed, Oct 18, 2023 at 07:32:48PM +0800, Qian Yun wrote:
>
>
> On 10/18/23 08:05, Waldek Hebisch wrote:
> > Currently coercion of types to OutputForm is fake: it uses
> > an interpreter function to produce a string and this string
> > serves as OutputForm. This is problematic because:
> > - resulting OutputForm has no structure
>
> Is there a way to get such OutputForm object from interpreter?

Wehn testing I just looked at printed output from type-valued
expressions, like:

(1) -> Record(a : Integer, b : Boolean)

(1) Record(a:Integer,b:Boolean)
Type: Type

In principle, one should be able to get OutputForm like:

(2) -> POLY(INT)::OutputForm

(2) Polynomial(Integer())
Type: OutputForm

but currently this behaves in rather irregular way and AFAICS
does not use new code.

>
> >
> > ModularAlgebraicGcd(PrimitiveArray(U32Vector),Record(svz: Symbol,sm: U32Vecto
> > r,sp: Integer),ModularAlgebraicGcdTools2)
> >
> > (that is single string which is broken between lines by output
> > formatter) we get:
> >
> > ModularAlgebraicGcd
> > PrimitiveArray(U32Vector)
> > ,
> > Record(svz:Symbol,sm:U32Vector,sp:Integer)
> > ,
> > ModularAlgebraicGcdTools2
> >
> > which is default handling of compound forms that are too big to fit on
> > a single line.
>
> About this multi-line output, I wonder if there's a way to get one line
> string, so that it can be copy-pasted to recreate that type.
> (By using Format1D?)

Note that currently my patch deals only with output of types as
values. Arguably we should use the same formatter for all
vales, so either 1D for everything or 2D for everything.

'printTypeAndTime' is separate and currently the patch does not
affect it. And for 'printTypeAndTime' it is natural to use
one dimensional formatter.

--
Waldek Hebisch

[Ralf Hemmecke]

On 18.10.23 16:25, Waldek Hebisch wrote:
> On Wed, Oct 18, 2023 at 07:32:48PM +0800, Qian Yun wrote:
>> On 10/18/23 08:05, Waldek Hebisch wrote:
>>> Currently coercion of types to OutputForm is fake: it uses
>>> an interpreter function to produce a string and this string
>>> serves as OutputForm.

First of all, it is a good idea to bring structure into the output of types.

>> Is there a way to get such OutputForm object from interpreter?

> Wehn testing I just looked at printed output from type-valued
> expressions, like:
>
> (1) -> Record(a : Integer, b : Boolean)
>
> (1) Record(a:Integer,b:Boolean)
> Type: Type
>
> In principle, one should be able to get OutputForm like:
>
> (2) -> POLY(INT)::OutputForm
>
> (2) Polynomial(Integer())
> Type: OutputForm
>
> but currently this behaves in rather irregular way and AFAICS
> does not use new code.

Well, either there is a funcion coerce: Type -> OutputForm that contains
the implementation of such a thing or it would be a hack for :: in the
interpreter. I prefer the first option. However, the question would be,
in which package that function should live. Additionally, this package
would have to be known to the interpreter in that whenever the
interpreter is about to output a type, then this coercion function is to
be called.

>>> ModularAlgebraicGcd(PrimitiveArray(U32Vector),Record(svz: Symbol,sm: U32Vecto
>>> r,sp: Integer),ModularAlgebraicGcdTools2)
>>>
>>> (that is single string which is broken between lines by output
>>> formatter) we get:
>>>
>>> ModularAlgebraicGcd
>>> PrimitiveArray(U32Vector)
>>> ,
>>> Record(svz:Symbol,sm:U32Vector,sp:Integer)
>>> ,
>>> ModularAlgebraicGcdTools2
>>>
>>> which is default handling of compound forms that are too big to fit on
>>> a single line.

Well, I think that would be OK, if it comes from the default handling
of OutputForm into physical text, i.e. handled by whatever

)set output SOMEFORMATTER on

is active at that time. It's the task of the formatter to transform
OutputForm into something that should appear on screen.
I'm not quite sure, but I somehow feel that our current formatters are
not properly able to handle the output of types even if it comes as an
OutputForm with this patch. So, maybe together with this patch should go
some tweaking of the formatters. Give me some time that I can look
deeper into the patch and its consequences for the FormatXXX stuff that
I wrote.

>> About this multi-line output, I wonder if there's a way to get one line
>> string, so that it can be copy-pasted to recreate that type.
>> (By using Format1D?)

> Note that currently my patch deals only with output of types as
> values. Arguably we should use the same formatter for all
> vales, so either 1D for everything or 2D for everything.

Definitely, the formatter should get an OutputForm, there is no
knowledge whether this comes from a type or from a mathematical
expresssion. In fact, a type can just be considered like an expression
where the function names are the type names. If the OutputForm produced
by Waldek's patch is like that, then everything would be easy.

> 'printTypeAndTime' is separate and currently the patch does not
> affect it. And for 'printTypeAndTime' it is natural to use
> one dimensional formatter.

If I am not completely wrong, then we must be careful with that
function, since I think I rely on it in jFriCAS.

Ralf

[Grégory Vanuxem]

Hello,

That can be completely out of context here  but in src/algebra in the file output.form there is an OutputForm domain and a set of structure about what you are talking about.

There are also out.spad, outform2.spad and mathml, tex, fortran, texmacs I guess and maybe other spad files that can be interesting about this discussion.

I can not be precise, I am on a smartphone and to read the code I have used the GitHub application.

All the best,

__
Greg

[Ralf Hemmecke]

> There are also out.spad, outform2.spad and mathml, tex, fortran, texmacs I
> guess and maybe other spad files that can be interesting about this
> discussion.

Yes. I guess that everyone who wishes to be involved in getting that
issue done knows about these files.

Ralf

[Waldek Hebisch]

'coerce' is always associated to appropriate type. Type of Type is
Category, so 'coerce' should be declared here. To use general rules
we need declaration. However, with current interpreter we are
forced to use a hack: Category does not exist as real domain
and any intepreter manipulation of types uses special code
(hacks).

Note that our types have arbitrary parameters and it is possible to
have domain without coercion to OutputForm. So 'coerce' from
types to OutputForm must be a lie/hack. If we want non-hacky
implementation we probably should insist that all domains have
coercion to OutputForm (that would make CoercibleTo(OutputForm)
redundant).

> > > > ModularAlgebraicGcd(PrimitiveArray(U32Vector),Record(svz: Symbol,sm: U32Vecto
> > > > r,sp: Integer),ModularAlgebraicGcdTools2)
> > > >
> > > > (that is single string which is broken between lines by output
> > > > formatter) we get:
> > > >
> > > > ModularAlgebraicGcd
> > > > PrimitiveArray(U32Vector)
> > > > ,
> > > > Record(svz:Symbol,sm:U32Vector,sp:Integer)
> > > > ,
> > > > ModularAlgebraicGcdTools2
> > > >
> > > > which is default handling of compound forms that are too big to fit on
> > > > a single line.
>
> Well, I think that would be OK, if it comes from the default handling of
> OutputForm into physical text, i.e. handled by whatever
>
> )set output SOMEFORMATTER on
>
> is active at that time. It's the task of the formatter to transform
> OutputForm into something that should appear on screen.
> I'm not quite sure, but I somehow feel that our current formatters are not
> properly able to handle the output of types even if it comes as an
> OutputForm with this patch.

Well, ATM types are only passed to old algebra format and TeX format.
One can only speculate why this is done that way. For FortranFormat
this is understandable, as Fortran can only handle expressions and
passing FriCAS types to it makes no sense. But for other formatters
this looks just as accidental ommision. Having coercion from types
to OutputForm this is easy to change.

> So, maybe together with this patch should go
> some tweaking of the formatters. Give me some time that I can look deeper
> into the patch and its consequences for the FormatXXX stuff that I wrote.

AFAICS ATM there is no consequences since produced OutputForm will
not get to other formatters. But I will post next version of the
patch where there will be some effect.

> > > About this multi-line output, I wonder if there's a way to get one line
> > > string, so that it can be copy-pasted to recreate that type.
> > > (By using Format1D?)
>
> > Note that currently my patch deals only with output of types as
> > values. Arguably we should use the same formatter for all
> > vales, so either 1D for everything or 2D for everything.
>
> Definitely, the formatter should get an OutputForm, there is no knowledge
> whether this comes from a type or from a mathematical expresssion. In fact,
> a type can just be considered like an expression where the function names
> are the type names. If the OutputForm produced by Waldek's patch is like
> that, then everything would be easy.

Well, most types are "like function calls", but there is bunch of special
cases.

> > 'printTypeAndTime' is separate and currently the patch does not
> > affect it. And for 'printTypeAndTime' it is natural to use
> > one dimensional formatter.
>
> If I am not completely wrong, then we must be careful with that function,
> since I think I rely on it in jFriCAS.

I hope you do not rely on specific form. 'printTypeAndTime' effectively
prints a string and you should be able to get this string in the future.

--
Waldek Hebisch

[Ralf Hemmecke]

On 19.10.23 03:54, Waldek Hebisch wrote:
>> Well, either there is a funcion coerce: Type -> OutputForm that contains the
>> implementation of such a thing or it would be a hack for :: in the
>> interpreter. I prefer the first option. However, the question would be, in
>> which package that function should live. Additionally, this package would
>> have to be known to the interpreter in that whenever the interpreter is
>> about to output a type, then this coercion function is to be called.
>
> 'coerce' is always associated to appropriate type. Type of Type is
> Category, so 'coerce' should be declared here. To use general rules
> we need declaration. However, with current interpreter we are
> forced to use a hack: Category does not exist as real domain
> and any intepreter manipulation of types uses special code
> (hacks).

> Note that our types have arbitrary parameters and it is possible to
> have domain without coercion to OutputForm. So 'coerce' from
> types to OutputForm must be a lie/hack. If we want non-hacky
> implementation we probably should insist that all domains have
> coercion to OutputForm (that would make CoercibleTo(OutputForm)
> redundant).

It seems thaat I did not express myself well enough.

AFAIK the :: notation is only syntactic sugar and translates into an
appropriate coerce, retract (or even convert in the interpreter).
This was what I meant by hack. The interpreter should know what it means
if it sees T :: OutputForm and T is a constructor (with or without
parameters). To be in line with the common interpretation of :: as
coerce, I suggested to implement a coerce function SOMEWHERE.

In fact, it need not be called coerce since we have the convention that
in FriCAS coerce is a homomorphism, however, I would have no clear idea
what it would mean to have a homomorphism from Category -> OutputForm or
Type -> OutputForm. I.e. calling that function for constructors "coerce"
is perhaps also a bit irritating.

And I seem to remember that we already have a function
print: OutputForm -> Void
in PrintPackage
https://github.com/fricas/fricas/blob/master/src/algebra/out.spad#L235
that is seemingly nowhere used except that the interpreter calls it to
display a value of a certain type on screen. Right?

My idea was to provide a simlar package for a function Type->OutputForm
or Category->OutputForm (name of that function need not be "coerce") and
then implement a hack in the interpreter that T::OutputForm (if T is a
constructor) is translated to that function call. Similar for the
ordinary printing of a type when ")set message type on" is active.

That has nothing to do with whether the type has parameters or not or
whether the type exports a coerce:%->OutputForm. It's about printing the
type not a value from that type.

> If we want non-hacky
> implementation we probably should insist that all domains have
> coercion to OutputForm (that would make CoercibleTo(OutputForm)
> redundant).

No, the interpreter would just need a fallback and show
"<non-printable>"
(and the name of the type if ")type on" is active).

>> So, maybe together with this patch should go
>> some tweaking of the formatters. Give me some time that I can look deeper
>> into the patch and its consequences for the FormatXXX stuff that I wrote.
>
> AFAICS ATM there is no consequences since produced OutputForm will
> not get to other formatters. But I will post next version of the
> patch where there will be some effect.

OK, maybe there is currently no effect (I still must look at the code),
but Qian already asked to get such an output form for a type. I.e.
wishing for T::OutputForm in the interpreter or outputForm(T) in the
compiler seems to be natural. And at that time a user might want to
print that output, i.e. any of our formatters would be involved.
Probably easy to handle, but we should keep that in mind.

> Well, most types are "like function calls", but there is bunch of special
> cases.

The ones with values in the type like SimpleAlgebraicExtension?

>>> 'printTypeAndTime' is separate and currently the patch does not
>>> affect it. And for 'printTypeAndTime' it is natural to use
>>> one dimensional formatter.
>>
>> If I am not completely wrong, then we must be careful with that function,
>> since I think I rely on it in jFriCAS.

> I hope you do not rely on specific form. 'printTypeAndTime' effectively
> prints a string and you should be able to get this string in the future.

Right. What jFricas (fricaskernel.py function addLinks) does is to take
what it finds after "Type: " in the output. Where that comes from is
irrelevant. "addLinks" simply (blindly) replaces CamelCase strings of
letters and numbers into links to fricas.github.io/api/CamelCase.html
links. So there is no big danger.

However, when in the future there will be more structure, then it might
make sense that aleady a special formatter translates the outputform
into html links.

Thinking of it... translating OutputForm to something with links is
already too late. To be precise either OutputForm should have a tag
that the form represents a type or link adding should happen at the time
when the type is translated to OutputForm (however I do not see why we
should overload OutputForm with links).

Anyway, if jFriCAS sees essentially the same string after "Type: " as
now, then all is fine.

Ralf

[Waldek Hebisch]

Well, interpreter has 'coerceInteractive' which is responsible
for handling coercions. It may call 'coerce' but in general it
is doing much more.

> In fact, it need not be called coerce since we have the convention that in
> FriCAS coerce is a homomorphism, however, I would have no clear idea what it
> would mean to have a homomorphism from Category -> OutputForm or Type ->
> OutputForm. I.e. calling that function for constructors "coerce" is perhaps
> also a bit irritating.
>
> And I seem to remember that we already have a function
> print: OutputForm -> Void
> in PrintPackage
> https://github.com/fricas/fricas/blob/master/src/algebra/out.spad#L235
> that is seemingly nowhere used except that the interpreter calls it to
> display a value of a certain type on screen. Right?

Yes.

> My idea was to provide a simlar package for a function Type->OutputForm or
> Category->OutputForm (name of that function need not be "coerce") and then
> implement a hack in the interpreter that T::OutputForm (if T is a
> constructor) is translated to that function call. Similar for the ordinary
> printing of a type when ")set message type on" is active.
>
> That has nothing to do with whether the type has parameters or not or
> whether the type exports a coerce:%->OutputForm. It's about printing the
> type not a value from that type.

Yes, we may provide extra package with such a function. However,
exact dependencies of things are to be worked out.

> > If we want non-hacky
> > implementation we probably should insist that all domains have
> > coercion to OutputForm (that would make CoercibleTo(OutputForm)
> > redundant).
>
> No, the interpreter would just need a fallback and show
> "<non-printable>"
> (and the name of the type if ")type on" is active).

That is hacky way to provide coercion for all types. And current
code make more effort to provide resonable result.

> > > So, maybe together with this patch should go
> > > some tweaking of the formatters. Give me some time that I can look deeper
> > > into the patch and its consequences for the FormatXXX stuff that I wrote.
> >
> > AFAICS ATM there is no consequences since produced OutputForm will
> > not get to other formatters. But I will post next version of the
> > patch where there will be some effect.
>
> OK, maybe there is currently no effect (I still must look at the code), but
> Qian already asked to get such an output form for a type. I.e. wishing for
> T::OutputForm in the interpreter or outputForm(T) in the compiler seems to
> be natural.

You can do this. In the past it was and with patch that I posted it
still is handled by different code.

> > Well, most types are "like function calls", but there is bunch of special
> > cases.
>
> The ones with values in the type like SimpleAlgebraicExtension?

SimpleAlgebraicExtension is syntactically like function call. One
example of different syntax is Record. Also tagged unions (essentially
the same as Record) and Mapping.

> > > > 'printTypeAndTime' is separate and currently the patch does not
> > > > affect it. And for 'printTypeAndTime' it is natural to use
> > > > one dimensional formatter.
> > >
> > > If I am not completely wrong, then we must be careful with that function,
> > > since I think I rely on it in jFriCAS.
>
> > I hope you do not rely on specific form. 'printTypeAndTime' effectively
> > prints a string and you should be able to get this string in the future.
>
> Right. What jFricas (fricaskernel.py function addLinks) does is to take what
> it finds after "Type: " in the output. Where that comes from is irrelevant.
> "addLinks" simply (blindly) replaces CamelCase strings of letters and
> numbers into links to fricas.github.io/api/CamelCase.html links. So there is
> no big danger.
>
> However, when in the future there will be more structure, then it might make
> sense that aleady a special formatter translates the outputform into html
> links.

We have special formatter that converts types into a form with embedded
links. This is old Saturn code. It uses it own data representation,
so directly may be unusable (and links are TeX/Hyperdoc style). But
IMO anybody trying to annotate types with links should look at
this code and at least have a rational explanation why he/she do
not want/can not reuse (possibly modified) Saturn code.

--
Waldek Hebisch

[Waldek Hebisch]

I have now better patch that changes interprter coercion and
passes type to all formatters except for FortranFormat.


--
Waldek Hebisch

[Ralf Hemmecke]

If I just look at the output of a particular type, then your patch seems
to produce a reasonable OutputForm value, see below.

Format1D translates this into reasonable output.

Actually also FormatMathJax and FormatLaTeX look reasonable. There is
only one little problem. The innermost type is not considered as an
operator and therefore printed as if it were a variable.
Well, it was my design decision to print operators in a different way
then arguments. Probably questionable, but in line with how for example
\gcd(x,y) is printed in LaTeX.

Additionally, since the OutputForm of a type is indistinguishable from

That said, and with the background that without that patch the other
formatters would not be able to print the type, I am much in favour of
this patch.

Looking at the BOOT code makes me wish for a testsuite that lists
domains/categories and there expected output.
It is somewhat clear for the common cases, but you add double quotes for
strings and I would like to see a type where this piece of code is used,
so that I can check the other formatters.

Additionally, I am not so happy with the explicit appearance of "->"
when translating the Mapping type. I somehow think that -> should become
a special treatment like zag or slash or ...

Ralf



%%% (186) ->
(186)
XHashTable
Matrix(Integer)
,
Record
fmats:
Record
fcusp:Cusp
,
fgamma:Matrix(Integer)
,
fred:Matrix(Integer)
,
ftriang:Matrix(Integer)
,
fex:QEtaLaurentSeries(Fraction(Integer))
--FORMAT:BEG:Format1D
XHashTable(Matrix(Integer), Record(fmats:Record(fcusp:Cusp,
fgamma:Matrix(Integer), fred:Matrix(Integer), ftriang:Matrix(Integer)),
fex:QEtaLaurentSeries(Fraction(Integer))))
--FORMAT:END:Format1D
--FORMAT:BEG:FormatMathJax
\[
\operatorname{XHashTable}\left(\operatorname{Matrix}\left(Integer\right),
\operatorname{Record}\left(fmats\texttt{:}\operatorname{Record}\left(fcusp\texttt{:}Cusp,
fgamma\texttt{:}\operatorname{Matrix}\left(Integer\right),
fred\texttt{:}\operatorname{Matrix}\left(Integer\right),
ftriang\texttt{:}\operatorname{Matrix}\left(Integer\right)\right),
fex\texttt{:}\operatorname{QEtaLaurentSeries}\left(\operatorname{Fraction}\left(Integer\right)\right)\right)\right)
\]
--FORMAT:END:FormatMathJax
--FORMAT:BEG:FormatLaTeX
\begin{fricasmath}{186}
\FUN{XHashTable}\PAREN{\FUN{Matrix}\PAREN{\SYMBOL{Integer}},
\FUN{Record}\PAREN{\SYMBOL{fmats}\STRING{:}\FUN{Record}\PAREN{\SYMBOL{fcusp}\STRING{:}\SYMBOL{Cusp},
\SYMBOL{fgamma}\STRING{:}\FUN{Matrix}\PAREN{\SYMBOL{Integer}},
\SYMBOL{fred}\STRING{:}\FUN{Matrix}\PAREN{\SYMBOL{Integer}},
\SYMBOL{ftriang}\STRING{:}\FUN{Matrix}\PAREN{\SYMBOL{Integer}}},
\SYMBOL{fex}\STRING{:}\FUN{QEtaLaurentSeries}\PAREN{\FUN{Fraction}\PAREN{\SYMBOL{Integer}}}}}
\end{fricasmath}
--FORMAT:END:FormatLaTeX

[Waldek Hebisch]

On Sun, Oct 22, 2023 at 12:25:01AM +0200, Ralf Hemmecke wrote:
> Looking at the BOOT code makes me wish for a testsuite that lists
> domains/categories and there expected output.
> It is somewhat clear for the common cases, but you add double quotes for
> strings and I would like to see a type where this piece of code is used, so
> that I can check the other formatters.

(1) -> Union(Integer, "failed")

(1) Union(Integer,"failed")

Actually string alone is a valide type, but without appropriate
context interpreter have trouble creating such types.

> Additionally, I am not so happy with the explicit appearance of "->" when
> translating the Mapping type. I somehow think that -> should become a
> special treatment like zag or slash or ...

"->" is operator producing mapping types. It is most natural to
use it. The only objectionable thing is that some infix operators
appear in OutputForm as (op, arg1, arg2) and some other as
(arg1 op arg2).

--
Waldek Hebisch

[Ralf Hemmecke]

On 22.10.23 18:08, Waldek Hebisch wrote:
>> Additionally, I am not so happy with the explicit appearance of "->" when
>> translating the Mapping type. I somehow think that -> should become a
>> special treatment like zag or slash or ...
>
> "->" is operator producing mapping types.

Yes, but that is not the operator in OuputForm.
See "rarrow".

http://fricas.github.io/api/OutputForm.html#index-69

rarrow produces an OutputForm with operator TAG and two arguments and
probably all formatters know how this has to be printed (at least I can
confirm this for the FormatXXX types.

Can you change in Mapping_to_OutputForm(argl) the respective lines to

['TAG, nargs, rt]

(I haven't tested it.)

> The only objectionable thing is that some infix operators
> appear in OutputForm as (op, arg1, arg2) and some other as
> (arg1 op arg2).

Do you mean forms produced via infix(f,l)?
But we have TAG and so do not need infix for ->.

Another thing...

Maybe your patch doesn't aim at providing also the following... but just
in case...

%%% (6) -> (Tuple(Integer))::OF

Cannot convert the value from type Tuple(Type) to OutputForm .

Ralf

[Waldek Hebisch]

That is related but different thing. In interperter types have
different representation than other values, so correctly handling
types as values requires special case code. It seems that most
needed code is missing. For example:

[Integer]

new(2, Integer)$PrimitiveArray(Type)

new(2, Integer)$Vector(Type)

[Integer, Float]::DirectProduct(2, Type)

(8) -> rr := [Integer, true]$Record(t : Type, b : Boolean)

(8) [t = NIL, b = true]
Type: Record(t: Type,b: Boolean)
(9) -> rr.t

(9) Integer
Type: Type

Type is invalid as argument to many constructors, but a lot of
constructors can by applied to it so users may expect that
printing of such things will do sensible things...

--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Oct 22, 2023 at 08:09:43PM +0200, Ralf Hemmecke wrote:

> On 22.10.23 18:08, Waldek Hebisch wrote:
> > > Additionally, I am not so happy with the explicit appearance of "->" when
> > > translating the Mapping type. I somehow think that -> should become a
> > > special treatment like zag or slash or ...
> >
> > "->" is operator producing mapping types.
>
> Yes, but that is not the operator in OuputForm.
> See "rarrow".
>
> http://fricas.github.io/api/OutputForm.html#index-69
>
> rarrow produces an OutputForm with operator TAG and two arguments and
> probably all formatters know how this has to be printed (at least I can
> confirm this for the FormatXXX types.
>
> Can you change in Mapping_to_OutputForm(argl) the respective lines to
>
> ['TAG, nargs, rt]
>
> (I haven't tested it.)

I am not sure if this is proper thing. Namely '->' is special,
it applies _only_ to types. TAG is for ordinary values.
So semantic difference would be lost. AFAICS Latex have
different arrows for both uses, so it makes sense to have
different OutputForm-s for the two cases.

--
Waldek Hebisch

[Ralf Hemmecke]

On 10/25/23 14:05, Waldek Hebisch wrote:
>> Can you change in Mapping_to_OutputForm(argl) the respective lines to
>>
>> ['TAG, nargs, rt]
>>
>> (I haven't tested it.)
>
> I am not sure if this is proper thing. Namely '->' is special,
> it applies _only_ to types. TAG is for ordinary values.
> So semantic difference would be lost. AFAICS Latex have
> different arrows for both uses, so it makes sense to have
> different OutputForm-s for the two cases.

But we have this already.

%%% (3) -> ((x +-> x^3)::OutputForm) pretend SExpression

(3) (+-> x (^ x 3))

The "+->" arrow corresponds to \mapsto (not to \to) in LaTeX.
Unfortunately, that we use "+->" is actually not listed in outform.spad,
i.e. a user cannot easily know that the formatters handle it.
I have no idea, which part of code is responsible for the output of (3).

We could treat (or rename TAG to ->) in the same way, but that is only a
cosmetic change. BTW, I am not exactly sure why the name "TAG" was
chosen to represent "->".

And yes, you are right, FriCAS is using "rarrow". However, it is only in
moebius.spad, and it is not according to "usual" mathematical notation
of mapping of elements.

%%% (1) -> moebius(5,4,1,1)$MoebiusTransform(Fraction Integer)

5 %x + 4
(1) %x -> --------
1 %x + 1

I would definitely like to see "+->" in the output of (1). moebius.spad
should be corrected.

Ralf

[Waldek Hebisch]

On Thu, Oct 26, 2023 at 01:14:50PM +0200, Ralf Hemmecke wrote:
> On 10/25/23 14:05, Waldek Hebisch wrote:
> > > Can you change in Mapping_to_OutputForm(argl) the respective lines to
> > >
> > > ['TAG, nargs, rt]
> > >
> > > (I haven't tested it.)
> >
> > I am not sure if this is proper thing. Namely '->' is special,
> > it applies _only_ to types. TAG is for ordinary values.
> > So semantic difference would be lost. AFAICS Latex have
> > different arrows for both uses, so it makes sense to have
> > different OutputForm-s for the two cases.
>
> But we have this already.
>
> %%% (3) -> ((x +-> x^3)::OutputForm) pretend SExpression
>
> (3) (+-> x (^ x 3))
>
> The "+->" arrow corresponds to \mapsto (not to \to) in LaTeX.
> Unfortunately, that we use "+->" is actually not listed in outform.spad,
> i.e. a user cannot easily know that the formatters handle it.
> I have no idea, which part of code is responsible for the output of (3).

"+->" is part of representation of _code_ and OutputForm simply
repeats internal representation. And formatters know how to
handle it.

> We could treat (or rename TAG to ->) in the same way, but that is only a
> cosmetic change. BTW, I am not exactly sure why the name "TAG" was chosen to
> represent "->".
>
> And yes, you are right, FriCAS is using "rarrow". However, it is only in
> moebius.spad, and it is not according to "usual" mathematical notation of
> mapping of elements.
>
> %%% (1) -> moebius(5,4,1,1)$MoebiusTransform(Fraction Integer)
>
> 5 %x + 4
> (1) %x -> --------
> 1 %x + 1
>
> I would definitely like to see "+->" in the output of (1). moebius.spad
> should be corrected.

It is debatable what we should output for Moebius transform.
And it is not only Moebius transform, we also have IDPO.
Default OutputForm for this uses TAG. Logically, this
is different than '+->', as it gives value of mapping only
at single point. Actually, also for Moebius transform we
have value of mapping at single point, but this uniquely
determines whole mapping.

Anyway, regardless of relation of "+->" with "TAG" both
are different than "->".

--
Waldek Hebisch

[Waldek Hebisch]

I think that in OutputForm "->" should be a binary operator. Change
to i-output.boot looks easy. Also, it is easy to modify 'tex.spad'
to handle this. There is question what various formats should
output for "TAG" and "->". Currently in my test version 'tex.spad'
outputs '\rightarrow' and '\to' respectively, which seem to
be reasonable. fmtlatex.spad outputs '\to' for "TAG", which
to me looks wrong, as '\to' seem to be used for domain/codomain
of mapping, that is types and not for values.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Oct 28, 2023 at 10:47:54PM +0200, Ralf Hemmecke wrote:
> On 10/28/23 03:33, Waldek Hebisch wrote:
> > I think that in OutputForm "->" should be a binary operator.
>

> Agreed.
>
> And the meaning should be "mapping between types/sets", not mapping of
> values.

Yes.

> > Change to i-output.boot looks easy. Also, it is easy to modify
> > 'tex.spad' to handle this. There is question what various formats
> > should output for "TAG" and "->".
>

> First of all, I think TAG is a rather strange name. I think, we can
> agree that TAG stands for "mapping of values", i.e. what is usually
> denoted via \mapsto in LaTeX. Can we?

Well, is the following "mapping of values"?

(1) -> iO := IDPO(Integer, Symbol)

(1) IndexedDirectProductObject(Integer,Symbol)
Type: Type
(2) -> monomial(1, x)$iO

(2) [x -> 1]
Type: IndexedDirectProductObject(Integer,Symbol)
(3) -> monomial(1, x)$iO + monomial(2, y)$iO

(3) [y -> 2, x -> 1]
Type: IndexedDirectProductObject(Integer,Symbol)

> > Currently in my test version 'tex.spad' outputs '\rightarrow' and '\to'
> > respectively, which seem to be reasonable.
>

> This is where I do not agree. Why is this reasonable, when TAG actually
> denotes the mapping of values? When I denote a function, then I write
>
> \begin{gather}
> f : Z \to Z,\qquad x \mapsto x^2
> \end{gather}

See above: we give map for each value separately, not a formula
for a function. Also "reasonable" does not mean very good,
but '\rightarrow' is different symbol than both '\to' and '\mapsto'.
There is trouble that '\rightarrow' looks identical to '\to',
I thought that they look different. So '\rightarrow' probably
should be replaced by differently looking arrow.
Using '\rightarrow' (or rather some different arrow) is reasonable in
sense of preserving distinction. You somewhat argue that TAG and
'+->' are the same thing, and I think that they are not the same.

> The current usage of rarrow in MoebiusTransform(F) is clearly in the
> meaning of denoting the mapping of values.
>
> I.e. moebius: F^4 -> (F -> F),
> (a,b,c,d) +-> (x +-> (a*x+b)/(c*x+d))

For moebius "+->" could be reasonable, but I have some doubts
about "clearly": arguably we give value of mapping at single
(generic) point.

> If FriCAS would print it like this, it would agree with the usual
> mathematical notation..

>
> > fmtlatex.spad outputs '\to' for "TAG", which to me looks wrong, as
> > '\to' seem to be used for domain/codomain of mapping, that is types
> > and not for values.
>

> Right, \to for TAG is wrong.
>
> But put the attached files into your fricas checkout (with your patches) and
> run "bash outputtest.sh". You will get the attached outputtest.pdf.
>
> Look at the second output for moebius. The OutputForm contains TAG and not
> only fmtlatex translates this to \to, but all other formatters produce the
> equivalent of "->" or \rightarrow (in TexFormat). So it is not a problem of
> fmtlatex alone.



> That is why I am wishing for a new function (besides rarrow) in OutputForm.
> It would be a little confusing to use rarrow for \mapsto, since rarrow seems
> to suggest \rightarrow, but was probably meant (just my guess) to denote the
> mapping of values.
>
> I want to change the output for moebius to +->, because it actually denotes
> the value mapping. Currently, it defeats the intention of Format1D, namely
> that one can cut&paste the output in Format1D form as input into FriCAS.
> Yes, Format1D is not perfect, but close.
>
> The OutputForm operators TAG and +->, as well as rarrow are not used in many
> places, so I think we can make incompatible changes.
>
> My suggestion for OutputForm:
>
> Introduce functions
> mapsto(a, b)== convert [eform("+->"::Symbol, a, b]
> rarrow(a, b)== convert [eform( "->"::Symbol, a, b]
>
> How the internal OutputForm operators are called, I actually do not care
> much about, the could also be 'MAPSTO and 'RARROW.
>
> What I care about is a distinction between the type mapping and the value
> mapping, i.e., I want to see Integer -> Integer and x+->x^2.
>
> What's your wish?

I would like to have 3 different OutputForm-s. AFAICS currently
two of them, that is "->" and "+->" are produced only by
interpreter code. The third one is used by algebra.
If we use of TeX arrows for third form, than 'rarrow' is reasonable
name.

--
Waldek Hebisch

[Ralf Hemmecke]

On 10/29/23 00:00, Waldek Hebisch wrote:
> Well, is the following "mapping of values"?
>
> (1) -> iO := IDPO(Integer, Symbol)
>
> (1) IndexedDirectProductObject(Integer,Symbol)
> Type: Type
> (2) -> monomial(1, x)$iO
>
> (2) [x -> 1]
> Type: IndexedDirectProductObject(Integer,Symbol)
> (3) -> monomial(1, x)$iO + monomial(2, y)$iO
>
> (3) [y -> 2, x -> 1]
> Type: IndexedDirectProductObject(Integer,Symbol)

Ah, now I see, what you mean. I agree, that the output looks reasonable,
however, I somehow think, it is similar to

AL ==> AssociationList(Symbol,Integer)
RSZ ==> Record(key: Symbol, entry: Integer)
al := construct([['x1,1]$RSZ,['x2,4]$RSZ,['x3,9]$RSZ])$AL

(11) table(x3 = 9,x2 = 4,x1 = 1)
Type:
AssociationList(Symbol,Integer)

Since IDPO represents a finite combination, I still think it should be
called "...Sum..." instead of "...Product...", but that is another matter.

For IDPO it would also make sense to have

2*y + 1*x

as output, similar to how divisors are denoted.

>>> Currently in my test version 'tex.spad' outputs '\rightarrow' and '\to'
>>> respectively, which seem to be reasonable.
>>
>> This is where I do not agree. Why is this reasonable, when TAG actually
>> denotes the mapping of values? When I denote a function, then I write
>>
>> \begin{gather}
>> f : Z \to Z,\qquad x \mapsto x^2
>> \end{gather}
>
> See above: we give map for each value separately, not a formula
> for a function. Also "reasonable" does not mean very good,
> but '\rightarrow' is different symbol than both '\to' and '\mapsto'.

I cannot confirm this on my computer. There
/usr/share/texlive/texmf-dist/tex/latex/base/fontmath.ltx
says
\DeclareMathSymbol{\rightarrow}{\mathrel}{symbols}{"21}
\DeclareMathSymbol{\to}{\mathrel}{symbols}{"21}
\DeclareMathSymbol{\mapstochar}{\mathrel}{symbols}{"37}
\DeclareRobustCommand\mapsto{\mapstochar\rightarrow}

> There is trouble that '\rightarrow' looks identical to '\to',
> I thought that they look different. So '\rightarrow' probably
> should be replaced by differently looking arrow.

Yes. I could live with showing the arrow for IDPO as something
different, perhaps ":>". Then I would prefer to also show the same
notation for all the Table domains and ALIST.

On the other hand, I would not be very happy with ":>", since I would
like to be able to cut&paste FriCAS output back into FriCAS (at least
for Format1D). Of course, the latter cannot work by design of OutputForm
(information is lost). Nevertheless, adding new output arrows that
prevent cut&paste would be somehow bad. So a better symbol would be
good. And we should also specify, how it should look in LaTeX and MathML
etc.

> Using '\rightarrow' (or rather some different arrow) is reasonable in
> sense of preserving distinction. You somewhat argue that TAG and
> '+->' are the same thing, and I think that they are not the same.

Yes, I seem to understand your point now.

>> The current usage of rarrow in MoebiusTransform(F) is clearly in the
>> meaning of denoting the mapping of values.
>>
>> I.e. moebius: F^4 -> (F -> F),
>> (a,b,c,d) +-> (x +-> (a*x+b)/(c*x+d))
>
> For moebius "+->" could be reasonable, but I have some doubts
> about "clearly": arguably we give value of mapping at single
> (generic) point.

The generic point is (a,b,c,d). And the value for this generic point is
a (value) mapping x +-> (a*x+b)/(c*x+d) with a formula on the right hand
side. Maybe I still don't understand your concern against +->.

>> What's your wish?
>
> I would like to have 3 different OutputForm-s.

Yes, ":>", "->", and "+->" (names not fixed). But maybe we can also do
without introducing an extra ":>" operator into OutputForm, see above.

Are there opinions of other users/developers?

Ralf

[Waldek Hebisch]

On Sun, Oct 29, 2023 at 10:23:23AM +0100, Ralf Hemmecke wrote:
> On 10/29/23 00:00, Waldek Hebisch wrote:
> > Well, is the following "mapping of values"?
> >
> > (1) -> iO := IDPO(Integer, Symbol)
> >
> > (1) IndexedDirectProductObject(Integer,Symbol)
> > Type: Type
> > (2) -> monomial(1, x)$iO
> >
> > (2) [x -> 1]
> > Type: IndexedDirectProductObject(Integer,Symbol)
> > (3) -> monomial(1, x)$iO + monomial(2, y)$iO
> >
> > (3) [y -> 2, x -> 1]
> > Type: IndexedDirectProductObject(Integer,Symbol)
>
> Ah, now I see, what you mean. I agree, that the output looks reasonable,
> however, I somehow think, it is similar to
>
> AL ==> AssociationList(Symbol,Integer)
> RSZ ==> Record(key: Symbol, entry: Integer)
> al := construct([['x1,1]$RSZ,['x2,4]$RSZ,['x3,9]$RSZ])$AL
>
> (11) table(x3 = 9,x2 = 4,x1 = 1)
> Type:
> AssociationList(Symbol,Integer)

Well, at first I expected AssociationList and hash tables to
use the same output as IDPO, but original authors did this differently.

BTW, the following looks strange:

(12) table(1 = 2.0)
Type: AssociationList(Integer,Float)

> Since IDPO represents a finite combination, I still think it should be
> called "...Sum..." instead of "...Product...", but that is another matter.
>
> For IDPO it would also make sense to have
>
> 2*y + 1*x
>
> as output, similar to how divisors are denoted.

IDPO may have extra structure but in general it is just product
with no additional structure. So '*' and '+' are inappropriate
in general case.

> > > > Currently in my test version 'tex.spad' outputs '\rightarrow' and '\to'
> > > > respectively, which seem to be reasonable.
> > >
> > > This is where I do not agree. Why is this reasonable, when TAG actually
> > > denotes the mapping of values? When I denote a function, then I write
> > >
> > > \begin{gather}
> > > f : Z \to Z,\qquad x \mapsto x^2
> > > \end{gather}
> >
> > See above: we give map for each value separately, not a formula
> > for a function. Also "reasonable" does not mean very good,
> > but '\rightarrow' is different symbol than both '\to' and '\mapsto'.
>
> I cannot confirm this on my computer. There
> /usr/share/texlive/texmf-dist/tex/latex/base/fontmath.ltx
> says
> \DeclareMathSymbol{\rightarrow}{\mathrel}{symbols}{"21}
> \DeclareMathSymbol{\to}{\mathrel}{symbols}{"21}
> \DeclareMathSymbol{\mapstochar}{\mathrel}{symbols}{"37}
> \DeclareRobustCommand\mapsto{\mapstochar\rightarrow}

Well, '\rightarrow' is clearly different thing than '\to'. In
default LaTeX setup they just happen to expand to the same thing...

> > There is trouble that '\rightarrow' looks identical to '\to',
> > I thought that they look different. So '\rightarrow' probably
> > should be replaced by differently looking arrow.
>
> Yes. I could live with showing the arrow for IDPO as something different,
> perhaps ":>". Then I would prefer to also show the same notation for all the
> Table domains and ALIST.

Hmm, I would be more happy with "~>" or maybe "=->". Actually,
we can make a lot of different 3 character arrow-like symbols.
If we insist on 2 character symbol, than "~>" is IMO pretty
good one.

> On the other hand, I would not be very happy with ":>", since I would like
> to be able to cut&paste FriCAS output back into FriCAS (at least for
> Format1D). Of course, the latter cannot work by design of OutputForm
> (information is lost). Nevertheless, adding new output arrows that prevent
> cut&paste would be somehow bad.

Well, current OutputForm is quite different than what is accepted
by interpreter. I do not plan significant changes to current
interpreter parser, but adding new operator symbols to old parser
is quite easy. So extra symbols actually can make cut&paste
easier.

<snip>

> Are there opinions of other users/developers?

Lately it was quiet here. I wonder if anybody else is looking
at this.

--
Waldek Hebisch

[Martin Baker]

If you did this it would enable the use of infix notation for Boolean
implies (I don't remember ever actually using the implies function so
its not important for me).

from prefix notation implies : (%, %) -> %
to infix notation % => % -> %

https://github.com/fricas/fricas/blob/master/src/algebra/boolean.spad#L63

The double lined arrow is used for implies here, for instance, to avoid
clash with function symbol:
https://en.wikipedia.org/wiki/List_of_logic_symbols

Martin

[Ralf Hemmecke]

On 10/30/23 17:19, Martin Baker wrote:
> If you did this it would enable the use of infix notation for Boolean
> implies (I don't remember ever actually using the implies function so
> its not important for me).
>
> from prefix notation implies : (%, %) -> %
> to infix notation    % => % -> %

Notation would be

=> : (%, %) -> %,

in fact, you just want to replace the function name "implies" by the
name "=>".

But "=>" is bad, because it is already part of the SPAD language and has
a clearly defined meaning.

Ralf

[Ralf Hemmecke]

[Ralf Hemmecke]

On 10/30/23 13:48, Waldek Hebisch wrote:
> Well, at first I expected AssociationList and hash tables to
> use the same output as IDPO, but original authors did this differently.
>
> BTW, the following looks strange:
>
> (12) table(1 = 2.0)
> Type: AssociationList(Integer,Float)

Yes. I cannot say that I am very happy with that notation. In fact, a
"better" notation would be

table[[key=1,entry=2.0], ...],

but that is too much notation, so original developers invented something
shorter using just "=" for Table and AssociationList and "->" for IDPO.

>> Since IDPO represents a finite combination, I still think it should be
>> called "...Sum..." instead of "...Product...", but that is another matter.
>>
>> For IDPO it would also make sense to have
>>
>> 2*y + 1*x
>>
>> as output, similar to how divisors are denoted.
>
> IDPO may have extra structure but in general it is just product
> with no additional structure. So '*' and '+' are inappropriate
> in general case.

Yes, of course. I was just stating an option.

> Well, '\rightarrow' is clearly different thing than '\to'.

I cannot really interpret this sentence, since \to feels to me more like
a latex command with a semantic name "to" that is to be represented by
an arrow. And \rightarrow is the name representing a symbol, an arrow.
LaTeX is not really the language for expressing semantics.

If you wanted to express that \rightarrow or rarrow to stand for what I
denoted as ":>", then OK. Yes, a third operator is fine for me.

> Hmm, I would be more happy with "~>" or maybe "=->".

Yes "~>" would be fine for me. Three letters defeats the idea of having
as little "non-information" as possible.

> If we insist on 2 character symbol, than "~>" is IMO pretty
> good one.

Fine. Looks good. Probably better than ":>".

>> Nevertheless, adding new output arrows that prevent
>> cut&paste would be somehow bad.

> Well, current OutputForm is quite different than what is accepted
> by interpreter. I do not plan significant changes to current
> interpreter parser, but adding new operator symbols to old parser
> is quite easy. So extra symbols actually can make cut&paste
> easier.

I want cut&paste, but on the other hand introducing ~> as a new operator
to the SPAD language is somehow not really in my interest. Then users
would be able to declare a function

"~>": Integer -> Integer

or

"~>": (Boolean, Boolean) -> Boolean

Although the latter would probably make Martin Baker happy, I thing it
is too indistinguishable from -> that it might lead to bugs that are
hard to find.

To support cut&paste better, it would make sense to introduce another
layer that translates output from Format1D into something that can be
pasted back to the FriCAS command line.

Even better, however would be, if there were a mechanism to cut and get
exactly the value that %%(stepnumber) represents. Unfortunately, one
usually only wants to copy part of the output back as input.

Too unsolvable for now. So to make the story short, I am in favour of
introducing "~>" which in LaTeX seems to be \leadsto (with symbol
\rightsquigarrow, as defined in amsfonts.sty and amssymb.sty.

BTW, I wonder whether we could get rid of "TAG" and replace it with "~>"
or "LEADSTO" and either "->" or "TO", and "+->" or "MAPSTO" as the tags
that appear in an OutputForm.

Ralf

[Waldek Hebisch]

On Tue, Oct 31, 2023 at 12:59:06AM +0100, Ralf Hemmecke wrote:
> On 10/30/23 13:48, Waldek Hebisch wrote:
> > Hmm, I would be more happy with "~>" or maybe "=->".
>
> Yes "~>" would be fine for me. Three letters defeats the idea of having as
> little "non-information" as possible.
>
> > If we insist on 2 character symbol, than "~>" is IMO pretty
> > good one.
>
> Fine. Looks good. Probably better than ":>".

<snip>

> Too unsolvable for now. So to make the story short, I am in favour of
> introducing "~>" which in LaTeX seems to be \leadsto (with symbol
> \rightsquigarrow, as defined in amsfonts.sty and amssymb.sty.

Yes. I am looking at other formatters. For MathML we probably
should use appropriate unicode characters. Two candidates I
found are:

219D;RIGHTWARDS WAVE ARROW
21DD;RIGHTWARDS SQUIGGLE ARROW;

By name the second is better match, but in my Firefox the
first looks a bit better.

> BTW, I wonder whether we could get rid of "TAG" and replace it with "~>" or
> "LEADSTO" and either "->" or "TO", and "+->" or "MAPSTO" as the tags that
> appear in an OutputForm.

I am not sure what you exactly propose. If we use 3 different symbols,
than changing "TAG" to "~>" in source files is reasonable.

--
Waldek Hebisch

[Ralf Hemmecke]

On 11/4/23 19:34, Waldek Hebisch wrote:
>> Too unsolvable for now. So to make the story short, I am in favour of
>> introducing "~>" which in LaTeX seems to be \leadsto (with symbol
>> \rightsquigarrow, as defined in amsfonts.sty and amssymb.sty.
>
> Yes. I am looking at other formatters. For MathML we probably
> should use appropriate unicode characters. Two candidates I
> found are:
>
> 219D;RIGHTWARDS WAVE ARROW
> 21DD;RIGHTWARDS SQUIGGLE ARROW;

There seem to be HTML names for it (see attachment).

<p>rarrw (&rarrw;) </p>
<p>zigarr (&zigrarr;)</p>

According to https://www.w3.org/TR/MathML2/byalpha.html it seems that
these are also the MATHML names for these arrows.

BTW, when I enter $\rightsquigarrow$ into jFriCAS, then MathJax
translates it to

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mo stretchy="false">&#x21DD;<!-- ⇝ --></mo>
</math>

> By name the second is better match, but in my Firefox the
> first looks a bit better.

I am definitely for zigarr (21DD). The wave arrow (219D) looks like the
arrow head pointing diagonally upwards, see attachment.

>> BTW, I wonder whether we could get rid of "TAG" and replace it with "~>" or
>> "LEADSTO" and either "->" or "TO", and "+->" or "MAPSTO" as the tags that
>> appear in an OutputForm.
>
> I am not sure what you exactly propose. If we use 3 different symbols,
> than changing "TAG" to "~>" in source files is reasonable.

I was not sure whether to use the arrow symbols itself as tags
(OutputForm operators) or rather use names. I am OK with arrow symbols.

BTW, can you create a pull request with your proposed code, then I could
add corrections to the formatters, if I find something incomplete.

Ralf

[Waldek Hebisch]

On Sun, Nov 05, 2023 at 05:49:45PM +0100, Ralf Hemmecke wrote:
> On 11/4/23 19:34, Waldek Hebisch wrote:
> > Yes. I am looking at other formatters. For MathML we probably
> > should use appropriate unicode characters. Two candidates I
> > found are:
> >
> > 219D;RIGHTWARDS WAVE ARROW
> > 21DD;RIGHTWARDS SQUIGGLE ARROW;
>
> There seem to be HTML names for it (see attachment).
>
> <p>rarrw (&rarrw;) </p>
> <p>zigarr (&zigrarr;)</p>
>
> According to https://www.w3.org/TR/MathML2/byalpha.html it seems that these
> are also the MATHML names for these arrows.
>
> BTW, when I enter $\rightsquigarrow$ into jFriCAS, then MathJax translates
> it to
>
> <math xmlns="http://www.w3.org/1998/Math/MathML">
> <mo stretchy="false">&#x21DD;<!-- ⇝ --></mo>
> </math>
>
> > By name the second is better match, but in my Firefox the
> > first looks a bit better.
>
> I am definitely for zigarr (21DD).

OK.

> > > BTW, I wonder whether we could get rid of "TAG" and replace it with "~>" or
> > > "LEADSTO" and either "->" or "TO", and "+->" or "MAPSTO" as the tags that
> > > appear in an OutputForm.
> >
> > I am not sure what you exactly propose. If we use 3 different symbols,
> > than changing "TAG" to "~>" in source files is reasonable.
>
> I was not sure whether to use the arrow symbols itself as tags (OutputForm
> operators) or rather use names. I am OK with arrow symbols.
>
> BTW, can you create a pull request with your proposed code, then I could add
> corrections to the formatters, if I find something incomplete.

Attached is complete diff + added file. I did nothing for Fortran,
as the symbols are meanigless there. I made hopefully correct
changes for other formatters.

--
Waldek Hebisch

[Ralf Hemmecke]

With the new code I now get

%%% (363) -> ((INT->String)::OutputForm) pretend SExpression

(363) (PAREN (CONCAT Integer -> String))

Why have you added "PAREN" to the OutputForm? Isn't that too much?

Furthermore, I see that you have changed the output in fmt1d and fmt2d
for -> to be "->" instead of " -> ". Was this a typo or a particular reason?

Ralf

[Waldek Hebisch]

On Sun, Nov 26, 2023 at 09:36:34PM +0100, Ralf Hemmecke wrote:
> With the new code I now get
>
> %%% (363) -> ((INT->String)::OutputForm) pretend SExpression
>
> (363) (PAREN (CONCAT Integer -> String))
>
> Why have you added "PAREN" to the OutputForm? Isn't that too much?

Well, we always printed such types with outside parens, "PAREN"
just encodes this at OutputForm level. And reason is that
deciding when to omit parens is in general tricky, so we
otuput more parens than strictly necessary.

> Furthermore, I see that you have changed the output in fmt1d and fmt2d
> for -> to be "->" instead of " -> ". Was this a typo or a particular reason?

This is for consistency with other formatters. And adding spaces
by putting them as part of a name is asking for trouble.

--
Waldek Hebisch