> I would claim that what we are lacking is a proper definition of the
> meaning of 'coerce'. When should some operation be called a "coercion"
> and when should it more properly be called a "conversion"
> ('ConvertibleTo')?I have the same feeling as Bill. Or can someone who knows give a pointer to the definition? > 'coerce' operations, as mappings A->B and B->C, can certainly be > composed in a meaningful way. But I am less certain about whether we > really want to consider > > A:CoercibleTo(B) and B:CoercibleTo(C) > > to be composible. You made a point here. With the above definitions you cannot easily claim that A: CoercibleTo(C), since that must have been declared explicitly. So in some sence "CoercibleTo" is not really appropriate and all taht counts in A is that there is a function coerce: % -> B where "coerce" is considered a special name for an embedding of A into B. Again, I'd like to point again to Doye's thesis. http://axiom-portal.newsynthesis.org/refs/articles/doye-aldor-phd.pdf As far as I remember, it is concerned with the topic of making a proper "coercion system". >> More generally CoercibleTo means _one way_ transformation, >> without a canonical way back. RetractableTo is closer to >> embedding. > By _one way_ I guess that you mean that information is lost. I am not > sure what you mean by "canonical" here. Perhaps another way of saying > this might be that the mapping 'coerce' is not one-to-one (monic). I > agree that this seems to be the intended meaning of 'coerce' in the > context of 'RetractableTo'. What you propose is that 'coerce' has a > different meaning in the context of 'CoercibleTo'. In contrast I > specifically wanted to *define* coercion as a mapping that is > necessarily one-to-one (because it is the pullback of an injection). I > am not sure that giving 'coerce' more than one meaning is a good idea. My two cents... The 'coercion system' (I just call it that way) is like a convention (for the name 'coerce') that says that is giving a directed acyclic graph (DAG) (in that sense it is _one way_). Furthermore the programmer must assure that composition of coercions is unique, i.e. all diagrams in the above mentioned DAG are commutative diagrams. (My feeling is that OutputForm is at the top (or bottom depending on how you view it) of that DAG. In order to be useful, any coerce should be accompanied with a retract (in the sense of the pullback that Bill mentioned earlier coerce A ---------> B | | id | pullback | retract | | \|/ \|/ A -------> Union(A,"failed") inj See also http://groups.google.com/group/fricas-devel/browse_thread/thread/54818857a282e1f0/9971b1d9312a29db?#9971b1d9312a29db ). The implementation of 'retract' would be in the responsibility of the programmer that implements 'coerce'. But all this 'coercion system' is only a *convention* in a library, but such a convention could then be used by a program that relies on it (for example the interpreter, to do some automatic coercions and thus ease the life of a user. The 'commutative diagram' property then ensures that the interpreter need not signal ambiguity if it finds several ways to coerce a value of type A into a value of type B. And clearly, having a directed graph is essential. I guess, all that puts quite a lot of burden onto the programmer and it would be somehow nice if such a 'coercion system' could have some support by the compiler. But I don't think that compiler support is absolutely essential. For the moment I would even rather like to keep the language simple and treat the 'coercion system' as a *convention*. In the interpreter (not in the compiler) coercions can be applied automatically. Conversions are just like any other function --- no automatic application. I am not so sure about retract. But also there would be a way to apply it automatically. For example, to automatically view a NonNegativeInteger as a PositiveInteger in the *absence* of retract: NonNegativeInteger -> PositiveInteger would be to first coerce to Integer and then retract to PositiveInteger (all coercions first than retractions). Of course that might fails in some cases. But I would rather propose to keep the search algorithm simple and (possibly) fast by just adding a missing coerce/retract pair to the library in an upcoming release. Ralf --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
