RE: [Aldor-l] [Axiom-developer] Re: exports and constants

[Page, Bill]

Ralf, 

On Thursday, July 27, 2006 11:26 AM you wrote:
> > ... 
> > This example is a good one but I object to the use of
> > String as a representation for the output of Reflection
> > operators.
> 
> Of course. But if you want to print out things you must be
> able to convert to something that you can put onto a screen.

Yes you are right. In Axiom such output is a matter resolved
by providing (almost) every domain with a coercion function
to the OutputForm domain. Since in Axiom lisp underlies
everything, providing such a coercion is relatively easy.
In Aldor as a stand alone high level language I am not sure
exactly what the best solution is. Does it really make sense
that such a high level language should care about the name
that a particular programmer assigned to one of it's objects?
Maybe this behavior (of associating an actual name string
with an object) should be controlled by a debugging option
on the compiler the way the rest of the Trace system works.

> It was just a simple example, after all.

Understood.

> 
> > In Aldor we can do much better than that. A function like
> > export should probably look something like this:
> 
> >   exports: Domain -> Generator Category
> > 
> > Yesterday I gave this example:
> > 
> > -----------
> > MyDom: with
> >   exports:Generator Category
> >   add2:(MyDom,MyDom) -> MyDom
> >   sub2:(MyDom,MyDom) -> MyDom
> >   neg: MyDom -> MyDom
> >  == add
> >   import from Integer
> >   Rep == Integer
> > 
> >   exports:Generator Category == generate
> >     yield with {add2:(MyDom,MyDom)->MyDom}
> >     yield with {sub2:(MyDom,MyDom)->MyDom}
> >     yield with {neg:MyDom->MyDom}
> > 
> >   add2(x:%,y:%):% == per(rep(x) + rep(y))
> >   sub2(x:%,y:%):% == per(rep(x) - rep(y))
> >   neg(x:%):% == per(-rep(x))
> 
> I liked your code, but in fact that does not use reflection
> at all and I think it should even compile. You are not doing
> anything fancy.

Why do you say that this does not use reflection? I suppose,
that as in the Aldor Users Guide this is better called
"self-identification", but really it seems to me that these
are the same things.

I agree that this is nothing "fancy". Actually, reflection is
not really such a "fancy" concept at all, its just that we have
got used to not having access to this sort of information in
non lisp-based programming without first-order types.

Yes, I agree that this should compile now. Obviously Aldor
does try to compile it but it fails for some obscure reason.
Here is the output:

> cat self2.as
--- BEGIN: self2.as
#include "aldor"
#include "aldorio"

#pile

MyDom: with
  exports: Generator Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  exports:Generator Category == generate
    yield with {add2:(MyDom,MyDom)->MyDom}
    yield with {sub2:(MyDom,MyDom)->MyDom}
    yield with {neg:MyDom->MyDom}

  add2(x:%,y:%):% == per(rep(x) + rep(y))
  sub2(x:%,y:%):% == per(rep(x) - rep(y))
  neg(x:%):% == per(-rep(x))

-- I think this should compile but it doesn't. :(
--for sig in exports$MyDom repeat
--   stdout << (Integer has sig) << newline;
---END self2.as

> aldor -grun -laldor self2.as
"self2.as", line 17:     yield with {add2:(MyDom,MyDom)->MyDom}
                     ....^
[L17 C5] #1 (Fatal Error) Compiler bug: no exit list for terrorSequence
(ooops).

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

I guess this means I should submit a bug report ... but until
Aldor is open source or we find some other way to deal with it
I am not too strongly motivated. Given the urgency (to us at
least!) of resolving the issue of the open source status of
Aldor, I am disappointed not to hear anything yet from Steven
Watt or Mike Dewar as Mike did state directly in an email to
me that they intended to discuss it during the recent meetings
in Europe... :( I am again impatient and thinking about drastic
alternatives.

Perhaps I will just create an issue report in the Axiom Wiki
issue tracker anyway at least to document it. Do you think it
is reasonable to assume that the Aldor developers (are there
really any?) are subscribed to the axiom-developer email list
and will receive such reports? Or is the proper procedure to
forward it specifically to aldor-l?

This same program using a List data structure instead of a
Generator compiles (almost):

> cat self1.as
--- BEGIN: self1.as
#include "aldor"
#include "aldorio"

#pile

MyDom: with
  exports:List Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  exports:List Category ==
    [with {add2:(MyDom,MyDom)->MyDom},
     with {sub2:(MyDom,MyDom)->MyDom},
     with {neg:MyDom->MyDom}]

  add2(x:%,y:%):% == per(rep(x) + rep(y))
  sub2(x:%,y:%):% == per(rep(x) - rep(y))
  neg(x:%):% == per(-rep(x))

--This should work but doesn't
--for sig in exports$MyDom repeat
--   stdout << (Integer has sig) << newline;
---END self1.as

> aldor -grun -laldor self1.as
cc1: note: -fwritable-strings is deprecated; see documentation for
details
cc1: note: -fwritable-strings is deprecated; see documentation for
details

---------

Except that I can not seem to get the "has" expression to
work the way I expected it to. Maybe this is another bug?

Any ideas?

Note: This warning referring to the "-fwritable-strings" option
used by Aldor means that Aldor can not be used with newer versions
of gcc (starting with 4.x) since modifiable string constants are
no longer supported. This is one more example of something that
could probably be easily and quickly resolved if Aldor was open
source.

> 
> BUT, in the "add" you list the exports explicitly. Note that 
> it would be better if you just say
> 
> for s in exports(Mydomain) repeat ...
> 
> where exports would have type
> 
>    Type -> Generator Category
> 
> and would be implemented in a runtime support library.
> 

But that would require that something somewhere actually store
the self-identifying information at run-time. Aldor avoids this
by explicit design (not withstanding that we have also been
talking about ways of getting around this design decision :).

Apparently (by reading "between" the lines in section 7.1 of
the AUG, see the quote in my email of yesterday) the designers
of Aldor intended that self-identifying information be explicitly
added by the programmer where it is needed.

I do not see any advantage of the syntax

> for s in exports(Mydomain) repeat ...

over my

  for s in exports$Mydomain repeat ...

which does not involve any explicit external function call.

Regards,
Bill Page.