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