Luke Palmer wrote:
Sam Ruby writes:
Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like:
$P0 = find_method Parrot_string, "find" # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) $P1("r")
This will be a recurring theme in my replies. Any thing which presumes a bit of knowledge "at compile time" will ultimately not work.
Consider the following:
class c: find = 7
def f(x): return x.find
print f(c()) print f("Parrot")("r")
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.
My first tendency here is to echo all attributes as methods (like Perl 6 does), and then always call the method when you see a dot. ParrotString has a find method, and it knows how to curry itself. Instances of c also have a "find" method, and that method always returns 7.
The distinction between attributes and methods is a bit subtle. Any object may implement the VTABLE_invoke method (or in Python terms, a __call__ method), so all attributes may already *BE* a method.
But largely, I could change the current implementation of Python on Parrot to follow such a protocol in a matter of minutes.
But my original comment (Any approach 'which presumes a bit of knowledge "at compile time" will ultimately not work.') still stands.
Although I agree that we should come up with a general, bare-bones object model that allows all of our current target languages to operate smoothly. Parrot's current model makes far too many assumptions. But that doesn't mean that anything you're trying to do is impossible; it just means it's harder.
I don't believe that Parrot should impose an object model. I return to Dan's "as long as we have a proper protocol that everyone can conform to, we should be OK."
- Sam Ruby
