mmd

[Jeff Horwitz]

for mod_parrot i want to support both passing both PMCs and native types
to the apache API, depending on the HLL. MMD was doing a great
job handling this for me until i ran into a problem.

given the following methods:

.sub bar method, @MULTI(Foo, string)
.sub bar method, @MULTI(Foo, pmc)
.sub bar method, @MULTI(Foo)

and assuming 'Foo' is an object PMC, here's what happens when i call
'bar' with various arguments:

$I0 = find_type 'Foo'
$P0 = new $I0
$P0.'bar'() # calls the empty arg version of bar
$P0.'bar'("a string") # calls the string version of bar
$P1 = new PerlString
$P1 = "a perl string"
$P0.'bar'($P1) # XXX calls the empty arg version of bar

the pmc version of bar() is never called, even when passing a PMC. if i
change the prototype to @MULTI(Foo, PerlString), i can pass the PerlString
to that, but i'd prefer to be able to pass any arbitrary PMC without
explicitly specifying its type in the method.

-jeff

[Leopold Toetsch]

Multi subs and especially multi methods are barely tested. 'pmc' or '_'
should match 'Any' PMC, so that's for sure a bug. Can you please provide
a test-like sample file to investigate, thanks.

> -jeff

leo

[Jeff Horwitz]

On Tue, 24 May 2005, Leopold Toetsch wrote:

> Multi subs and especially multi methods are barely tested. 'pmc' or '_'
> should match 'Any' PMC, so that's for sure a bug. Can you please provide
> a test-like sample file to investigate, thanks.

here you go. it should print "string PMC nothing", but instead prints out
"string nothing nothing". interestingly, if you change @MULTI(Foo) to
@MULTI(_), it all works, but that seems more of a band-aid solution for
this particular case.

-jeff

---

.namespace ['Foo']

.sub bar method, @MULTI(Foo, string)

print "string\n"
.end

.sub bar method, @MULTI(Foo, pmc)

print "PMC\n"
.end

.sub bar method, @MULTI(Foo)
print "nothing\n"
.end

.namespace ['']

.sub main @MAIN
newclass $P0, 'Foo'

$I0 = find_type 'Foo'
$P0 = new $I0

$P0.'bar'('Bar!')

$P1 = new PerlString
$P1 = "Bar!"
$P0.'bar'($P1)

$P0.'bar'()
.end

[Leopold Toetsch]

[ cc'ed list ]

Chip Salzenberg wrote:

> On Tue, May 24, 2005 at 02:42:47PM -0400, Jeff Horwitz wrote:
>
>>.sub bar method, @MULTI(Foo, pmc)
>
>

> At first blush, I think mmd based on representation choice ($I vs. $P)
> is a mistake. Why should an integer in a $P0 be mmd'd differently from
> an integer in a $I?
>
> I could of course be missing an important use case.

Dunno. But at least we already have MMD based on types and "int" vs
"Integer" isn't special cased anymore. These are just different type
numbers albeit not related.
The problem is of course that you can't call the same subroutine with
either a native int or an Integer PMC, if the sub isn't aware of that.

We'd need something like:

.sub foo @MULTI(Integer)
I5 = P5
.sub_entry foo @MULTI(int)
# ... I5 already passed in

[ in terms of current pdd03 ]

Or we have some glue code that does the same.

leo

[Leopold Toetsch]

Jeff Horwitz wrote:

[ mmd test code ]

> the pmc version of bar() is never called, even when passing a PMC.

This is fixed now. A differing argument count had a too low distance
penalty. But please note that the MMD system still has no clue what is
an invocant and what a plain call argument because current calling
conventions don't provide this information.

If a multi is found all arguments are used for distance calculation. If
the function is called with less arguments there, is an arbitrary bigger
penalty for this candidate then for a matching argument count.

> -jeff

leo