Ralf Hemmecke wrote:
> Is there any particularly deep reason why the build system extracts each 
> pamphlet into separate .spad files, i.e. one for each 
> domain/package/category?
> 
> I guess (modulo dependency resolution) it should be fine to build one 
> .spad file from one .spad.pamphlet file and compile that.
> 
> Putting everything into separate files ... doesn't that give problems if 
> someone thinks about defining two domains that mutually depend on each 
> other? Shouldn't they be compiled in one stroke?

Currently having separate files is a crucial help in resolving
dependencies.

> I would be even more happy if we had
> 
>    .spad.pamphlet -> .spad -> .lsp -> .fasl -> .o
> 
> all with the same data. In particular no FOO.NRLIB directories for each 
> separate constructor. Is this too wild a dream to be achievable in the 
> near future?
> 

All are relatively easy, simply ratio effect/effort seem to be
lower than for other projects.  Consider:

- binding to GMP (= much faster bignum multiplication with sbcl)
- faster GCD for polynomials with algebraic coefficients
- binding to Lapack/ATLAS
- noncommutative Groebner bases (in "solvable" Ore algebras)
- adding new special functions
- making integrator faster (so that it can in practice do integrals
  which theoretically it is capable of doing)

I work on things above and IMHO the I consider effects more
significant that simplifing file structure of compiler output.

Note: I think that changing or replacing database mechanism
to allow easy addition (installation) of new constructors
would be useful (simplify creation of packages).  OTOH just
now it is possible to create packages on top of ')read' and
')lib', so this has reduced priority.

-- 
                              Waldek Hebisch
[email protected] 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en.

Reply via email to