Re: [Axiom-developer] Algebra bootstrap

[Gabriel Dos Reis]

Waldek Hebisch <address@hidden> writes:

| > 
| > I think we need to have a basic interpreter, and a basic compiler
| > in the sense that they are almost like the interpreter and compiler,
| > but they "know" only 
| > 
| >    * simple types: Boolean, Integer, Float
| >    * constructed types: List(T), Vector(T)
| >    * fundamental structure: Category
| > 
| > Form that, we must separate and rationalize the database construction.
| >
| 
| Current compiler (before algebra bootstrap) does not know about Integer.

I don't think so.  

The internal AST that eventually reaches the type analyzer and the
semantic analyzer, starting from compTopLelve, already contain mention
of Integer (and the other basic types).

| And Integer depends on large part of algebra.  So I would say that such
| basic compiler while a noble goal would require substantial algebra
| rewrite.  Such rewrite in turn need something like Aldor post facto
| extension.

By "simple type", I don't expect the basic type to understand beyond
simple operations defined on their domains.  

The glorious version of Integer is not needed wholesale when starting
the boostrap process.  The glorification is a set that needs to come
after.  Yes, post facto extensions are ways to achieve late
glorification -- and if you look at the practice, this is not fancy;
just think "type classes" (Haskell), which Axiom would have invented
two decades ago if it had post facto extensions.

| As an excercise I tried to make a minimal algebra.  I compiled
| about 20 very simple domains and categories and generated corresponding
| databses, but resulting interpreter was non-functional.  More effort
| would probably give functional system, but ATM I am not sure if such
| system is useful for bootstrap.

I don't think the interpreter is a good way tp arrive to the
bootstrap.  We must be in "type checking" mode, not "type inferencing"
mode where we will be trying to infer and load things.  No, that way
lies madness.

| > We must also be able to process a file without first having to split
| > it into several chunks.  We have been able to process SPAD files that
| > way; making )abbrev a no-op.
| > 
| 
| In longer run sure.

Well, Axiom has 25-year horizon; so not sure what you mean by 
"longer run" :-)

| ATM I am using quite different method: I dumped
| parse trees of the whole Axiom algebra into a file.  So now I can load
| the whole algebra just as a single S-expression. 

Well, (almost) everything is an S-expression; so I must ask which
"form" do you save an load?  The parse tree?  the parse form?  The
internal AST? or the generated Lisp code?

What other thing we have been doing, we have found both the parse form
(not the parse tree) and the internal AST useful to save and load later.
A third form, not conveniently present in Axiom at the moment, is one
where either the parse form or the internal AST is completely typed
(just before code generation).

| I am loading this
| S-expression into sbcl running various analyses on it.  The idea is to
| write (in Lisp) a simple compiler capable of extracting type declarations
| and generating from them Axiom databases.

Oh, that is simply done in Boot and I do hope you don't go to Lisp for
that.  Just catch the parse form from postTranform or parseTransform.

I do sincerely hope, we don't end up multiplying parsers, analyzers,
type checkers, macro expanders, each with its own share of bugs, and
mix all those in form or Axiom!

[...]

| Concerning abbrev declaration: I am not sure how to find out wether
| something is a package or a domain without using information from
| abbrevs.

We should get to a poing where we don't need to distinsguish that!

Now, if you look at a capsule, it tells your whether something "is"
for a domain or not by the presence or absence of 'domain in the
category declaration.  Again look at the the internal AST produced by 
parseTransform.

I'm sorry the whole documentation is not online yet, but many things
are happening and I need to petition for 48h in a day.

Th algebra interface to the parser is very simple minded.  There is
work going on to define different levels of fully typed ASTs.


-- Gaby

gdr-reader.boot
Description: Text document

gdr-spad-parser.spad
Description: Text document