[Top][All Lists]

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

[Fwd: Re: [Axiom-developer] types as values, and type internals

From: Peter Broadbery
Subject: [Fwd: Re: [Axiom-developer] types as values, and type internals
Date: Tue, 27 Sep 2005 01:18:09 +0100

Didn't check the To: list - here's a dose of axiom internals fun..

Peter Broadbery <address@hidden>
--- Begin Message --- Subject: Re: [Axiom-developer] types as values, and type internals Date: Mon, 26 Sep 2005 20:56:26 +0100
On Mon, 2005-09-26 at 12:21 -0400, root wrote:
> If memory serves me Aldor made Types be first-class objects.
> You could create, assign, and pass Type objects to functions.
> t

Yep; they can be passed around as normal.

As people have discovered, you wind up confusing the interpreter when
used directly.  

You can still do some useful things with them by disguising the fact
that they are domains, so in aldor have a type

AldorDomain: with {
        make: (T: BasicType) -> %
} == add {
        Rep ==> T;

        make(T: BasicType): % == per T;

and your aldor programs can return this to axiom.

Then make sure the interpreter can only see it.

Of course, it isn't really that useful as it is - there are no
operations on domains that are documented in aldor, so for example you
can't say 
        "if T = Integer then ..."
        "findOperation(T, add, (T, T) -> T)"

The second is handy if you want to write a specialised interpreter, by
the way.  In any case, you can write a domain like (see
below).  All it does is makes sure that axiom sees an object, while
aldor has a type to play with.  It can be extended to "know" about any
number of domains.

Even with these limitations, types and constructors as first class
objects are pretty powerful.  You can build domains on the fly,
construct functions, etc. To go further, you need a bit of reflection
(cf the java lang.reflect stuff for where this is going). People not
interested in axiom internals should switch off here.

Of course, the axiom interpreter must be able to do the "findOperation"
thing, and here we need to know how axiom (and aldor) represent domains.
This is where the less brave stop reading, and I should stop writing.

>From memory, and looking at interop.boot, we find that a domain is a
cons pair of two elements.  The first is a vector of functions (eg.
$oldAxiomDomainDispatch), and the second is used as an argument to
functions within the vector. 

The functions do the following:
1)      return the name of the domain, as a null terminated string
2)      unknown
3)      lookup an export by hashcode
4)      return the domain's hashcode
5)      unknown (inheritance related).

Categories are similar, but have a different vector of functions.

Next step is to abuse this information and extend our aldor domain above
to include these operations.  Here aldor's "pretend" keyword and a
strong stomach are useful.

You wind up with something like, below.

I've tested this as far as:
        lookup(theIntegerType(), "1", theIntegerType())
which extracts 1 from the Integer domain.

NB: This is very crash prone, and don't try to print the name of a
mapping - it won't work - not sure why.

There are other things that could be held in a domain object - eg a list
of exports, or a list of categories.  Adding this would be a bit of a
project though.

Anyway, hope this is interesting...


Peter Broadbery <address@hidden>

Description: application/applix-spreadsheet

Description: application/applix-spreadsheet

--- End Message ---

reply via email to

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