Re: MMD and VTABLE_find_method

Sam Ruby wrote: I took your example code, almost word for word, and added approximately three, count them three, machine instructions (not Parrot instructions, not C statements, but machine instructions) to the path length, and now adjectives like "horribly slow and wierd" come out. It looks li

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: pmclass default abstract noinit { PMC* add (PMC* left, PMC* right) { PRESERVE_CONTEXT; add_func = mmd_find("__add"...) // via VTABLE_find_method and here it becomes horribly slow and weird. You are already in one "add". What do you want t

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: PyStringPyIntPyNum Integer ... -- PyString py_add_sadd_err add_err add_err PyInt add_err add_i add_n add_i PyNum add_err add_n add_n add_i

Re: MMD and VTABLE_find_method

Sam Ruby wrote: [ a lot - I'll split answers ] Leopold Toetsch wrote: Sam Ruby wrote: It seems obvious, but it leads to surprises. Example: '1' + '2' The result will depend on what the actual types are of the inputs perhaps even what the context is of the caller. Ehem, given that and ... (from

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: First, a few things to note: the semantics of "add" vary from language to language. In particular, add is not guaranteed to be commutative in Python (think string addition). Yes, of course. It seems obvious, but it leads to surprises. Example: '1' + '2'

Re: MMD and VTABLE_find_method

Sam Ruby writes: > In the general case, a call to a subroutine with three arguments can > have four possibilities: anywhere from zero to three arguments may be > involved in the dispatch. > > I also read this to say that whatever code is generated by a subroutine > call is independent of the nu

Re: MMD and VTABLE_find_method

Hi, a lurker here. Probably you forgot the braces: > + /* let's ignore the complexities of a distance_func for now... */ > + mmd_flag = 0; > + addsub = VTABLE_find_method(INTERP, $1, __add, 0, &mdd_flag); > + if (!addsub) { > + mmd_flag = 0; > + adds

Re: MMD and VTABLE_find_method

Sam Ruby wrote: First, a few things to note: the semantics of "add" vary from language to language. In particular, add is not guaranteed to be commutative in Python (think string addition). Yes, of course. As my proposal is primarily focused on where the logic is placed in the system, not how i

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: First, a direct quote from : Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects,

Re: MMD and VTABLE_find_method

Sam Ruby wrote: First, a direct quote from : Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects, if we can't even find

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetica

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetical MMD PMC come from? A

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs.

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs. How do you find the co

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: However, from : Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distingu

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: However, from : Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distinguish between calls to si

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: The caller sets: mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth In the general case, how does the ca

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: The caller sets: mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth In the general case, how does the caller know that MMD is i

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: 2) n-dimensional MMD Perl6 supports a more general form of MMD: multi sub foo(ClassA $a, ClassB $b, ClassC $c : ...) { ... } [snip] 4) Proposed changes: a) All method lookup goes through VTABLE_find_method. To achieve MMD functionality, two arguments are added to the find_