Sam Ruby wrote:
Now, what should the code for function f look like? The only reasonable answer is something along the lines of:
getattribute $P0, P5, 'find'
I doubt that. All languages have different semantics, and we can't implement them all, because they are conflicting. You, as a compiler designer, have the opportunity to design things so that they work. And you definitely have to be clever if you're looking for language features that Parrot doesn't natively support.
I disagree. As Dan once said, "as long as we have a proper protocol that everyone can conform to, we should be OK."
I don't care if Perl, Python, Ruby, TCL, and others each implement different semantics. I do care that we adopt a common protocol.
The current set of VTABLE entries is a excellent first order approximation for the common protocol.
In case that isn't perfectly clear, let me illustrate this with actual source code:
inline op getattribute(out PMC, in PMC, in STR) :object_classes {
$1 = VTABLE_get_attr_str(interpreter, $2, $3);
goto NEXT();
}Note that the opcode doesn't actually implement any semantics. It merely delegates the request to the $2 PMC.
Languages which share semantics for this operation can chose to inherit a common implementation. Those with unique semantics can override this (or can find other languages with similar requirements and pool their implementation).
It seems rather likely to me that this was the original intent to providing a VTABLE_get_attr_str VTABLE entry in the first place.
This seems to me to be a rather good design pattern.
- Sam Ruby
