World: r4wp

Going over some basic evaluation errors, which look like they're 
easier to fix than I thought they'd be. While at it, I've been discovering 
R3 language features that I never knew about before. Going to check 
older versions to see when they were added. Turns out that there's 
a SET optimization that I never knew, but which would really come 
in handy :)

>> a: 1 
== 1 
>> set [:b] [a] 
== [a] 
>> b 
== 1


Setting a get-word in a block to a word sets the get-word to the 
value of the word, not to the word itself. This would eliminate the 
intermediary block in most set word-block reduce value-block expressions, 
making it a better multi-assignment function.

Is there an opposite function to DEHEX in R3?

Setting a get-word in a block to a word sets the get-word to the 
value of the word, not to the word itself.

 - this is rather dangerous if not documented, I do not think it is 
 expectable

Rebolek: to-url

Vincent, unfortunately not:


>> to url! "http://www.domain.com?url='http://nope.it.is/unencoded'"
== http://www.domain.com?url='http://nope.it.is/unencoded'

Anyway, I wrote simple enhex function that does what I need.

Ladislav, document it then. It's too useful to drop. And according 
to the docs you couldn't use get-words in SET block at all, so I 
never wrote code that had them. SET block with anything other than 
word! is rare, at least until R3 added FUNCT, which makes set-words 
very common.

It is a little unfortunate that SET [:word] works like get-word parameters 
used to in R2, but don't anymore. Inconsistent. Still, too useful 
to drop.

Works that way in R2 as well, so if it would have caused a problem, 
it hasn't so far :)

Care with documentation on this one.  Could become a problem if people 
know about it.

Not really. It would only be a problem if people started using this 
and someone wanted to remove the feature.

It hasn't been a problem so far, and there's nothing wrong with the 
code. This code:
    set [:get-word] [word]
is currently equivalent to this code in R2:
    get-word: get 'word

There's a general problem in R3 that SET block acts like SET/any 
block, but I'm going to fix that too.

AFAICT noone has used get-words in a SET block call before, even 
in R2 code.

It would be interesting for this feature to make it into Red as well, 
just to cut down on intermediate block creation. Of course an optimizing 
compiler could get rid of the intermediate block creation too, changing 
SET block into a multi-assignment statement.

s currently equivalent to

 - I think I already wanted to have something like that a couple of 
 times. It probably will be useful, the question being where to put 
 this doc

Do you find the Rebol programming wikibook appropriate?

Sure, why not? I don't really follow it.

We should add tests for this behavior too, just so we can be notified 
if it gets removed.

Was somewhat tongue in cheek comment.  So many things that are really 
powerful that are under-documented.

Agreed, and speaking of which I also noticed RETURN/redo, which even 
has a visible option and I didn't notice it before. It's a general-purpose 
function trampoline, and as hard as I try I haven't run out of new 
ideas for how to use it.

Phenomenal!  :)

The ultimate Mulligan!

I'm having some trouble understanding what's the point of return/redo. 
 isn't it a way to implement pretty nasty side-effects?  

so far I can see quite a few ways to fuck up a program using it, 
but nothing useful that can't be done some other way...


brian, can you give me some good example of what new things it allows?

Knowledge capture here  http://stackoverflow.com/questions/14760916/why-does-return-redo-evaluate-result-functions-in-the-calling-context-but-block

Well, beyond what I wrote on SO, I think it might allow you to implement 
the kinds of functions that needed the [throw] function attribute 
in R2 that we don't have in R3. I haven't worked through the details 
yet though, so don't make any assumptions about that yet.

Basically, it allows you to do exactly what DO function allows, since 
it basically *is* DO function.

And, it does break through the APPLY security trick, which I might 
want to review some code about. I think that needs a ticket.
>> apply does [return/redo :add] [1 1] 1 1
== 2

Sorry, this is a better illustration:
>> apply does [return/redo :add] [] 1 1
== 2


If you were using APPLY to protect your code from get-word hacks, 
you're SOL. There's no point in removing the /redo option because 
the same trick could be done with native functions. We just need 
to fix APPLY so it does its /redo to the arguments it takes.

Warning, check your code, http://issue.cc/r3/1763is coming! Make 
sure that SET block! block! uses SET/any when that is what you mean.

Also SET object! block!, since it has the same bug.

If you have any code that uses SET block! block! or SET object! block!, 
and the values block might possibly have unset values in it, then 
*your code is buggy*. If you want the unset values to be assigned, 
you should be using SET/any. If you want the unset values to trigger 
errors (a fair assumption, since you're using SET instead of SET/any), 
those errors are currently *not* being triggered because of a bug 
in R3. Either way, check your code.

Buggy until this is fixed?

If you're using SET block! block! or SET object! block! in cases 
where you can get unset values and are expecting errors to be triggered, 
then your code is buggy until this is fixed. If you are expecting 
it to *not* trigger errors, then your code will be buggy until you 
change to using SET/any - it's just accidentally working until this 
is fixed, and then will properly not work after it is fixed.

I was always using SET/any in those cases, not knowing about the 
bug. I still use SET/any in those cases, so my code will continue 
to be correct after the bug is fixed.

has much changed wrt bind for Rebol 3? I see, for example that this 
line (under 'Variables') in the Bindology section on rebol.net returns 
true whereas it used to return false with R2. Is that article 

variable? /rebol

Just a bit lower this:

o: make object! [a: none]
o-context: bind? in o 'a
same? o o-context ; == false -> now returns true

Is there an R3 specific explanation of binding?

Adrian, I wrote the Bindology article. There are differences in the 
behaviour as you noticed, some of them are quite minor (like the 
latter you mentioned), some may have a more noticeable effect. In 
the future, some revision of the article to adjust it for R3 will 
be needed.

So there's no short list (i.e. not something that goes into the kind 
of detail Bindology covers) of documented changes? In the meantime 
I asked this on StackOverflow:

http://stackoverflow.com/questions/14818324/is-there-a-summary-of-the-differences-in-binding-behaviour-between-rebol-2-and-3

Answered. There's still no short list - it had to be a long answer 
:)

Question about DO binary here: http://issue.cc/r3/1952

There's a bug in SAVE/HEADER when using Unicode characters in header. 
See http://issue.cc/r3/1953

Not exactly. Instead, SAVE/header is getting caught by a really obscure 
INSERT bug.

Ah, I thought you can't insert string directly into binary.

can somebody write an example of REWORD usage?

>> reword "$1 is $2." [1 "This" 2 "that"]
== "This is that."

Thanks

It can do more than that, but that's the basics. And you can have 
words as well, not just numbers.

If you are writing tests, there are a few things you should know 
about the behavior-as-designed of REWORD:

- values is a collection of key/value pairs, like a map. If a block, 
no reduce is done, it's just data.

- Keys are converted to strings if they aren't strings already, and 
are considered equivalent if their strings are equivalent.

- Empty strings don't count, but the check for empty keys is done 
after the string conversion so none is not empty, it's "none".
- If a value is unset or none, the key/value pair is ignored.

- If the same key is specified more than once, the last value of 
that key takes precedence.

- After all of the key/value conflicts are resolved, if there are 
ambiguities between keys (like "ab" vs. "a") then the first key gets 
priority. That means that you probably want to put the longer key 
first, same as with PARSE alternates.


If we're writing tests, we need to write tests for all of those. 
And we probably need tests because it was intended that REWORD be 
converted to a native for speed after we settled on its behavior. 
The current REWORD works as designed, but we might want to tweak 
the design after further discussion.

Oh, and if a value is a function, that function will be called every 
time with an argument of the string at the position of the escape. 
We need to test for that too. This makes *really* flexible replacement 
possible.

Just for this, Brian.

http://stackoverflow.com/questions/14924801/what-considerations-should-be-made-when-using-reword-in-rebol

Damn. Now I have to answer that :-/

heh