On Wed, 2008-04-02 at 14:16 -0700, [EMAIL PROTECTED] wrote:
> =head3 Directives used for Parrot calling conventions.
>
> +{{ A bit of a radical idea, but now would be the time to decide on this:
> + Remove the whole "long-style" invocation syntax altogether.
> + Only allow the short version.
> + As PIR is typically being generated, and hopefully by PCT-based
> + compilers, there seems to be no real use for too much syntactic
> + sugar. Just a thought.
> +}}
Not sure I understand this, since it seems self-contradictory. Or maybe
I'm just reading it wrong. To my eyes, you're saying you want to get
rid of the syntax that involves a pile of directives, setting up various
parameters, return slots, etc., and then doing .call, in favor of
keeping <var>._method([args]). But then you go on to say that you don't
want too much syntactic sugar, while the short form is definitely more
highly sugared. I'm confused.
Apart from that confusion, I'd still argue against removing the short
form. One rule of assembly languages is that even if the normal case is
that compilers write the assembly code, there are always times when a
human has to do it by hand (bootstrapping, microoptimization, whatever).
Having to write a fair amount of it myself right now, I'm VERY thankful
for every bit of sugar I can get.
I'd also be against getting rid of the *functionality* present in the
long form, because there are things the short form apparently can't do
yet, such as hoisting repeated return continuation creation out of a
loop. (I haven't had to do that myself yet, but I would expect that an
optimizing compiler would, and a hand-optimizing PIR programmer
definitely would.)
Mind you, there's nothing magical about the *syntax* used for the long
form. If someone has better syntax, or wants to fold the special
features of the long form into adverbial flags on the short form, or
what have you, so much the better.
-'f
