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

integer interning (was: MMD and VTABLE_find_method)

Sam Ruby wrote: Oh, well, back to coding. BTW, I'm committing the change to opcode issame to make use of the similarly named VTABLE entry as I need this in order to pass a test. Oddly, in Python: (1,2) == (1,2), (1,2) is (1,2) (True, False) 1+2 == 1+2, 1+2 is 1+2 (True, True) But: >>> 101+2 ==

add (out PMC ... (was: MMD and VTABLE_find_method)

Sam Ruby wrote: Leopold Toetsch wrote: the basics are: * the destination PMC $1 is created by the opcode I don't want to dwell on this point, but it would be rather handy if the caller were able to pass in an object which was responsible for producing the desired destination PMC on request. It

MMD distance (was: MMD and VTABLE_find_method)

Sam Ruby wrote: Leopold Toetsch wrote: * finding the "__add" method uses VTABLE_find_method to find all possible "__add" methods and a distance function to get the best match * the best matching function is invoked The word "best" here should be setting off alarm bells in everybody's head.

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'

MMD and pdd03 (was: MMD and VTABLE_find_method)

Luke Palmer wrote: A ruling: The caller might not know that it's calling a multimethod at all at compile time, much less how many invocants it has. This seems to invalidate calling conventions aka pdd03, *if* multi subs with native types are allowed. The register setup of calling these two multis

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_

MMD and VTABLE_find_method

The current MMD scheme is strictly 2-dimensional and it is totally static. It is not suitable for supporting Perl6 in it's current form. 1) summary of current state MMD (multi method dispatch) is used to find a method for binary operations like "add" or "cmp" depending on the classes (or types)