BUG: a package is a domain?

[Ralf Hemmecke]

When I enter this


GETDATABASE('ElementaryFunctionsUnivariateLaurentSeries,
'CONSTRUCTORKIND)$Lisp

into FriCAS, the result is:

domain

But the file says

)abbrev package EFULS ElementaryFunctionsUnivariateLaurentSeries

and I don't see anything that justifies that this is not a package.

How does FriCAS compute whether something is a package or domain?

It currently leads to a wrong list here:
http://fricas.github.io/api/Domains.html

Ralf

[Ralf Hemmecke]

I'm not sure, but maybe an indication for the wrong DB entry (domain
instead of package) of the following packages might be that all these
packages get their exports from a category.

A comment in ncomp.spad

-- at this stage distinction between domain and package does
-- not matter, so we treat packages as domains

https://github.com/fricas/fricas/blob/master/src/interp/ncomp.boot#L172

and in define.boot

------->This next line prohibits changing the KIND once given
--------kk:=GETDATABASE($op,'CONSTRUCTORKIND) => kk

https://github.com/fricas/fricas/blob/master/src/interp/define.boot#L423

makes me suspect that the packages below get assigned a DB entry of
"domain" which is not corrected later. I have however no idea how to
prove my suspicion.

Maybe someone can fix this easily.

ElementaryFunctionsUnivariatePuiseuxSeries efupxs
ElementaryFunctionsGeneralizedUnivariatePowerSeries genser
ElementaryFunctionsUnivariateLaurentSeries efuls
TaylorSeriesExpansionGeneralized serexp
TaylorSeriesExpansionTaylor serexp
TaylorSeriesExpansionPuiseux serexp
TaylorSeriesExpansionLaurent serexp
GuessOptionFunctions0 mantepse
ModularEvaluation1 evalut
ModularEvaluation2 evalut
ModularAlgebraicGcdTools3 amodgcd
ModularAlgebraicGcdTools4 amodgcd
ModularAlgebraicGcdTools2 amodgcd

Additionally, there is a wrong )abbrev entry.

-)abbrev domain LODO3AUX LinearOrdinaryDifferentialOperator3Aux
+)abbrev package LODO3AUX LinearOrdinaryDifferentialOperator3Aux

Can I commit the attached patch?

Ralf

[Waldek Hebisch]

Patch yes, please commit. OTOH please understand that difference
between package and domain is fuzzy, it is more developer intent
than science. Aldor UG gives definition (exports depend on %),
and FriCAS tries to implement it, but this definition does not
work well in cases above...

Also, package/domain distintion is mostly about complaining
to user that they used wrong word...

--
Waldek Hebisch

[Ralf Hemmecke]

> Patch yes, please commit. OTOH please understand that difference
> between package and domain is fuzzy, it is more developer intent
> than science.

Of course, I understand that. And it's not vitally important. I've
already reprogrammed api.spad yesterday to actually depend on what is
written in )abbrev. Also not very reliable, but at least that can be
fixed more quickly as in the patch that I've proposed.

> Also, package/domain distintion is mostly about complaining
> to user that they used wrong word...

Yes, yes. But for a user it still makes a difference. One can easily
say, a domain contains elements, a package just provides functions.
Of course, "contains elements" is in fact wrong, since looking at SPAD
as a OOP programming language then the domain describes the element object.

Anyway, am I right that you don't intend to invest time to fix the
domain<-->package problem for the packages that I've listed in my
previous mail?

Ralf