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.
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.
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.
Luke
