On Tue, Nov 18, 2008 at 6:30 PM, Waldek Hebisch wrote: > ... > Bill Page wrote: >> I think that testing for specific function signatures should be >> avoided. That leads to the "slippery slope" of full reflection and >> run-time types - something that the original designers of Axiom >> intended to avoid. >> > > No. Even without tests Spad needs runtime representation of > types.
I agree enthusiastically that Spad needs runtime representation of types. Spad needs types a first class objects (values). Spad needs types whose values are types, i.e. the domain named Domain - the domain of all domains and subdomains of Domain (categories). > > _Without_ tests conditional signatures would be less usefull > then there are now. You may argue that testing for categories > is cleaner, but both ways have its own problems (for example, > as Ralf pointed out there are no semantic checks), and testing > for signature may better explain programmer intent (for example > you may test for presence of coercion). I do not know how to test for the presence of coercion without invoking some convention, e.g. that the name of the function which performs coercions is formed from the English word 'coercion'. Certainly other possibilities exist. It does not seem to me to better explain the programmer's intent. Recently Martin argued for increased use of the category constructor 'CoercibleTo(x)'. To me, in spite of it's limitations (we have no way to express the fact that this predicate is transitive) this notation has significant semantic advantages over just testing for the presence of an operation with a given name. > Actually, since signature which appears in tests are static such > test do not interfere too much with static type checking. > I agree. Providing this feature is not expensive. I am just arguing that it is against what I think is the "design philosophy" of Spad. But I have to admit that this philosophy is not so clearly specified anywhere, so my argument is not a very strong argument. > Concerning runtime types: the original design was to have runtime > representation of types but avoid runtime type checks. Also, the > idea was to do static resolution of overloading (but still the > actual functions to call are determined only at runtime). > Yes. > Concerning reflection: reflection complicates semantics and > it is easier to implement language without reflection. But > reflection has some good uses and I would like to support > them (as long as there is no conflict with compilation). Ok. This is a "permissive" approach to language design. From the point of view of a general purpose language maybe it is ok to let the programmer use certain constructs if it is more convenient even if it does fit some preconceived model of how one's program "ought" to look. But Spad was originally designed for a very specific purpose - as a language in which to express mathematical algorithms for the Axiom library. I think the restrictions that sometimes makes Spad a somewhat difficult language to use also often contribute to the goal of making it more precise and expressive when it comes to the mathematics. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~----------~----~----~----~------~----~------~--~---
