On 10 Jul 2022, at 14:28, Waldek Hebisch <[email protected]> wrote:
>
> Anyway, once you have type, it passed all checks
> that we have so you can be resonably confident
> that type is correct (there are known bugs in
> corner cases). With type expression all this
> work to check type is before you. You could
> probably cop out and use interpreter to evaluate
> types, but ATM there are some traps, interpreter
> is handling types slightly different than Spad
> compiler (and our runtime system).
I think I found one of those traps. Consider the package:-
)abbrev package FRIMACS Frimacs
Frimacs: Exports == Implementation where
Exports ==> with
showOpImpSummary : (t:Type) -> Void
Implementation ==> add
showOpImpSummary(t) == showImp(t)$Lisp
this seems to work okay, for example, in the REPL:-
showOpImpSummary(Expression(Integer))$Frimacs
prints out a nice summary showing where each operation is implemented.
However, it fails if you give it a domain that uses a symbol as parameter, for
example:-
showOpImpSummary(Variable(‘z))$Frimacs
gives:-
System error:
The variable |z| is unbound.
On the other hand, supplying the type as a package parameter seems to work:-
)abbrev package FRIMACS2 Frimacs2
Frimacs2(t:Type): Exports == Implementation where
Exports ==> with
showOpImpSummary : () -> Void
Implementation ==> add
showOpImpSummary() == showImp(t)$Lisp
so that now:-
showOpImpSummary()$Frimacs2(Variable(‘z))
gives a nice summary description, as it does for every other type I’ve tried so
far.
Paul
--
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/D164E466-9789-492B-9B9F-551D64205867%40gmail.com.
