axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Algebra bootstrap


From: Waldek Hebisch
Subject: Re: [Axiom-developer] Algebra bootstrap
Date: Wed, 7 Feb 2007 04:40:00 +0100 (CET)

Gabriel Dos Reis wrote:
> Waldek Hebisch <address@hidden> writes:
> 
> | 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).
>

Try starting with minimal databases.  You will get messages as:

Integer is not a known type

or

Boolean is not a known type

Compiler do have _some_ knowledge: Record, Union, Mapping and
Enumeration are built-in.  There are some more or less random
pieces of information hardcoded in various parts of the compiler.
But Integer, Boolean and List are recognized only if present in
databeses.

Note that already postTransform uses semantic information:

postAtom x ==
  $BOOT => x
  x=0 => '(Zero)
  x=1 => '(One)
  EQ(x,'T) => 'T_$ -- rename T in spad code to T$
  IDENTP x and GETDATABASE(x,'NILADIC) => LIST x
  x
               ^^^^^^^^^^^^^^^^^^^^^^^

and parseTransform (more precisely parseHas) again preforms database
lookup. 
 
> | 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.
> 

I use the following Integer for bootstrap:

)abbrev category INS IntegerNumberSystem
IntegerNumberSystem(): Category == with nil
)abbrev domain INT Integer
Integer: IntegerNumberSystem with
    FakeIdentityToAppeaseSpad: % -> %
  == add
    FakeIdentityToAppeaseSpad(x) == x

This is enough to convince compiler that Integer is a valid type.  I do
not see how better Integer will help in bootstrap.  More precisely to
bootstrap you need to resolve forward references.  And the problem is
that in _last_ bootstrap pass there is a lot of forward references.
I do not think that will help resolve those references.

I guess that you think about something like classic compiler bootstrap,
where you need to get translator for small language running and than
you can use it to translate rest of the compiler.  In particular such
set of basic domains would allow to write large part of compiler in
Spad.  But current bootstrap problem is really all about databases,
we do not care if during database bootstrap we get correct code (or
any code at all), we just want to collect type declaration.  And
we need a lot of declarations in databases to start compiling
current Axiom algebra.

> | 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.
> 

That was just a sanity check of what I did.  All I am saying here is
that my attempt to create small system failed (it does not mean that
other will fail -- I certainly did not try hard and gave up early).

> | > 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" :-)
> 

Few months and longer.

> | 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?
> 

I wrote: parse tree.  More precisely I took output of Meta parser, just
before call to postTransform.  I replaced call to postTransform by
call to a simple flattener (to replace nested trees having semicolon
as operator by lists) and pretty-printed the result of flattener 
(without flattening the expression had too much nesting and
pretty-printer could not print it correctly). 

> 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!
> 

My Lisp code is throw-away code (or research if you prefer such name).
The basic thing is that I am getting better turnaroud with sbcl.  
I can load the algebra tree into sbcl in about half of second (I am
loading it from a fasl).  Tree walk trough this tree takes small part
of second.  If I have large output most of the time is spent pretty-printing
the results, which may take few seconds.  If results are small the
whole run may finish in a second.  I do not see how I could get
such turnaroud working inside Axiom tree.  FYI, Axiom needed about
70 seconds to parse algebra -- I certainly do not want to loose
70 seconds each time I try something.

> [...]
> 
> | 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 do not want to use output of parseTransform because it depends on
databases.  If databases miss some information the resulting tree
is incorrect (sometimes the compiler will later fix such a tree, but
many cases lead to errors).  

I think that currect Axiom apprach to compilation has serious flaw.
Namely postTransform and parseTransform are dane _before_ macro
expansion.  This means that they have only limited syntactic
information and some transformations just work blindly.  Both
parseTransform and postTransform compensate this lack of syntactic
data by use of semantic informations from databases.

I think that macro expansion should be done just after initial parse
(before any semantic transformations), that is why I have written
my macro expander.  BTW: current Axiom way allow pretty weird 
macro tricks, but it seems that algebra uses only small, well
behaved subset.

P.S. Thanks for the attached code.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]