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
|
