[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**: |
Page, Bill |

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

**Date**: |
Wed, 28 Sep 2005 15:06:34 -0400 |

On Tuesday, September 27, 2005 3:12 AM William Sit wrote:
>* ...*
>* 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?*
>* *
This toy example
http://wiki.axiom-developer.org/SandBoxMapping
"... provides a function-like type that can be queried for
domain and co-domain."
Of course this is not same as being about to manipulate
the code part of a function. On the other hand in the
Axiom interpreter (which operates closer to lisp then to
Aldor) this is also nearly possible.
Try:
\begin{axiom}
f:Float->INT
f(x) == floor(x)
f(1.1)
f::InputForm
\end{axiom}
Unfortunately Axiom's 'interpret' function is not able to
interpret the InputForm generated for such functions. :( See
issue report:
#208 interpret(x::InputFor)=x is broken for functions and types
http://wiki.axiom-developer.org/208InterpretXInputForXIsBrokenForFunctio
nsAndTypes
However, my opinion is better to rely on higher-order functions,
e.i. functions that manipulate and return functions in the
manner provided by Aldor and Spad rather than handling the
interpreter's functions in this lispy manner.
Formal results from the theory of programming languages and
category theory show that a language like Aldor that includes
sufficient structure to represent cartesian closed objects and
operations based on typed lambda calculus are equally powerful
to such lower level manipulations.
Regards,
Bill Page.

[Prev in Thread] |
**Current Thread** |
[Next in Thread] |

**[Axiom-developer] RE: Types as values, and Re: Static versus Dynamically typed**,
*Page, Bill* **<=**