Should We Repurpose ^ To What @ Is Now Doing?

I've been looking at the lay of the land and it is becoming extremely temping to do away with /ONLY entirely.

The main complaint I have is simply the somewhat unappealing heft of the @ operator.

>> append [a b c] @[d e f]
== [a b c [d e f]]

>> item: first ['d]

>> append [a b c] item  ; quoted will lose a quote level
== [a b c d]

>> append [a b c] @item  ; adds extra quote level to be dropped
== [a b c 'd]

>> append [a b c] @ first ['d]
== [a b c 'd]

Mechanically it's fantastic. Aesthetically it's a bit grating...and @rgchris has had his eye on @ for other purposes.

There aren't a ton of options on the old ASCII character set. But... wouldn't caret seem a bit more subtle and suited to this?

>> append [a b c] ^[d e f]
== [a b c [d e f]]

>> item: first ['d]

>> append [a b c] item  ; quoted will lose a quote level
== [a b c d]

>> append [a b c] ^item  ; adds extra quote level to be dropped
== [a b c 'd]

>> append [a b c] ^ first ['d]
== [a b c 'd]

It hints a little more visually that it's associated with quoting. Just perhaps a bit more forceful kind of quoting...

>> '[a b c]
== [a b c]

>> ^[a b c]
== '[a b c]

Or maybe it's just that the standalone operator uses ^.

>> append [a b c] @[d e f]
== [a b c [d e f]]

>> append [a b c] ^ first ['d]
== [a b c 'd]

Not sure. Thoughts? I'm feeling kind of pro about moving this feature entirely to ^

This does open the possibility that @-words and types remain and are used for other purposes. Dialecting is made more powerful the more of these you have available. Think for example what UPARSE might do with them if it wasn't matching things literally (?)

The original idea was to make them inert, and involve them in DATATYPE!. Maybe that needs to get put back on the table again.

 >> type of 10
 == @integer

 >> @integer
 == @integer  ; no evaluative behavior

(Other ideas of @['integer] to involve quote levels, @(...) for type constraints, etc.)

1 Like

append [a b c] only[d e f]

:smile: just kidding!

I also like that the symbol is somewhat like a single quote. It's almost like ^ indicates a placeholder for '.

1 Like

It points at the location. "I'm going to put something...right there! (...after evaluating the thing that comes after this point)"

1 Like

Whether you are joking or not, previously the idea of ONLY making a block around the argument was raised:

>> only [d e f]
== [[d e f]]

This would mean that you would get the effect of appending a single item:

>> append [a b c] only [d e f]
== [a b c [d e f]]

It's somewhat incoherent, as well as inefficient (compared to quoting). So under these new rules, QUOTE makes much more sense if you feel you have to call a function:

>> append [a b c] quote [d e f]
== [a b c [d e f]]

Any hesitance to taking QUOTED! types to mean "append value as is" came from the rampant likelihood of losing quotes at random on values. I now think that really, it has reached the point where the types can be restricted for array appending to:

  • BLANK! => no-op
  • BLOCK! (quite possibly ANY-ARRAY!) => splice
  • QUOTED! => unquote the item one level and append as-is

Once restricted, I think people will be in the habit that they will not be appending unqualified variables unless they are sure they are blank, any-array!, or quoted!... because they'll know everything else will be an error.

Since appending NULL is an error in this scheme, I will point out how ^ is not exactly like QUOTE:

>> ^ null
; null

>> quote null
== '

So you'd get a different meaning from append data ^ item and append data quote item. The latter would gloss over potential complaints if item were null. Which may be what you want.

Also, if you use append data ^item you have GET-WORD! semantics for free, so you don't have to say append data quote :item.

I've already mentioned the neat property of being able to put the TRY on the outside of the ^, so you can write append data try ^item, and consciously indicate you're willing to take no-op-on-null behavior.

I know the ^ is a little bit of a "tic" to have to worry about, but /ONLY is to my tastes now a much more confusing and performance-costing tic.

I'm not that troubled about the necessary transformations.

 append data 'word
      => append data [word]  ; best
      => append data quote 'word
      => append data ^ 'word
      => append data ^(just word)

 append data 123
      => append data [123]  ; maybe best
      => append data ^ 123  ; at least competitive for best
      => append data ^(123)
      => append data quote 123

 append/only data :var
      => append data ^var  ; best
      => append data quote :var
      => append data :[var]  ; (I think this will have the right semantics)

Well, it was meant to be a teaser. To tip the way to think about things here.
Some of the time the focus is a lot on short code and using yet another symbol where the language is perhaps better served by use of a small word. It is a bit more work to type but it reads allright and the meaning is more clear that way.
Balance between brevity, syntax and clarity.
Make the language better but not more cryptic.

That can be people's choice I suppose. I've pointed out QUOTE would not be exactly the same.

LIT could be short for LITERALIZE which is what ^ does, and if someone thinks it's better to write that out. I'd been thinking I'd call ^ itself a "LIT!" data type, and instances of it might be named LIT.

ONLY is a possible alias for LITERALIZE. I don't care for it, as I've pretty much always hated ONLY.

There is the possibility of JUST, but I like JUST for what it is doing now.

>> just x
== x

As opposed to if it meant literalize:

>> just null
; null

>> just x
== 'x

>> just [a b c]
== '[a b c]

I'll be using ^, because to me it's very close to the tic for quote, which people become easily familiar with. It's just saying you want the quote added after the evaluation...not before.

1 Like

If it said QUOTE in words you would have a better idea of what is meant than if you have to look up what the symbol ^ is used for before a block!.

That is the trade-of here.

I can imagine that in early tutorials, it might be worth it to write out QUOTE, and then explain the reasons behind the more sophisticated methods.

It's good to have options available, and I think this gives them.

My instinct is that it is worth it to keep people trained on not throwing random values into blocks so that they are surprised the one day that value is an array/quoted/blank. I am bitten by this all the time.

Instead get them to learn from the beginning that when appending items to arrays they either use arrays or quoteds (or blanks to opt out)...and that's it.

I think over the long run it will be better. One key is training people to expect interfaces that can handle multiple things at a time, so they won't be suprised when they go to FIND a BLOCK! in a BLOCK! and it looks for a spliced sequence...they'll know they have to quote the block. This is something that is best reinforced systemically.

2 Likes

There's another important aspect to this "family" of caret-values: which is that if something is an isotope...such as an ~unset~ BAD-WORD! isotope, it becomes a non-isotope BAD-WORD!.

>> asdf
** Script Error: asdf is ~unset~ isotope

>> ^asdf
== ~unset~

There's also the interesting fact that if something vanishes entirely, you get a void isotope:

>> ^(comment "hi")
; ~void~ isotope, which console does not display

This is distinguished from something that actually returned a void isotope, e.g. by evaluating the ~void~ BAD-WORD!, which would have its isotope status removed:

>> ^(~void~)
== ~void~

Which is neat, because it means you can tell the difference between something that actually vanished and something that made an isotope to represent the idea of vanishing. Caret it twice, and see if you end up with a quoted item or not!

>> ^ ^(comment "hi")
== ~void~

>> ^ ^(~void~)
== '~void~

That's very META.

So should these be META-WORD!, META-GROUP!, etc?

The use of the ^ symbol is often associated with "meta" or "escaping" concepts.

Right now the "meta" term is used for a generic info object you can associated with actions or contexts. I guess that could be called something else.

foo -> WORD!
foo: -> SET-WORD!
:foo -> GET-WORD!
^foo -> META-WORD!
@foo -> ???-WORD!

@ is hard, since I've taken @ to mean "literally that", e.g. a synonym for THE.

Otherwise we could go with @ being inert and generally used for datatype purposes, those could be considered TYPE-WORD!, TYPE-PATH!, TYPE-GROUP!, etc. But we wouldn't want @ to be called TYPE!

Similarly DATA-WORD!, DATA-PATH!, etc. decaying down to @ being DATA! is weird.

But ^ being META! seems okay.

2 Likes