Le mer. 22 oct. 2025 à 03:14, Waldek Hebisch <[email protected]> a écrit :
>
> On Tue, Oct 21, 2025 at 07:54:14AM +0200, 'Ralf Hemmecke' via FriCAS -
> computer algebra system wrote:
> > Now this might be a report that is perhaps not reproducible.
> > I still want to report although I no longer have the files to demoonstrate.
>
> It is hard to do anything without a reproducible testcase.
+1
-- Greg
> > Suppose I have two functions
> >
> > ZZ ==> Integer
> > foo: ZZ -> ZZ -> Boolean
> > foo: ZZ -> (ZZ, ZZ) -> ZZ
> >
> > in a package/doman A and I want to call them from another domain that also
> > has such functions.
> >
> > Conclusion is that I have to package-call them using foo $ A.
> > Somehow the compiler was (for my situation) unable to distinguish the two
> > functions from the context.
> > I should have been able to discriminate using the @-notation.
> > However, how exactly do I specify such double post-fix stuff?
> >
> > ((foo $ A) @ (ZZ -> Boolean))(2)(4)
> >
> > did not compile.
>
> In principle it should compile.
>
> > I just want to know what actually should work for such situation or whether
> > that is not implemented at all.
>
> Both Spad compiler and interpreter try to handle such things. Why
> it did not work for you? Code to handle this case could be a missing.
> Some other case can declare your code as an error, before handler for
> right case can do anything. There are many possibilities for bugs.
> For example:
>
> (1) -> parse("((foo $ A) @ (ZZ -> Boolean))(2)(4)")$InputForm
>
> (1) (((@ ($elt A foo) (Mapping Boolean ZZ)) 2) 4)
> Type: InputForm
>
> This shows that interpreter parser transforms "ZZ -> Boolean" into
> "Mapping(Boolean, ZZ)". Conseqently, in right places interpreter
> needs special handling for Mapping.
>
> > Another issue that I saw recently was that I had a construction like
> >
> > (foo $ A)(a)(b)
> >
> > where the error message of the compiler claimed that elt a b does not work.
> > After I added a dot like this
> >
> > (foo $ A).(a)(b)
> >
> > it compiled. Obviously the parenthesis around the first object change
> > something in the associativity of function application. Sorry, that is also
> > something I can currently no longer reproduce.
>
> I get:
> (2) -> parse("(foo $ A)(a)(b)")$InputForm
>
> (2) ((($elt A foo) a) b)
> Type: InputForm
> (3) -> parse("(foo $ A).(a)(b)")$InputForm
>
> (3) (($elt A foo) (a b))
> Type: InputForm
>
> So, at least intepreter thinks that in second case it should apply 'a'
> to 'b' first, and than take result as argument to 'foo'. That is
> quit different than applying 'foo' to 'a' and than applying result
> to 'b'.
>
> > Has someone seen similar situations?
>
> When I do my calculation I see various weird cases. When it is
> looks like a bug I am trying to fix it. But in borderline cases
> I frequently just do things in a sligthly different way to
> avoid weirdness. And there is a lot of cases waiting to
> be fixed.
>
> --
> 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 visit
> https://groups.google.com/d/msgid/fricas-devel/aPgv_lEQrEw3eGG6%40fricas.org.
--
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 visit
https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZTjcTf2O-KzdecoGaboH5gFUyNxCx5QjLpT9h%3DtNcBCQ%40mail.gmail.com.
