On Thu, Sep 01, 2022 at 07:32:00PM +0200, Kurt Pagani wrote:
> On 01.09.2022 19:11, Waldek Hebisch wrote:
> > On Thu, Sep 01, 2022 at 09:11:33AM -0700, Kurt Pagani wrote:
> >> Problem: when using a type A(p:Polynomial Integer) in another type B, then 
> ...
> > 
> > ATM I see no chance to make this working.  Let me recall what I wrote
> > im March 2021:
> > 
> > : However, as long as use is strictly at
> > : Spad level, types are not used in conditions and
> > : parameters are first assigned to variables and
> > : only variables are passed to constructors, then arbitrary
> > : non-type parameters probably should work (I know of no obstacle
> > : to such use).
> 
> I had this vaguely in the back of my head, but did not find the page.
> Now I can remember that only variables may be passed ... that's why the 
> function
> "g" is working.

I would say "no error is detected", it does not mean int works...
 
> > You violated one of rules above, namely you are passing nontrivial
> > constants directly to constructor.
> 
> Yes, indeed :(
> 
> > 
> > BTW: '2 pretend PINT' is really bad code.  It works only when
> > '2@PINT' works and otherwise silently produces wrong result.
> 
> I only wanted to build an A(0) type and was surprised by the
>  "The value 0 is not of type CONS", so I tried other things (numbers),
> which I don't need, actually.

If you look at BDOM.NRLIB/index.KAF you will see:

(CATEGORY |domain| (SIGNATURE |coerce| ($ (|Symbol|)))
           (SIGNATURE |f| ((A 0) $)) (SIGNATURE |g| ((A |r|) $))
           (SIGNATURE |h| ((A (|pretend| 2 (|Polynomial| (|Integer|))))

And this shous explain source of the problem: constants in signatures
are represented by Lisp expressions directly taken from source.
Later. the expressions are passed (maybe quoted) to Lisp eval.

So 0 produces Lisp integer 0.  But as you can see:

(3) -> PRETTYPRINT(0::Polynomial(Integer))$Lisp
(0 . 0)

0 in Polynomial(Integer) is represented by a pair, with first
element indicating Union branch, in this case base ring R (that
is Integer), the second element is value in R, this time
Lisp integer 0.

This is not easy to fix, because at each place in code we need
to know intended meaning.  Namely, one meaning is syntactic,
the other is actual value in the domain.  ATM we have no way
to represent general domain values in signatures.  Stephen
Watt sayed that during type checking Aldor compares parse
tree of actual argument with parse tree of formal argument.
More or less the same holds for Spad compiler.  But at runtime
we need values from the parameter domain.  So, compiler
and intepreted should insert code computing values.
Unfortunetly this is missing and requires finding all places
where we need to do this.  Additionally, interpreter represents
things differently than Spad compiler, so we need extra
work in interpreter.

-- 
                              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/20220901183821.GB23265%40fricas.math.uni.wroc.pl.

Reply via email to