[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-developer] Re: exports and constants
Date: Fri, 28 Jul 2006 09:20:33 +0200
User-agent: Opera Mail/9.00 (Linux)


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"


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;
} == 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:%):% == {


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:
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx -lalgebra -laldor && ./test3
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details

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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]