On Thu, Oct 19, 2023 at 08:51:04AM +0200, Ralf Hemmecke wrote: > 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.
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 -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZTD55OV8lgjvZaYR%40fricas.org.
