On Wed, Oct 18, 2023 at 07:11:23PM +0200, Ralf Hemmecke wrote:
> 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.
'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
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZTCMU4sPIapMWALS%40fricas.org.
