Removing ISSUE! from the ANY-WORD! category


#1

A controversial move in R3-Alpha was changing ISSUE! from being a versatile string type to a more strict WORD!.

http://www.rebol.net/r3blogs/0108.html

Not everyone was a fan. And it created several porting hassles, plus raised questions about if #123 was a legal ISSUE!, why wouldn't you be able to convert it to a WORD!?

http://www.rebol.net/cgi-bin/r3blog.r?view=0108#comments

One argument for it came from efficiency--that preprocessor references would commonly use the same text over and over, and that WORD!s were stored more efficiently as symbols. As with the use of tags like <opt> in function specs, we want to be able to do this efficiently for ANY-STRING!. Ren-C has gotten more efficient on this front by being able to store short string series in the series node...and with UTF-8 everywhere that means even longer strings can be stored in the node.

But another argument was the desire to have access to another "bindable" type.

Getting bindings by putting WORD! in PATH!/TUPLE!

One thing about getting rid of the REFINEMENT! data type is that what's going on is you really just have a PATH! with a blank at the head. This provides cool options we did not have before:

'/one
'/one/two
'''/one
/one:
/one/two:
:/one
:/one/two
''':/one/two   ; etc. etc.

And words in those paths get bindings, which can be used or not used as you wish.

Generalized-TUPLE! is on the horizon, and that would give another option:

.one
.one.two

There's no technical reason not to allow SET-TUPLE! and GET-TUPLE!. One thought I had for what it might do--which would make sense in light of the predicate usage--would be a way of doing a CHAIN or specialization of some kind:

odd?: get .not.even?
odd?: :.not.even?

So with PATH! and TUPLE!, we now have two inert bindable types that look kind of like WORD! and would have the same efficiency profile, .foo and /foo. But then, we could perhaps get more with #.foo and #/foo. And depending on how we think of FILE! (still debated) maybe %.foo and %/foo could have bindings too.

In any case, it just feels too me like there's something unnatural about the ISSUE!-as-WORD!-choice. And now that REFINEMENT! has been taken away, there's a pretty clear meaning of ANY-WORD! as being WORD!, SET-WORD!, and GET-WORD!...which makes the category name actually make sense.

Does anyone want to speak in favor of ISSUE! being an ANY-WORD!?

From what I understood, most everyone hated it. If it goes back to being an ANY-STRING!, does anyone see a problem?

I can't think of any existing usages that would break (in a meaningful way, e.g. nothing uses the binding).


#2

Because binding is involved in this...I'll point out this thread, where the question of relationship between strings and binding is raised:

If you're writing a preprocessor system you might argue that you'd want some context information along with #foo. But off the top of my head, there are more pressing examples where templatize {some $(foo) and $(bar)} would like to be able to know what foo and bar you mean, without having to pass those in explicitly as templatize/with {some $(foo) and $(bar)} [foo bar].

Just doesn't seem to make sense that ISSUE! should be an ANY-WORD!, when precedent clearly favors #123 being an ISSUE!, and it having string-like properties. If new ideas come along that make it easier to associate bindings with strings, that would be a good development. And we should be open to how such tricks could be done. But if those ideas don't come, I don't see what makes ISSUE! picked as a word type to be the exception to the rule.