World: r3wp

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)

I just have a problem to see how huge is the burden you noticed. 
I would like to see some real use case at this point.

context [
    a: "OK"
    foreach a ["out of luck"] [print self/a]
]

this may be considered a real use case, compare the results in R2 
and R3

and, it is not a huge problem, I would call it just a gotcha, but 
do not like it

the problem is, that such a situation cannot be "hidden" by any number 
of hacks, but there is an easy and clean solution: just allow the 
majority of contexts to not contain the word 'self

(that principle was proven in R2 to work much better than any hack 
proposed/used in R3)

honestly , i would never do such thing (to be forced to use a path/var 
just to avoid name collisions) because i know paths are slower to 
evaluate than immediate words.
And I don't do that in R2 too for the same reason.

this does not have anything in common with paths, and it is a surprise 
for me, that you do not see it

I just used a path to illustrate the difference, but I can as well 
not use path, which I leave as an exercise for the reader

It's surprising me aswell you don't recognize a simple fact: self/a 
is a path! it's is a bad design to use them when you can avoid it

I certainly avoid that, when useful. In this case it was useful as 
a short example illustrating the problem

but there is no gain to illlustrate your point with something I would 
never do because simpler ways exist, no ?.

That''s why I asked for real use cases, because until now i'm not 
convinced by the benefits of such change.