A simple PIC api

[Jochen Theodorou]

Am 12.03.2015 19:37, schrieb Mark Roos:
> Jochen
>
> The comment on the test part of the pic is interesting. Since I am
> looking at multimethods
> I would like to have a better  understanding of how you decide which
> code to dispatch at a site.

We currently have no PIC in Groovy. The naive implementation would be 
using the guards I use to check for the validity of my current method 
selection. But that means several guards to check the receiver and each 
argument as well as a switchpoint to ensure the validity of the meta 
class. So for a N argument call we have up-to N+1 guards. The guard will 
ensure the value is of the expected class and not null. Since I 
transport static information if available I can skip the guard for 
primitives. I could in theory skip the class check for final classes, 
but since null would be still a legal value and since it would 
potentially change the selected method, I would still have a guard. What 
I could do further, which I haven't done yet, is to check the overloads 
of the method. If there are none, I need only one guard for the 
receiver. And depending on the signatures I could also omit single 
guards. Problem is that the internal structures we currently have, have 
not been written to make this happen efficiently, which is why I did not 
go further yet.

> My pic suggestion assumes that one test method is applied to the
> arguments and its result
> used to select the code to execute.   This may be too limiting to be the
> general case.

But you made me think... considering a guard like this:

boolean testArguments(Object[] args, Class[] types) {
   for (int i=0; i<types.length; i++) {
     if (types[i]!=null) {
         if (args[i]==null || args[i].getClass()!=types[i]) return false;
     } else {
         if (args[i]!=null) return false;
   }
   return true;
}

plus some dropping of arguments to skip parts I don't want to guard, I 
could indeed go with one test handle. For null and class. The question 
though is how the performance of this would be. (Haven't tested it)

> The way I reason about a pic is that it is presented the current stack
> args and if it does
> not see a match the stack and the site are passed to the fallback.  The
> fallback has
> two responsibilities, to find the code for the current args and to
> generate a test which
> when applied to args in the future will dispatch the same code.

Yes, that was the same in my suggestion

> I see
> this test as
> a pattern match against some facet of the args.  Since I use a chain of
> GWTs each guard
> can have a different test/match.  I am looking at some form of bit
> vector for the facets and the
> pattern to match ( as in the paper Rémi suggested) so I don't have to
> have a complex tree
> like test.

Yes, a tree of tests should be avoided, I totally agree. Same for the 
code I have shown above probably.

So far I have avoided using projections since I am not sure about how to 
do this. Basically I am missing a way to project a Class to an usable 
int. I guess if I wanted to I could use the hashcode sum as a 
potentially quick first test and then continue from there.

> Perhaps my original thought of just declaring the site to be a pic and
> letting the jvm do its
> best optimizing the target will be the best.

needs testing I guess

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org