Should sequences permit non-head SIGILs?

Development Lexer
4

As things have gestated, I started wondering about the value of $x: being a modality of assignment:

x: 10
y: 20
if 1 = 1 {  ; wrapped branch
    $x: 30  ; $ subverts wrapping of this word
    y: 40
    print ["inner" x y]  ; 30 40
}
print ["outer" x y]  ; 30 20

Compare that with "$CHAIN! just binds the chain in the current context"

>> $x:
== x:  ; bound

You can say that other ways, maybe even using the English word BIND

>> $ 'x:
== x:  ; bound

>> bind 'x:  ; proposed
== x:  ; bound

I delved into the alternate interpretation. But the problem is that if you sacrifice $ for binding CHAIN! in order to get this other purpose, you (probably?) sacrifice it for TUPLE! too.

get $obj.field  ; this would stop working how you expect

The generality of being able to say "all bindable types have $ forms" goes away. You no longer have the reliability of being able to TIE any bindable type.

Iterators Bring Yet Another Argument In

Provoked by Chris's Iterators, I came to realize there was a missing "dereference" operator.

I also realized the inert forms of @xxx hadn't been pulling their weight (besides @[block!])

This made the interpretation of @iter.field dereferencing the iterator and picking a field out of the dereferenced thing was like having an analogue to C++'s -> operator.

That more-or-less requires @iter to be inside the TUPLE!.

I've discussed the question of if there could be an asymmetry here. It seems like there could be, but having the rules be "muddy" is unpleasant.

The asymmetry appears to be unpleasant enough that (@iter).field is the price of admission. You'd also need to do that if you wanted an anchor to add a request for that to be a ^META access.

(For the moment, we'd assume that @iter itself has no meta-controllability... so it's more like a function call).

Does ^META-Assignment Belong Under CHAIN! ?

There's a kind of annoying aspect here:

 x: expr  =>  set x expr
^x: expr  =>  set the ^x expr

These relationships become structurally inconsistent if the ^x tries to live outside the chain.

Probably Settles That Sigils Live Outside Sequences

I was hoping for @iter.field to "just work". But on the plus side, when the Sigil lives on the sequence, that means @obj.iter can work. e.g. you can derefrence an iterator that lives in an object. (The common case is probably just @iter (give me the current item) anyway.)

I was also hoping for $x: thing to work as an assignment. But it's too broken to lose $obj.field, and to a lesser (but still large extent) CHAIN! and PATH!.

But [$x]: thing is still an option.

Displaying Prime Factors