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 internalsDate: 2005年9月26日 20:56:26 +0100On 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 ..." or "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 domain.as (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 domain2.as, 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. -- Peter Broadbery <address@hidden>Attachment: domain.as
Description: application/applix-spreadsheetAttachment: domain2.as
Description: application/applix-spreadsheet
--- End Message ---