r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

BrianH
9-Apr-2010
[16252]
On the other hand, it is meaningful to say that the block has bindings 
to the context, or not.
Andreas
9-Apr-2010
[16253]
if `bind block context` has no observable effect due to no single 
binding being changed, one can certainly consider that a noop
Ladislav
10-Apr-2010
[16254x9]
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)
NickA
11-Apr-2010
[16263]
Ladislav is spamming us with REBOL bindology examples :)
Geomol
12-Apr-2010
[16264]
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?
Ladislav
12-Apr-2010
[16265]
I do not understand, which one looks strange to you: is it the representation 
of mold "^""?
Henrik
12-Apr-2010
[16266x3]
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
Ladislav
12-Apr-2010
[16269]
when writing it as: {"} you may immediately see, it is just three 
chars, while "^/" is four characters
Geomol
13-Apr-2010
[16270]
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
== {
^^/"}
Maxim
13-Apr-2010
[16271x3]
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.
Geomol
13-Apr-2010
[16274]
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?
Oldes
13-Apr-2010
[16275x2]
>> as-binary s
== #{220A22}
>> as-binary t
== #{225E2F22}
Maybe what you want is:
>> form s
== {"
}
>> length? form s
== 3
Gabriele
13-Apr-2010
[16277x3]
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...
Oldes
13-Apr-2010
[16280]
FORM - Converts a value to a string.
MOLD - Converts a value to a REBOL-readable string.
Geomol
13-Apr-2010
[16281x4]
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 (^).
Ladislav
13-Apr-2010
[16285x3]
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)
Geomol
13-Apr-2010
[16288]
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?
Maxim
13-Apr-2010
[16289x2]
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)
Oldes
13-Apr-2010
[16291]
MOLD simply escapes everything so you will not end up with string 
like {^} which is not REBOL-readable.
Ladislav
13-Apr-2010
[16292]
 If the original holds a newline outside any string, it should just 
 be kept as a newline, shouldn't it? 
 - no!
Geomol
13-Apr-2010
[16293x2]
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.
Ladislav
13-Apr-2010
[16295x2]
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"
Geomol
13-Apr-2010
[16297]
Maybe the problem lies in the fact, that we can create strings in 
two ways, using " and {}.
Ladislav
13-Apr-2010
[16298]
(no newline char, you see?)
Geomol
13-Apr-2010
[16299x3]
Or maybe there isn't a problem, and it's just me. :)
I would expect molding "^/" would produce: {^{^/^}}, 3 characters, 
not 4.
And I see no problem with my way:

>> length? {^{^/^}}
== 3
>> load {^{^/^}}
== "^/"