World: r3wp

R1

Maxim, in your example, the user has access to the function f, can 
call it direcly. Let's say, we couldn't give the /local refinement, 
then I could just write:

	f evil-func "Print occurs as if nothing is wrong"


Why is it a problem, we can give the /local refinement? Isn't it 
false security, if it is changed, so we can't call with /local ?

Ah, a scheme engine leftover :-)

Carl reacted to its complexity with extreme simplicity, so this one 
may have been one bridge too far

i wish we would live in a world where u shouldn't be concerned about 
this kind of security issues :D

this concept is sooo lovely, that u can even build such a fundamental 
feature as local variable via the already existing specs dialect, 
my heart hurts to see we can't keep this virgin beauty and have to 
sacrifice it on the altar of security...

Yeah, I also thought it elegant when I heard about it, but on the 
other hand it violates the principle of least surprise

REBOL is too weird compared to other programming languages for it 
to really be possible or even desirable to avoid surprise :)

I know, but this one would be surprising in any language

Not any language - I think you are underestimating the variety in 
languages. Some don't have local variables at all, for instance.

Doesn't matter. The surprise is about local variables being initialisable 
from the outside

Local variables are by definition about encapsulation, and this is 
not encapsulation

The surprise being that there aren't really any local variables, 
just arguments which might be optional. There was a proposal to make 
there be non-argument local variables in R3, and I wouldn't be opposed 
to this, but "least surprise" isn't a good enough argument for why 
in such an inherently surprising language as REBOL. I also wouldn't 
be opposed to having FUNCT add an ASSERT/type [local none!] to the 
beginning of the code block of every function it generates.

That last trick would be difficult to do safely though, at least 
as FUNCT is used in the mezzanine generation process. Mezzanines 
are generated with FUNCT but saved with MOLD into the form where 
they will be loaded at runtime. This means that FUNCT can't generate 
code that has inline function or datatype values in it, since they 
won't mold properly. Unless you inline the references to ASSERT and 
NONE!, those words couldn't be used as function parameters or local 
variables in the generated functions. Tradeoffs, I guess.

I hereby propose to rename the /local refinement to /not-local

:-D

I can't figure out, if the /local behaviour is a real problem, or 
just one in our minds.

It has become a problem, now that people know it can be abused :-)

But who can abuse it? Just ourselves or outside hackers in a web 
application?

If it's just the programmer, who has full control over the functions 
anyway, then I see no problem.

Yeah, that's the criterium. You still need to be able to inject code

However, if someone gets a sandbox, every function made available 
can now be probed for code injection through this hole

For better local variables, you can use USE. But it's a bit clunky.

   f: func [a b][use [c] [c: a + b c]]   ;; 'c is local to the function, 
   and not easily/obviously affected by anything outside

It's really not any more of a problem for /local than it is for any 
other function option or argument, since the real problem is that 
the techniques for code injection have been revealed. Fortunately, 
so have the methods for avoiding or counteracting it: APPLY, type 
checking, get-words, or wrapping expressions in parens or putting 
them at the end of blocks to make sure that they can't get access 
to modifiable values later on in the block.

Sunanda, agreed, and also about it being clunky, particularly because 
USE has both COPY/deep and BIND/copy overhead in R3. ASSERT/type 
[local none!] is still the most efficient method.

Has anyone tried to use extensions in R3 OSX? Do these work?

Yes, they work. (Only did some basic testing, though.)

Callback as well then?

Didn't try.

Yes, my basic callback test works fine.

Perfect.

In R3, BACK doens't behave as SKIP ... -1.

>> s: [1 2 3 4]
== [1 2 3 4]
>> t: skip s 3
== [4]
>> remove/part s 3
== [4]

Now it takes 3 x BACK t to see anything:

>> back back back t
== [4]

while it only takes 2 x skip -1:

>> skip skip t -1 -1
== [4]

I'm not sure, if this is known or desired behaviour.

In R2, indexes are constrained to the bounds of the series they reference, 
so if you shorten the series you lose your position. In R3 your position 
is preserved for most of the standard operations, just in case you 
add back to the series later. The operations that can't possibly 
work for those out-of-bounds references trigger errors (mostly modifying 
operations), and the ones that could work if you consider series 
bounds to be an implementation detail and out-of-bounds values to 
be just not there return none (data access functions). SKIP is an 
exception, afaik, to allow you to sync up with the bounds - useful, 
but I don't remember whether it was intentional or a happy accident.
>> a: "abc"
== "abc"
>> c: skip a 2
== "c"
>> remove/part a 2
== "c"
>> index? skip c 0
== 2
>> index? c
== 3

The point of this in R3 was to rebalance the behavior in favor of 
not triggering as many errors when they aren't useful. The policy 
in R3 is that errors should be your friends, and that means triggering 
errors where they help in general, preferably informative errors, 
and not triggering errors where they aren't generally helpful. The 
conceptual definition of series was changed in R3 to make bounds 
less hard so as to trigger fewer errors; out-of-bounds positions 
are now considered to have no values in them, rather than not being 
there, under most circumstances when you can get away with it - you 
can't necessarily get away with it for modifying operations. This 
change was based on analysis of common code patterns, and considering 
that error catching is expensive in most programming languages, including 
REBOL; none checking is much less expensive. In the cases where explicit 
bounds checking is necessary, that isn't expensive to add to your 
code, not nearly as expensive as the bounds checking required in 
code in R2 that isn't required at all in R3.

BrianH: that's a beautiful description. it should be part of the 
R3/Concepts document. can we just dump it to there? (i don't have 
write privileges yet)

It would be a victory if we can get to the point where if R3 developers 
see an error triggered in R3 they are thankful for the information 
provided, because it will make it easier for them to find the mistake 
in their code that caused the uncaught error to be triggered in the 
first place. This is why error locality is so important, as is triggering 
better errors, and not assuming that something is an error unless 
the code says it is. If developers can think of errors as being their 
friends, all the better.

these are the kind of explanations which i miss in case of other 
languages when im wondering over design decisions like: "what kind 
of animal could have came up with such a fucked-in-the-nose idea?"

It's a little easier with R3, where a lot of the design decisions 
were made for good reasons, and by consensus. And because we decided 
early that R3's answer to backwards compatibility with R2 is to keep 
maintaining R2 for such code. That frees us to fix aspects of R2's 
design that turned out to not be that good an idea in retrospect.

+1 for getting Brian's detailed notes logged someplace so they are 
usable (and so they don't get lost).

Desiding what to do with block indexes out of range is a tough call, 
I think. I understand the argument not to cause errors, if it can 
be handled somehow, but I'm not sure, handling out-of-range problems 
is always good. What if it's a user bug in the code, that made the 
index get out of range? Then the user won't easily find that bug, 
as it causes no error.


It's not possible to index a block lower than 1 (first element). 
It's only possible to index out of range in the other end of the 
block, getting past the tail. And that can only be done by having 
an index there, and then remove something from earlier in the block. 
When the index is beyond the tail, then it has to be desided what 
to do with
	insert, remove, skip, next, back, pick, select, append
used on that index. (and maybe more like TAIL?, INDEX?, ...)

What does other languages do?

what other languages have position markers associated with arrays/lists/vectors 
inherently?

Let's say, my index is way beyond the tail, and I insert a new element 
there. It may then just be appended to the series, which is at an 
index way before my pointer. What if I then e.g. say:
	remove/part my-index -1

what should happen? And why?

Geomol: "I'm not sure, if this is known or desired behaviour" - Brian 
used a long description, but the fact is, that the best part of it 
is "accident". I bet, that it has not been checked, and it is not 
clear, whether the difference is desirable or not.

As far as I am concerned, the difference is not desirable.

Let's say, my index is way beyond the tail, and I insert a new element 
there.
 - you are out of luck, such an operation is not supported

>> s
== [1 2 3]
>> t: tail s
== []
>> remove/part s 2
== [3]
>> insert t 1
== []
>> s
== [3 1]

>> index? t
== 4
>> system/version
== 2.100.111.2.5

Seems to be.

Hmm, did not actually check, thanks