On 10/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:
>
> Klaas-Jan Stol (via RT) wrote:
> >
> > Hi,
> >
> > This proposal is about resolving method names: bare words or quoted
> >
> > it might be that i'm not well informed on this issue, so please correct
> me
> > where I go wrong.
> >
> >
> > IMCC currently allows for method call syntax like this:
> >
> > foo.bar()
> > foo."bar"()
> >
> > Both invoke the method named "bar" on the object "foo", UNLESS there is
> a
> > local variable named "bar", in which case the first statement will
> invoke
> > the method whose name is stored in that local variable.
> >
> > This is confusing, and makes reading code not easy (imagine having a
> > subroutine of 50+ instructions, and debugging it)
>
> Agreed on the problem. I've raised it myself several times over the
> years, especially right after nasty debugging sessions where I was
> caught by it.
>
> > PCCMETHODs (a method on a pmc written in C) is, IIRC, invoked using a
> bare
> > word methodname like so:
> >
> > foo.bar()
> >
> > So, what is called here? Is bar a method, a PCCMETHOD (but I guess that
> does
> > not matter), or a local variable containing the name of a method?
>
> For methods, both foo.bar() and foo."bar" translate to:
>
> callmethodcc P1, "bar"
>
> For subs, both bar() and "bar"() translate to:
>
> set_p_pc P0, bar
> ...
> invokecc P0
>
> For methods, a call to foo.methname(), where methname is a .local
> string, translates to:
>
> callmethodcc P1, S0
>
> and calls the method just fine. While a call to subname(), where subname
> is a .local string, won't even output PASM code, and gives an error:
>
> error:imcc:Sub isn't a PMC
>
> For both sub and method calls, if bar is a .local PMC String, you get
> the error:
>
> invoke() not implemented in class 'String'
>
> Which is not useful behavior at all.
Thanks for the analysis! Very clear.
> In order to prevent confusing, I propose that methodnames are always
> written
> > between quotes. This should also be true for PCCMETHODs.
> > Only then is it always clear when calling a method whose name is stored
> in a
> > local variable, or if it's actually the name of the method that was
> written.
>
> I've always been annoyed by the quotes around method calls. Too much
> typing, too distracting when reading/modifying code (making it difficult
> to pick out the real constant strings). It's true that it's just a
> matter of syntactic sugar, but then the only value of the abbreviated
> method call syntax is syntactic sugar to make the programmer's life
> easier. It doesn't help the compiler either way.
>
> > I think the method "new" on a class is a PCCMETHOD, right?
>
> Yes.
>
> > This would mean that you would create a new object instance like so:
> >
> > local pmc b
> > b = Foo.new()
> >
> > Having to write
> >
> > b = Foo.'new'() might seem inconvenient, but I think it's a matter of
> > getting used to, and it is more consistent.
> >
> > Consistency is good.
>
> Agreed that consistency is good. In this case the most important
> consistency is between method and sub calls.
>
> > The assembly language (if you can call PIR that) should not have too
> many
> > rules and exceptions.
>
> I think the most surprising inconsistency is the fact that you can use a
> string literal or string register as a sub/method name, but not a string
> PMC. That's not normal behavior for Parrot. In most places any of the 3
> will do. And, there's not really a good reason for it here, it's just
> literal-minded syntax that expects all PMC arguments to be invokable.
> It's also a need for fast method calls, which makes checking the type of
> the PMC argument undesirable.
Let me check if I get this. It's allowed to use a string literal, string
register, but not a string pmc.
Based on your last sentence ("It's ...undesirable."), I understand that you
don't like the assumption that all PMCs can be invoked, because this needs a
runtime check.
Could you explain what you mean here?
(I'd say that, if a PMC is not invokable, it'll just thrown an exception
(because the method invoke() is not implemented on the pmc).)
Anyway, I agree that writing quotes on method names is annoying; the syntax
should be based on the Huffman principle; what's done most, should be
easiest to write (but I don't write enough PIR to know what's used most).
It's also true that local variables (strings and pmcs) are in fact just
registers, so whatever syntax is used for registers, it should also be
applied to local variables. For instance (and this is not a proposal, at
least at this point), if you'd need to indicate that you're using a
register, like so:
.local pmc obj, meth
obj = new 'Foo'
obj.[$P0] ( ) # don't worry, just an example!
then this should also be the case for local variables:
obj.[meth] ( ) # indicates the method whose name is stored in local var.
meth, should be invoked.
while doing:
obj.$P0 ( )
would in that case be not allowed, and
obj.meth ( )
would just invoke "meth".
What's crossing my mind is the "->" syntax, which was just removed a week
ago or so (but which had the same meaning as a '.'), although I don't really
like that.
The point I'd like to make is, that local vars and registers are in fact the
same (except you declare the former) and should be treated as such, IMHO.
just some thoughts.
We haven't yet come up with an alternative that's clearly better than
> what we have now. Add a note on this proposal to the PIR PDD and I'll
> review it and any other proposals on the problem all at once.
done.
kjs
