in reply to Re: Experimenting with Lvalue Subs
in thread Experimenting with Lvalue Subs
You know, when I first read that section of A6, I thought "that's as ugly as anything I've ever seen... eh, I'm sure it'll get changed". Now, around 3 years later, I re-read it, and I think "that's as ugly as anything I've ever seen -- it's gotta get fixed, or we'll be stuck with it". This doesn't match how I think about lvalue subs. It doesn't match how I think of lvalue subs. I think of lvalue subs as a different calling convention from a normal sub -- a view reinforced by that being the way most languages that have them seem to think of them. The way you're doing it seems to match the way perl5 does it. Lvalue subs aren't much used in perl5, and them being annoying to use is one reason for that.
Why not make $foo->bar('baz')='quux'; with a declared method multimethod bar($this: *@lvalues, @rvales :rvalues); does... well, the obvious: makes $this be $foo, @rvalues be ('bar') and @lvalues be ('quux'). IOW, make the lvalues be a special zone (in A6 terms), with no presigil signifier, but only a long name. (I suppose you haven't yet used > (points to the left) for anything in this context, but it'd be confusing, because it comes up rarely, and could be difficult to find in the docs, whereas "rvalue" is somewhat obvious, or at least easier to look up.)
As is normal for multimethods, that body is only called if the call matches it -- that is, it's done in an lvalue context.
One difficulty is in determining the context of the RHS of the assignment. Normally, the context of an assignment is determined by what is being assigned to. This is one of the major reasons in both p5 and p6, the lvalue is evaluated before the rvalue, which is why the lvalue sub can't tell what rvalue is being assigned. This needs an aditional rule, I think, instead of a workaround that keeps information from the programmer when they want it. If the lvalue sub has only a single scalar paramter in the :rvalues zone, then it's in scalar context. Otherwise, it's in list context. (If there are two multimethods that have equally compatable signatures, and one of them would be list context by this rule, and the other scalar, then warn, and do it in list.)
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: Experimenting with Lvalue Subs
by TimToady (Parson) on Jan 25, 2005 at 02:11 UTC | |
by theorbtwo (Prior) on Jan 25, 2005 at 02:18 UTC | |
by TimToady (Parson) on Jan 25, 2005 at 03:31 UTC | |
by demerphq (Chancellor) on Jan 25, 2005 at 09:19 UTC | |
by dragonchild (Archbishop) on Jan 25, 2005 at 14:32 UTC | |
| |
by BrowserUk (Patriarch) on Jan 25, 2005 at 04:03 UTC | |
by Juerd (Abbot) on Jan 27, 2005 at 22:53 UTC | |
| |
by Aristotle (Chancellor) on Jan 25, 2005 at 03:09 UTC | |
by tye (Sage) on Jan 25, 2005 at 04:24 UTC | |
by fergal (Chaplain) on Jan 25, 2005 at 06:38 UTC | |
| |
by BrowserUk (Patriarch) on Jan 25, 2005 at 02:15 UTC | |
by TimToady (Parson) on Jan 25, 2005 at 03:20 UTC | |
by BrowserUk (Patriarch) on Jan 25, 2005 at 03:58 UTC | |
by Aristotle (Chancellor) on Jan 25, 2005 at 04:10 UTC | |
| |
Re^3: Experimenting with Lvalue Subs
by theorbtwo (Prior) on Jan 25, 2005 at 02:10 UTC |