World: r3wp

It's not a noop, it's a composite operation. If the *block* was really 
bound to the context, rather than its contents (as applicable), then 
it would be a simple operation.

On the other hand, it is meaningful to say that the block has bindings 
to the context, or not.

if `bind block context` has no observable effect due to no single 
binding being changed, one can certainly consider that a noop

Yes, Andreas, thanks for the explanation, that is what I meant

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

sorry, this notebook is never doing what I think it is

(a small "mistouch" and it detects it as multiple clicks)

Ladislav is spamming us with REBOL bindology examples :)

Something about MOLD:

>> length? mold "^""
== 3
>> length? mold "^/"
== 4


Many other 'escaped' characters become 2 characters, when using MOLD. 
Is there a good reason for this?

I do not understand, which one looks strange to you: is it the representation 
of mold "^""?

geomol, it probably is because the double-quote does not need to 
be escaped internally.

>> length? probe mold "^""
{{"}}
== 3

>> length? probe mold "^/"
{"^^/"}
== 4

Different reason, I guess

when writing it as: {"} you may immediately see, it is just three 
chars, while "^/" is four characters

The 4 chars are the strange ones to me. I think, these two should 
be the same:

>> s: {"^/"}
>> t: mold "^/"

I would expect both to hold 3 chars. But they're different:

>> s
== {"
}
>> t
== {
^^/"}

no the first is a string with a new line the second is an "escaped" 
newline

which is why printing it doesn't cause a new line on the console.

remember that molding a string actually escapes special chars, so 
you can 'LOAD it back intact.

REBOL can LOAD a script from file, which holds real newlines, not 
escaped ones. So it's not possible to produce a string including 
newlines, when using MOLD?

>> as-binary s
== #{220A22}
>> as-binary t
== #{225E2F22}

Maybe what you want is:
>> form s
== {"
}
>> length? form s
== 3

Geomol, no, REBOL cannot load your S string...

>> s: {"^/"}
== {"
}
>> load s
** Syntax Error: Invalid string -- 
** Near: (line 1) "

I'm not sure why you'd want MOLD to produce something that cannot 
be LOADed...

FORM - Converts a value to a string.
MOLD - Converts a value to a REBOL-readable string.

Gabriele, interesting. My understanding of LOAD changed a bit. Loading 
a script... hm

>> s: {^{1
{        2^}}
== "{1^/2}"
>> t: mold {1
{    2}
== {"1^^/2"}
>> length? s
== 5
>> length? t
== 6
>> length? load s
== 3
>> length? load t
== 3

I'm confused! :-)

Well, doing other work at the same time could be the problem. I have 
to think about it later.

Nah, my understanding of load didn't change. I can't have a string 
with double quotes across lines. But I still can't see, why my t 
get the extra hat (^).

that's too easy, Geomol. You have to find out, why 
    length? "^^" ; == 1
, as well as how the look of
    mold "^/"
is related to the look of
    "^/"

, i.e. how would you write a string containing exactly the characters 
listed on the line below

    "^/"

(four characters)

Well, as I understand MOLD, it will create a string, we can LOAD 
in again. If the original holds a newline outside any string, it 
should just be kept as a newline, shouldn't it? REBOL can LOAD newlines, 
which are seen as white space (like the space character). Maybe tab 
is better to illustrate, what I mean:

>> mold {^-}
== {"^^-"}


I get a result string holding 4 characters, while 3 is good enough. 
When I LOAD this result, the two characters #"^^" and #"-" get changed 
into one tab. Why? And why does MOLD produce 4 characters in the 
first place?

when debugging these things you should always use probe... its more 
consistent, since it always shows the "escaped" value of a string!

(just something I've come to do through the years.. never rely on 
print)

MOLD simply escapes everything so you will not end up with string 
like {^} which is not REBOL-readable.

 If the original holds a newline outside any string, it should just 
 be kept as a newline, shouldn't it? 
 - no!

ok :)

Should LOADing a string be the same, as if I entered the content 
of the string at the prompt? I would expect that. If I write:

>> "^^-"

I entered a string consisting of 2 chars. So loding this:

>> load {"^^-"}

should be the same, 2 characters, but it isn't.

As said, if the original contains a newline, then it can be written 
as

    original: "^/"


, and the MOLD ORIGINAL expression should just yield a string containing 
the above four characters following the space after the colon

, i.e. two "doublequote"s, one "hat", and one "slash"

Maybe the problem lies in the fact, that we can create strings in 
two ways, using " and {}.

(no newline char, you see?)

Or maybe there isn't a problem, and it's just me. :)

I would expect molding "^/" would produce: {^{^/^}}, 3 characters, 
not 4.