World: r3wp
[Core] Discuss core issues
older newer | first last |
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) | |
older newer | first last |