RE: [Axiom-developer] [MutualRecursion] (new)

[Peter Broadbery]

On Tue, 2005-01-18 at 17:42 -0500, Page, Bill wrote:
> On Tuesday, January 18, 2005 3:50 PM Peter Broadbery wrote:
> > ...
> > > > 
> > > > I wonder how the Aldor compiler handles such mutual
> > > > recursive structures. Perhaps Peter Broadbery knows.
> > > 
> > > I would also like to know.
> > 
> > [Disclaimer: I'm not an expert on the type checking bit -
> > and if you want info, it is nicer to ask]
> >
> 
> It's great to find out that there is someone here to ask!
> Thank you very much for taking the time to explain. In the
> future I will try to ask in a more polite manner. :)

No worries.  I replied mostly on aldor issues - I know that area much
better than I do axiom.

> > ... 
> > If you have a situation with mutually referencing domains
> > in separate files, then you have to use the extend keyword,
> > and build the defn. up in steps - there may well be an
> > example or two of this in the aldor library sources shipped
> > with the compiler.
> 
> The point of this discussion (for me at least) is to understand
> the problem of attempting to build the Axiom library from spad
> code alone. Apparently in the previous century Axiom had always
> been built using a running system. (So says Tim Daly.) So it
> seems that the Axiom algebra evolved incrementally over time,
> gradually building one layer on top of another and (for the
> most part) discarding the information about the path that
> lead to the then current state of the library. Each port of
> the system to a new environment was built with the resources
> of the old and as a whole over time the library became more
> tightly integrated and highly structured. This seems like a
> remarkable thing to study from a historical perspective since
> it seems to run counter to the evolution of most software.

I'd say this is how most s/w behaves - gradually accumulating layers of
stuff.  Just that it isn't hidden in axiom's case.

> .. MutualRecursion...

Much of the circularity comes mainly from exported signatures - It _may_
be possible to statically determine all the type signatures from
the .spad files, write out as a bootstrap definition, then compile
against these definitions. 

This won't handle code changes caused by the inliner making different
decisions based on domain implementation knowledge (replacing function
calls with their defintion where possible), but these should always be
conservative.

Regards,

Peter.