[Aldor-l] exports and constants

[Christian Aistleitner]

Hello,

On Tue, 25 Jul 2006 15:19:31 +0200, Bill Page  
<bill.page1 at synthesis.anikast.ca> wrote:

> On July 25, 2006 2:00 AM Christian Aistleitner wrote:
>>
>> func( R: Ring ): () ==
>> {
>> 	if ( R has Field ) then
>>        {
>>           ...
>>        }	
>> }
>>
>> Aldor has to have more knowledge about R than only its static
>> type. Aldor knows about the dynamic type. And the "types on
>> variables" paradigm does not deal with this. If I am not wrong,
>> "Types on variables" refers solely to the static type.
>
> I think that because of multiple inheritance, you are in fact
> wrong. And I am reluctant to introduce a new concept "dynamic type"
> that is not defined in the current Aldor or Axiom documentation.

I understand that you do not want to introduce things not being mentioned  
in the AUG.
But how does multiple inheritance come into play?
The given example, does not make use of multiple inheritance.

But even if ...

CatA: Category == with { funcA: () -> () };
CatB: Category == with { funcB: () -> () };
CatC: Category == with { funcC: () -> () };
func( R: with { CatA; CatB; } ): () ==
{
	if ( R has CatC ) then
         {
            ...
         }	
}

R still has one static type ( with { CatA; CatB; } ) and one dynamic type  
( I would have to give an actual function call to determine it).

How does this setting cause problems to static/dynamic typing?

>> So for domains, we have more than the static type -- more
>> than the type on a variable. We have dynamic types --
>> "Types on data" (Be it that the type is really stored in memory
>> locations close to the data, be it that there is some lookup
>> table for dynamic types, or be it something completely
>> different. Aldor gets to know the dynamic type of a domain
>> and thereby associates a type to data, not to the variable).
>>
>
> I agree that there is more than "static type"

Fine.

> but I do not
> agree that this is "types on data". "types on data" (i.e.
> dynamic type checking at run time) contradicts one of the
> design goals of Aldor.

We have to separate between "types on data" and "dynamic type checking at  
run time".
I use "types on data" as in the AUG: Each data value is self-identifying.  
As I described in my last mail, for me it even suffices if the mapping  
between the data and the type is not in one memory block, but can somehow  
be achieved.
"dynamic type checking at run time"  -- I assume you mean "dynamic" as  
attribute to type, "checking dynamic types". You can have dynamic types  
and still not allow to check them at runtime. (People with more knowledge  
about C++ will probably prove me wrong, but C++ without RTTI extension  
looks like to me, as if (mostly) all type checking could be done at  
compile time.)

I think, for domains, Aldor has types on data.
Assume, we have not types on data. How do you think, Aldor knows that
   R: Ring == Fraction Integer;
is actually a Field.

I think, "has" performs "type checks on the dynamic type" (most likely at  
runtime). How else could the function
   func( R: Ring ): Boolean == { R has Field; }
yield false for
   func( Integer );
and true for
   func( Fraction Integer );
(Safe for inlining and such topics)?


> I do not see anywhere in Aldor where
> the notion that all data (values) have type.

By Aldor you mean the compiler or the AUG?
For the compiler, we already gave tons of examples.
For the AUG, talk to the authors.

--
Kind regards,
Christian