Should [TUPLE! PATH! CHAIN!] Casually PRINT or FORM?

Usage Philosophy
1

Rebol has always been a genuinely wacky medium... and it has always been hard to pin down what kinds of semantics best serve the wacky Rebol gods.

For instance: what should happen if you PRINT a SET-WORD?

sw: first [Hello:]

print [sw "World!"]

  1. Is the most important thing about sw that it bears the textual payload "Hello", and the colon decoration is incidental to carrying that payload?

  2. Is the colon part of the visual intent, to where you should definitely see it?

  3. Might trying to use a SET-WORD in this way represent an accident, such that PRINT shouldn't do anything at all?

Let's Ask History...

rebol2>> print [sw "World!"]
Hello World!  ; okay, so option [1]

r3-alpha>> print [sw "World!"]
Hello: World!  ; going with [2]

red>> print [sw "World!"]
Hello World!  ; they do whatever they do, don't expect a rationale

Ren-C Has Conservatively Chosen [3]

It's gotten weirder with time, since "SET-WORD" is actually an instance of a generalized sequence type called CHAIN!, which sounds weird but explains why things like (a): are just as valid as a:... and I think it's pretty well established as a good thing.

But right now, it won't do anything with it... just panic:

>> print [sw "World!"]
** PANIC: Use @var to mold sequences

You could of course... say that you wanted to mold it, and you could have done that in any historical Rebol as well:

>> print [mold sw "World!"]
== "Hello: World!"

But Ren-C offers the notational shortcut that if you say @var you get molding and bypass the error:

>> print [@sw "World!"]
== "Hello: World!"

Which is a little bit of a consolation.

(This same idea is used in PARSE, where it won't blindly assume you knew what you meant if you say some x and X turns out to be a SET-WORD or whatever. If you say some @x that means you mean "literally, what this variable holds"... which works also for BLOCK! so some @block doesn't run it as a rule.)

I Used To Be Even More Conservative: stopped WORD!s too...

I didn't like this at first:

 >> print ['Hello "World!"]
 ** PANIC: ...

It seemed like there was a lot of opportunities for mistake, of having a value that was supposed to encode a variable be treated as plain text.

Eventually I loosened up a bit, and started to think that WORD! is a pretty basic currency and tool. Its lack of decoration makes it occupy a very central lexical position, and it would be a shame to waste it.

Only sequences like TUPLE! and PATH! and CHAIN!, and lists like BLOCK! and GROUP! and FENCE!, were prohibited from casual forming because it's irresponsible to casually do so for things which may have embedded structure.

But What About Things like 1.2.3?

Today you get an error:

>> tuple: 1.2.3

>> print ["My tuple is" tuple]
** PANIC: Use @var to mold sequences

>> print ["My tuple is" @tuple]
My tuple is 1.2.3

By-and-large, I like the generality... and I think the mistakes it catches outweigh the annoyances.

But this case is a little annoying. And I don't know. If you can print ['a] then why not print 'a.b]

Maybe the rule is a little more oddly shaped:

"Don't FORM sequences which have embedded structural elements like BLOCK! or GROUP! or FENCE!, or which have blank slots."

So a:b might be legal, but not a: or :b or [a]:[b]... and this rule would allow 1.2.3 as well.

I Definitely Like the @foo Dialect Point

It works extremely well in PARSE, and I thought that made it a natural fit to carry over to things like printing.

But every time I try to print an all-numeric TUPLE! I think "why are you stopping me"? And what if my tuple had words in it? windows.1.2.3, why should I need an @ for that?

Just food for thought. Whether it loosens or not, I think the "@ means mold anything" will remain.

2 Likes