On 8/13/07, Gabriel Dos Reis wrote: > On Mon, 13 Aug 2007, Bill Page wrote: > > [...] > > | > > Similarly, an expression of type PositiveInteger is coercible to > | > > Integer bcause PositiveInteger is a subdomain of Integer. Similarly, > | > > a domain expression of type C1 is coercible to C2 if C2 appears > | > > in the list of named categories extended by C1. > | > > > | > > The exact rules are implemented by the function coerce() defined in > | > > compiler.boot. They are split into three categories: > | > > > | > > (1) easy coercion -- ceorceEasy > | > > (2) subset coercion -- coerceSubset > | > > (3) hard coercion -- coerceHard > | > | I think coercions from subdomain to domain and from subcategory to > | category (presumably (2) above) are of a different kind than coercions > | provided by the programmer. These are guaranteed to be correct by the > | nature of what we mean by these subtypes. That is why we need the > | concept of subdomain to be be "builtin" to the language instead of > | pasted on externally via an exported coerce operation. > > So, what are discussing now? To change the existing semantics? >
No. subdomain is already part of Spad. Spad implements things this way but Aldor does not. If I am discussing changing anything it would be Aldor not Spad. > > If we believe that we should treat values and types uniformely, I'm not > sure we should start with the principle that coercions from subdomain > to domain and from subcategory to category are different. If we want > uniformity, we should have a single rule. > I agree, however these coercions do arise from fundamentally different properties of domains and categories. > As for coercions, I'm not so sure I agree that they violate the > principle of least surprise. > There are many easy examples of this when you use the Axiom interpreter. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer