BLOCK! Behavior In DELIMIT (hence SPACED, UNSPACED, PRINT)

Development Semantics
1

Because I've thought of Redbols as targeting being a kind of "user friendly" and intuitive language, I was long bent out of shape about how junky things like PRINT and REJOIN were.

If your "Hello World" level programs are unpredictable nonsense, I don't see how you know where to start. :-/

So an early thing I came up with was the idea to replace REJOIN with something that had some nice learnable invariants...which was called COMBINE. It was harder than I thought.

Among the various philosophies that were tried out, was that blocks would be reduced recursively:

>> var: "World"

old>> print ["Hello" var]
Hello World

>> block: ["Hello" var]

>> print ["((" block "))"]
(( Hello World ))

But I began having second thoughts, because it seemed like reducing blocks inside the print was a bit "dangerous". You were in an evaluative context so if you wanted reduction you could ask for it.

Many ideas were tried over time, such as using BLOCK! as a means of getting "tight spacing" so you could intermix spaced and unspaced portions:

>> print ["Outer" "spaced" ["inner" "not" "spaced"] "was an" "idea"]
Outer spaced innernotspaced was an idea

This seemed to give a best of both worlds scenario. But it wasn't clear whether the blocks should be reduced, or exactly what this "unspaced non-reduced block" operation was.

Today, I Think We Have A Direction and Rationale

I just posted my reasoning for why I think this should be true:

>> print ["abc" [] "def"]
abc def

Rebol2 and Red throw in two spaces and that's no good.

If BLOCK! is going to be an aggregator for material inside of PRINT then the base case needs to basically act as if no material is there. Otherwise it's mostly useless, e.g. it couldn't be used for indentation:

print [collect [repeat indent [keep tab]]], "what if indent is 0?"]

With that laid down I think it's safe to say that we want what's in a BLOCK! to be considered as being pre-reduced. But also, that it be unspaced.

>> word: "part"
== "part"

>> print ["Mixing" ["unspaced" word] "with" "spaced" word]
Mixing unspacedword with spaced part

We have a nice tool now with GET-BLOCK! that will reduce, so you have every tool on hand:

>> print ["Mixing" :["unspaced" word] "with" "spaced" word]
Mixing unspacedpart with spaced part

Invariant For BLOCK! Inside DELIMIT (hence PRINT, etc)

So I came up with a good model for what the BLOCK! inside of the PRINT above will do.

It does the same thing that APPEND of a BLOCK! to a string would do.

>> append copy {} ["unspaced" word]
== "unspacedword"

Whatever that is, that's what happens with blocks in print. So it's not FORM-ing, and no spaces. It's the behavior of raw material being appended blockwise to a string.

This keeps us from having to define a separate new behavior. It doesn't define that behavior, so we're not out of the woods. But as I say, it's a slow process...one step at a time.

2 Likes
2

While we're on the subject, I might ask if we'd expect the following:

>> parse "abcd" ['[a "b" c] "d"]
== "d"

We might look for analogous questions like:

rebol2>> find "abc" [a "b" c]
== "abc"

But in Red and R3-Alpha, that doesn't work:

red>> find "abc" [a "b" c]
== none

r3-alpha>> find "abc" [a "b" c]
== none

I think it's evident that when we talk about the relationship between BLOCK! and TEXT!, the most foundational is to just treat everything as being smooshed together...no spaces.

This makes me lean to wanting to say that TO TEXT! of a BLOCK! would have that behavior...thus leaving other behaviors to the likes of SPACED, FORM, MOLD, etc.

Even so...how many places that accept strings should accept BLOCK!s-of-string-parts? It's interesting that representationally, blocks of string parts have better characteristics for rearrangement and growth...especially if a string is long.

Just more things to think about.

3

So in the isotopic world, I have come to think that you can't do this with plain blocks, but rather with antiform groups... e.g. splices.

Splices push you out of the realm of concrete consideration. You're no longer coming back and saying "yes, I found a BLOCK! at this position". You are saying "I found matches for that sequence of distributed things".

>> find "abc" [a "b" c]
** Error: Cannot find literal ANY-LIST? in strings (did you mean to use SPREAD?)

>> find "abc" spread [a "b" c]
== "abc"

It seems legit to me, and a nice way of avoiding having to produce intermediate strings.

So I think this is a very useful idea.

But I don't think it should work if the block is not literally there, e.g. looked up through word reference:

>> block: ["this" "shouldn't" "work"]

>> print ["Outer" "spaced" block "was an" "idea"]
** Error: Unknown rendering for block in DELIMIT

Narrowing it seems the right tradeoff of utility and safety.

Since it's a feature of DELIMIT (upon which SPACED--which PRINT uses--is built) what it means is "sequence to which not to apply the delimiter".