Re: [Axiom-developer] New branch?

[Waldek Hebisch]

Gabriel Dos Reis wrote:
> Waldek Hebisch <address@hidden> writes:
> 
> | I consider starting a new branch.  I feel that Axiom needs a period
> | of faster developement, in particular removing and/or cleaning old
> | code.
> | 
> | General directions:
> | -- generate all information that can be generated (documentation,
> |    images, databases)
> | -- remove unused code (both old and new but unfinished)
> | -- rework file handling (current code is buggy, complicated and
> |    inefficient)
> | -- improve SPAD compiler
> | 
> | My goals partially overlap with goals of build-improvements, but
> | I reached a point where I need deeper changes (including compiler)
> | to support better build.  Also, unused/needlessy complicated code
> | makes changes and understanding harder, so I think that cleanups
> | and removals should be done quickly -- accepting risks of 
> | temporary breakage.
> 
> >From my priority list, "improve SPAD compiler" has a strong list.
> I do hope there is no duplicate effort there.  Yesterday, I was
> considerig gdr-sandbox from build-improvements, but maybe we should
> just work on compiler-improvements branch and deal with the merges?
> 

My curent plan for the compiler is as follows: parse all the algebra
files and invoke a new mini-compiler on the result. In the first stage
this new compiler should just collect declarations and emit 
databases.  Besides direct benefits this is intened to verify my
understandig of abstract syntax and typechecking of SPAD. In the
next stages the new compiler should act as a pre-pass for current
SPAD compiler, incrementally taking more and more responsibilities.

However, I think that before making such changes I need preparations
(cleanups, helper variables and routines ...).  Here I would like
to go fast forward -- the whole thing is experimental and if 
something fails it is better if it fails quickly.  

Concerning compiler-improvements branch: If you think about merging
changes for private branches I would think that first we need some
real working code to merge.

> As for the databse, I have strong feeling that we should not
> underestimate the work done by the dynamic libraries community. 

Could you elaborate: I feel that I have adequate understanding
of dynamic code generation and linking but maybe I am missing
something?

-- 
                              Waldek Hebisch
address@hidden