World: r3wp

>> g: func [] [self]

>> same? 'self first body-of :g
== false

hmm, seems to be used

how about the #447, it does not look like accepted to me?

It's not rebound by the function. What you are seeing is the script 
context.

>> a: 'self
== self

>> b: 'self
== self

>> same? a b
== true

Right. Scripts all use the same default context: system/contexts/user.

Modules get their own contexts.

>> same? self system/contexts/user
== true

then, what makes the difference in the above case of the function 
body?

The 'self word you are comparing is not bound to the function context, 
it is bound to the script context.

Or whatever other "outer" context 'self is bound to depending on 
where the function was defined.

>> a-body: [self]
== [self]

>> g: func [] a-body
>> same? first a-body first body-of :g
== false

so, something has to happen when the Func is called

No, something happens in BODY-OF - the words are unbound in the copy 
of the body returned, for security purposes.

right, sorry

>> a-body: [first [self]]
== [first [self]]

>> g: func [] a-body
>> same? first second a-body g
== true

>> a-body: [self same? first a-body 'self]
== [self same? first a-body 'self]
>> g: func [] a-body
>> g
== true

and how about #447, do you consider it solved?

Yeah. It must have been reported by that other BrianH :)

which one?

LOL

I use that joke in the tickets when someone doesn't realize that 
they are reporting the same bug twice :)

Just checked: I have reported 1/6 of the R3 tickets in CureCode.

, which is probably less, than what Meijeru has reported?

(amazing)

It's harder for me to get the proportion of Meijeru's tickets - I 
have to count tickets rather than pages.

nevertheless, shouldn't #447 be marked as still not solved?

- taking into account, that your comments still apply...

No, it's solved. The bug was binding 'self in the code block, which 
it used to do and now doesn't (as of alpha 50).

The 'self in the argument list duplicate word bug is separate.

OK, checked, and you are right

I would be willing to accept getting rid of 'self binding from closures 
if that is the choice, no big deal.
 (from above here)

aha, that was "the other BrianH"

:)

.... all fronts are so silent ....

indeed

The most "action" seems to be in R3 GUI documentation here: http://www.rebol.com/r3/docs/gui/gui.html

I noticed the docs are getting a bit prettier too ... some icons, 
images, right panel menu, etc.

>> extract/index [a b c d e] 2 2
== [b d none]

Is the last NONE desirable?

Surely not, but it''s so easy to make your own that i don't see the 
interest to have such mezz :)

R2 and R3 do the same.

It's the problem with such mezz, they are allowing to much refinements 
so that it ended all messed up :)

By example, the refinement /index has absolutly no interest.

The obvious and regular way with rebol, is to use SKIP or AT as a 
prefetch.

see.
extract/index [a b c d e] 2 2
vs.
extract at [a b c d e] 2

the second one is faster and even shorter to write :)

fair point

Henrik, the /index option of EXTRACT assumes that there will be something 
there at the index (record length specified is assumed), and that 
the R3-style treatment of series bounds is in effect. That means 
that the programmer is expected to do their own bounds checking, 
or to not care. The none value is a placeholder for missing data.

Steeve, the second example you gave was missing a 2 on the end. But 
still, if that is the answer you want then that is a good way to 
do that. However, since EXTRACT is used for field extraction fron 
fixed-length records, Henrik's code is correct for that use. He just 
forgot to put a value in the proper place in the third record, so 
it returned none.

Your method didn't return a value at all, as if the whole record 
was missing; not the same thing at all.

As for the reason for the inclusion of the EXTRACT function and its 
/index option, it is because of how much they are used, even in mezzanine 
code. There are a lot of functions there for our convenience, even 
if they would be easy to remake if missing. This doesn't make them 
less useful.

Actually, I used it on a table header with arbritrary data and simply 
wanted every second element in the block, regardless of the block 
content, so the block was not a db record of any known length. Perhaps 
it should be emphasized that extract/index works best on, or is intended 
for database records.