Rethinking the Console Prompt: >> to ? or .\

Rebol has historically used >> for the console prompt. It also inside the language uses << and >> for bit shift operators. Red continues this, and it looks a little weird, e.g.

>> 2 >> 1
== 1

The use of some form of > is fairly common as prompts, going back to C:\> and before. It's rather common to just find the single character > used. Yet even in those languages, they use > to mean "greater than". So the idea of prompts themselves pursuing an out-of-band nature is apparently kind of a big thought.

@BrianOtto asked about what I thought of using << and >> for comments, and I wanted to mention that I think they are "high value" asymmetric symbol patterns. There's a relatively scarce space of things that can act as short, clean-looking, asymmetric delimiters.

So I think they're wasted as bit shift operators, when more suboptimal choices are being made. e.g. Red has chosen #() to express literal MAP!s, a parallel to JSON's associative arrays.

>> x: #(a: 10 b: 20)
== #(
    a: 10
    b: 20
)

>> x/b
== 20

(On a related note, @rgchris and I believe that if anything, construction syntax should have been the one to take #() instead of #[], in the sense that it's not creating a BLOCK! of anything...rather it's splicing (kind of like evaluating) an element inline.)

But what if we tried to make the prompt something that didn't have meaning in the language? Let's imagine for a moment that we take that pesky lone ? I've been looking for a "higher" purpose for (after all, h is a fine console shortcut for help, if one is really too lazy to type help). And then the complementary !. Let's imagine their higher purpose is no purpose in the language by default, and use them for console prompts...then take << and >> for MAP! literals:

? x: <<a: 10 b: 20>>
! <<
    a: 10
    b: 20
>>

? x/b
! 20

Contrast with Red's scheme: when you think about looking at a long list of keys and values...and you get to the end and see just a ), you have to scan up to know if you're looking at a GROUP! or not. But here you'd be better off. I think there's a lot more need for something like this than bit shifting.

? is just an idea. Because I'd been looking for a good purpose for ? and !. I kind of thought it might be fun if they were postfix, so it could be like asking a question of something...but that never came off very well. I thought it might be okay for ? foo being shorthand of set? 'foo but while it saves some typing it makes the code look unnatural...and that's not what Rebol is about.

(Same arguments about why we've scrapped the definition !: :not... it's ugly to say ! condition when you could say not condition, and there's no reason to support it.)

So with lone ? and ! being enigmatic, thin and unpopular... the idea of not giving them any default meaning has some amount of appeal...and then they'd be something you could visually filter out. But on that note, regarding recent discussions of backslash of it not being used at all...what if that property were exploited for fun and profit?

Welcome to Rebol.  For more information please type in the commands below:

  HELP    - For starting information
  ABOUT   - Information about your Rebol
  CHANGES - What's different about this version

.\

.\ comment "I actually like dot backslash as the prompt"

>\ comment "other symbols combine noisily, lone backslash too minimal"

breakpoint(3) .\ repeat x 2 [print [x "stuff to the left"]]
1 stuff to the left
2 stuff to the left

.\ <<a: "doesn't" b: "clash" c: "with chevrons!">> 

.\ 1 + 2
=\ 3

.\ all [
[\  1 < 2 (
(\  3)
[\  ]
=\ 3

.\ quote ==
=\ ==

.\ quote >>
=\ >>

(Colorization would of course help somewhat.)

The interesting thing about what I've done above--including a little cleverness with the multiline--is that you wind up with a transcript that can be pasted into a console session and filtered to run the commands again. Using some of the same rationale as when discussing the backslash being filtered by a "dumb" parser, it doesn't take a lot of intelligence for the console to figure out what your commands were distinct from the output.

Then again, the convention could say that if it sees a backslash it ignores up to one character on the right of it, possibly a space...which might be more conventional-seeming.

breakpoint(3) \> repeat x 2 [print [x "stuff to the left"]]
1 stuff to the left
2 stuff to the left

\. <<a: "doesn't" b: "clash" c: "with chevrons!">> 

\. 1 + 2
\= 3

\. all [
\[  1 < 2 (
\(  3)
\[  ]
\= 3

Maybe even some kind of hybrid? :-/

.\ 1 + 2
\= 3

Anyway I'm not going to say MAP! literals are the final ante on what might be done with the very valuable << and >>, but it's more in league with the level I think it should be at. And if it's that prominent (or moreso) in the language, then being able to avoid its use in the console prompts has an advantage...so I think these contemplations are worthwhile.

Can this be easily configurable?

Sounds like it should be a user config setting. Aesthetics differ between people and I'm not seeing a compelling issue to change the default prompt ( which might mean changing all rebol documentation worldwide ! ).

It is already configurable. You can override just the prompt itself:

system/console/prompt: ".\ "

Or if you want you can override the code that uses that prompt text currently:

system/console/print-prompt: does [
    loop 3 [write-stdout ">"]
]

(Long term you probably will want to think twice about overriding more than just the prompt symbol, because the prompt function will do more than just print it...it will gather information about the debug state/etc. and combine that in. You probably would rather ADAPT the existing prompt function if there's just some code you want to run each time a prompt shows up.)

And I'm rather proud of the error tolerance, which is done via some amount of cleverness in how the C code interacts with the usermode console code via its protocol:

>> system/console/print-prompt: does [fail "check this out"]

** Error: check this out
** Where: fail print-prompt _
** Near: [fail "check this out" ~~]

** UNSAFE ERROR ENCOUNTERED IN CONSOLE SKIN
** REVERTING TO DEFAULT SKIN

>>

For more on console skinning, see: @draegtun's writeup

So people using old tutorials could not only put the system into Rebol2/Red mode, it could also change the prompt. I'm not worried about that.

But here in the Deep-Thoughts-R-Us department, my point was just that as we rethink what << and >> might mean, there could be a better default choice, taking advantage of out-of-band signaling.

I agree with Graham on this. Since it's configurable, leave it as is and allow the user to change/configure in their settings.

A post was split to a new topic: Console Transcript Replay: I Want It

It's a powerful point that << and >> are asymmetric symbol patterns that when paired can deliver high value to syntax.

I'm not enamoured with .\ as a console prompt.

Apart from the variadic appearance "do " might be an interesting console prompt.

The transcript idea is very interesting. But first, is there another way to achieve a similar result? E.g. if the console or api can recognise a transcript due to the speed of delivery and the use of "^/do " then can it not pre-process it into code? May be it could even mark up the embedded results so that they can be automatically compared with the current session. Just wondering.

I started out by suggesting the lone question mark and exclamation point, and if you consider it being called out with color then that could make it stand out more. If the question mark was stepped in by one space, it could provide room for the concept I give above of leaving room for markup, and be intermixed with backslash:

  ? all [
 [\     1 < 2 {
 {\     hello} (
 (\     3) 
 ]\ ]
  ! 3

Given that single : is not legal as a WORD!, I don't know how bad it would be if single ? and single ! were also removed from the pool for the sake of giving this more rigor. It would never be perfect as you could always have PRINT statements that chose to output the line patterns to fool you, though. But the point here is about how == won't mean equality and >> may have a significant and common meaning, calling their roles into question.

Anyway, as I said in the beginning a colorful or bold ? seems like a noble application of the ? I was thinking of.

But first, is there another way to achieve a similar result? E.g. if the console or api can recognise a transcript due to the speed of delivery and the use of "^/do " then can it not pre-process it into code?

Some version of it could be done.

The console would have to be more stylized than it is now, at minimum like the backslashes above. If you just have something like how line continuations are today, it would be hard to tell if a bracket starting a line is the result of some mold of a block from code executing or a line continuation, too many heuristics would be needed.

Not sure that's a good enough trade and why there has to be a trade. I want as many tokens/symbols available as possible - even if they have no useful meaning in DO they may be highly useful for other dialects that may need specialised notations. If a dialect wants to use a single : may be it should be able to even if DO wants to reject it.

Ah yes. Ok.

Then I'd wonder whether the sender prepare the transcript in a reasonable format since it may (probably not now) may have more information.