[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: William Sit
Subject: [Axiom-developer] Re: Types as values, and Re: Static versus Dynamically typed
Date: Tue, 27 Sep 2005 03:11:48 -0400

Dear Bill:

Thanks for taking the time to explain things to me.

Bill Page wrote:
> > > From
> > >  Types and functions are first class entities allowing
> > >  them to be constructed and manipulated within Aldor
> > >  programs just like any other value.


William Sit wrote:
> > 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.


In light of your view (which is the correct view) that functions are constants,
I might have used the term "code-modification" wrongly. I was using it in the
sense that function code is data and data is being modified, so code is modified
in the process, but not in the sense of changing the function, which perhaps
should remain unaltered. So let me instead ask whether a copy of the data
representing the definition of the function may be modified to create another
Constants should still be available to create new objects. So let me modify my
example. Suppose "inc" is a compiled function that increments 1 to its argument.
Then I can assign it to a variable:

variableFunction := inc

if you like,

variableFunction := copy(inc)

so I will not modify "inc" in any way. However, I want the definition for "inc"
to be available to me (perhaps as a lambda expression, perhaps its Axiom
equivalent) and that I can change this definition in my copy of "inc" (that is,
operating ON the function object) to create a new function that increments 2 to
its argument. This would be analogous to say how one modifies the entries of a
matrix via a copy. (Actually, we are allowed to directly change the entry of a
matrix for efficiency if the matrix has Mutable). But for this discussion, I am
no longer assuming functions are mutable (I probably was).
> > 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.

These are operations USING the function, not operations ON the functions. If
"constructed and manipulated" means only USING the functions, I don't see any
extra power in Aldor that is not already in Axiom.

> 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.

I will assume functions are not mutable, but I don't see a compelling reason to
enforce this if functions are indeed "first class" (here, meaning on equal
footing as data objects). If matrices and other structures can be mutable, why
should functions be different? (OK, in the hands of careless programmers, this
power will play havoc; but so would such programmers do damage to matrix
computations or other mutable objects).

> 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.

You mean I can do:

variableFunction:= inc1

variableFunction:= inc2

I don't see that as a powerful feature. In fact, its power is much like a TeX
macro. Convenient, yes.

> > 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.

The statement needs clarification. But shouldn't the definition of function (the
code, not just the signature) be available for manipulation even if the function
itself is kept constant?
> 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."
> 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.

OK, grant you that. There is still a difference in "types and functions as first
class entities" and usual domain objects as first class entities. For domains,
we are normally not exposed to the Rep, but if we like, we CAN provide that
functionality by means of functions exported for that domain. An example would
be PRODUCT or FRAC (where using "numerator" and "denominator" we can extra
fields in the Rep, modify them, and create a new fraction). For the "domain of
functions", the Rep of a function may be its anonymous function constant (lambda
expression), but it seems we are not allowed to provide functionality to read
this lambda expression and construct new objects from it. If indeed objects in
the "domain of functions" are first class objects, we should be able to query
its properties. The same thing for the "domain of Type" (probably an
ill-constructed term), we should be able to query the properties of domains and

> 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.

All that amounts to is just pointers or macros. As long as it is only USING the
functions rather than operating ON the functions, such features do not give
functions equal status as objects in domains (even if by definition, they are
both first class; perhaps they should be called weak first class).

> 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:
[example using Union to switch types: snipped]

> and x would still be considered a statically typed first
> class object.
Sure, because the type of x is actually Union(Integer, ...) throughout all these
computations. It is only because the interpreter understands Union to apply
automatically the  "case" function and locate the other function calls. I am not
following the relevance to "first class object".

Thanks again for your input.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]