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: [EMAIL PROTECTED] -- 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. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
