Should `[: . /]` Require Escaping In RUNE! ?

Should it be:

>> second "a.b"
== #.

Or should it be:

>> second "a.b"
== #"."

The ramifications here are that if these delimiters are RUNE! contents without escaping, then you can't put RUNE! inside of [CHAIN! PATH! TUPLE!]

>> type of #a/b
== \~{rune!}~\  ; antiform  (e.g. not a PATH!)

You Can Put the SPACE RUNE! In Sequences Today

I haven't questioned it lately, but the SPACE character (now denoted by an underscore) is what's used to indicate there's nothing in a PATH!/TUPLE!/CHAIN! slot:

>> second first [:a]
== a

>> first first [:a]
== _

That doesn't mean that all RUNE! have to be legal. It could be the only one that is.

Single-Hash Is The Biggest Loss

When I think about how one might use RUNE! in tuples or paths or chains, the patterns I think are most likely to be interesting for dialects would be those that just put hash marks in spots. An example of the kinds of patterns:

a:#:c

#:#:#

#:b:#

If you look at the problem with those glasses, you might question the value of:

>> to text! #:#:#
== ":#:#"

But how you see such things depends on what examples you're comparing it to.

Note that if you just want the characters, [: / .] are WORD!

>> parse "./:" ['. '/ ':]
== :

So you already have a 2-character means of matching them in strings, for that purpose...that looks cleaner than:

>> parse "./:" [#. #/ #:]
== #:

The Legality of SPACE Twists My Arm A Bit

I did say that just because space runes are legal doesn't mean all runes need to be legal. But it does make me more inclined to say they are.

My leaning here is to say you have to escape them. I think the hash character in tuple!/path!/chain! has more potential for enabling novel features than worrying over slightly briefer character notations.

1 Like