libaxiom.al: dependencies
Ralf Hemmecke
I've checked now what dependencies you have calculated in src_aldor2.
That seemingly differs by a few domain.
Maybe it is important, but maybe not. Therefore my question. Do you know
enough about the aldor compiler internals to be able to say something
about the following?
Suppose I have 3 files a.ap b.ap, c.ap where a depends directly on b but
not directly on c. And where b depends directly on c.
Now I want to create the corresponding .ao file.
Is it enough if while compiling a.ap that only b.ao is mentioned as a
library?
The current compiler 1.1.0 compiles the stuff below without problem. If
it really is enough to list direct dependencies why should one bother to
figure out dependencies recursively?
It might be different if I try to compile to .a files, but I am speaking
here only of the .ao files which are necessary for the libaxiom.al
construction.
Ralf
---BEGIN a.as
#include "aldor"
#library LLL "library"
import from LLL;
AAA: with {
afoo: % -> %
} == add {
Rep == BBB;
import from Rep;
afoo(x: %): % == per bfoo rep x;
}
---END a.as
---BEGIN b.as
#include "aldor"
#library LLL "library"
import from LLL;
BBB: with {
bfoo: % -> %
} == add {
Rep == CCC;
import from Rep;
bfoo(x: %): % == per cfoo rep x;
}
---END b.as
---BEGIN c.as
#include "aldor"
CCC: with {
cfoo: % -> %
} == add {
cfoo(x: %): % == x;
}
---END c.as
---BEGIN Makefile
a.ao: a.as libbbb.al
cp libbbb.al liblibrary.al
aldor -llibrary $<
libbbb.al: b.ao
ar r libbbb.al $<
b.ao: b.as libccc.al
cp libccc.al liblibrary.al
aldor -llibrary b.as
Bill Page
> ...
> Suppose I have 3 files a.ap b.ap, c.ap where a depends directly on b but
> not directly on c. And where b depends directly on c.
>
> Now I want to create the corresponding .ao file.
>
> Is it enough if while compiling a.ap that only b.ao is mentioned as
> a library?
>
> The current compiler 1.1.0 compiles the stuff below without problem.
> If it really is enough to list direct dependencies why should one
> bother to figure out dependencies recursively?
Isn't the point of chasing dependencies to find the strongly connected
components, i.e. the cycles in the dependency graph? As I understand
it, these need special treatment.
Or did you mean something else by this question?
Regards,
Bill Page.
Ralf Hemmecke
> Yes, but c.ao should be available (ie. in the library search path,
> or in a library). c will be needed if any types from there are
> implicitly used.
I have verified that by explicitly deleting c.ao before compiling a.as.
Then the compilation will fail. So c.ao *is* needed.
I just wanted to make sure that the compiler complains if I give it not
all the needed .ao files.
Yes and no. Peter has in src_aldor3 already done quite a lot of things
to break big cycles by providing some initial data. There are only 3 or
4 cliques with more than 1 element left.
> Or did you mean something else by this question?
Yes. For src_aldor3, libaxiom.al is produced by first finding all the
dependencies and then for each X.ap file collect the (already compiled)
.ao files into a library libaxiom_X.al and then compile X.ap to X.ao
using that library.
More on that, when I have everything running for fricas. I have no time now.
Ralf
Bill Page
> Bill Page wrote:
>>
>> Isn't the point of chasing dependencies to find the strongly
>> connected components, i.e. the cycles in the dependency
>> graph? As I understand it, these need special treatment.
>
> Yes and no. Peter has in src_aldor3 already done quite a lot of
> things to break big cycles by providing some initial data. There
> are only 3 or 4 cliques with more than 1 element left.
>
Aldor can solve 1 element cliques, right? But what about the others?
If we change the structure of the FriCAS algebra library - perhaps
introducing some new dependencies - could this impact the ability to
build the Aldor extension? Would someone else have to manually
"provide initial data" so that the build could proceed? Or does the
build process somehow automate this in a manner similar to how Waldek
builds the algebra library in FriCAS without any bootstrap data?
>> Or did you mean something else by this question?
>
> Yes. For src_aldor3, libaxiom.al is produced by first finding all the
> dependencies and then for each X.ap file collect the (already
> compiled) .ao files into a library libaxiom_X.al and then compile
> X.ap to X.ao using that library.
>
> More on that, when I have everything running for fricas.
I look forward to that! :-) Thank you very much for working on this.
> I have no time now.
>
I know what you mean.
Regards,
Bill Page.
Ralf Hemmecke
Well, that's compiling one file, right?
> But what about the others?
Good question. As far as I understand up do now, the file genax.lsp
generates an .ap files from certain input files. I haven't completely
checked that, but it seems for cliques that correspond to more than one
file, it generates just *one* .ap file for the whole clique so that
aldor can deal with mutual dependencies in one file.
Peter, is that true?
> If we change the structure of the FriCAS algebra library - perhaps
> introducing some new dependencies - could this impact the ability to
> build the Aldor extension?
Restructuring might be a problem, but simply adding domains should be fine.
> Would someone else have to manually "provide initial data" so that
> the build could proceed? Or does the build process somehow automate
> this in a manner similar to how Waldek builds the algebra library in
> FriCAS without any bootstrap data?
If I knew how Waldek bootstraps algebra, I could tell, but I haven't
looked at Waldek's code. The initial data is rather small. It's
basically in baselist.lsp (as far as I understand). A few extra
dependencies are given in extra_deps.lst. That is all of the handwritten
stuff. The rest is computed from the .spad files.
Basically the idea is the following. For libaxiom one must add
axextend.as and axlit.as, but both depend already on certain domains. So
they cannot live at the bottom of the algebra universe, but somewhere
in the middle.
The first step is to find types that live above and below that line.
For the types that axextend and axlit depend on, there must be some care
taken so that it bootstraps OK. That is basically done with data from
baselist.lsp and adjusting dependencies.
Once it is clear what lives above and below, the clique stuff can begin.
To me it seems that Peter magically already broke huge interdependencies
by setting up the previous step. So only very small cliques remain. (I
haven't investigated src_aldor2 as extensively as src_aldor3/4.)
>> More on that, when I have everything running for fricas.
> I look forward to that! :-) Thank you very much for working on this.
That is approximately what I know now. More to come. And actually, I
really wonder how Peter could come up with something like that in the
first place. It all looks like magic if you look at the src_aldor2
files. src_aldor3 seems a bit easier, but still, I would have been
unable to do this myself, even with the knowledge I have now. So a big
thanks must go to Peter Broadbery. I actually only do minor details.
Perhaps I should work with that code "improvement" in the open.
Ralf
Ralf Hemmecke
By the way, could someone look into genax.lsp and try to add some
documentation. For me that is mostly a blackbox, since it somehow
connects to Axiom internals (I guess) and can generate the .ap files and
dependencies. My LISP knowledge is rather weak and what the LISP
functions in FriCAS are, I have no idea. So whoever could contribute
with bits of documentation, that is more than welcome.
Thank you
Ralf
Peter Broadbery
>> Aldor can solve 1 element cliques, right?
>
> Well, that's compiling one file, right?
>
>> But what about the others?
>
> Good question. As far as I understand up do now, the file genax.lsp
> generates an .ap files from certain input files. I haven't completely
> checked that, but it seems for cliques that correspond to more than one
> file, it generates just *one* .ap file for the whole clique so that
> aldor can deal with mutual dependencies in one file.
>
> Peter, is that true?
>
Yes, cliques.as takes the dependency graph, finds the strongly
connected components of that graph (ie. the mutually dependent bits),
then deals in terms of those subsequently. Happily 99%
of these have a single element, the rest are tagged by thier first
element, with the generated .ap
file containing all the elements. It might have been a better idea to
set the name to something pointing out that it's a set, and indicate
the number of elements.
>> If we change the structure of the FriCAS algebra library - perhaps
>> introducing some new dependencies - could this impact the ability to build
>> the Aldor extension?
>
> Restructuring might be a problem, but simply adding domains should be fine.
>
>> Would someone else have to manually "provide initial data" so that
>> the build could proceed? Or does the build process somehow automate
>> this in a manner similar to how Waldek builds the algebra library in
>> FriCAS without any bootstrap data?
>
> If I knew how Waldek bootstraps algebra, I could tell, but I haven't looked
> at Waldek's code. The initial data is rather small. It's basically in
> baselist.lsp (as far as I understand). A few extra dependencies are given in
> extra_deps.lst. That is all of the handwritten stuff. The rest is computed
> from the .spad files.
>
> Basically the idea is the following. For libaxiom one must add axextend.as
> and axlit.as, but both depend already on certain domains. So they cannot
> live at the bottom of the algebra universe, but somewhere in the middle.
>
> The first step is to find types that live above and below that line.
> For the types that axextend and axlit depend on, there must be some care
> taken so that it bootstraps OK. That is basically done with data from
> baselist.lsp and adjusting dependencies.
>
> Once it is clear what lives above and below, the clique stuff can begin. To
> me it seems that Peter magically already broke huge interdependencies by
> setting up the previous step. So only very small cliques remain. (I haven't
> investigated src_aldor2 as extensively as src_aldor3/4.)
>
_2 is the same algorithm - except that the axextend/axlit separation
is written into the makefiles. Which didn't work well. V3 is
clearer, with the ugliness of setting the cliques up obvious from the
aldor code.
The 'initial data' isn't much - a list of 10 or so fundamental domains
(categories aren't a problem), and a type for some of them. Plus some
dependency data where we couldn't pick it up correctly. This has to
be done experimentally, unfortunately.
A more general approach is possible; break each domain into a trivial
definition 'X: with == add;', and an extension containing the actual
definition. Fix the dependency generator to distinguish between uses
of these two definitions (ie. 'used in an export', 'used in a type
expression'), then find the dependency graph. Invent a condition that
lets one unify the initial definition and extension (some graph theory
fact here, I'd guess) to avoid having too many domains. axextend and
similar would just fit in at the appropriate point.
If there is a goal of trying to include aldor code in the axiom build,
then this sort of approach would be the way to go.
Peter
Ralf Hemmecke
> definition 'X: with == add;', and an extension containing the actual
> definition. Fix the dependency generator to distinguish between uses
> of these two definitions (ie. 'used in an export', 'used in a type
> expression'), then find the dependency graph.
Could you elaborate a bit here. Why would 'used in an export' make a
distinction to 'used in a type expression'? My guess, the first just
needs "X: with == add" while the latter needs the extended version of X.
The only problem I have with that is that I have not yet any
understanding of the 'dependency generator' (I guess you mean
genax.lsp), but I would be happy to learn and extend it into that direction.
> Invent a condition that lets one unify the initial definition and
> extension (some graph theory fact here, I'd guess) to avoid having
> too many domains.
For a first approach it would be enough to have "X: with == add" for
every domain. We may improve later.
> axextend and similar would just fit in at the appropriate point.
OK.
> If there is a goal of trying to include aldor code in the axiom
> build, then this sort of approach would be the way to go.
I don't know of that goal. All I want at the moment is to be able to use
aldor-combinat inside FriCAS. To be honest, since we actually would need
some extensions of existing Algebra domains, being able to throw in some
Aldor code in the FriCAS build process (especially extentions of Algebra
domains), that would be great. But certainly easier and better would be
to have post-facto extensions in FriCAS.
Anyway, does somebody know of a list of Domains that are absolutely
necessary for the Interpreter to run? Put in another way. Is it possible
to build the complete algebra just with the aldor compiler? For a start,
what would be the minimal set of domains that one would have to provide
as .as files to get a (basically knowledgeless) FriCAS.
Suppose FriCAS-Algebra is build from .as files instead of .spad files, I
guess the problem would remain that extensions of Integer, say, that are
made via some ")co myintext.as" would not be understood by the interpreter?
Ralf
Ralf Hemmecke
> It should be enough for "a" to mention just "b".
Hmm, after Peter send me:
> Yes, but c.ao should be available (ie. in the library search path,
> or in a library).
> c will be needed if any types from there are implicitly used.
I modified the a.ao target of my Makefile to
cp libbbb.al liblibrary.al
aldor -llibrary $<
then I get
>make
aldor c.as
ar r libccc.al c.ao
ar: creating libccc.al
cp libccc.al liblibrary.al
aldor -llibrary b.as
ar r libbbb.al b.ao
ar: creating libbbb.al
rm c.ao
cp libbbb.al liblibrary.al
aldor -llibrary a.as
#1 (Fatal Error) Could not open file `c.ao'.
make: *** [a.ao] Error 1
Is that OK?
> If "b" was created using a version of the compiler that circumvents
> the "inline from" declaration (thereby allowing inlining from everything),
> then if "c" changes, "a" may need to be recompiled.
Well, I don't know if any inlining happens here. I am using v1.1.0.
Ralf
Waldek Hebisch
>
> > Would someone else have to manually "provide initial data" so that
> > the build could proceed? Or does the build process somehow automate
> > this in a manner similar to how Waldek builds the algebra library in
> > FriCAS without any bootstrap data?
>
> If I knew how Waldek bootstraps algebra, I could tell, but I haven't
> looked at Waldek's code. The initial data is rather small. It's
> basically in baselist.lsp (as far as I understand). A few extra
> dependencies are given in extra_deps.lst. That is all of the handwritten
> stuff. The rest is computed from the .spad files.
Just few crucial details:
- we start with set of fake (empty) constructors, which are later
replaced by the real one (effect is similar to using Aldor extend)
- for categories I use hand-maintained list giving order in which
they should be compiled -- I started toplogically sorting
categories based on ancestor relation, but I had to tweak it
You can find more information in src/algebra/Makenotes.tex.
Extra remark: I need manually "provide initial data", namely various
list of files give order in things are compiled, 'boo-nilcat.spad',
'boo-nildom.spad' and 'bootstrap.spad' contains fake constructors...
--
Waldek Hebisch
heb...@math.uni.wroc.pl