On Friday, July 18, 2014 12:59:37 PM UTC-7, Robert Bradshaw wrote:
>
> Yes, but here T must explicitly implement to multiple dispatch. One
> can't take an existing object and "add a method" based on the type of
> the second argument.
>
Do you mean that
a.bar(b)
a.bar(c)
would dispatch to different methods
a.bar_B(b)
a.bar_C(c)
based on properties (probably type) of b,c?
You could do that via exactly the same mechanism. You may have to jump
through some hoops to get the right binding behaviour. And of course,
inheritance of "method" on subclasses of type(a) might get messy.
Use could be spelled similar to
class foo(...):
bar = binding_multimethod()
@bar.register(int,float)
def i_f(self, n, epsilon):
...
@bar.register(int,int)
def i_i(self,n,m):
...
and monkeypatching would be straightforward too:
@foo.bar.register(float,float)
def f_f(self,epsilon,delta):
...
and could be desirable if for some reason the code for f_f is best grouped
according to another parameter.
>From a language design point of view, you'd get a strange mix, because
you'd be using the "a.bar" spelling, which is purpose-made for single
dispatch, and mix it with another dispatch mechanism: if you have a more
general dispatch mechanism, why not use it for the first argument as well?
For integration with the rest of python it might be appropriate to go with
the hybrid, though. It would be the kind of thing you can just add to an
existing class.
We also have @coerce_binop
>
> https://github.com/sagemath/sage/blob/6.2/src/sage/structure/element.pyx#L3260
>
> which is nice.
Yes, that does a good job for what it's for. However, not all multiple
dispatch problems are coercion problems, and they're not all for binops.
> Here we're conflating the issue of types and Parents
> (where the latter can be viewed, somewhat, as dynamically created
> parameterized types),
You don't have to do multiple dispatch on type. In a statically typed
language you would want to do that, though, because that's the only case
you may be able to optimize at compile-time. All the other ones can only
try to do some runtime work to try the most likely candidates first.
The most obvious place where I think multimethods might have a place in
sage at the moment is in constructors/factories and conversion calls (which
are almost spelled as constructors anyway).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
