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
--
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/e5913719-e9ed-4794-be53-3e9dfe460e49%40hemmecke.org.
