RE: [Axiom-developer] RE: algebra Makefiles with explicit dependencies, bootstrap, fixed-points etc.

[Bill Page]

Tim, Steve,

On Thursday, January 13, 2005 12:22 AM Tim wrote:
> 
> I think you hit upon a problem with SINT.
> The way it propagates is that in order to compile a domain 
> you need to load the domains it uses. You can see this when
> you watch the loading messages during a compile.
> 
> In order to test one? from SINT the compiler will look at the
> infovec for SINT and find the operation index. This will get
> coded into the domain being compiled. The compiler will also
> look on the property list for the operation to see if there
> are any replacement items.
> 
> So SINT used to call ONEP from lisp in the bootstrap code
> which is coded into the infovec as:
>         (CONS IDENTITY (FUNCALL (|dispatchFunction| 
> |SINT;One;$;11|) $))
> 
> I'll have to look deeper into this issue. Methinks you are 
> on to something.
> 

Actually it was Steve who first saw the details of what is
going on here.

I found a brief paragraph in "Chapter 12 Categories" of the
Axiom book (page 897 of the online PDF version)

http:// ...

that suggests that this issue was (more or less) understood by
the Axiom developers long ago, but perhaps the implications of
the propagation between domains together with cyclic dependencies
was not fully appreciated:

"Categories form hierarchies as shown on the inside cover pages
of this book. The inside front-cover pages illustrate the basic
algebraic hierarchy of the Axiom programming language. The inside
back-cover pages show the hierarchy for data structures.

"Think of the category structures of Axiom as a foundation for
a city on which superstructures (domains) are built. The algebraic
hierarchy, for example, serves as a foundation for constructive
mathematical algorithms embedded in the domains of Axiom. Once
in place, domains can be constructed, either independently or
from one another.

"Superstructures are built for quality-domains are compiled into
machine code for runtime efficiency. You can extend the foundation
in directions beyond the space directly beneath the superstructures,
then extend selected superstructures to cover the space. Because of
the compilation strategy, changing components of the foundation
generally means that the existing superstructures (domains) built
on the changed parts of the foundation (categories) have to be
rebuilt-that is, recompiled."

Do you recall anything else that was ever written about this
during the original development of Axiom?

----------

Steve, in the last email I recall from you about this 

On Monday, January 10, 2005 7:08 PM you wrote:
> On Mon, Jan 10, 2005 at 05:37:27PM -0500, Bill Page wrote:
> > You mean the others are built in the same way, with errors? 
> 
> Yes. All code is identical to what one obtains after a
> `make clean && make', save for RECLOS and ROIRC. 
> 

Thank you for uploading your modified bootstrap files. I have
not yet had a chance to incorporate them into my current
Axiom build. But as I understand from the above message you
first attempts to correct for the propagation effects by
updating the bootstrap files failed - at least for some of
the original files that showed differences on the first
iteration.

What is the current status of your effort to update the
bootstrap files? Having update the bootstrap and run the
fixedPoint interactions, exactly which files still show
differences during the first iteration?

> > ...
> >
> > If the bootstrap files and the database files have been
> > updated but D01AGNT still changes then it must be from
> > some other cyclic dependency.
> 
> But the domain vector for D01AGNT does change in a subtle
> way after the new bootstrap build. Even though its code is
> no different, how the domain is being instantiated has changed.
> More below.
> ...  
> SINT's missing `one?' is more interesting. I need to confirm
> this, but I believe that dependent domains are resolving Monoids
> default definition for `one?'. This might explain why other
> domains, such as D01AGNT, are being instantiated differently
> under the new bootstrap build. I need to look into this further.

There is something called the "add-chain formed by domain
extensions" which is described in the Glossary of the Axiom
book:

  "add-chain

  a hierarchy formed by domain extensions. If domain A extends
  domain B and domain B extends domain C, then A has add-chain
  B-C."

and

  "domain extension

  a domain constructor A is said to extend a domain constructor B
  if A's definition has the form A == Badd.... This intuitively
  means "functions not defined by A are assumed to come from B."
  Successive domain extensions form add-chains affecting the
  search order for functions not implemented directly by the
  domain during dynamic lookup.

  "dynamic lookup

  In Axiom, a domain may or may not explicitly provide function
  definitions for all its exported operations. These definitions
  may instead come from domains in the add-chain or from default
  packages. When a function call is made for an operation in the
  domain, up to five steps are carried out.
  1. If the domain itself implements a function for the operation,
     that function is returned.
  2. Each of the domains in the add-chain are searched; if one
     of these domains implements the function, that function is
     returned.
  3. Each of the default packages for the domain are searched in
     order of the lineage. If any of the default packages implements
     the function, the first one found is returned.
  4. Each of the default packages for each of the domains in the
     add-chain are searched in the order of their lineage. If any
     of the default packages implements the function, the first
     one found is returned.
  5. If all of the above steps fail, an error message is reported.

---------

It is a pity that these concepts were not described in more detail
anywhere else in the main body of the book. It seems strange for
them to be only here in the "glossary".

Although the emphasis here is on "dynamic" to you think that
domain extensions of this kind might be involved in the kind
of propagations that you have observed?

> ... 
> However, it is only a map into the vectors layout. The subtle
> changes which I have noticed in the bootstrap build do not
> involve the `shape' of the vectors. For example, where a certain
> slot was filled with a hard reference to a compiled function,
> now we have a call to the runtime dispatch mechanism. 
> 
> Some of the notes that I promised deal with how byte vectors
> and the runtime dispatch mechanisms work. I hope to get around
> to writing it down soon ;)
> 

BTW, how are those notes coming along? :)

Regards,
Bill Page.