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

[Christian Aistleitner]

Hello,

> I still see conceptual problems with "names". I can take one
> source code containing, say a local variable named X that
> compiles and runs properly, do a text substitution of X to Y
> (assumming that the variable Y does not aldready occur) to create
> an entirely new source code that compiles abd which (usually)
> results in exactly the same machine code. The "name" I give to
> the variable X (or Y) does not play any logical role in the
> program. It is like a comment. It is only interesting (perhaps)
> to someone wishing to debug the source code and who knows the
> (human) meaning of X.
>
> But there are other names, such as the names of functions and
> types from an external library that do certainly make sense to
> associate with the object code.

maybe I did not make my statement clear enough. In code like:

SomeDom: with {
   func:( B: A, C: B ) -> ();
} == add {
	func( B: A, C: B ): () == {
         local x: Integer;
         x=1;
       }
}

Reflection should be able to tell you "SomeDom contains a function with  
name func".
Reflection should be able to tell you "SomeDom contains a function with  
name func, whose first parameter is B and is of type A".
Reflection should not be able to tell you "SomeDom contains a function  
with name func, which uses the variable x".

So I guess me actually agree on this one, don't we?

>> > [ example of "self-identifying" code ]
>>
>> 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.
>
> I am not sure what you mean by "proper types" but it seems
> clear that it is possible in Aldor to add many different kinds
> of self-identifying information as exported constants.

I'll give you some hints about the tip of the iceberg. Consider the piece  
of code above. What would your exports function yield? Probably something  
like
generate {
   yield with { func: ( B: A, C: B ) -> () }
}

But that's of limited use. How can you extract information from "with  
{ func: ( B: A, C: B ) -> () }"?
You should have to extract the identifier "func" and it's type "( B: A, C:  
B ) -> ()". But your yielded expression is a black box -- you can test it,  
but not look inside of it.
You should be able to determine the domain and codomain of mappings. You  
should be able to "explode" "( B: A, C: B )" into "B of type A and C of  
type B".

But as I said, it's probably to early to discuss these issues now.

--
Kind regards,
Christian