Differences Between ^x: and [^x]:

[bradrn]

@bradrn

It still doesn’t explain why you can’t add sigils to things like THE-WORD!, though. I still maintain that that capability would be useful to have, considering that the various sigils have more or less orthogonal semantics. It also doesn’t address my second bullet point (that Ren-C has this elaborate structure but doesn’t seem to get much use out of it).

If anything, I’m now leaning even more in the direction that combining sigils should be possible, because I can see obvious interpretations of those combinations. For instance, ^x: could assign the meta of the following value to x. Or @:x could get the value of :x, then apply @ to it. (Note that these should probably be unordered, as I mentioned earlier.) Of course, they’re useful in dialects too.

[hostilefork]

@bradrn

For instance, ^x: could assign the meta of the following value to x.

Note that this is what [^x]: does, and I'm not particularly bothered by needing a block for the few times it comes up (if anything, it improves visibility).

Using blocks and groups as structuring parts helps you distinguish between e.g. that and ^[x:]. So to me, they are the mechanism for accomplishing composition.

Introducing ANY-FENCE! to bring in another array type will give another tool for structuring. And as I mentioned, it will be a good composable choice for picking the main return result out of a multi-return.

[x {y} ^z]: ...

[x y {^z}]: ...

That's something we have a vocabulary and API and mechanism for, and I think the ergonomics in sum surpass what a system based on multi-sigils would be like.

[bradrn]

@hostilefork

Note that this is what [^x]: does, and I'm not particularly bothered by needing a block for the few times it comes up (if anything, it improves visibility).

Oh, this is quite interesting. I never realised this was possible! It does seem fair to say that this improves visibility, which is a nice bonus.

[hostilefork]

@hostilefork

@bradrn

For instance, ^x: could assign the meta of the following value to x.

Note that this is what [^x]: does, and I'm not particularly bothered by needing a block for the few times it comes up (if anything, it improves visibility).

So as things have moved along it's now actually possible to do this (though it's not an example of "multiple sigils"... the colons come from CHAIN!, which is a separate aggregate type now.)

And I've realized that the two are semantically different in the case where you have an unstable antiform on the right hand side.

^x: will store the meta of unstable antiforms

...though the assignment expression passes through the antiform as-is:

>> ^x: pack [10 null 20]
== ~['10 ~null~ '20 ]~  ; antiform (pack)

>> x
== ~['10 ~null~ '20 ]~

It accepts everything on the right-hand side--including ERROR!, GHOST!, VOID.

But in the case of ERROR!, it still passes it through as an unstable antiform as the result of the assignment. So by default you'll still get escalation to a panic if you don't put some kind of TRY or otherwise on the expression (though the assignment will have already been performed by that point.)

[^x]: will unpack a pack, meta'ing the first item

...and ignoring any further ones:

>> [^x]: pack [10 null 20]
== ~['10 ~null~ '20 ]~  ; antiform (pack)

>> x
== '10

It won't accept ERROR! or GHOST! on the right (or VOID...which is just an empty PACK!...if there's more than 0 items in the SET-BLOCK)

If the right hand side is not a pack, then they will be identical.

>> ^x: [a b c]
== [a b c]

>> x
== '[a b c]

>> [^x]: [a b c]
== [a b c]

>> x
== '[a b c]

Should ([...]: ...) require a PACK! on the right?

Allowing non-packs allows you to basically say "decay the right" implicitly...

So [^x]: acts as a shorthand for:

^x: decay (...)

That's a useful thing to have a shorthand for.

I'd have to think of a pretty big bad consequence to disallow it.