Non type parameters to types

[Waldek Hebisch]

As you may remember for long time non type parameters to types
were problematic. Some time ago I fixed some use cases, but
for example someting like:

Format1DInternal(false)

still was problematic. I just commited a fix to this problem.
Almost surely there are remaing problems, but this is one more
step towards making such parameters fully usable.

--
Waldek Hebisch

[Qian Yun]

Aldor-interface build fails, error message:

=====
(Message Preview)
"ap/DGRPH.ap", line 951:
(|Apply| |SCartesian| 2))
..................................................................^
[L951 C67] #1 (Fatal Error) Expecting a (parenthesized) list here.
=====

- Qian

[Waldek Hebisch]

On Sat, Jul 25, 2026 at 04:41:21PM +0800, Qian Yun wrote:
> Aldor-interface build fails, error message:
>
> =====
> (Message Preview)
> "ap/DGRPH.ap", line 951:
> (|Apply| |SCartesian| 2))
> ..................................................................^
> [L951 C67] #1 (Fatal Error) Expecting a (parenthesized) list here.
> =====

The error happens when generating info about categorty defaults.
Do anybody knows why Aldor wants it? Attached is quick and dirty
patch which disables generating info about defaults. With this
patch Aldor interface builds and passes the two tests that we
have.

--
Waldek Hebisch

[Ralf Hemmecke]

I've just translated FriCAS (with the same Aldor version).
Attached you find the respective DGRG.ap for FriCAS

For FriCAS 1.3.13 6cafaeb7603e379c55244e3d9292ecff5058dd63 there is

(|Apply| |SCartesian|
(|RestrictTo| (|LitInteger| "2") |PositiveInteger|))))

For FriCAS f6d3ff21ce2460ce83cb25bf560fbfc407db27ee there is

(|Apply| |SCartesian| 2)))

Since the Aldor interface or Aldor hasn't changed there must be
something that FriCAS changed in the structures?

I don't know which FriCAS commit caused that change.
Ralf

[Waldek Hebisch]

On Sun, Jul 26, 2026 at 10:21:09PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> I've just translated FriCAS (with the same Aldor version).
> Attached you find the respective DGRG.ap for FriCAS
>
> For FriCAS 1.3.13 6cafaeb7603e379c55244e3d9292ecff5058dd63 there is
>
> (|Apply| |SCartesian|
> (|RestrictTo| (|LitInteger| "2") |PositiveInteger|))))
>
> For FriCAS f6d3ff21ce2460ce83cb25bf560fbfc407db27ee there is
>
> (|Apply| |SCartesian| 2)))

Yes, I know this.

> Since the Aldor interface or Aldor hasn't changed there must be something
> that FriCAS changed in the structures?

This is recent commit, fix for passing parameters to domains.
Attached to my previous message is possible fix, which skips
generating the offending info.

What I do not know is if this info is needed at all. If it is
not needed we could simply remove part of ax.boot responsible
for producing this info. If the info is critically needed,
then we are in trouble: in principle instead of simple thing
like '2' above we may have arbitrarily complex FriCAS expression.
Producing faithful translation of such expression to Aldor is
probably bigger effort than what was already done on Aldor
interface. OTOH it is not clear why Aldor wants information
about defaults: resolving defaults is supposed to happen at
runtime and to compile code all what is needed is information
about available signatures (and not where they are implemented).
If Aldor uses this information for some worthwile optimizations,
then we could try to provide it on "best effort" basis, that
is skip compilcated stuff (which Aldor is unlikely to understand
well enough to optimize) and genrate info for simple cases.
OTOH I do not see how this info could be used to optimize code:
without access to implementation of FriCAS functions Aldor can
not expand them inline. And even trying to hardcode Lisp name
of a function (which could save time spend on runtime lookup) is
problematic, as those names seem to be unavailable in the
interface.

--
Waldek Hebisch

[Ralf Hemmecke]

On 7/26/26 23:24, Waldek Hebisch wrote:
> On Sun, Jul 26, 2026 at 10:21:09PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
>> I've just translated FriCAS (with the same Aldor version).
>> Attached you find the respective DGRG.ap for FriCAS
>>
>> For FriCAS 1.3.13 6cafaeb7603e379c55244e3d9292ecff5058dd63 there is
>>
>> (|Apply| |SCartesian|
>> (|RestrictTo| (|LitInteger| "2") |PositiveInteger|))))
>>
>> For FriCAS f6d3ff21ce2460ce83cb25bf560fbfc407db27ee there is
>>
>> (|Apply| |SCartesian| 2)))
>
> Yes, I know this.

The bad commit is this: 3b68a1899cb2b131d4cb44d4ffc9ccd69b61ca0b

> This is recent commit, fix for passing parameters to domains.
> Attached to my previous message is possible fix, which skips
> generating the offending info.
>
> What I do not know is if this info is needed at all. If it is
> not needed we could simply remove part of ax.boot responsible
> for producing this info. If the info is critically needed,
> then we are in trouble: in principle instead of simple thing
> like '2' above we may have arbitrarily complex FriCAS expression.

I think, I cannot answer this. Peter, can you say something?

Ralf

[Peter Broadbery]

I've not had time to test the updated release, but some comments. 

Aldor will need a expression that evaluates to the desired argument - "(|LitInteger| 2)" is that expression in this case. The surrounding RestrictTo is

to force the value to be read as a PositiveInteger, which may not be needed given that the constructor is not overloaded.

I'd be fairly confident about patching ax.boot - it only appears to deal with a few types properly, rather than arbitrary expressions.

 

Peter

[Waldek Hebisch]

On Mon, Jul 27, 2026 at 10:10:02PM +0100, Peter Broadbery wrote:
> I've not had time to test the updated release, but some comments.
> Aldor will need a expression that evaluates to the desired argument -
> "(|LitInteger| 2)" is that expression in this case. The surrounding
> RestrictTo is
> to force the value to be read as a PositiveInteger, which may not be needed
> given that the constructor is not overloaded.
>
> I'd be fairly confident about patching ax.boot - it only appears to deal
> with a few types properly, rather than arbitrary expressions.

My question is a bit more specific. Current code in ax.boot
generates something like simiplified code below. That is there
is block of Declare-s which looks OK (and below I simpilified
to a single one) followed by a Default block. The trouble is
in Default block. My understanding is that Declare-s tell Aldor
what signatures are exported from given category. But I do
not understand purpose of Default block. The one line patch
that I posted skips generation of Default block and I see
no ill effect from doing this, but I just run tests included
in FriCAS, which is extremally limited testing.

(|Sequence| (|Import| NIL |FriCASLib|) (|Import| NIL |Boolean|)
(|Import|
(|With| NIL (|Declare| |integer| (|Apply| -> |Literal| %)))
|PositiveInteger|)
(|ForeignImport| (|Declare| |dummyDefault| |Exit|) |Lisp|)
(|Export|
(|Declare| |DirectedGraph|
(|Apply| -> (|Declare| |#1| |SetCategory|)
(|With| NIL
(|Sequence| |SetCategory|
(|Declare| |subdiagramSvg|
(|Apply| ->
(|Comma|
(|Apply| |Scene|

(|Apply| |SCartesian|
(|RestrictTo| (|LitInteger| "2")
|PositiveInteger|)))

% |Boolean| |Boolean|)
(|Comma|)))
(|Default|
(|Sequence|
(|Define|
(|Declare| |subdiagramSvg|
(|Apply| ->
(|Comma|
(|Apply| |Scene|
(|Apply| |SCartesian| 2))
% |Boolean| |Boolean|)
(|Comma|)))
(|Lambda|
(|Comma|
(|Declare| |t#1|
(|Apply| |Scene|
(|Apply| |SCartesian| 2)))
(|Declare| |t#2| %)
(|Declare| |t#3| |Boolean|)
(|Declare| |t#4| |Boolean|))
(|Comma|)
(|Label| |subdiagramSvg|
|dummyDefault|))))))))
....

--
Waldek Hebisch

[Peter Broadbery]

Sorry, answering the wrong question again.

 

The default block is necessary during compilation. It tells Aldor that the given signature in the category has a default implementation, and so instances of that category do not need to provide an implementation for the signature.

Lookup of the actual implementation is at runtime.   The generated Aldor default block below is something like:

default

   foo(x: Aa): Bb == never

'dummyDefault' being written as 'never'.

At runtime, Aldor will pick up the spad category and its default implementations.

Peter

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

[Waldek Hebisch]

On Tue, Jul 28, 2026 at 12:10:50PM +0100, Peter Broadbery wrote:
> Sorry, answering the wrong question again.
>
> The default block is necessary during compilation. It tells Aldor that the
> given signature in the category has a default implementation, and so
> instances of that category do not need to provide an implementation for the
> signature.

I see, the following compiles with previous version of the interface:

-----------<cut here>---------------
#include "fricas"

MyOrder : OrderedSet == add {

Rep == Integer;

import from Rep;

(a : %) = (b : %) : Boolean == rep(a) = rep(b);

(a : %) < (b : %) == rep(a) < rep(b);

coerce(a : %) : OutputForm == coerce(rep(a));

}
-----------<cut here>---------------

but it fails if we skip the defaults, saying:

"mord.as", line 3: MyOrder : OrderedSet == add {
........................^
[L3 C25] #1 (Error) The domain is missing some exports.
Missing min: (%, %) -> %
Missing max: (%, %) -> %
Missing <=: (%, %) -> Boolean
Missing >=: (%, %) -> Boolean
Missing >: (%, %) -> Boolean
Missing <: (%, %) -> Boolean
Missing smaller?: (%, %) -> Boolean
Missing latex: % -> String
Missing ~=: (%, %) -> Boolean

> Lookup of the actual implementation is at runtime. The generated Aldor
> default block below is something like:
>
> default
> foo(x: Aa): Bb == never
>
> 'dummyDefault' being written as 'never'.
>
> At runtime, Aldor will pick up the spad category and its default
> implementations.

I wonder what is the simplest dummy (in .ap notation) that Aldor will
accept.

--
Waldek Hebisch

[Waldek Hebisch]

I have now a different patch (attached). With this patch Aldor
interface build OK and the attached file 'mord.as' compiles OK.
However, trying to add it the testsuite I get:

testTrue("1 pretend MyOrder < 2 pretend MyOrder")

Internal Error
The function < with signature (%, %) -> Boolean is missing from
domain UNPRINTABLE

UNPRINTABLE is probably due to changes in printing of files and
is a separate problem. But missing signature seem to indicate
trouble with the interface.

I do not know if this used to work.

--
Waldek Hebisch

[Qian Yun]

In commit 3b68a189, shall "COPY_-TREE(lispize(compForm)))"
be changed to "lisplize(COPY_-TREE(compForm)))", if the goal
is to prevent destructive change to propagate?

- Qian

On 7/25/26 2:46 PM, Waldek Hebisch wrote:

[Waldek Hebisch]

On Wed, Jul 29, 2026 at 07:34:57AM +0800, Qian Yun wrote:
> In commit 3b68a189, shall "COPY_-TREE(lispize(compForm)))"
> be changed to "lisplize(COPY_-TREE(compForm)))", if the goal
> is to prevent destructive change to propagate?

Maybe. AFAICS NRTreplaceAllLocalReferences changes the expression
in unacceptable way, so copy is needed. 'lispize' is also
used without a copy, so changes it is doing probably are OK.

--
Waldek Hebisch

[Peter Broadbery]

This looks to be down to the missing return type on the '<' function.
It's a regression in aldor, as it should be a compilation error.
Replacing the definition with
(a : %) < (b : %): Boolean == rep(a) < rep(b)
works as expected.

Peter

[Waldek Hebisch]

OK thanks. The aldor version I use is:

Aldor version 1.4.0(2c53e759f1e00e345f8b172e7139debda72fda13) for LINUX(glibc2.10+) (debug version)

--
Waldek Hebisch