functions that return function

[Ralf Hemmecke]

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.

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.

I just want to know what actually should work for such situation or
whether that is not implemented at all.

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.

Has someone seen similar situations?

Ralf

[Waldek Hebisch]

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.

> 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

[Grégory Vanuxem]

Le mer. 22 oct. 2025 à 03:14, Waldek Hebisch <de...@fricas.org> 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

> --
> 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/aPgv_lEQrEw3eGG6%40fricas.org.