ask AI questions on fricas codebase

[Qian Yun]

I discovered https://deepwiki.com today and asked it
to index fricas, here is the result:

https://deepwiki.com/fricas/fricas

I have skimmed through the generated doc pages, seems
accurate enough.

I also asked some questions about code base, seems
smart enough to answer some newbie's questions.

Please have a try if you have the time.

- Best,
- Qian

[Kurt Pagani]

Cool, quite impressive, thanks :)

I asked two questions:
* Do you know the connection with aldor?
* Is it feasible to port fricas completely to aldor (instead of
common-lisp based)?


a tiny snippet out of the comprehensive answers
""
Based on the codebase, porting FriCAS completely to Aldor instead of
Common Lisp would be theoretically possible but practically infeasible
due to the deep architectural dependencies on Lisp throughout the system.
""

I also think so. Only recently I tinkered with the aldor interpreter and
have to conclude that it would need enormous effort to obtain a
comparable environment like current fricas is offering.

I made a clang/scan-build of aldor
(https://nilqed.github.io/aldor-scan-build/) and could fix some
SEGFAULTS and included some more #int options in order to change
appearance (prompt/type display) so it looks more like fricas. However,
similar look doesn't mean similar behavior ;)

(see https://github.com/nilqed/aldor/tree/nilqed)

I guess the lisp sceptics have to settle for CL as part of the system ...

[Peter Broadbery]

On Fri, 23 Jan 2026 at 12:23, Kurt Pagani <nil...@gmail.com> wrote:
>
> Cool, quite impressive, thanks :)
>
> I asked two questions:
> * Do you know the connection with aldor?
> * Is it feasible to port fricas completely to aldor (instead of
> common-lisp based)?
>
>
> a tiny snippet out of the comprehensive answers
> ""
> Based on the codebase, porting FriCAS completely to Aldor instead of
> Common Lisp would be theoretically possible but practically infeasible
> due to the deep architectural dependencies on Lisp throughout the system.
> ""
>
> I also think so. Only recently I tinkered with the aldor interpreter and
> have to conclude that it would need enormous effort to obtain a
> comparable environment like current fricas is offering.
>
> I made a clang/scan-build of aldor
> (https://nilqed.github.io/aldor-scan-build/) and could fix some
> SEGFAULTS and included some more #int options in order to change
> appearance (prompt/type display) so it looks more like fricas. However,
> similar look doesn't mean similar behavior ;)
>
> (see https://github.com/nilqed/aldor/tree/nilqed)

This looks useful - the main changes could go into the main code base
if you're happy with that.
(Since I don't use the interpreter mode much, any improvements and
ideas are appreciated)

The clang scan looks good as well - I'll look into getting rid of the
easier issues.

Thanks,

Peter

[Kurt Pagani]

On 25/01/2026 14:29, Peter Broadbery wrote:
> On Fri, 23 Jan 2026 at 12:23, Kurt Pagani <nil...@gmail.com> wrote:
>>
>> Cool, quite impressive, thanks :)
>>
>> I asked two questions:
>> * Do you know the connection with aldor?
>> * Is it feasible to port fricas completely to aldor (instead of
>> common-lisp based)?
>>
>>
>> a tiny snippet out of the comprehensive answers
>> ""
>> Based on the codebase, porting FriCAS completely to Aldor instead of
>> Common Lisp would be theoretically possible but practically infeasible
>> due to the deep architectural dependencies on Lisp throughout the system.
>> ""
>>
>> I also think so. Only recently I tinkered with the aldor interpreter and
>> have to conclude that it would need enormous effort to obtain a
>> comparable environment like current fricas is offering.
>>
>> I made a clang/scan-build of aldor
>> (https://nilqed.github.io/aldor-scan-build/) and could fix some
>> SEGFAULTS and included some more #int options in order to change
>> appearance (prompt/type display) so it looks more like fricas. However,
>> similar look doesn't mean similar behavior ;)
>>
>> (see https://github.com/nilqed/aldor/tree/nilqed)
>
> This looks useful - the main changes could go into the main code base
> if you're happy with that.

Yes, of course :) But do as you like.

> (Since I don't use the interpreter mode much, any improvements and
> ideas are appreciated)

I only committed a hack in this branch for the null pointers below (not
worth a pull request). Works well since.

[#int set history on ...]
Program received signal SIGSEGV, Segmentation fault.
0x0000555555705da7 in dnfIsTrue (xx=0x0) at dnf.c:391

[import from Set]
Program received signal SIGSEGV, Segmentation fault.
0x00005555556d0afc in symeExtensionFirst (syme=0x0) at syme.c:401

>
> The clang scan looks good as well - I'll look into getting rid of the
> easier issues.

Well, I'm not sure if all the 'deref null ptrs' really will have an
impact. Although I providently fixed some, it might be better to wait on
... ?

>
> Thanks,
Thank you as well!
>
> Peter
>

[Peter Broadbery]

On Sun, 25 Jan 2026 at 17:44, Kurt Pagani <nil...@gmail.com> wrote:
> > The clang scan looks good as well - I'll look into getting rid of the
> > easier issues.
>
> Well, I'm not sure if all the 'deref null ptrs' really will have an
> impact. Although I providently fixed some, it might be better to wait on
> ... ?
>

There'll be another release with at least two planned features.
Basically, better type inference, pattern matching, and happy enough
to add more. Timeframe is at least a month, probably two.

Peter