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

[Christian Aistleitner]

Hello,

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

yes, there are lots of applications of reflection that do not involve  
debugging. So you should typically be able to get the names of things.


> #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))

Actually, I do not like your code, as this does not give you the kind of  
information you would like to have with a reflection framework (e.g.:  
Using proper types for types and functions, Getting parameter types), and  
will cause you lots of problems  -- but maybe I am too early thinking  
about such issues. However, besides the parsing part, the extensions and  
all the other issues, if it's the way you choose, let me help you getting  
it to compile and run. The following piece of code works:

#include "aldor"
#include "aldorio"

macro T == Category;
macro yieldT( expt ) == { yield ( address@hidden ) }

EXPORT0: T == with {add2:(%,%)->%};
EXPORT1: T == with {sub2:(%,%)->%};
EXPORT2: T == with {neg: % -> %};

MyDom:  with {
    exports: () -> Generator T;
    EXPORT0;
    EXPORT1;
    EXPORT2;
} == add {
  import from Integer;
  Rep == Integer;


  exports(): Generator T == generate {
        yieldT EXPORT0;
        yieldT EXPORT1;
        yieldT EXPORT2;
  };

  add2(x:%,y:%):% == {
      per(rep(x) + rep(y))
  };

  sub2(x:%,y:%):% == {
      per(rep(x) - rep(y));
  };

  neg(x:%):% == {
      per(-rep(x));
  };

}

checkSign( Dom: with{}, sign: T ):Boolean == {
    Dom has sign;
}

import from MyDom;
for sign in exports() repeat
{
    stdout << ( checkSign( Integer, sign ) ) << newline;
    stdout << ( checkSign( MyDom, sign ) ) << newline;
}


Its output is:
____________________________________________
address@hidden
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx  
-lalgebra -laldor test3.as && ./test3
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
F
T
F
T
F
T


Just as expected. What did I do to get the code working?

I got rid of pile.
Piles are simply a pain to my eyes.

I turned exports into a function, as you'd probably want to call it more  
than once.

You yielded anonymous categories, created just within the yield clause.  
This looked dangerous to me, so I turned them into proper definitions  
within MyDom's add part. This however gave problems when checking by has  
(as the Categories where no longer anonymous), so I had to use them  
already in the with clause, and moved them to the top-level scope  
(EXPORT0, ...).

I use the macro yieldT instead of simply yield, to tell the compiler the  
yielded thing really is a Category. For some of my experiments this wasn't  
necessary -- for some it was.

I moved your "has" check in a separate function. It doesn't seem to work  
out well, if the Cat part of "Dom has Sig" is not constant in scope.

That's it.

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

Your code demonstrates more than just one compiler bug ... ;)

> [ warning about "-fwritable-strings" ]
> This is one more example of something that
> could probably be easily and quickly resolved if Aldor was open
> source.

I doubt that. In May, I got a mail from one of the compiler people telling  
me

I have spent the last couple of days looking into this [Remark by CA: the  
"-fwritable-strings" issue] , but the whole compiler uses char * a = "abc"  
(and the compiler is about 250K LOC).  In most of the places they seem to  
be treated as const char *, but I still have a long way to go.

So somebody is already working on it, and I believe him, that it's not one  
of those problems you fix in the 5 minutes till lunch break ;)
Nevertheless, maybe he'd get help and feedback once the compiler is freed.


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

First of all (as I described in the upper part of my mail), you wouldn't  
be able to get two different generators. Hence, if the generator ran out  
of elements, you cannot restart it -- very nasty thing ;)

The second issue is abstraction. Even if you get the thing done your way,  
I'd never call exports$SomeDom directly.

Create some domain

Reflection( T: Type ): with {
        exports: () -> Generator Category
}

and use exports$(Reflection(SomeDom)). Thereby you can extend the whole  
reflection thing quite naturally, and if reflection gets built into  
compiler/runtime, you wouldn't have to change the programs relying on  
reflection, but only need to change the domain Reflection.

--
Kind regards,
Christian