[Axiom-developer] Re: organization

[David MENTRE]

Hello Tim,

Your email is quite interesting.  Please find below my questions on your
approach:

root <address@hidden> writes:

> For each domain contruct an "index card" that contains various fields
> (the index card is the structural equivalent of a "concept"). Given a
> set of these index cards each field has at least one default ordering
> and a default search mechanism. 
>
> The data for the fields in the index card can be constructed by 
> automated programs, for example, the compiler.

> Of course each of the parts contains subparts (the individual list of
> functions) and references to other index cards (Cat with sigs), etc.
> So in general there is a lot of implied structure given on each index
> card.

How would you define the structure of each card? Using Common Lisp data
type? Specifically defined data types? With a Card Definition Language?
Using standardized tools as W3C RDF or OWL? Using ACL2 common lisp
subset? 

> Having created this pile of index cards we can look at the implied
> structures and other interesting organizations.
>
> Now if we look at a given FIELD in the set of index cards we can create
> a program which connects the cards together. So we could classify
> the cards into many networks, at least one per field. For instance, 
> we could create the inheritance lattice based on the way that one 
> domain uses another. 

Building new structures _dynamically_ is important there. I would like
to build a structure, examining it and find it misses something, build a
new one and finally save it as a card because I find it interesting.

> There can be many kinds of index cards created by many kinds of parsers
> (e.g. an index card that parses a pamphlet file into component parts
> like title, list of chunk names, list of section names, etc). 

How would you store the cards? On disk? As Common Lisp data structure?
On a web server?

> The general picture emerges of a very rich set of objects (the various
> index cards) that are classified into dozens of different relationships. 
> You can construct predicates that walk many different paths to answer a
> question. For example, find the function that will be called to
> multiply a matrix of complex numbers by a vector of polynomials over
> the integers and tell me what file contains it. We could compute the
> coercion from one domain to another per Nicolas's thesis.
>
> This approach breaks the problem into three parts, 
> writing parsers to automatically construct the index cards, 
> constructing the relations, 
> constructing the queries.

I would add:

 define a common repository for card structures (with attached semantics
 for each field, or reference to other card structures)


> (The generalization which I'm exploring but not explaining is that the
> index card itself is just another network. The whole thing eventually
> dissolves into a very large, structured network but it's too complex
> to explain that way).
>
> I'm essentially constructing the index cards for the algebra (by hand
> at the moment) to experiement with this idea. I'll post the reduced
> form of these once I've completed the first pass.

I would be interested to write index cards starting from the source
file.

For example, considering the simplest card:

Source file : file-name-type
Subsystem   : choice-in(boot database spad-compiler spad-interpreter ???)
Explanation : english-text

source file                   subsystem explanation
-----------                   --------- -----------
src/boot/Makefile.pamphlet      boot    building of the boot parser sub-system
src/boot/boothdr.lisp.pamphlet  boot    header for boottran lisp package
src/boot/bootload.lisp.pamphlet boot    loading of various lisp files 
constituing the boot subsystem
src/boot/btincl2.boot.pamphlet  boot    parsing of included lines in boot 
sources
src/boot/btpile2.boot.pamphlet  boot    handling of piles (source indentation) 
in boot
src/boot/btscan2.boot.pamphlet  boot    parsing of boot syntax
src/boot/ccl-bootsys.lsp.pamphlet       boot    loading of several lisp files 
constituing the boot subsystem
src/boot/ccl-depsys.lsp.pamphlet        boot    lisp file used to build depsys 
on top of CCL
src/boot/exports.lisp.pamphlet  boot    set of lisp symbols exported by the 
boottran package
src/boot/npextras.lisp.pamphlet boot    definition in lisp of various boot 
variables and elementary functions
src/boot/ptyout.boot.pamphlet   boot    set of lisp functions to translate boot 
into common lisp
src/boot/tyextra.boot.pamphlet  boot    ?? Handling of boot data structures ??
src/boot/typars.boot.pamphlet   boot    ?? Handling of boot syntax ??
src/boot/typrops.boot.pamphlet  boot    Parsing of boot keywords (tokens?)
src/boot/tytree1.boot.pamphlet  boot    transformation of boot into common lisp
src/doc/msgs/co-eng.msgs        database        list of error messages
src/doc/msgs/s2-us.msgs database        list of Axiom error messages

After that, I would like to dig into each file and build new cards, for
example describing the internal structure of s2-us.msgs. I would like to
build cards indexing each boot or lisp function, using internal
information from the compiler.

Now, two last but probably most traitorous questions:

 - do you thing we could be quickly a tool to navigate in cards? I think
   a computerized tool is of most importance to attack Axiom
   complexity. I can imaging throwing some common lisp data structure
   and functions, however it might become rapidly unusable. Have you any
   idea of a (free software) tool that we might reused?

 - don't you think attacking this issue now could delay too much the
   release of a _stable_ Axiom (with a documentation, which is probably
   the most lacking currently)? What about people that have submited bug
   reports?


In short, I like your approach and I'm eager to apply it (however not on
the algebra ;-). However, I fear it would delay more important tasks.

Yours,
d.
-- 
David MENTRE <address@hidden> -- http://www.nongnu.org/axiom/