[Aldor-l] exports and constants

Gabriel Dos Reis gdr at integrable-solutions.net
Mon Jul 24 17:48:49 EDT 2006


"Bill Page" <bill.page1 at synthesis.anikast.ca> writes:

| On July 24, 2006 5:10 PM Gaby wrote:
| 
| > | > ...
| > | > Bill Page wrote:
| > | ... 
| > | Could you define for me what you mean by "dynamic type"?
| > | I think the usual definition involves type checking during
| > | run time.
| > 
| > Not really.  If you take the C language for example, there is the
| > notion of "static type" and "dynamic type" (sometimes called
| > "effective type"), yet C does not require type checking during
| > runtime.  
| > 
| > When you have the notion of variable declaration and the possibility
| > of "cast", i.e. in the sense of change of *type of expression* used
| > to access data, you naturally get into distinguishing "static type"
| > from "dynamic type".  You don't necessarily need to have runtime
| > type checking involved.
| 
| Oh, the water is so muddy! Let's reserve talking about Aldor's
| 'pretend' for another time, but recall that 'rep' and 'pre' are
| intended as a "type-safe" implementation of this idea.

But, casts in C are also intended to be "type-safe" too -- no kidding,
really. :-)

| > "static type" concerns with the properties of the program that
| > can be derived only from "static" analysis without taking into
| > account any runtime semantics.
| > 
| > "dynamic type" concernes the properties of the program that can
| > be derived by taking into account runtime semantics.
| 
| Yes, this definition seems fine to me.
| 
| Do you agree that Aldor uses only "static type"?

not from my understaing of "static type" and the way Aldor handles
"multiple inheritance" and "has".

| > | Since Aldor is statically typed how can we define this in a
| > | useful way in Aldor?
| > | 
| > | Should we say something like this?
| > | 
| > |  The "dynamic type" of Y is
| > | 
| > |    Join( x for x in Category where Y has x)
| > 
| > that is close -- and certainly matches practice in object oriented
| > languages and non-object orinted ones like C.
| > 
| > | But then dynamic type would be just type satisfaction as I
| > | said earlier, no?
| > 
| > no, "type satisfaction" is a generic term that applies to both
| > the static semantics and the dynamic semantics.
| 
| I meant "type satisfaction" as it is used in the Aldor Users Guide
| in the definition of the "has expression".

It says in section "7.7 Type Satisfaction":

  We say that a type S satises the type T if any value of type S can
  be used in any context which requires a value of type T.

That does not tell me that "type satisfaction" is only in the sense of
"dynamic type" -- nor does the rules that are listed there...

| > ... 
| > I suspect the trouble here is that in some context "has" is
| > evaluated statically, and in other context it is evalued
| > dynamically.  So you fail to appreciate the distinction.
| 
| The Aldor Users Guide says that "has" expressions are evaluated
| at run time.

Yet, you have to confront that with earlier claims that Aldor uses
only "static type" when one is confronted with codes like

   with {
           BoundedFiniteLinearStructureType S;
           if (T has TotallyOrderedType) then {
                   TotallyOrderedType
                   sort!: % -> %
           }
   }

-- Gaby



More information about the Aldor-l mailing list