UPDATE: I've discovered that this isn't really viable. The @ applies to the "whole thing".
This means @a.b is interpreted as @obj.iter (dereference iterator that is a field of an object, which is useful in its own right).
In any case, the rationale that might be given here as to why @[block] is inert is because blocks are inert. So we'd assume @(group) would let you calculate the thing to dereference.
It's likely that @{fence} should evaluate to @[block], wrapped. But I'm not sure. insert your imagination here.
On the plus side, @iter: can still work with the semantics of @(iter): in the same way that ^var: works to "meta" an assignment statement.
>> iter: iterate block: [a b c]
>> @iter
== a
>> iter/next
>> @iter
== b
>> @iter: <a-ha!>
== <a-ha!>
>> block
== [a <a-ha!> c]
So I decided to do a little bit of experimenting to see what would break if @foo was retaken for iterator functionality.
I got the system to boot pretty quickly, so I could inventory what all had to change (or probably should change, even if it doesn't technically have to).
In PARSE I'd been using @var to mean "match literally", and that doesn't have to change... if for some reason you were using an iterator to iterate rules, you could say inline (@rule-gen) ... and if you wanted to literally match something that was in an iterator you could say @(@rule-gen).
This is pretty consistent with dialecting just generally speaking... if your dialect is doing something different with a part in the box than what EVAL does, your dialect should offer some functionality based on GROUP! to shift into eval to get that behavior back if you need it.
A little bit harder to cope with is the loss of the @var in DELIMIT to mean "mold". That's tougher because DELIMIT is actually doing an eval on each step, so you're still in the "eval dialect" as it were. You can't really take away iterators there if that's what it does elsewhere.
Similiarly, print @var was a shortcut for print mold var
One might be able to argue that since DELIMIT can't heed bindings, there's no particularly good reason why $var couldn't mean "variable as-is".
If that were the case, then the same could be true in PARSE:
If we were to say BLOCK!s themselves could be iterated as-is we get something interesting, where @iter acts as a synonym for iter.1 and @iter: as a synonym for iter.1:
>> iter: [a b c]
>> @iter
== a
>> iter/next
== [b c]
>> @iter: <magic>
== <magic>
>> head of iter
== [a <magic> c]
On the surface that looks pretty cool. @iter is notably less expensive than iter.1 (more compact, better locality direct in-Cell). And the theoretical performance and benefit of it is just more favorable.
But there's a devil in the details of how things like iter/next could work. If you were going to update such an iterator, then the iterator update must operate directly on a variable. You can't calculate a BLOCK! used as an iterator, only calculate the name of an iterator variable, because the index portion is an immediate value.
I don't know if this kills the idea, or if "immediate iterators" are something that could be accommodated. Does it imply something architecturally about iterators in general?
When thinking about the BLOCK! possibility of being the iterator, it made me reflect on how it's not a GET/SET of the iterator, it's a GET/SET of the @iterator.
e.g. when you SET a BLOCK!, that's a multi-return unpacking.
>> x: y: ~
>> block: [x y]
>> set block pack [1 2]
== \~['1 '2]~\ ; antiform (pack!)
>> x
== 1
>> y
== 2
This generally points to an idea that @iter: foo doesn't mean set iter foo.
I think it means set the @iter foo.
This goes along with other things I've been saying, but wanted to just kind of point out some more supportive reasoning.
>> iter: [a b c]
>> @iter
== a
>> next $iter ; <-- using the "pass in the variable to update" trick
== [b c]
>> @iter: <magic>
== <magic>
>> head of iter
== [a <magic> c]
I think my biggest objection is that NEXT is a common variable name, and I've been trying to move away from it being in global namespace, preferring NEXT OF. (If you're doing a lot of NEXTs in your code, you could always say next: next-of/)
So with ADVANCE:
advance $iter
advance the iter ; if you don't like the $ sign
advance:2 $iter ; dialected call with how much to advance y
advance:by num $iter ; refinement form (potential "positional" refinement)
It "hides" the mutation (in the sense that there's no SET-WORD). But it would mean that BLOCK! could act as a light iterator, and be compatible with the object-like iterators which implemented ADVANCE as a mutating function.
In deciding whether this should be done or not, I'll point out that we have some nice short words to use here... the repurposing of AT (as PICK of position 1) and I think PUT (as POKE of position 1)
>> iter: [a b c]
>> at iter
== a
>> next $iter
== [b c]
>> put iter <magic>
== <magic>
>> head of iter
== [a <magic> c]
It could be reasonably argued that this looks less noisy and is more in line with Rebol philosophy.
Also, @iter: would never correlate with creating a new variable. The variable already exists. So turning it into a SET-like thing has negative value (at least from the respect of gathering as a variable).
In my view, AT and PUT change the equation significantly here--swinging the balance to where I'm more likely to say we keep @xxx under its current purposes (of evaluating to the bound version of the type, but keeping the decoration).
I'll continue to think about it. It would provide a performance and storage optimization, and it's succinct. And it might be what people would expect it to do given the word "AT".
Things to consider here, but maybe you should have to use RebindableSyntax if you want it to do this.
