[Axiom-developer] RE: Types as values, and Re: Static versus Dynamically typed

[Bill Page]

On September 24, 2005 12:07 PM William Sit wrote:
> 
> Bill Page wrote:
> > 
> > On September 23, 2005 7:36 AM William Sit wrote:
> > > From www.aldor.org:
> > > > Types and functions are first class entities allowing
> > > > them to be constructed and manipulated within Aldor
> > > > programs just like any other value.
> > > >
> > > Can some Aldor expert expand on this? For example, can 
> > > functions be created, modified, and compiled and called
> > > all at run time? (People used to do code modification on
> > > assembly languages and may still do, but the practice is
> > > I think no longer promoted, if not outright banned.)
> > >
> > 
> 
> > In Axiom it is possible. See for example section 9.50
> > MakeFunction in the Axiom book. There are numerous other
> > examples of this in Axiom.
>
> Thanks, but MakeFunction only turns an expression into a 
> function by enabling evaluation. So in this sense, sure a new
> function is created, much like defining a new function in the
> interpreter. What I meant (sorry I wasn't clear) was to
> take an existing library function, say a simple one like 
> "inc" which adds 1 to the argument, modify the code and create
> FROM THAT CODE a new function "incBy2" (or for that matter,
> use the same function name "inc") that adds 2 to its argument
> (note, not rewriting from scratch "incBy2", and not
> implementing "incBy2" USING "inc" twice, but by modifying
> existing code, changing where "1" is, to "2" in the code
> itself), have that function compiled, and executed, all
> without leaving the interpreter or Axiom (or, Aldor). The 
> crucial thing I am asking is "code-modification" because
> that is the real meaning, as I understand it, of
> "constructed and manipulated [Types and functions] ... 
> just like any other value".

No I do not think that "code-modification" is the meaning
of "constructed and manipulated" in reference to Aldor.
What you are describing is equivalent for example to allowing
modifiable string *constants* -- something that used to be
possible in the C programming language, i.e. pass a pointer
to a string constant say "xxx" to a function that modifies
it's value to, say "123". Later in your program when you
have written what looks like "xxx" is now treated as "123".
I am also old enough to remember when it was possible for
a bug in Fortran to inadvertently modify the value of a
integer constant because these were passed by reference
to a location in memory that was initialized to the proper
value.

I agree that this practice is essentially "banned" - for
good reason!


> Similarly, the "curry" type functions in Axiom do not
> "modify" code and is a variant of MakeFunction. Can Aldor
> manipulate types and functions much like Lisp (or Scheme)
> does?

But I think that is exactly what is implied by construct
and manipulate in this context. Functions in lisp are
just lists of a certain kind and so yes of course they
can be manipulated as lists. Functions in Aldor (and most
other languages) are more complex things than lists but
still then can be constructed and manipulated like any
other *first class objects*. For example we can curry
them, we can compose them etc., to make new functions,
in the same way that we can create the integer 2 and we
can add 2 + 2 and get a new integer.

I supposed however that what you might be asking is whether
functions in Aldor are "mutable" in the same way that
lists are mutable in lisp (or arrays are mutable in other
languages). I think the answer is "no". In general constants
are not mutable in this way and functions are constants.
But Aldor does allow use to use names which are assigned
values which are functions and of course the values assigned
to such names can change during the course of a computation.

> In principle, this is easy, if the code is treated
> as a string, and if the format structure and language 
> syntax are known; so the question is not whether this
> is "possible", but whether this is "available" as a
> feature of the Aldor language, that the code string
> can be returned, manipulated, edited, and sent back to
> the compiler to get a new or modified function. In
> Axiom, I would imagine one has to go the relevant NRLIB,
> look at the code.lsp, and create a new version of it,
> create the corresponding .o file to make this "possible".
> I don't consider that as "available".
>

I am quite sure that by design this is not "available" in
Aldor and that it is not implied by the description of Aldor
quoted at the beginning of this messages.

In an interesting paper recently pointed out to me by Ralf
Hemmecke:

http://www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/discussion/define.pdf

A D Kennedy defines first class entities as follows:

"An object is first class if its value can be expressed as
an anonymous constant expression."

And gives the following examples:

  address@hidden -- is an anonymous integer constant,

  (x: SingleInteger): SingleInteger +-> x * x
    -- is an anonymous function constant
    -- (a.k.a. a lambda expression)

  with {+: (%,%) -> %; inv: % -> %}
    -- is an anonymous category constant

  add {
    Rep == SingleInteger;
    import from Rep;
    (x: %) + (y: %): % == per((rep x) + (rep y));
    inv(x: %): % == per(1 / rep x)
  } -- is an anonymous domain constant

--------

So the fact that "types and functions are first class entities"
in Aldor specifically allows them to be constructed and
manipulated like anything else whose value is a constant.
This does not mean that we can change the *value* (i.e. the
meaning) of a function that adds 1 to its argument (referred
to as "inc" in your example above) so that later adds 2
instead of adding 1, any more than we can change 1 to mean 2.
But we can of course change what the name "inc" refers to so
that it might later refer to a function that adds 2. And
we can pass functions as arguments to other functions which
might apply them or use them to construct new functions which
are then returned as the value of the function etc.

However Aldor is still statically typed in the sense that
we cannot change an object which has been declared as being
of one type into another. But Aldor/Axiom types are quite
powerful since then can be constructed from union, record
and mapping, so we can write things like:

(1) ->   x:Union(Integer,Float,Integer->Integer)
                                        Type: Void
(2) ->   x:=1

   (2)  1
                            Type: Union(Integer,...)
(3) ->   x+x

   (3)  2
                               Type: PositiveInteger
(4) ->   x:=1.0

   (4)  1.0
                               Type: Union(Float,...)
(5) ->   sin(x)

   (5)  0.8414709848 0789650665
                                          Type: Float
(6) ->   x:=(w +-> w+1)

   (6)  theMap(Closure)
                 Type: Union((Integer -> Integer),...)
(7) ->   (x::(Integer->Integer))(1)

   (7)  2
                                 Type: PositiveInteger
(8) ->

and x would still be considered a statically typed first
class object.

Regards,
Bill Page.