Hi Geoffrey,
thanks for your reply and your thoughts. Please keep in mind it was
not a proposal to remove this long-invocation syntax, it just came to
mind when I realized that it's not used that much.
On Thu, Apr 3, 2008 at 5:17 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> 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.
Yes, my choice of words was poor there. What I meant was, is it
desirable to have More Than One Way To Do IT? After all, PIR is not
Perl, it's an assembly language (although a bit higher level than your
average ASM), so once there are complete HLLs, the need to write PIR
manually will decrease, and I doubt the need to have such a rich
assembly language.
I can see advantages in both keeping it and removing this sugaring, I
don't really have a personal preference. It's just a thought.
>
> 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 don't argue to remove the short form; I think the short form should
be kept definitely.
>
> 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.)
I can't say anything about this, because I don't really understand this :-)
But if what you say is true, it is a very valid reason to keep all
syntax (or fix the short-version).
>
> 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
Summarizing, I noticed that the long-invocation form is not used that
much; even the PCT generate the short version.
If there's PIR syntax that's never used, it may as well be removed.
Note that I do not propose to do so, I just want to give this a bit of
attention, so it's at least well-considered.
If there's any reason whatsoever to keep the long-invocation syntax
(or any syntax for that matter), then I'm all in favor of keeping it.
kjs
