World: r3wp

>> 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.

To me this is a case of a method that exists for specific use, but 
is implemented in a general way. That's OK, I suppose, as long as 
you know Steeve's way to produce an optimized and more correct result.

Correct is relative. EXTRACT/index is working as designed - it just 
wasn't doing what you wanted to do.

It's the mandatory width argument that makes EXTRACT record-oriented, 
not the /index option.

The none as missing value feature is also taken into account by the 
/default option, even in the middle of the block.

Added an unrelated (at least slightly) comment #55 to the error handling 
blog discussion; are there other opinions, than mine and BrianH's?

(related to the 'self word I mean)

Do you ask for the removing of the self word in objects ?

No, definitely not object! contexts.

I don't see the distinction currently.

Internally, there is none. Ladislav is proposing that the internal 
'self field in the beginning of all contexts be made optional, with 
that option taken by MAKE object! (and as a side effect, modules), 
but not taken by contexts created by functions, closures and binding 
structural functions. As opposed to allowing the field to be overriden 
for that other stuff, and not doing the BIND trick with 'self in 
those cases (as we demonstrated we can do when that problem was fixed 
for closures).

The potential problem with Ladislav's proposal is that the internal 
'self field might be mandatory for a good reason - we don't know.

There are two problems we are trying to fix here:
- bug#1528: 'self seems to be reserved in closures and funcs

- bug#1529: 'self is being bound by For, Repeat, Foreach, Map-each 
and Remove-each

Now bug#1529 is basically the same thing as bug#447, which was for 
closures: BIND is doing the special treatment of 'self where it shouldn't. 
And as bug#447 proves, you can shut that off with no difficulty (internally).

And functions and closures don't do the BIND trick with 'self, so 
that's not a problem.

I am suggesting that this ability to turn off BIND's special treatment 
of 'self be made available as a BIND/no-self option (or whatever 
else we decide to call it). This would allow us to write mezzanine 
functions that act like FOR and such, not necessarily in the sense 
of looping, but in the sense of not treating 'self weirdly.

The only problem that might need Ladislav's proposal is that you 
can't use the word 'self as a parameter of functions or closures: 
A duplicate arg error is thrown. And since you can't use that field 
as a function argument, Ladislav is suggesting that it shouldn't 
be there at all. While I am suggesting that MAKE function! can just 
skip that field when checking function arguments at function creation 
time - a solution that wouldn't require any changes to the internal 
data model of all contexts.