libaxiom.al dependencies part 2

2 views
Skip to first unread message

Ralf Hemmecke

unread,
Jun 1, 2008, 3:38:42 AM6/1/08
to fricas-devel, Peter Broadbery
Dear Peter,

in thread
http://groups.google.com/group/fricas-devel/browse_frm/thread/fcdc842baaab7e5c/3c255bc63addd6a1?tvc=1#3c255bc63addd6a1
you wrote.

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

After looking more closely at what you Makefile from src_aldor3 does, I
have the impression that one would need an extended genax.lsp also right
now.

I am not 100% sure, but here are some argument for it.

genax.lsp does find the dependencies

BOP STRING
SEX STRING
SEX OUTFORM
PFECAT VECTOR
UPOLYC NNI

that are listed in extra_deps.lst (as can be seen from gendeps/BOP.dep,
for example). However, clique.as computes all the (recursive)
dependencies of axextend+axlit and there it finds also BOP, SEX, PFECAT,
UPOLYC. (I.e, in your terminology they are among the "top level" types.)

For all those types clique.as says:

for s in union([i for i in fileMap."initaxiom"],
topLevelAncestors) repeat {
depIds: Set String := [id for id in readNames("deps/"+s+".dep")];
for id in depIds repeat {
if member?(("init__" + id), allTypes) then
addLink!(g, "init__" + id, s);
else
addLink!(g, id, s);
}
}

Or in other words, that BOP depends on STRING is added as BOP depends on
init_STRING.

I guess that condition is not right. It should rather say:

if BOP 'uses STRING in a type' (see your initial comment) then
BOP depends on STRING
else if BOP only 'uses STRING in an export' then
BOP only depends on init_STRING
else
never

This problem comes to light from the types that have to be added to
extra_deps, but might be hidden in other cases.

How did you find out that these extra_deps where needed?


I have the suspicion that to problem from

http://groups.google.com/group/fricas-devel/browse_frm/thread/4edc7d9a8dfd0be

From: Martin Rubey <martin.ru...@univie.ac.at>
Date: 21 May 2008 06:58:52 +0200
Subject: Re: [fricas-devel] Re: aldor interface

I see the following error:

-------------------------------------------------------------------------------
ar: creating
/home/hemmecke/scratch/fricas/fricas-build/src/aldor/tmp/libaxiom_FS.al
(Message Preview)
"/home/hemmecke/scratch/fricas/fricas-build/src/aldor/ap/FS.ap", line 1318:
(|Apply| |Polynomial|
......................................................^
[L1318 C55] #1 (Error) No one possible return type satisfies the context
type.
These possible return types were rejected:
-- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with
if (#1 has Algebra(Fraction(Integer))) then integrate: (%,
Symbol) -> %
else
The context requires an expression of type with

-------------------------------------------------------------------------------

is related. But that is only a guess.

For example, SEG.spad says:

expand(s : %) == expand([s]$List(%))$%

and genax.lsp finds

LIST ORDRING SEGCAT SEGXCAT SETCAT STAGG TYPE

(see deps/SEG.dep). But since SEG is a "top type", spadset.mk only says:

SPADSET_axiom += SEG
SPADSET_ITEM_axiom_SEG := \
SEG \

SPADSET_DEPS_axiom_SEG := \
lang \
minimach \
boolean0 \
attrib \
init_LIST \
ORDRING \
SEGCAT \
SEGXCAT \
SETCAT \
STAGG \
TYPE \

i.e. init_LIST instead of LIST. Maybe LIST is too builtin and this
special instance would still be OK, but perhaps there are other types
that should have listed X instead of init_X?

So my conclusion would be, one needs your above mentioned extension
already now. My only problem is that I hardly can rewrite genax.lsp to
already write X or init_X depending on whether X is 'used in a type' or
'used in an export'. Any suggestions are welcome.

If genax.lsp could be extended that way then your suggestion from above
would also be easily implemented. Take the init_X files that
axextend+axlit depend on and write X:with==add as an initial start for
them. And rewrite init_X into X for dependencies of types Y that live
after axextend+axlit (those types are what you call 'upper types' in
clique.as).

Sorry for this long mail, but I'd like to get it right.

Ralf

Peter Broadbery

unread,
Jun 1, 2008, 5:37:28 AM6/1/08
to Ralf Hemmecke, fricas-devel
On Sun, Jun 1, 2008 at 8:38 AM, Ralf Hemmecke <ra...@hemmecke.de> wrote:
> Dear Peter,
>
> in thread
> http://groups.google.com/group/fricas-devel/browse_frm/thread/fcdc842baaab7e5c/3c255bc63addd6a1?tvc=1#3c255bc63addd6a1
> you wrote.
>
>> 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.
>
> After looking more closely at what you Makefile from src_aldor3 does, I have
> the impression that one would need an extended genax.lsp also right now.
>

Yes - there seems to be some support for differentiating the two - the
'context' contains a field which can be 'apply', 'declare', 'with',
etc. I obviously wasn't sufficiently confident that it worked
correctly, and it turned out that 90% of them were 'declare', so that
got to be the default behaviour.

Yes, true.

> How did you find out that these extra_deps where needed?
>

There were not too many, so simply adding them as needed worked.

>
> I have the suspicion that to problem from
>
> http://groups.google.com/group/fricas-devel/browse_frm/thread/4edc7d9a8dfd0be
>
> From: Martin Rubey <martin.ru...@univie.ac.at>
> Date: 21 May 2008 06:58:52 +0200
> Subject: Re: [fricas-devel] Re: aldor interface
>
> I see the following error:
>
> -------------------------------------------------------------------------------
> ar: creating
> /home/hemmecke/scratch/fricas/fricas-build/src/aldor/tmp/libaxiom_FS.al
> (Message Preview)
> "/home/hemmecke/scratch/fricas/fricas-build/src/aldor/ap/FS.ap", line 1318:
> (|Apply| |Polynomial|
> ......................................................^
> [L1318 C55] #1 (Error) No one possible return type satisfies the context
> type.
> These possible return types were rejected:
> -- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with
> if (#1 has Algebra(Fraction(Integer))) then integrate: (%,
> Symbol) -> %
> else
> The context requires an expression of type with
>
> -------------------------------------------------------------------------------
>

This is probably something else - FS.spad can trigger a compiler issue
- but not always.(apologies to Martin if I didn't reply - March was
somewhat busy). I tried to send the fix to aldor-l, but it bounced.
It might be in some archive somewhere - the fix was in sefo.c, if that
helps.

See above - the context info is enough; Return that info as well as
the name, then fix clique.as to read 'type context' per line instead
of just the type. I started playing with this, but it'll probably
take me longer than you'd like.

> If genax.lsp could be extended that way then your suggestion from above
> would also be easily implemented. Take the init_X files that axextend+axlit
> depend on and write X:with==add as an initial start for them. And rewrite
> init_X into X for dependencies of types Y that live after axextend+axlit
> (those types are what you call 'upper types' in clique.as).
>
> Sorry for this long mail, but I'd like to get it right.
>

That's fine. The whole thing's a work in progress, and I don't have
vast amounts of time to put into it (slightly more at the moment, but
it won't last), so someone else pushing it on is great.

Peter

Ralf Hemmecke

unread,
Jun 1, 2008, 5:52:19 AM6/1/08
to Peter Broadbery, fricas-devel, aldor-l
>> I see the following error:
>>
>> -------------------------------------------------------------------------------
>> ar: creating
>> /home/hemmecke/scratch/fricas/fricas-build/src/aldor/tmp/libaxiom_FS.al
>> (Message Preview)
>> "/home/hemmecke/scratch/fricas/fricas-build/src/aldor/ap/FS.ap", line 1318:
>> (|Apply| |Polynomial|
>> ......................................................^
>> [L1318 C55] #1 (Error) No one possible return type satisfies the context
>> type.
>> These possible return types were rejected:
>> -- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with
>> if (#1 has Algebra(Fraction(Integer))) then integrate: (%,
>> Symbol) -> %
>> else
>> The context requires an expression of type with
>>
>> -------------------------------------------------------------------------------
>>
>
> This is probably something else - FS.spad can trigger a compiler issue
> - but not always.(apologies to Martin if I didn't reply - March was
> somewhat busy). I tried to send the fix to aldor-l, but it bounced.
> It might be in some archive somewhere - the fix was in sefo.c, if that
> helps.

Oh, could you resend it? Recently at least the aldor svn server was down
several times.
I don't know what happened to aldor-l but that might have been connected.

Thanks in advance.

Ralf

PS: I really wonder how fast you could find out what the real problem in
the compiler was. Great!

Ralf Hemmecke

unread,
Jun 1, 2008, 6:26:52 AM6/1/08
to Peter Broadbery, fricas-devel
On 06/01/2008 12:14 PM, Peter Broadbery wrote:

> On Sun, Jun 1, 2008 at 10:55 AM, Ralf Hemmecke <ra...@hemmecke.de> wrote:
>>> Yes - there seems to be some support for differentiating the two - the
>>> 'context' contains a field which can be 'apply', 'declare', 'with',
>>> etc. I obviously wasn't sufficiently confident that it worked
>>> correctly, and it turned out that 90% of them were 'declare', so that
>>> got to be the default behaviour.
>>> See above - the context info is enough; Return that info as well as
>>> the name, then fix clique.as to read 'type context' per line instead
>>> of just the type. I started playing with this, but it'll probably
>>> take me longer than you'd like.
>> Yes, I think I can figure that out, but could you explain, what I do about
>> 'apply', 'declare', and 'with'? For which I would need just init_X and which
>> requires the full knowledge of X?
>>
>> Ralf

> apply (eg. LIST INT) implies full knowledge, declare (eg. foo: INT)
> would be 'init' and 'with' should just apply to categories. If it
> doesn't, then probably 'full', and figure out why the context tracking
> failed..

How about something like

foo(blah)$List(Integer)

that would certainly need full knowledge of List, but under which
keyword will that come in the context? Will/should I see LIST in the
context of 'apply?

Ralf

Peter Broadbery

unread,
Jun 1, 2008, 6:40:49 AM6/1/08
to Ralf Hemmecke, fricas-devel

Not legal in category definitions (default bodies are skipped by the
process), so you won't see it when compiling the spad parts of
libaxiom. In .as code, the context will be that of the surrounding
context for List, but something else for the argument. Let's call it
'anytype' for the sake of, erm, argument. The surrounding context
will be 'declare', which will cause problems. One probably wants a
different context for definitions inside add and default bodies.

> Ralf
>

Peter Broadbery

unread,
Jun 1, 2008, 6:41:46 AM6/1/08
to Ralf Hemmecke, fricas-devel, aldor-l

.. From memory.. The issue was that when two categories are compared
for structural similarity the compiler shouldn't try to go any
further, and fall back to doing a proper job.
Finding this little swine took several days.

Peter

sent to aldor-l, fricas-devel.
-----------------------
On Thu, Mar 13, 2008 at 9:21 PM, Gregory Vanuxem <g.va...@orange.fr> wrote:
> Dear Peter, *
>
> I was waiting for your small Aldor patch and never see it. Did you send
> it somewhere ? The main concern of this mail is if you are able to
> compile ecfact.as (attached) and _execute_ the
> LenstraEllipticMethod(Integer) function. On my system it fails, a bug
> somewhere. Am I alone with this issue ? Martin ? I'm still using the
> old build process and want to switch to the new one but this stops me. I
> do not want to take your time but maybe you have an idea of what's going
> on with this issue.
>
....
apologies for the, um, delay..
The following patch affects the build of libaxiom.al - if a given file
compiles, then it will work or fail independently of this (it fixes
the compilation of FRMOD amongst others).

The hashcode fix _should_ help with runtime bugs. It tracks the
change to hashcodes marked 1_1_13_18 in gf_add.c

Index: src/sefo.c
===================================================================
--- src/sefo.c (revision 23)
+++ src/sefo.c (working copy)
@@ -1361,7 +1361,9 @@
Bool eq;

sstNext("symeEqual", syme1, syme2);
+
eq = symeEqual0(NULL, syme1, syme2);
+
sstDoneSyme(syme1);

return eq;
@@ -1847,6 +1849,9 @@
if (tfIsDefine(tf1) || tfIsDefine(tf2))
return true;

+ if (tfIsThird(tf1) || tfIsThird(tf2))
+ return true;
+
if (tfTag(tf1) != tfTag(tf2))
return false;
if (tfArgc(tf1) != tfArgc(tf2))

Ralf Hemmecke

unread,
Jun 2, 2008, 3:25:40 AM6/2/08
to Peter Broadbery, fricas-devel
>> How about something like
>>
>> foo(blah)$List(Integer)
>>
>> that would certainly need full knowledge of List, but under which keyword
>> will that come in the context? Will/should I see LIST in the context of
>> 'apply?
>>
>
> Not legal in category definitions (default bodies are skipped by the
> process), so you won't see it when compiling the spad parts of
> libaxiom.

But they shouldn't be thrown away?
To treat them would it be enough to change

(defun find-deps-default (env list)
nil)

into

(defun find-deps-default (env list)
(find-deps-add env list))

?

Ralf

Peter Broadbery

unread,
Jun 2, 2008, 4:39:10 AM6/2/08
to Ralf Hemmecke, fricas-devel


Yes, that would work. and is probably needed for .as files, but they
aren't needed if all you want to do is compile the axiom type
signatures (the declaration that the default methods implement will be
either in the local with body, or an earlier category; in either case
we'll have seen the dependencies).

>
> Ralf
>

Ralf Hemmecke

unread,
Jun 2, 2008, 5:01:28 AM6/2/08
to Peter Broadbery, fricas-devel
> Yes, that would work. and is probably needed for .as files, but they
> aren't needed if all you want to do is compile the axiom type
> signatures (the declaration that the default methods implement will be
> either in the local with body, or an earlier category; in either case
> we'll have seen the dependencies).

I am only guessing with what is needed and what not, but let me state my
concerns. (I don't know whether that really happens in the Axiom library.)

Suppose there is a category

Cat: Category ==
...
add
foo(x: %): Integer == 1$Integer

If that where Aldor (then with "default" instead of "add"), then

foo: % -> Integer

is an explicitly exported function of Cat even if it doesn't appear
explicitly in the exports part (here abbreviated by ...).

I don't know how SPAD behaves in this case.
Anyway, Cat depends not only on init_Integer, but on the full domain of
Integer (or at least one, that exports 1: %).

Wouldn't you agree?

Ralf

PS:
The .ap file of

#include "aldor"
Cat: Category == with {
default {foo(x: %): Integer == 1$Integer;}
}

is

(Sequence
(Sequence () ())
(Import () aldorlib)
(Inline () aldorlib)
()
(Import () Boolean)
(Sequence () ())
()
()
(Define
(Declare Cat Category)
(With
()
(Default
(Define
(Declare foo (Apply -> (Declare x %) AldorInteger))
(Lambda
(Comma (Declare x %))
AldorInteger
(Label foo (Qualify \1 AldorInteger))))))))

Peter Broadbery

unread,
Jun 2, 2008, 5:17:40 AM6/2/08
to Ralf Hemmecke, fricas-devel
On Mon, Jun 2, 2008 at 10:01 AM, Ralf Hemmecke <ra...@hemmecke.de> wrote:
>> Yes, that would work. and is probably needed for .as files, but they
>> aren't needed if all you want to do is compile the axiom type
>> signatures (the declaration that the default methods implement will be
>> either in the local with body, or an earlier category; in either case
>> we'll have seen the dependencies).
>
> I am only guessing with what is needed and what not, but let me state my
> concerns. (I don't know whether that really happens in the Axiom library.)
>
> Suppose there is a category
>
> Cat: Category ==
> ...
> add
> foo(x: %): Integer == 1$Integer
>
> If that where Aldor (then with "default" instead of "add"), then
>
> foo: % -> Integer
>
> is an explicitly exported function of Cat even if it doesn't appear
> explicitly in the exports part (here abbreviated by ...).
>

Ok, my memory might be iffy; I thought one had to declare stuff before
implementing in default bodies.

> I don't know how SPAD behaves in this case.
> Anyway, Cat depends not only on init_Integer, but on the full domain of
> Integer (or at least one, that exports 1: %).
>
> Wouldn't you agree?
>

For .as files, yes. For .spad files, nope - the generated .ap won't
contain 1$Integer.

Peter

Ralf Hemmecke

unread,
Jun 2, 2008, 5:22:38 AM6/2/08
to Peter Broadbery, fricas-devel
>> I don't know how SPAD behaves in this case.
>> Anyway, Cat depends not only on init_Integer, but on the full domain of
>> Integer (or at least one, that exports 1: %).
>>
>> Wouldn't you agree?
>>
>
> For .as files, yes. For .spad files, nope - the generated .ap won't
> contain 1$Integer.

Ooops. Then I would guess, that ax.boot is buggy. But good to know. So I
will have to check add-bodies in Categories by hand and adjust
appropriately. Let's hope there are not so many.

Ralf

Peter Broadbery

unread,
Jun 2, 2008, 5:31:28 AM6/2/08
to Ralf Hemmecke, fricas-devel

This is by design; spad is implementing the functions, users of
libaxiom.al only need to be assured that the methods exist. What does
the .ap generated from your
example look like?

> Ralf
>

Ralf Hemmecke

unread,
Jun 2, 2008, 6:15:07 AM6/2/08
to fricas-devel
My SPAD knowledge is rather weak, but why would

)abbrev category AAA Aaa
Aaa: Category == OutputForm with
bar: % -> %
foo: % -> Integer


add
foo(x: %): Integer == 1$Integer

not compile in FriCAS?
Apperently FriCAS requires BasicType where I have written a dummy
"OutputForm". Strange.

Ralf

>fricas
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 29 2006 02:32:45
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/hemmecke/
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-01-18
Timestamp: Monday January 21, 2008 at 19:44:19
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

(1) ->
(1) -> )co aaa.spad
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/apply.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/c-doc.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/c-util.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/profile.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/category.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/compiler.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/define.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/functor.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/info.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/iterator.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/modemap.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/nruncomp.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/package.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/htcheck.
Compiling FriCAS source code from file
/home/hemmecke/scratch/aaa.spad using old system compiler.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/parsing.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/bootlex.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/def.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/fnewmeta.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/metalex.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/metameta.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/parse.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/postpar.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/preparse.
AAA abbreviates category Aaa
------------------------------------------------------------------------
initializing NRLIB AAA for Aaa
compiling into NRLIB AAA
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/SETCAT.o
for category SetCategory
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/BASTYPE.o
for category BasicType
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/KOERCE.o
for category CoercibleTo

;;; *** |Aaa| REDEFINED
Time: 0.01 SEC.


>> System error:
Caught fatal error [memory may be damaged]

(1) ->

Martin Rubey

unread,
Jun 2, 2008, 6:34:01 AM6/2/08
to fricas...@googlegroups.com
Ralf Hemmecke <ra...@hemmecke.de> writes:

> My SPAD knowledge is rather weak, but why would
>
> )abbrev category AAA Aaa
> Aaa: Category == OutputForm with
> bar: % -> %
> foo: % -> Integer
> add
> foo(x: %): Integer == 1$Integer
>
> not compile in FriCAS?
> Apperently FriCAS requires BasicType where I have written a dummy
> "OutputForm". Strange.

OutputForm is a domain constructor. Shouldn't we expect a category there?

Martin

Ralf Hemmecke

unread,
Jun 2, 2008, 6:42:30 AM6/2/08
to fricas...@googlegroups.com
You are right. I mixed that up with Aldor's OutputType (which is a
category).

Anyway. If I compile any code and that leads to "memory may be damaged",
then I still would consider that as a bug.

Ralf

Ralf Hemmecke

unread,
Jun 2, 2008, 7:00:23 AM6/2/08
to Peter Broadbery, fricas-devel
>>> For .as files, yes. For .spad files, nope - the generated .ap won't
>>> contain 1$Integer.
>> Ooops. Then I would guess, that ax.boot is buggy. But good to know. So I
>> will have to check add-bodies in Categories by hand and adjust
>> appropriately. Let's hope there are not so many.
>>
>
> This is by design; spad is implementing the functions, users of
> libaxiom.al only need to be assured that the methods exist. What does
> the .ap generated from your
> example look like?

How would I do this? I have to compile for example

---BEGIN aaa.spad
)abbrev category AAA Aaa
Aaa: Category == BasicType with


bar: % -> %
foo: % -> Integer

add
foo(x: %): Integer ==

u: String := "abc"
(# u)::Integer
---END aaa.spad

in fricas. But I am unable to figure out how to get the .ap file.

Ralf

Peter Broadbery

unread,
Jun 2, 2008, 7:38:57 AM6/2/08
to Ralf Hemmecke, fricas-devel

not sure myself - try dropping it into the algebra dir - the aldor
build process should pick it up.
Or replace an existing domain in the same dir.

> Ralf
>

Waldek Hebisch

unread,
Jun 2, 2008, 8:03:42 AM6/2/08
to fricas...@googlegroups.com

We have:

PAdicInteger(p:Integer) == InnerPAdicInteger(p,true$Boolean)

I would also consider:

Foo (blah : Integer) == Bar(foo(blah)$List(Integer))

legal. It seems just that such constructs are rare in current
algebra and more complicated ones probably will hit Spad compiler
bugs.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Waldek Hebisch

unread,
Jun 2, 2008, 5:08:48 PM6/2/08
to fricas...@googlegroups.com
Ralf Hemmecke wrote:
>
> You are right. I mixed that up with Aldor's OutputType (which is a
> category).
>
> Anyway. If I compile any code and that leads to "memory may be damaged",
> then I still would consider that as a bug.
>

Yes, this is a bug -- Spad compiler should detect that source is
wrong.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Waldek Hebisch

unread,
Jun 2, 2008, 7:26:43 PM6/2/08
to fricas...@googlegroups.com
Ralf Hemmecke wrote:
> > This is by design; spad is implementing the functions, users of
> > libaxiom.al only need to be assured that the methods exist. What does
> > the .ap generated from your
> > example look like?
>
> How would I do this? I have to compile for example
>
> ---BEGIN aaa.spad
> )abbrev category AAA Aaa
> Aaa: Category == BasicType with
> bar: % -> %
> foo: % -> Integer
> add
> foo(x: %): Integer ==
> u: String := "abc"
> (# u)::Integer
> ---END aaa.spad
>
> in fricas. But I am unable to figure out how to get the .ap file.
>

Something like (in AXIOMsys prompt):

)lisp (load "pp/src/aldor/genax.lsp")
)compile "aaa.spad"
)lisp (|makeAxFile| "aaa-ax.ap" '(|Aaa|))

This is chunk correspnding to Aaa. libaxiom.al build process may
concatenate several such chunks and extra data from other files
(I do not know what exactly will be in other files -- just
reading genax.lsp tells me that that those file may be used).

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Ralf Hemmecke

unread,
Jun 3, 2008, 4:44:17 AM6/3/08
to fricas...@googlegroups.com

Thank you, Waldek.

BTW, the above file does not compile if the line

foo: % -> Integer

is missing. So that is different from Aldor.

The resulting .ap file contains:

(|Sequence| (|Import| NIL |AxiomLib|) (|Import| NIL |Boolean|)
(|Foreign| (|Declare| |dummyDefault| |Exit|) |Lisp|)
(|Define| (|Declare| |Aaa| |Category|)
(|With| NIL
(|Sequence| |BasicType|
(|Declare| |bar| (|Apply| -> (|Comma| %) %))
(|Declare| |foo|
(|Apply| -> (|Comma| %) |Integer|))
(|Default|
(|Sequence|
(|Define|
(|Declare| |foo|
(|Apply| -> (|Comma| %) |Integer|))
(|Lambda| (|Comma| (|Declare| |t#1| %))
|Integer|
(|Label| |foo| |dummyDefault|)))))))))

which does not contain the identifier |String|.

But what Peter said yesterday in
http://groups.google.com/group/fricas-devel/browse_frm/thread/d9ed840e9b031b1b
and what I realised last night, it seems OK to me that String is not
there and that neither String not init_STRING is also not needed to
compile the above .ap file.

That, in fact, might result a different compilation order than Waldek
does for compiling the .spad files. I slowly begin to understand what
ax.boot and genax.lsp is about.

As you can see from the .ap file. A function definition like

foo(a: A): B == F

is replaced by makeAxExportForm by

foo(a: A): B == dummyDefault

where for me 'dummyDefault' looks a bit like 'never' or 'error ""'.
Well, it's just a placeholder.

All that seems plausible now for the kind of dependencies that are
needed for libaxiom.al.

Ralf

Reply all
Reply to author
Forward
0 new messages