given the output of dom, can I get the type?

[Martin R]

For example, consider

(17) -> f := integrate(x*sin(1/x), x=0..1);

                                                Type: Union(fail: failed,...)
(18) -> dom(f)

   (18)
   (Union  (: f1 (OrderedCompletion (Expression (Integer))))
    (: f2 (List (OrderedCompletion (Expression (Integer)))))
    (: fail "failed")  (: pole "potentialPole"))
                                                            Type: SExpression

Is there a (boot) function that turns the SExpression into a type again?  I.e., I'd like to get hold of

   Union( f1:OrderedCompletion(Expression(Integer)),
      f2:List(OrderedCompletion(Expression(Integer))),
      fail:"failed",

      pole:"potentialPole")
                                                                   Type: Type

[Waldek Hebisch]

In simple cases one can use 'EVAL', but I but general this not
always works. At Lisp level currently each type constructor
has corresponding function. To create a type you just call this
with appropriate arguments. The devil is in handling non-type
parameters: sometimes we need bare values (which in general
can not be passed to EVAL), sometimes we want to use EVAL).
AFAICS 'dom' gives you bare values.

In principle solution is easy: you need to quote all non-domain
parameters and then use EVAL. But there are some irregulatities
and it is not clear to me if there is any Boot function which
correctly (in all cases) handles what you want. Currently
probably the best shot is:

EVAL(mkEvalable(s))

but 'mkEvalable' does not use information that is needed for
correctness.

Alternative way is via Input form, when you pass it to the
interpreter it will perform various sanity checks and adjustments.

BTW: Please understand that functions like mkEvalable are
internal things which may change with no warning. Historically
changes to such things were quite slow, but I am now working
at significant internal restructuring and things may change
much faster.

--
Waldek Hebisch

[Martin R]

Thank you!  Apparently `unparse$InputForm` works in *very* simple cases.  It does not work in the case of arguments which are lists (as in MultivariatePolynomial) and when arguments are strings (as in Union(T, "failed")).  It also has a minor problem with constructors that do not take arguments.

(I guess that `unparse` is intended for objects)

NB: it's not a major problem for me.

Best wishes,

Martin

(9) -> unparse(dom([1, 2]::Record(a: MPOLY([x,y], INT), b: FRAC INT))::INFORM)

   (9)
   "Record(a: MultivariatePolynomial(x(y),Integer()),b: Fraction(Integer()))"
                                                                 Type: String
(10) -> unparse(dom(1::Union(a: INT, b: "failed"))::INFORM)

   (10)  "Union(a: Integer(),b: failed)"
                                                                 Type: String

[Waldek Hebisch]

On Tue, Apr 14, 2026 at 02:34:11AM -0700, 'Martin R' via FriCAS - computer algebra system wrote:
> Thank you! Apparently `unparse$InputForm` works in *very* simple cases.
> It does not work in the case of arguments which are lists (as in
> MultivariatePolynomial) and when arguments are strings (as in Union(T,
> "failed")). It also has a minor problem with constructors that do not take
> arguments.
>
> (I guess that `unparse` is intended for objects)

Hmm, I get:

(1) -> t := MultivariatePolynomial([x, y], INT)

(1) MultivariatePolynomial([x, y],Integer)
Type: Type
(2) -> t::InputForm

(2) (MultivariatePolynomial (construct x y) (Integer))
Type: InputForm
(3) -> unparse(t::InputForm)

(3) "MultivariatePolynomial([x,y],Integer())"

which looks correct.

If you mean that what 'dom' produces does not work as argument
to 'unparse', that is right: 'dom' contains bare values.

My idea was to use 'typeToForm' from i-coerce.boot, like

typeToForm(dom(1$t), ["InputForm"::Symbol])$Lisp

(where 't' is is above) to get input form. AFAICS this will do
exactly what coercion of a type to InputForm would do, but
starting from result obtained form 'dom'.

> NB: it's not a major problem for me.

There is no need to unparse if the goal is to evaluate. Valid
InputForm can be passed to 'processInteractive'. Actually,
when you have a string, usual idiom is to parse first and
then call 'processInteractive' to evaluate.

> --
> 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...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/21daaba2-2d92-40d0-9cbe-b5783fc85085n%40googlegroups.com.


--
Waldek Hebisch

[Martin R]

The reason for using dom is that the coercion to INFORM does not work with Union:

Union(MultivariatePolynomial([x, y], INT), INT)::INFORM

gives

(Union)

Indeed, this would be *much* nicer for my application.

Best wishes,

Martin

[Waldek Hebisch]

On Tue, Apr 14, 2026 at 08:25:36AM -0700, 'Martin R' via FriCAS - computer algebra system wrote:
> The reason for using dom is that the coercion to INFORM does not work with
> Union:
>
> Union(MultivariatePolynomial([x, y], INT), INT)::INFORM
>
> gives
>
> (Union)
>
> Indeed, this would be *much* nicer for my application.

I have now commited better coercion of types to InputForm. The
above now gives:

(1) -> Union(MultivariatePolynomial([x, y], INT), INT)::INFORM

(1) (Union (MultivariatePolynomial (construct x y) (Integer)) (Integer))
Type: InputForm
(2) -> interpret(%)

(2) Union(MultivariatePolynomial([x, y],Integer),Integer)
Type: Type

There are potential troubles. For example, I can not test the above
using testing tramework. Namely, trying to compare result from
'interpret' to the actual type I get complaint about 'testEqualsAux',
intepreter wants pass String, Any and Type and this does not work.
I tried to produce Any in a different way, using

coerce(t)$AnyFunctions1(Type)

(where 't' contains the type), but then equality test fails.
AFAICS this is due to different representation of types: 'coerce'
produced representation used by runtime system and Spad (that
is domain vector), while 'interpret' produced representation
used by interpreter, that is SExpression.

--
Waldek Hebisch

[Martin R]

cool, thank you!