The object sigil
Luke Palmer
delegation at the language level for calling methods on iterators (the
kind used by C<for>), junctions, etc. This is basically because it's
both unclear to the program and the reader which object is the
invocant, the container or the containee.
If we're doing this, why not be consistent and use it for sub objects,
too? So, instead of:
my &code = &foo.assuming(y => 2);
We'd just have:
my &code = foo.assuming(y => 2);
Well, obviously this idea is preposterous. But it sparked another
idea that I hope people won't find so preposterous: use a sigil to
refer to the container itself rather than the value contained (This
only refers to iterators and junctions and the like, not like Scalar
containers, etc.).
The unfortunate thing is that we have to get another piece of keyboard
for this sigil. It may be possible to generalize & from the sub sigil
to the object sigil, so I'll use it in my examples. So, for instance:
class Barzy {
method states() { ... }
}
my $j = any(Barzy->new xx 4);
print $j.states; # Prints junction of return values from Barzy::states
print &$j.states; # Prints 4 Barzies
Or,
for @array -> $iter {
print $iter; # Prints an element of @array
if some_condition() {
&$iter.next; # Advances the iterator
}
}
The parallel with sub calls is rather obvious, as well.
As far as actually using & for this purpose, the only problem I see is
with declarations:
my &local_sub := &global_sub;
How is it clear that that's a sub, and not some other kind of
thing...? It's clear in that there's no other primary sigil after &,
but other than that it could be misleading. I don't know, somehow the
parallels make up for it, though.
There are surprisingly few other free characters that would result in
an unambiguous interpretation in this context, namely: "|", and "^" [1],
neither of which, IMO, are acceptable sigils.
But the idea's good, no?
Luke
[1] But let's not forget ";", ",", "]", ")", and "}". >:-)
Dave Whipp
> As some of you may have noticed, I'm disconcerted by the use of
> delegation at the language level for calling methods on iterators (the
> kind used by C<for>), junctions, etc. This is basically because it's
> both unclear to the program and the reader which object is the
> invocant, the container or the containee.
> The unfortunate thing is that we have to get another piece of keyboard
> for this sigil. It may be possible to generalize & from the sub sigil
> to the object sigil, so I'll use it in my examples. So, for instance:
>
> for @array -> $iter {
> print $iter; # Prints an element of @array
> if some_condition() {
> &$iter.next; # Advances the iterator
> }
> }
> There are surprisingly few other free characters that would result in
> an unambiguous interpretation in this context, namely: "|", and "^" [1],
> neither of which, IMO, are acceptable sigils.
I was thinking along similar lines a few weeks ago. But I didn't post
because I realised (or thought I did) that what I was wanting was
nothing more than a standard reference. I.e. your example would be:
for @array -> $iter {
print $iter; # Prints an element of @array
if some_condition() {
\$iter.next; # Advances the iterator
}
}
Dave.
Luke Palmer
Yep, I realized that too. But then I proved myself wrong since the
precedence of the \ operator is looser than that of the . operator,
with good reason. So, \$iter.next would mean:
\ do { $iter.next }
Which has its own, useful meaning.
Luke
Dave Whipp
>> \$iter.next; # Advances the iterator
> Yep, I realized that too. But then I proved myself wrong since the
> precedence of the \ operator is looser than that of the . operator,
> with good reason. So, \$iter.next would mean:
>
> \ do { $iter.next }
>
> Which has its own, useful meaning.
So you decided that & would make a good high-precedence referencing
operator. I guess it can be argued that that's what its doing in its sub
context, so I think you're right: it seems to be a good generalization.
Dave.
Luke Palmer
Well, no. I've decided that & would make a good object sigil. What I
just realized after sending that last message is that even:
\$iter
Has another meaning. Get the current element that $iter points to and
take a reference to it. If that doesn't work, how is the effect
achieved?
I'm wondering how one would call .next on the pointed-to iterator when
another iterator is pointing to it.
&(&$iter.value).next
Or something like that? It's good from Huffman's perspective, but,
how can I put this... eeeeeewwwwww. It beats the old delegation
method though, because It's Actually Possible To Do It.
Luke
Simon Cozens
> Well, obviously this idea is preposterous. But it sparked another
> idea that I hope people won't find so preposterous: use a sigil to
> refer to the container itself rather than the value contained (This
> only refers to iterators and junctions and the like, not like Scalar
> containers, etc.).
Alternatively, why not generalize the "flattening" unary * operator?
> print $j.states; # Prints junction of return values from Barzy::states
> print &$j.states; # Prints 4 Barzies
By association with
@array # The array
*@array # The list of values
We could have
print $j.states # The junction
print *$j.states # The list of states
> for @array -> $iter {
> print $iter; # Prints an element of @array
> if some_condition() {
> &$iter.next; # Advances the iterator
> }
> }
for @array -> *$iter { # A little bit C-like, there
print *$iter; # Prints an element of @array
if some_condition() {
$iter.next; # Advances the iterator
}
}
--
The UNIX system is harder to use than a toaster. -Kaare Christian
Dave Whipp
>>So you decided that & would make a good high-precedence referencing
>>operator. I guess it can be argued that that's what its doing in its sub
>>context, so I think you're right: it seems to be a good generalization.
>
>
> Well, no. I've decided that & would make a good object sigil. What I
> just realized after sending that last message is that even:
I'm not sure that I entriely understand that statement: surely all the
things involved here are/could-be objects: the container, the iterator,
and the containee/iteratee. Perhaps you mean the "variable" sigil.
> \$iter
>
> Has another meaning. Get the current element that $iter points to and
> take a reference to it. If that doesn't work, how is the effect
> achieved?
For your amusement: what to the following do? which are errors?
for 1..Inf -> $x
{
$a := $x;
&$x.next;
print $a;
&$a.next;
print $x;
last;
}
for 1..Inf -> $x, $y
{
print $x,$y;
&$x.next;
print $x,$y;
&$y.next;
print $x,$y;
last;
}
This latter example makes me wonder if were're missing something wrt
exposing the underlying iterator. Of course, this doesn't change the
need for a way to refer to a variable vs its value: there are many
context (As you showed in your initial post) where the distinction is
needed.
Dave.
Dulcimer
> > print $iter; # Prints an element of @array
> > if some_condition() {
> > \$iter.next; # Advances the iterator
> > }
> > }
>
> Yep, I realized that too. But then I proved myself wrong since the
> precedence of the \ operator is looser than that of the . operator,
> with good reason. So, \$iter.next would mean:
>
> \ do { $iter.next }
>
> Which has its own, useful meaning.
You should still be able to say
(\$iter).next;
right? Kinda ugly, though....
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Piers Cawley
>> Luke Palmer replied:
>>
>> >> \$iter.next; # Advances the iterator
>>
>> > Yep, I realized that too. But then I proved myself wrong since the
>> > precedence of the \ operator is looser than that of the . operator,
>> > with good reason. So, \$iter.next would mean:
>> >
>> > \ do { $iter.next }
>> >
>> > Which has its own, useful meaning.
>>
>> So you decided that & would make a good high-precedence referencing
>> operator. I guess it can be argued that that's what its doing in its sub
>> context, so I think you're right: it seems to be a good generalization.
>
> Well, no. I've decided that & would make a good object sigil. What I
> just realized after sending that last message is that even:
>
> \$iter
>
> Has another meaning. Get the current element that $iter points to and
> take a reference to it. If that doesn't work, how is the effect
> achieved?
\(\$iter).value
Not pretty, but not exactly common either.
--
Piers