axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] RE: Types as values, and Re: Static versusDynamica


From: William Sit
Subject: Re: [Axiom-developer] RE: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )
Date: Mon, 26 Sep 2005 13:57:01 -0400

Ralf Hemmecke wrote:
> 
> >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.
> 
> Interesting. If that were so easy, it would be possible to ask a type
> for the functions it implements.
> 
> > Exactly. It has been a long standing (but lost) request (I believe from me) 
> > that
> > Axiom constructors (that include category, domain and packages, but not the
> > developers :-)) allow query of their arguments. It is useful, for example, 
> > to be
> > able to distinguish whether a field is a quotient field of some integral 
> > domain
> > or just a field to make codes more efficient. The request was not acted upon
> > because at the time (around 1990 +/- 3 years?), effort was concentrated on
> > developing the Aldor (A#) compiler, which promised to solve such problems.
> 
> I am not so sure whether I would really need that kind of reflection. In
> some cases it would be useful, for example, for the implementation of
> something like JUnit for Aldor. However, I somehow do not think that
> being able to query the structure of a type is a good idea. You gave a
> good reason, but isn't there a better way to achieve efficiency?

Yes, but another reason, in the above example of field, is in allowing
generalizations to work, not just efficiency due to data representation
(reducing computation in the field to that in the underlying integral domain, as
in Grobner bases computation). For example, if I have a constructor that
requires an integral domain R as a parameter, and I constructed in the package
the quotient field of R, as you may suggest as an explicit way to achieve
efficiency, then the package will FAIL if R is actually a field (you can
consider this as a bug if you like), even though a field IS an integral domain,
mathematically. If we COULD ask whether R is a quotient field (not just a field)
and if in case of affirmative answer also find out the underlying integral
domain S of R = FRAC S, we would be able to replace R by S for the package. Of
course, you may say a user should then use S in the first place. But we should
not expect that, which limits the power of the system, and we are aiming for
automation: the requested integral domain R could be just something returned
during the course of a computation. So without such a feature, I doubt types and
domains can be considered as "first class" objects.

> >>Aldor allows something like
> >>
> >>#include "aldor"
> >>#include "aldorio"
> >>Dom: with {
> >>   foo: % -> Boolean;
> >>} == add {
> >>   foo(x: %): Boolean == true;
> >>}
> >>
> >>import from Dom;
> >>if Dom has with {foo: % -> Boolean} then {
> >>        stdout << "foo is there" << newline;
> >>} else {
> >>        stdout << "foo is missing" << newline;
> >>}
> >>
> >>However, I cannot, for example, write a function that returns a list of
> >>names of functions implemented in Dom. (That is the current knowledge I
> >>have.)
> 
> > In other words, if I understand the example, you can't list unless you 
> > already
> > know?
> 
> Exactly. Well, returning the list of function names would certainly be
> do-able, but the next thing a programmer would ask for is: How can I
> call the function with name "foo"? What is the input type? ...

Yes, this would be recursive, and certainly relates to the Crystal vision of
Tim.

[snipped]
 
> >>And, of course, I see no way of morphing the result of "foo" to
> >>"false" without writing a new function.

The "way" to do that would be to pass "true" or "false" as parameters to the
package Dom to avoid run-time code-modification. However, this is not "totally"
dynamic (modification is anticipated at compile time):

Dom(b:Boolean): with           {
   foo: % -> Boolean;              } 
  == add                       {
   foo(x: %): Boolean == b;        }

> > That is what I was asking: code modification. Like you, I also interpret 
> > "first
> > class object as data" that way (but that need not be the "official"
> > interpretation).
> 
> I think I am happy that the Aldor code itself is not modifyable (as in
> Maple).
> 
This is a balance (trade-off?) between power and responsibility. Don't most
programmers want power and not responsibilities? :-)  Much code-modification (at
least for higher level languages) is obsoleted (that is probably a good thing)
due to parametric polymorphism, but I am not ruling out applications (other than
hacking) that require that type of programming power. Note that
code-modification is "totally" dynamic since the modification is not
anticipated. It is not reasonable to expect programmers to anticipate all
possible modifications of code, and thus, parametric polymorphism is not
sufficient, or equivalent, and not as powerful.

William




reply via email to

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