World: r3wp

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

and why this reserved word bother you ???
can't you just avoid to use it ?

Actually, I would like to see a real code where it appears to be 
a problem

What if you want to emulate another language's OOP model? Or not 
do OOP at all? Or use functions like FOR, FOREACH, MAP-EACH, REMOVE-EACH 
and REPEAT in functions that are defined in an object, module or 
script? (That means every single time, btw)

Bug#1529 in particular needs fixing; bug#1528 perhaps less so.

Again, i don't see your point, sorry. Can you just show me a snippet 
of what can't be done ?

If you are writing code in a script, module or object (which means 
all code) then the way that you refer to the script, module or object's 
context is with the word 'self. And if that word is overriden, you 
can't use it. And those context references are used often.

The use case for allowing 'self as a function argument is less pressing, 
but since the fix is easy (at least my fix is) there is little problem 
with fixing this. And it will save a lot of support headaches, or 
at least a FAQ entry: "Why can't I USE [self] [...]?"

ok i see now, but it's not a problem to my mind, I just use another 
word to pass the object to inner contexts.

context [
  this: self
  x: context [
     parent: this 
 ] 
]

I mean it's easy to bypass the problem, with "mediator" variables.

Ah, but that is when you are *expecting* to override the context. 
Only advanced users expect FOR and such to override the context. 
And I don't see the problem: It's an easy fix, as was proved when 
the exact same fix was applied to MAKE closure! in bug#447. There 
don't need to be any structural changes; just flip a flag in BIND.

if you say so :)

Can you show me a use case for doing the special treatment of 'self 
in FOR and such? Keep in mind that R2 doesn't do this, so it's only 
worth doing if it's a definite improvement in some significant way.

and sometimes i use this trick too.

context [
  a: construct reduce/no-set [
     parent: self
  ]
]

Does that work in R3? Interesting :)

there are two problems...

 - actually, not, there are more than these two problems, as you bind/no-self 
 proposal illustrates, that is what I wrote in my comment

re your question, Steeve: if you ask for the code to be evaluated 
by For, do you expect, that For binds some words in the block it 
evaluates in addition to the words you specify? I doubt it, and it 
makes a problem.

In case of the Context function you are in a different situation, 
since you expect it to bind the word 'self

this problem cannot be "cured" by bind/no-self, since it requires 
the user to always know, how he wants to bind the words in the block, 
while such an information is already "automatically available" (as 
can be proven in R2)