SPAD specification: inheritance of category default implementations (FriCAS vs Aldor)

[Ralf Hemmecke]

Suppose, I have a category with a default function implementation and I
define another category that inherits from the first one an gives
another default implementation for that function.

Can I rely on the behaviour below?

I have tried this in Aldor and seem to remember that somewhere in the
Aldor description it deliberately leaves it unspecified in which order
the defaults are taken. Indeed Aldor yields different results.

I guess I also shouldn't rely on the current behaviour of the SPAD
compiler, right?

Ralf



(2) -> [foo(1)$Bar, bar(1)$Bar, baz(1)$Bar]

(2) [1, 2, 6]
Type: List(Bar)
(3) -> [foo(1)$FooBar, bar(1)$FooBar, baz(1)$FooBar]

(3) [1, 2, 6]
Type: List(FooBar)
(4) -> [foo(1)$BarFoo, bar(1)$BarFoo, baz(1)$BarFoo]

(4) [1, 2, 6]
Type: List(BarFoo)


%%15 >> [foo(1)$Bar, bar(1)$Bar, baz(1)$Bar]$List(Bar)
[1,2,6] @ List(Bar)
Comp: 20 msec, Interp: 0 msec
%%16 >> [foo(1)$FooBar, bar(1)$FooBar, baz(1)$FooBar]$List(FooBar)
[1,1,3] @ List(FooBar)
Comp: 10 msec, Interp: 10 msec
%%17 >> [foo(1)$BarFoo, bar(1)$BarFoo, baz(1)$BarFoo]$List(BarFoo)
[1,2,6] @ List(BarFoo)

[Waldek Hebisch]

On Tue, May 02, 2023 at 02:25:44PM +0200, Ralf Hemmecke wrote:
> Suppose, I have a category with a default function implementation and I
> define another category that inherits from the first one an gives another
> default implementation for that function.
>
> Can I rely on the behaviour below?
>
> I have tried this in Aldor and seem to remember that somewhere in the Aldor
> description it deliberately leaves it unspecified in which order the
> defaults are taken. Indeed Aldor yields different results.
>
> I guess I also shouldn't rely on the current behaviour of the SPAD compiler,
> right?

Well, Spad search for functions is sequential with well specified
order. There may be subtleties due to overloading (say you indeded
types to be equal but they are not) and conditions (if conditions
are not satisfied than search will use later functions that satisfies
conditins), but in general this should be stable.

Look at (sub)chapter 14.2.2 in the FriCAS book, there is part
about search path. Also, Daventport article about Schratchpas II
design gives a lot of details.

IIRC rules are: domain inheritance first, then tree of categories with
depth-first search where order of arguments to Join gives order
on parents.

It is probably not wise to depend on order being depth-first (people
may change order of arguments to Join), but within linear inheritance
chain order should be reliable.

--
Waldek Hebisch

[Ralf Hemmecke]

>> I guess I also shouldn't rely on the current behaviour of the SPAD compiler,
>> right?

> IIRC rules are: domain inheritance first, then tree of categories with
> depth-first search where order of arguments to Join gives order
> on parents.

Yes and the Join makes everything basically unpredictable for a user.
Clearly, the compiler has its rules, but as a user one gets surprises
when one expects one thing but the rules actually tell something else.
And why it should be left unspecified is, because one can have default
implementations in different categories and joins them, if there is
overlapping the rules may give you a definite implementation, but maybe
not the one that one would actually like.

I remember that long time ago I wanted to put lots of things into
category defaults, because then one could have inheritance from multiple
"domains". That works well as long as nothing overlaps. But overlapping
usually happens quite soon. So one has to find the right balance for
what to implement and what not. Category defaults should definitely not
be (ab)used to achieve multiple inheritance.

> It is probably not wise to depend on order being depth-first (people
> may change order of arguments to Join), but within linear inheritance
> chain order should be reliable.

The linear inheritance is actually what I wanted.
Now thinking a bit more then I was actually doubtful of something like this.

)abbrev domain DFOOBAR DFooBar
DFooBar: Join(FooCat, BarCat) == Bar

)abbrev domain DBARFOO DBarFoo
DBarFoo: Join(BarCat, FooCat) == Bar

But that should go always by the rule "domain implementation first" and
so both would be identical to Bar no matter what overlapping defaults
there are in the Join.

> Look at (sub)chapter 14.2.2 in the FriCAS book, there is part
> about search path. Also, Daventport article about Schratchpas II
> design gives a lot of details.

Well, I did and realized that the content does not agree with reality.
Or maybe I am not smart enough to find a button labelled "Linage".
Grepping through the FriCAS sources doesn't find anything for "Lineage".

Ralf

[Waldek Hebisch]

On Tue, May 02, 2023 at 04:36:09PM +0200, Ralf Hemmecke wrote:
> > > I guess I also shouldn't rely on the current behaviour of the SPAD compiler,
> > > right?
>
> > IIRC rules are: domain inheritance first, then tree of categories with
> > depth-first search where order of arguments to Join gives order
> > on parents.
>
> Yes and the Join makes everything basically unpredictable for a user.
> Clearly, the compiler has its rules, but as a user one gets surprises when
> one expects one thing but the rules actually tell something else.
> And why it should be left unspecified is, because one can have default
> implementations in different categories and joins them, if there is
> overlapping the rules may give you a definite implementation, but maybe not
> the one that one would actually like.
>
> I remember that long time ago I wanted to put lots of things into category
> defaults, because then one could have inheritance from multiple "domains".
> That works well as long as nothing overlaps. But overlapping usually happens
> quite soon. So one has to find the right balance for what to implement and
> what not. Category defaults should definitely not be (ab)used to achieve
> multiple inheritance.

Well, multiple inheritance should not be abused. And implementaions
giving significantly different results counts as abuse (OK for
testing, but not for normal use). OTOH if down linear chain we
have enough conditions to use more efficient implementation,
then search should reliably pick later version.

> > Look at (sub)chapter 14.2.2 in the FriCAS book, there is part
> > about search path. Also, Daventport article about Schratchpas II
> > design gives a lot of details.
>
> Well, I did and realized that the content does not agree with reality.
> Or maybe I am not smart enough to find a button labelled "Linage". Grepping
> through the FriCAS sources doesn't find anything for "Lineage".

I not sure why you write about "Lineage". AFAICS it is not present
regardless if you look at code or documentation.

--
Waldek Hebisch

[Ralf Hemmecke]

> I not sure why you write about "Lineage". AFAICS it is not present
> regardless if you look at code or documentation.

Well, look at page 870 of https://fricas.github.io/book.pdf.
Figure 14.15 has a "Lineage" and "Client" and "Benefactors" hyperlinks.

In fact, it seems that the hyperdoc pictures need some revision.

Ralf

[Waldek Hebisch]

You mean "dumps of hyperdoc screens included in the book"? Yes,
they correspond to some very old hyperdoc version. I normally
view documentation via hyperdoc, so I see real thing (dumps
are "texonly"). AFAICS creating new dumps is not that much
work, but this is manual process that must be repeated for
all updates.

--
Waldek Hebisch

[Ralf Hemmecke]

> You mean "dumps of hyperdoc screens included in the book"?

Yes.

> I normally view documentation via hyperdoc, so I see real thing
> (dumps are "texonly").

Too small on my 4K laptop screen. One of the reasons I stopped with
HyperDoc long time ago.

We should at least tell users how to pipe something into xrdb to get a
readable size.

> AFAICS creating new dumps is not that much work, but this is manual
> process that must be repeated for all updates.

Well, since I will not invest time in generating updated picture for
every release, we must live with the old ones as long as HyperDoc lives.

Ralf

[Waldek Hebisch]

On Wed, May 03, 2023 at 01:13:51PM +0200, Ralf Hemmecke wrote:
> > You mean "dumps of hyperdoc screens included in the book"?
>
> Yes.
>
> > I normally view documentation via hyperdoc, so I see real thing (dumps
> > are "texonly").
>
> Too small on my 4K laptop screen. One of the reasons I stopped with
> HyperDoc long time ago.
>
> We should at least tell users how to pipe something into xrdb to get a
> readable size.

Well, FriCAS respects standard X11 geometry parameter, that is

FriCAS.hyperdoc.Geometry: 600x500

will give you 600x500 window. There is also

FriCAS.hyperdoc.FormGeometry

parameter, I am not sure when this one is used. And there are
font/color parameters documented in Chapter 3.8 of FriCAS book.

BTW: Anybody using screen with 4K resolution should be prepared
to give resonable parameters to programs. And unfortunetely,
good large fonts for such screen are nonstandard, so user must
know which fonts to use.

BTW2: There are folks that have huge monitors and good sight.
They use high resolution modes to cram a lot of windows on
the screen. So it is really for user to decide how big the
window should be and what font size to use.

--
Waldek Hebisch