axiom-developer
[Top][All Lists]
Advanced

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

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


From: Page, Bill
Subject: RE: [Aldor-l] [Axiom-developer] Re: exports and constants
Date: Wed, 26 Jul 2006 11:36:34 -0400

On Wednesday, July 26, 2006 10:35 AM Ralf Hemmecke wrote:
> ... 
> I believe reflections are not too complicated once we know
> how the internal datastructures for domains are. (Yes, yes,
> we must look inside the compiler sources, or does anybody
> already have a description of how domains are represented
> in memory?)
> ...

I think the documentation that you need for this is Aldor's
abstract machine layer called FOAM. This is where implementation
details such as you describe are specified. This abstract
machine is implemented in Lisp, Scheme, and in a C runtime
system. I believe that the program code that is generated by
Aldor before being converted to real machine code is accessible
in the .asy and .ao files. If we had to parse the output of the
compiler in order to know what it was doing, then it seems to
me that this a better and fully portable place to look rather
Lisp or intermediate C code.

To fully implement reflects in Aldor it might be necessary to
provide some new operations at the FOAM level and in particular
in the RunTime support library (which is written in Adlor).

Here is a useful introduction:

http://www.orcca.on.ca/~ldragan/aldor/fp/fp.html

Apparently there is a detailed reference

[6]: Stephen M. Watt and Peter A. Broadbery and Pietro Iglio
and Scott C. Morrison and Jonathan M. Steinbach,
FOAM: First Oder Abstract Machine

which is referenced here

www.csd.uwo.ca/~watt/pub/reprints/2005-mc-towers.pdf

but I have not been able to find it online anywhere.

But even without extending the RunTime support it may be possible
to use the approach discussed in the Aldor Users Guide to make
"data self-identifying". See section 7.1:

"Aldor, on the other hand, adopts the ``Types on Variables''
approach, and values are not normally self-identifying....
For example, self-identifying data may obtained by incorporating
types in the values."

By this I presume is meant something like this:

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

  describe: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))

----------

Unfortunately this code causes a compile error in the current
version of the Aldor compiler.

It also raises the question of how reflected information
should be represented in Aldor. Perhaps a List would be
better than a generator? Unfortunately although the above
code using List does compile, it does not seem to work as
expected at runtime. See

http://wiki.axiom-developer.org/SandBoxAldorSemantics#msg20060726062837-
address@hidden

But in principle this would allow one to write something like

  for s in describe$MyDom repeat
    if MyDom2 has s then
      ...
      etc.

and maybe (with some extension to the syntax) even to instantiate
new domains from categories defined like this:

  with { s for s in describe$MyDom where MyDom2 has s }

Regards,
Bill Page.




reply via email to

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