Robert Bradshaw wrote: > I think Haskell has something like this. It's like > type coercion going the opposite direction--one wants an int result > so it changes the expression itself (perhaps after passing through > several layers? How feasible is this?).
I don't think that's quite the same thing. It's possible for type inference to propagate information downwards as well as upwards, but at the end of the process, Haskell decides on a *single* type for every function. That type may have parameters, but it's a single type nonetheless, within the Haskell meaning of the term. You wouldn't be able to define a single Haskell function that returns an int in some contexts and a string in others, for instance, *unless* one of its parameters was also correspondingly an int or string. In that case, you don't really have two functions returning different types -- you have a single function with type a -> a, where a can be any type. Once you know the type of the argument, then you know the type of the result. Your get_something() example would be impossible in Haskell, because it explicitly returns either a string or an int depending on run-time conditions, and there is no way of unifying those into a single return type that's parameterised with the argument types. -- Greg _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
