On Thu, Nov 23, 2023 at 05:06:59PM +0800, Qian Yun wrote:
> So the added check in this commit exposed the bug, real problem
> happen in "formArguments2String" when trying to format a type.
>
> Can the recently added "constructor_to_OutputForm" be helpful
> in here?
We need more. AFAICS trouble is caused by condition which
contains an expression. This is actually _much_ bigger
problem, it is related to using types with nontrivial
parameters in signatures.
Ideally, one should be able to put arbitrary (or at least
resonably complex) expression in place of non-domain parameter
to a type. But currently even "interesting" constants
cause troubles. First step in solving this is to define consistent
representation of such types. Currently compiler/interprter code
basically takes representaion from Lisp. But in Lisp
we have unevaluated expressions which in some situations must
be evaluated to get runtime values. So in fact we get
two distinct Lisp representatins. When we dealing with
expressions, Spad compiler has its own represention which
is later transformed to Lisp. Actually, when typechecking
compiler and interpeter change between various representations.
And interpeter uses different representation than Spad compiler.
So, there is several different representation and only one
'form2String' which tries to handle all and consequently
get confused in more complicated cases.
So proper fix will require work in many places to make
various part consistent. ATM we could try to add some
local tests to avoid popular bad cases, but those are
workarounds that do not solve core problem.
--
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/ZWACjQ6JsdiYGJIt%40fricas.org.
