On Fri, Jun 12, 2009 at 4:23 AM, Ralf Hemmecke wrote: > Bill Page wrote: >> But using / in Spad this would become a little awkward. Eg. >> >> y:NonZero(Integer):=retractIfCan(z) >> y case "failed" => error ... >> x/y > > Well... we should have exceptions anyway...
I am not convinced. I don't think I want Spad to be that much like Java and other conventional languages. > And since NonZero(X) would be a subdomain of X, there is actually no > need to do any conversion at all I rather think of "telling the compiler > about extra properties of an element". > As you say there no conversion is required but retraction to a subdomain does require evaluating a predicate. I emphatically do not agree however that this has anything to do with "properties of an element". Spad is a statically typed language which means that elements in themselves (i.e. values) do not have properties or even types. A value only has a type because it was produced by evaluating a constant, variable or function whose type is known to the compiler. NonZero(X) is a subdomain of X defined by the property or predicate (not zero?). You can produce a value of NonZero(X) by retracting values from X but this involves either a Union with a case construct or a function that might fail. I have experimented a little with this here: http://axiom-wiki.newsynthesis.org/SandBoxNonZeroInteger > ... > So I'd rather like a way to transport such information to argument > properties of /. It seems to me that the signature /:(Integer,NonZero(Integer)->Fraction(Integer) is exactly how this information should be associated with /. I do not think there is a need to add anything new to Spad for this purpose. (However getting what's already there now to work properly, e.g. SubDomain - that's another question!) > These are questions that should be tackled in the future. I don't > see some immediate remedy for that right now. Looks like a need > to invent a more powerful language. ;-) > I am very skeptical that one can achieve much by ad hoc extensions intended to create "a more powerful language". The problem is more fundamental and requires a sound general approach - well, category theory, of course. :-) 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 -~----------~----~----~----~------~----~------~--~---
