This is Paulcc_two's Typepad Profile.
Join Typepad and start following Paulcc_two's activity
Join Now!
Already a member? Sign In
Recent Activity
Re. comment from Jens - the ambiguity only arises if your implicit rule is allowed to apply everywhere. That's why approaches like coercive subtyping only trigger when the value type does not match the expected type - ie it uses both source type and target type, not just source type alone.
How about some kind of implicit conversion feature? You might have seen something like this in Scala, and type theorists have been studying more powerful systems with dependent types under the name of "Coercive Subtyping". Here's the type theory view Basically, we add an inference rule f : B -> C x : A c : A sub B ------------------------------------ f(x) = f(c x) : C And declare certain functions as coercions A sub B (from A to B) So, if we want values to act like collections, we can declare (\x -> [x]) as a coercion and hence (sum 2) now works. What about (map sum 2)? Do we want the coercion to be applied twice? And what about this coercion's interaction with other coercions? (We have answers to some of these questions.) Does this translate to a dynamically typed OO setting? Maybe - it might boil down to "if we can't find method M in class/proto C or its ancestors then look in different class D"... That might be fun to try.
Paulcc_two is now following The Typepad Team
Mar 18, 2013