[Aldor-l] "has" and "with" and bug

Ralf Hemmecke ralf at hemmecke.de
Mon Aug 20 07:22:22 EDT 2007


>> If you call
>>
>>    f(Fraction Integer)
>>
>> then R = Fraction Integer
> 
> More precisely, we know that
> 
>   R: Ring == Fraction Integer.
> 
> So,
> 
>   R: Ring == some_right-hand_side
> 
> . And that is indeed of the same shape as we had in the previous code
> 
>   Dom: with {} == some_right-hand_side
> 
> .

Obviously,

   R: Ring == Fraction Integer

and

   R: Ring == Fraction Integer add

is not the same thing. In fact, I don't know exactly, how the first is 
to be interpreted. Can someone show me whether for the first case R 
should be of category Field? It's clearly category Ring (and only Ring) 
in the second case.

> No. Consider the following counter example:
> 
>   #include "algebra"
>   f( R: Ring ):() == {
>     import from R;
>     1 / 1;
>   }
>   f( Fraction Integer );
> 
> fails to compile with
> 
>   "demo.as", line 4:   1 / 1;
>                      ....^
>   [L4 C5] #1 (Error) There are no suitable meanings for the operator `/'.

I would have guessed so. You are saying with that definition: "For all I 
am going to use inside the body it is sufficient that R is a Ring."

> . However, replacing "R: Ring" by "R: Field" compiles and works:
> 
>   #include "algebra"
>   f( R: Field ):() == {
>     import from R;
>     1 / 1;
>   }
>   f( Fraction Integer );
> 
> In both cases, "the actual exports of the domain you plug in" are the 
> same. However, the first piece of code does not work.

As you know "has" accesses the type of the actual parameter that is 
plugged in into the function. It can do that because it is evaluated at 
runtime. For your example, at compile time the meaning of "/" must be 
clear. That is completely independent of what you plug in to f(...).

>> It boils down to the question whether after
>>
>>    macro DomA == add {privatfunc():()=={}}
>>    DomB: with {} == DomA;
>>
>> DomA and DomB are two different things.
>>
>> In my eyes they are. Maybe in your eyes they are different, too.
> 
> Yes. In my eyes they are different too.
> 
>> But I want to hide (for "has") that DomB has any knowledge of
>> "privatfunc" and you don't.
>>
>> If you allow "has" to see "privatefunc", that violates the data
>> hiding principle.
> 
> No, it does not.
> And it now seems to me that we have been following different goals. The 
> discussion does not seem to be about static and dynamic types, but 
> telling Aldor to not export a function giving in the "add" part ;)

Exactly.

> (However, I did not erase my above comments, as we do not seem to have 
> the same view on typing in Aldor, and it may be interesting in 
> straightening things out there.)

> You can tell Aldor to _not_ export a function by adding "local" to the 
> definition of the function.

Completely clear. But what do I do then if someone has written a domain 
that exports some functionality that I don't want to have. Simple 
example: I want to rename a function.

Let's say someone has implemented a domain A that exports (and 
implements in the "add" part exactly the functions

   foo: % -> %
   +: (%, %) -> %

and nothing else.

What should

B: with {foo:%->%; *:(%,%)->%} == A add {*: (%,%)->% == +}

export?

How would you rewrite that with your understanding of how things should 
work?

Ralf



More information about the Aldor-l mailing list