IndexCard

[Waldek Hebisch]

I tried to provide replacement IndexCard using data from
BrowserInformation. My current version misses important parts,
but I think that I can provide good replacement.

However, current IndexCard has:

coerce : String -> %
++ coerce(s) converts \spad{s} into an \spad{IndexCard}. Warning: if
++ \spad{s} is not of the right format then an error will occur when using
++ it.

This signature exposes internal representation and is incompatible
with replacement. But AFAICS it is also essentially useless:
argument string must be in database format, otherwise it would
not work. So I think that we should remove this signature.

Opinions?

--
Waldek Hebisch

[Grégory Vanuxem]

Hello,

Personally I have no objection to this removal. I don't even know if it is used and as you said it seems useless. 

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

[Tim Daly]

If I remember correctly IndexCard was a simple, throw-away demo.

[Grégory Vanuxem]

Thanks, Tim,

You're a guy, for me, that I like.

Sorry I am not an "affective" guy. I have to do do with that.

Greg

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/f84442a9-af9e-45dc-8624-8456a18cf4c2n%40googlegroups.com.

[Grégory Vanuxem]

I am

[Grégory Vanuxem]

Error. I was traeong other thins. 

[Ralf Hemmecke]

I don´t care much about the old IndexCard.

I know that it appears in the FriCAS book as an example, but I am not so
happy that it entered the FriCAS library by this name. As Tim said it
was meant to be a toy domain. If you now turn it in to a more important
domain to extract information about the library (which I am in favour
of) maybe it would be time to think about a better name. I cannot think
of something good at the moment, but IndesCard is definitely to
non-telling for my taste if that domain is supposed to provide information
about other FriCAS internals.

Just my 2 cents.
Ralf

[Waldek Hebisch]

On Wed, Jan 28, 2026 at 07:43:10PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> I don´t care much about the old IndexCard.
>
> I know that it appears in the FriCAS book as an example, but I am not so
> happy that it entered the FriCAS library by this name. As Tim said it was
> meant to be a toy domain. If you now turn it in to a more important domain
> to extract information about the library (which I am in favour of) maybe it
> would be time to think about a better name. I cannot think of something good
> at the moment, but IndesCard is definitely to non-telling for my taste if
> that domain is supposed to provide information
> about other FriCAS internals.

Well, it is not going to be more important. Simply:
- We need a demo as part of FriCAS book. If IndexCard were removed
we would need a replacement.
- For 30+ years IndexCard was the only documented way to get
information about constructors and operations from Spad
programs. Some users may depend on it.

I hope that for retrieving information about constructors and
operations BrowserInformation will be much better. But I not
for deliberatly breaking old code without any warning.

The two reasons above means that I would like to have working
IndexCard. As I wrote I have now a preliminary version that
works on top of BrowserInformation.

I would prefer that people writing new code use BrowserInformation,
but at least for now I do not want to remove IndexCard. But
I want to remove (most of) Boot that was called by IndexCard.

Actually, ATM in my private version of FriCAS IndexCard and a
helper for checking backward compatiblity in BrowserInformation
are the only users of 'libdb.text' and 'comdb.text'. Once I
integrate new IndexCard into my private version I will be
able to remove old database support from it. There are
probably still months to the moment when new code is mature
enough to include it in the trunk, but some pieces (probably
a new IndexCard) may go in earlier.

--
Waldek Hebisch

[Tim Daly]

Not that it matters but I'd be in favor of removing libdb.text and comdb.text.

On a more creative note I can think of five potential ways to make IndexCard

much more useful.

One path is to expand the domain to support full SQL queries of category

and domain information (BrowserInformation) or of an external database.

One could consider IndexCard as the "bibliography domain" which provides

bibliographic reference information with external hyperlinks. Good research

always involves bibliographic references. Every domain would have a

"biblio" function.

Another path is ANKI-style "flash cards" that can be customized to help people

remember mathematics and their expression in the command line for a wide

range of topics. Most useful would likely be either integration or linear algebra.

Each index card would present a working example of each function.

Another somewhat more ambitious path would be to come into the 21st century

and make it a "cover" for the MCP LLM protocol allowing two-way access for an

LLM. That way it would integrate LLM input/output to the system. Fill out an

"index card", sent it to the LLM, and present the reply in another "index card".

IndexCard would be a "cover" for an underlying MCP.

The remaining idea is to integrate LEAN theorems / proofs. IndexCard could

provide access to known LEAN theorems that relate to current Catgegories,

Domains, Packages, and Functions. A simple example would be group theory

related proofs for Category information (e.g. Commutative) or to prove the

GCD algorithm used in the system.

Just because your only tools are hammers doesn't mean you can't use them

to learn to juggle.

Tim

Tim

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/Y2nhGiAriL0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/aXp42weQsnhFPc0q%40fricas.org.

[Grégory Vanuxem]

Hello, 

Le jeu. 29 janv. 2026, 06:53, Tim Daly <axio...@gmail.com> a écrit :

Not that it matters but I'd be in favor of removing libdb.text and comdb.text.

Alléluia 

I forgot to thanks again on my last mail, at beginning of my mail, Waldek.

I was hurry. Loving something can hurts women gentle things. I am used. Thanks for all here. 

Not readed the rest of your mail. Just an epidemic though. 

Have a good day, 

Cordially, 

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/CAJn5L%3DJzc0kOfvYuLABWksPMfP1V4DcHVrnx5fCRmuTGNLRAcA%40mail.gmail.com.