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

World: r3wp

[Core] Discuss core issues

Ashley
5-Apr-2010
[16241]
Typo in the code above:

	target: change -> change
Ladislav
7-Apr-2010
[16242]
A new idea for the Bindology article enhancement: for a given BLOCK 
and CONTEXT find out, whether the block is in the given context or 
not. Do you think, that such a function might be interesting?
Gregg
7-Apr-2010
[16243]
Absolutely.
Ladislav
7-Apr-2010
[16244]
:-)
BrianH
9-Apr-2010
[16245]
Blocks aren't bound to anything; their contents are. You could check 
whether the block contains any words bound to a context though.
Steeve
9-Apr-2010
[16246]
words only
BrianH
9-Apr-2010
[16247]
I'm sure that's what he meant.
Ladislav
9-Apr-2010
[16248x3]
The idea was a bit different: there is theĻ
bind block context
operation, and it is meaningful to say, that "the block is bound 
to the context", if this operation is actually a no-op
BrianH
9-Apr-2010
[16251x2]
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.
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)