AltME groups: search

Doesn't the speed also have to do with the message limit per chat 
settings? I've decreased mine and  it's much faster. Though I do 
wonder how accurate that setting is or what it really measures. I 
set mine to a higher number after a search and warning that it needs 
to be set higher. I've thought that there's no way there could be 
that many messages (several 1000's) in that one topic.

OK, nevermind. I prefer

    do quote 'a/1

to yield

    == a/1

to be honest

We need to make sure that we don't follow the same pattern for set-words 
and set-paths. Explicit DO of set-word/set-path values doing any 
setting is another security hole.

I like the current behavior of set-words:
>> a: 1 do quote a: 2 a
** Script error: invalid argument: a:
But the behavior of set-paths leaves a bit to be desired:
>> a: [1] do quote a/1: 2 a
== [1]  ; no error triggered, just a noop.

I figured out a new way to express the equivalence that can safely 
be used for word! (http://issue.cc/r3/1882), path! (http://issue.cc/r3/1881), 
lit-word! and lit-path! (http://issue.cc/r3/1434), set-word! and 
set-path! (http://issue.cc/r3/1883), and get-word! and get-path! 
(current behavior), that matches the behavior of paren!. This code 
should work in all cases.

use [a b] [
    a: func [] ["blah"]

    foreach t compose [(paren!) (to-block any-word!) (to-block any-path!)] 
    [

        assert [any [all [error? try reduce [to t 'a] error? try [do to t 
        'a]] same? do reduce [to t 'a] do to t 'a]]
        assert [b: to t 'a strict-equal? to t 'a b]
    ]
]


Basically, the equivalence of an individual type would be this (using 
word! as an example):
    same? do [a] do 'a
    b: 'a same? 'a b


The important part of the equivalence would be that DO value would 
be equivalent to DO reduce [:value], that it be equivalent to evaluating 
that value inline *in a block all by itself*. That would deal with 
the parameter problem, with making sure that set-words and set-paths 
trigger errors properly, it even would work with refinements and 
issues.

That would also extend to unbound words. The harm would be in having 
explicit DO trigger an error in an otherwise harmless case that would 
be common in data. Do we need this error?

Consistency might be a good enough excuse to do so, but I don't want 
to break code unnecessarily.

The advantage would be to trigger errors when you DO code that isn't 
properly bound or set. It's either an error that it isn't bound or 
set, or it's an error that you are trying to DO it.

Brian wrote:

<quote>
>> b: quote 'a/1 
== 'a/1 
>> b 

== 'a/1 ; regular evaluation of lit-path value does not convert to 
path 
>> do :b 

== 'a/1 ; explicit evaluation of lit-path value does not convert 
to path


So it's not exactly like parens, but it's what Maxim, Geomol and 
I would prefer.
</quote>

No, I just posted the observed behaviour. I don't agree with it.

well, if it works and do the job. And it's nice, there are more than 
one way to do things.

...and I do not think it has been discussed thoroughly, but, anyhow, 
I guess, that nobody objects against having lit-words or lit-paths. 
In that case, it is strange to object against QUOTE, especially taking 
into account, that QUOTE is much more universal, so, instead of saying

    get 'word

we can always say

    get quote word

Why I wrote "QUOTE is necessary" - because that is the only way how 
to do it directly. Using the "double conversion method" you can do 
it usually as well, but that certainly does not count as a "direct 
method".

If allowing get-words in spec blocks, then QUOTE is fine. I'm questioning 
allowing get-words in spec blocks. It can lead to uses as this:


I make a function, that can do a paren! (in lack of better example, 
but it makes the point, I think):
>> do-paren: [:p] [do p]
I can try it on a paren:
>> do-paren (1 + 2)
== 3
Works ok so far, so I try having a var holding a paren:
>> q: quote (1 + 2)
== (1 + 2)
>> do-paren q
== 3
I got the feeling, I know how do-paren works, until I write:
>> do-paren quote (1 + 2)
** Script Error: do is missing its value argument
Hm, what if I use the old method:
>> do-paren first [(1 + 2)]

** Script Error: p expected series argument of type: series pair 
event money date object port time tuple any-function library struct 
even...

That's confusing, as I see it. (Example done in R2.)

(i didn't know about the :p where is it documented? otherwise i used 
the 'p notation many times. it even allows to add explanatory words 
to the parameters, so u can make a nice dialect by using the default 
'do evaluator...)

there is no LIT-LIT-WORD argument, so, to obtain a lit-word, the 
most natural way is to use: quote 'a

Some thoughts:

So one use of this is to make it easier to e.g. insert a lit-word 
in a block. I come to think of how to insert a block in a block. 
We can't do:

	insert blk [a b c]


as that will insert the 3 words, a, b and c, in blk. So I can write:

	insert blk [[a b c]]
or
	insert/only blk [a b c]


Why not use the same kind of thinking, when dealing with lit-words? 
So I can write:

	insert blk ['a]
or maybe
	insert/only blk 'a


(maybe the refinement should be called something else than /only). 
Now, the rule for INSERT should then be, that if it get a word (the 
lit-word, 'a, will be translated to the the word, a), it should change 
that to a lit-word, if it got the refinement too.


Result is, that unevaluated get arguments can be avoided making the 
REBOL scanner/parser simpler.

As for functions with get-word arguments, the DO dialect used to 
need more of them, but in R3 most of those needs are handled by QUOTE. 
For other dialects though it is much more useful, as it prevents 
evaluation by the DO dialect when it is unwanted. It can be used 
on occasion in security situations if you want to block calculated 
values. Also, it could be used in a statically compilable subset 
of REBOL for the block arguments of all control and loop functions 
like IF and WHILE.

Consensus adds to the strength of an argument. Chiming in with an 
"I agree with Ladislav" on a potentially controversial issue reduces 
the controversy that might otherwise block it, especially if you 
are sometimes someone who disagrees with Ladislav effectively (which 
is pretty difficult to do).

Back to QUOTE and get-word arguments...


We need something like QUOTE, especially for set-*, *-paths, and 
functions, because these block an evaluation that may have side effects, 
or at least cause a value copy. Even if QUOTE is the only function 
with this evaluation model, it depends on DO supporting something 
like get-word argument evaluation in order to work at all. The alternative 
is to make 'quote a keyword in the DO dialect, which decidedly doesn't 
have keywords. So we can't get rid of get-word arguments altogether 
without ridding ourselves of QUOTE, and you'd get a bit of resistence 
from anyone who's used it if you want to do that.

I notice ++ and --, which was discussed here:
http://www.rebol.net/cgi-bin/r3blog.r?view=0057#comments

Would it be ok to let NEXT and BACK do the job, like this:

next: func [series] [
	either word? series [
		set series system/contexts/lib/next get series
	][
		system/contexts/lib/next series
	]
]

Examples of use:

>> blk: [a b c]
== [a b c]
>> next blk
== [b c]
>> blk
== [a b c]
>> next 'blk
== [b c]
>> blk
== [b c]

you are protected when using FUNC, while you are allowed to do what 
you want when knowing what you are doing

What would the consequences be?

 - I do not know, you did not give me enough specifications to be 
 able to guess.

I wouldn't have closure, but use object instead (or context, as I 
call them), if that functionality is wanted. And block content isn't 
bound to start with, so if I write:

>> f1: [a]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 2


because 'a' inside f1 is bound to local 'a' in f2, when evaluated. 
If I want another 'a', I could write:


>> context [a: 1 set 'f1 compile [a]]	; f1 will be a block, [a], 
where the 'a' is bound to 'a' in the context
>> f2 f1
== 1

and the last result could be achieved:

>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


Calling f3 will be slower, as blk is recompiled each time. This language, 
I illustrate, isn't REBOL, but another with many similarities to 
REBOL, but with a compile function. Maybe kinda the same could be 
achieved in REBOL, if the binding rules was changed, and "compile" 
in my examples above was changed to a "rebind" function.

I wouldn't have closure

 do I understand correctly, that you do want the programmers to enjoy 
 the benefits of having closures?

err, "do not want" is what I wanted to write

I already gave examples to do that. They were:

>> context [a: 1 set 'f1 compile [a]]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 1
>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


I haven't finished reading about CLOSURE, so maybe it can be even 
simpler.

It would be easier in R2 to create CLOSURE this way:

>> closure: :func
>> f: closure [a b] [[a + b]]
>> do f 1 2
== 3

Those first three values in the source of C are direct references 
to the functions DO, MAKE and the type function!, so there are no 
word conflicts.

Yeah, they will be reused. But the way, REBOL do it, if you have 
an application, that do a lot of block parsing for example, with 
new words coming in all the time, then that global context will just 
grow and grow. In reality, it will probably come to an end, as there 
are a finite number of words in a human language, if that's what 
being parsed.


If words were not bound by just being loaded, but only when evaluated 
(or compiled, if that's the case), then parsing blocks would not 
produce any unset! words in the global context. But a consequence 
of this is, that blocks of code being sent to a function (like LOOP), 
will be able to see the words local to that function, unless the 
block is first bound outside the function, like

	count: 1
	loop 10 bind [print count] 'count
, which will then print the number 1 10 times.

The consequence:

>> count: 1
>> blk: [print]
>> append blk to block! "count"
== [print count]
>> do blk
** Script Error: count word has no context

I wonder, why TO BLOCK! works like this.

AFAIK, to block! doesn't do binding, you have to LOAD the block.

I think, there is a third alternative. When we deal with strings, 
a data structure is made, and we just have a pointer to that.

var: "a string"
var: none


When noone is using the string anymore, memory can be completely 
cleaned for it. If I do the same with a word:

var: 'word
var: none


I don't see, why memory can't be cleaned just the same. Is it a design 
flaw, the way it is?

John, you are missing some things others know and find obvious. For 
example, do you know the answer to the following question?

    What is the ratio between

        stringn: func [n] [head insert/dup copy "" #"a" n]


        word: to word! stringn 1 t1: time-block [equal? word word] 0,05

        word: to word! stringn 1000 t2: time-block [equal? word word] 0,05
        t2 / t1

compared to


        string: stringn 1 t1: time-block [equal? string string] 0,05

        string: stringn 1000 t2: time-block [equal? string string] 0,05
        t2 / t1
?

Thanks, Ladislav. Good examples!


The thing, I missed, was that REBOL has this extra internal data 
structure to hold symbols (words), I though, just the contexts was 
used for that. So comparing words (that are not bound to any context) 
are much faster than comparing strings in REBOL. I see different 
possibilities, depending on implementation. If a word is changed 
to the result from a hash calculation, then two different words might 
give the same result, right? It's unlikely, but it could happen. 
That's why map datastructures are combined with lists, when two different 
hash calculations give same result. The other possibility is, that 
words are changed to pointers pointing to their entry in the map 
(hash table). Do you know, what of the two, REBOL implement? In other 
words, could two different words be equal in REBOL?


About the strings, then it's possible to do kind of the same with 
hashing. Lua does that. If you have two different but identical strings 
(same string content) in Lua, they share the same memory area. Hashing 
is involved, and I guess, comparing string would be equal fast as 
comparing words, if REBOL did the same. (unless words are exchanged 
with the result from the hash calculation, but then two words might 
be equal)

You're right. to word! put it in system/words, I need to do to block!, 
I guess.

Geomol, refinements are not just for translating to paths. You can 
use a subset of the possible refinements for that purpose, but rest 
can be used for whatever reason you like in other dialects. REBOL 
is not just the DO dialect, remember. (This is the official answer; 
I am just writing it out again, for the 4th time this year.)

Jerry, the /local refinement is just another function option. If 
you provide that option when you call that function, you can provide 
initial values for the "local variables". In the case of sys/load-module, 
the security and control flow of that function depends on the local 
variables being initialized with the none value, so we want to avoid 
the /local option being used when the function is called. When a 
function refinement is not used its value is none, so if you want 
to ensure that it is none and trigger an error if it isn't, ASSERT/type 
[option none!] is the most efficient way to do this in R3.

That is up to the implementor/designer to deside. :-) Maybe it should 
be a number, like actions returns in R2, or none as R3 do.

The ability to do that is limited for an interpreter until it becomes 
too slow

but the idea is that we usually limit the input types when it matters. 
 and the function has to do the handling of the /local refinement.


I'd much rather get an interpreter error telling me I can't use or 
apply /local refinements.  this would also mean that /local would 
have to be the last refinement... always.

Here is an example of a function hi-jacking.


it is something that can commonly be seen in larger apps, where some 
locals are only used conditionally.  in this case, the original function 
is hijacked and we could really do nasty things here.


--------------------------------------------------------------------
rebol []

f: func [a [string! block!] /local str][

	; uncomment to make the function safe
	; str: none

	if block? a [
		str: mold a
	]
	print any [str a]
]

evil-func: func [a ][
	; do something evil here
	print "EVIL!" 
	head insert a " >:-P >>>  "
]

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

ask "!"

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.

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

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?

This is by far the longest period of Carl's disappearance, IIRC. 
The reasons we can only speculate about - some personal/family difficulcies, 
burn-out to the REBOL topic, new daily job, which does not   left 
you with much energy and free time to do some other stuff, REBOL 
related.


We tried to get Carl's answer on R3 Chat, only with sporadic answer 
of recent Carl's job. But no answers to "what's next" for the REBOL. 
The reasons might be various again - Carl is willing to proceed, 
he just dosn't have time/energy. He is most probably not willing 
to open-source the project either, which gets us into kind of schizophrenic 
situation - no open-source, no progress either. If Carl would know 
the answer to what's next for REBOL question, he would already share 
it with us. But he did not do so, yet, which is a bit disappointing 
of course.


As for a phone call - I don't know - I would not call him, as it 
could get him into feeling, that we push him to give us an answer, 
which he might not have right now. But - I think that call from some 
friend, e.g. Reichart, would be accepted differently. But then - 
we can't push anyone to do anything, and from few weeks old discussion 
I think that Reichart does not necessarily feel urge to do such a 
thing, which is OK too.


So ... we wait ... and RED progresses at least, so hopefully in the 
end, there is still the chance that we will see the light in the 
end of the tunnel :-)

We are going to drive the priorities by the things RMA needs. This 
shouldn't be a problem for anyone because if you are going to use 
R3 for serious development than you will need it as well.


The thing is, that we are not going to jump-start for every requested 
feature etc. We know there is a lot to do and we will work through 
it step-by-step. And, this is not because we don't care what you 
all state here. Definetly not. I want to move R3 forward as fast 
as possible. This needs concentration, focus and pushing to finally 
get it done. At the end of the day the only thing that counts is, 
if we make it to make R3 stable enough for prime time development.

I might not be as good as you guys are, but if there is anything 
I can do to help R3, let me know. My email: [JerryTsai1218-:-Gmail-:-com]. 
Let's make R3 hit the beta this year.

Has it been tried to get the source for R2's load/library, make routine! 
and then the calling from Carl? That seems to me to be a lot easier 
to start with that code, as it do work.

#1888 is definitely not a bug. #1886 should be looked at by the person 
who knows what SPLIT is supposed to do. It wasn't one of mine, and 
there was never really any consensus about its behavior. SPLIT isn't 
finished yet.

SPLIT has enough cognitive overhead that I've never understood what 
it was supposed to do, and thus never used it. A sign?

Like most developers, I don't read the docs for a function unless 
it is complex enough to need docs, and powerful enough to make it 
worth the time to do so. PARSE is an example of a function that deserves 
docs beyond the doc strings, or maybe the source. SPLIT should be 
more like FIND, understandable without reading a web page. Requiring 
otherwise is a design failure. I couldn't even understand SPLIT's 
rationale from its own source code.

I think he wants to do that.

If I use an async callback from C to R3 and want to access the result 
from the Rebol callback on the C side, how do I find out, if the 
async-callback has been executed by R3?


If not, I think I need some kind of active waiting / polling on the 
C side until the callback was executed.

Carl could not do anything worst to rebol ... and neither the less 
it was a logical conclusion of a pharaonic oneman driven project...

now can we ask why and hope to have a frantic reply on that matter 
or  do we have to play happy face   forever ?

I see the other language grow I see rebol shrink. Can I ask what 
you really plan to do to change this ?

can we show concretly that carl is wrong to be AWAY undefinatly from 
rebol ? Can rebol survive this  or will rebol community be tired 
and bring a community project that will continue what ever Carl do 
to bring the interest back to rebol?

my point is that I really fear all the actual project to be nothing 
more than oneshots that runs short and disapear after Carl brillant 
return to announce on his all mighty goodness he will reboot rebol 
and do r4 :)

The way I see it, it's fairly simple. We have no control over REBOL. 
The clones are open source, so we do have control over them. If they 
go nowhere, it must be because we're not interested in them, so we 
would only have ourselves to blame, which is much different from 
REBOL

and I don't understand red ... well I didn't spent too much time 
on it and I don't want to hum be more of  a SoB that I am ... I can 
say I like 3 things in rebol code efficient and short, one small 
VM to do everything, the console to code interactively ... and I 
think this part was underestimated by carl in r3  ...

As I see it, the rule should be, that either you wish the function 
you create to be modified/modifiable and then you should use the 
property of the MAKE function, or you don't wish that, and in that 
case other functions should not help to do it.

OK what do we have to do to put an end to this masquerade ???

do we have to buy rebol source code from carl like it was done from 
neogeo by blender ? if that the case I'm ready to give to taht purpose 
one moth of salary in full this is how commited I am to rebol cause 

I like rebol I always liked it and will always like it ... I'm just 
extermely sad that we can't organise a proper stuff to make rebol 
the gran scripting language it deserves to be 

We lack comitement we lack seriousnes and sorry to tell you this 
but rebol shouldn't be our hobby it should be our reason to very 
live 

You guys should be ashamed to see so much people leaving this community 
and instead of smugging them and ignoring them YOU (yeah you !  don't 
force me to call you by your name !) should be an offering  force 
to create main project AND WORK WITH THE OTHERS to make rebol something 
noticeable not just something to fill your spare time !

you shoudl be ashamed of this ... common are you so blind that you 
see rebol being abandonned and deserted more and more  RMA is faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar 
zillion light years of being as community moving as RebGUI and the 
main reason is that by abandoning REbGUI you slaped us in our faces 
and know what we don't like that we don't like the gurus selected 
fews we don't like RMA we don't like what rebol has become and the 
one more hating is is carl sassenrath  himself  we forced his hand 
to give us more  freedom and more action on rebol and WE WASTED IT 
purely and simply 


Then all we ever standed for is futile and void ... and what I see 
here is stupid comments about a dead product that it's main own and 
only author abandoned .

Instead of giving bucktracks that will never been read or take in 
considaration please the remaining of you the rebol community TAKE 
ACTION !!!

If you hate me if you dispise me then this is your chance to prouve 
me wrong and make miserable ! cause hey the mniserable ones til now 
are you the stupid tens thousand bugs founders that will never find 
a solution cause the main guy to  implement those fixe is gone since 
november 2010

focus on one and single project do what RMA wasn't able to do ... 
and if to acheive that you have to make cyphre Robert and the other 
RMA members myserable just do it ! do a freaking r3gui that can hold 
a candle to was rebGUI was and is ! so far you are just fucking sploiled 
child and I hate you  sooooooooooo much .  you were given everything 
I never had, the fame the confidence the spot light  the ears of 
each and everyone and what you do out of that  ????!!!  nothing ! 
 you let carl to totally toy you !

now you will continue to do what you have always done ... submiting 
stuff that noones cares about it just to feel the blanks of your 
existence ... this is one thing that not even carl wants to participate 
in ... so face it ... and stop you  are ridiculous can you give me 
since january 2010 one noticeable thing that is worst mentioning 
?

Pardon? What does Carl have to do with Boron?

No, I deny his work with the community, that is all. Imight set-up 
REBOL conference, and invite no-one, just do some infrastructure, 
web-presentation, etc., not talk to ppl, and wonder, why noone is 
attending ... I never felt enough "marketing" is surrounding Orca 
or Boron.


And yes, open-source world is ignoring REBOL clones, maybe because 
1) they think that there is very few ppl involved anyway 2) because 
they might feel that anything REBOL related is doomed, not enough 
popular, etc. 3) because REBOL syntax and functional languages do 
not attract many, and they hardly become mainstream ... 4) because 
world is moving towards - do-everything-in-JS+HTML+CSS

I might be able to do that as a by-product of learning R3 module.

Yup. The source code represents the current intended design, though 
one question has popped up recently that didn't arise during the 
design process. The !REBOL3 Modules group here has a lot of info 
too. I hope to get the chance soon to go over the docs on rebol.net 
and update them to the latest design. I was going to do that last 
weekend, but I got really sick. However, I am using REBOL at work 
now for utilities, so I can afford to work on it again here and there.

Brian, regarding BIND, I mean e.g. this:

>> f: make function! compose/only [[a b c](body: [a do c])]
>> a: first body
== a

>> f 1 1 [a + b]
** Script error: b has no value
** Where: do f
** Near: do c

>> f 1 1 bind [a + b] first body
** Script error: none word is not bound to a context
** Where: bind
** Near: bind [a + b] first body

I do like that. but, nevertheless, the MAKE function is able to bind, 
while I am not, which proves, that it is just an artificial, (not 
making anything more secure) and annoying limitation

You can do it with CHANGE only if you get access to the bound body 
block, which is why letting a reference to that out is a security 
hole.

I do not want to do that with a function. It really suffices to do 
it with a word

But you can already BIND to a word bound to a function context.

 - actually, I cannot, if the function isn't already running (in that 
 case BIND refuses to do that)

>> bind 'a do func [/a] ['a]
** Script error: a is not in the specified context
** Where: bind
** Near: bind 'a do func [/a] ['a]


Well, then you don't have to be as careful with letting bound function 
words leak I guess.

or, having the access to the body, you can do other tricks

>> head change [1] 'a
== [a]
>> head change [1] #"a"
== [#"a"]


With BIND, you can leak the 'a word and get access to the 'b word 
from that same context. You can't do that with CHANGE.

But, if you do want to "play dirty", then having 'a is completely 
sufficient

I'm curious: How can you get a word 'b bound to a function context, 
when the function is not running, you don't have access to the original 
function body, and all you have is a word 'a bound to that same context? 
No command or extension tricks either - they're already assumed to 
be unsafe.

 - I offer you this statement, which I *can* prove in a reasonable 
 sense:


- I assume, that F is a function having a context with more than 
one variable (Otherwise, there is nothing to prove, is there?)

-, so, for the simplification, let's assume, that there are variables 
'var-a and 'var-b in F's context, such that:

- the Attacker has already access to the variable 'var-a bound to 
the F's context

- , but he does not have the access to the variable 'var-b bound 
to the F's context yet

- now, let's assume, that having access to the variable 'var-b in 
the F's context he would be able to "do some harm" (whatever that 
"harm" is)


Provided, that the above conditions are met, the Attacker is already 
able to do the harm even not having the variable 'var-b bound to 
the F's context available yet. Do I have even to prove the statement?

Oh, that's what you meant. I was asking specifically about the particular 
question I asked. It sounded like you were saying you had a way to 
do a BIND without BIND. If so, that would be an interesting trick, 
but also a security hole. I'm more interested in the trick though, 
if it exists.

Let's ignore the function context aspect of it all, and simplify 
the problem. If you have a word bound to a context, and want to get 
access to another word bound to the same context, and don't have 
access to the BIND or IN functions at all, how would you do it?

Once again, the assumptions are:

- I have a word 'var-a bound to the F's context

- It is true, that *if* I had a word 'var-b bound to the F's context, 
then I would be able to do "some harm"


Provided that these conditions are met, then I am able to do the 
harm.

What you are requesting is something that we are trying to prohibit, 
and we have good reasons for doing so. 
 - by the above, I just proved, that you do not

Above you mentioned, that the reson is this:


- if I had access to a 'var-a variable bound to the F's context, 
and if I were able to do "some harm" having another variable 'var-b 
bound to the F's context, then that is a good reason why to cripple 
BIND, to not give me the access to the 'var-b bound to the F's context 
as well when the function is not running.

 As stated, I can disprove that as a reason.

Proof:


1) Due to the way how the function contexts are implemented in R3, 
the word 'b in F's context does not refer to a password when F is 
not running.

2) Because of that, I either cannot read the password at all, or 
have to be able to read it somehow, which is possible *only* when 
the function is running. (oherwise, there is no danger of me reading 
the password as is well known)
3) do I have to continue?

The "But the ban on BIND to the function! value *itself*..." statement 
refers to this:
>> not find second types-of :bind function!
== true


The BIND function doesn't accept function! values for its context 
argument. The reason for this is so that functions can prevent access 
to their context from leaking to code *that the function calls* that 
could be exploited while the function is running. All the function 
has to do is not leak bound words, and it's safe. If that doesn't 
work, please show how.

As said, I do not have to. The string is already there for me to 
read.

If getting access to 'stuff is the only way to get access to what 
it refers to, how do you get access to 'stuff if all you have is 
:a ?

blah: module [] [hidden hidden-stuff: "something you want" a: func 
[code /stuff] [stuff: hidden-stuff code]]
blah/a func [] [do something to get access to hidden-stuff]

So, do I assume correctly, that I cannot examine the BLAH module 
to get the HIDDEN-STUFF value?

a func [] [do something to get access to hidden-stuff]


The function a doesn't exclude functions from its arguments and it 
refers to its argument with a word rather than a get-word, so it 
can be tricked into running code while it is running. That means 
its context is valid while the exploit code is running.

Do I understand correctly, that this is what you propose as demonstrating 
the reason for the functions not being accepted by BIND?

a: func [] [do something to get access to hidden-stuff]

No, that's nothing to do with overlong forms, but with PARSE in combination 
with bitsets being broken.

On a separate note, I want to standardize on either R2 or R3 for 
work (no GUI or SDK required). What are the advantages of R3 compared 
to R2 at present, and what (apart from GUI and SDK) can R2 do that 
R3 can't?

I would add following "negatives" (depends upon how you look into 
it):


- no /libary extension and easy wrapping of DLLs. There was a bounty 
started to bring in kind of R2 DLL capabilities using extensions, 
Max was working on something, but did not deliver. Some ppl claim, 
that working with extensions is easy enough, much more powerfull, 
and that in fact R2 /library interface was weak in comparison in 
capabilities.


- weak and underpowered CALL.No /output or /wait parameter IIRC. 
Carl said, that R2 C code to it was complex, and that the code is 
eventually awailable for volunteer to bring in to R3. The outcome 
is - CALL is limited in usage in comparison to what can be easily 
achieved in R2.


- protocols. The only protocol IIRC was available was HTTP, done 
by Gabriele. It was HTTP 1.1 compatible, but due to some bug (?) 
it was downgraded to 1.0 version. No proxy support. Other protocols 
were done by some other ppl, I do remember Graham doing some work 
here. In regards to protocols, IIRC there was some work done by Kaj, 
who brought Curl networking extension to R3.


- under Windows console is a bit more inconvenient in usage than 
in R2, we use native Windows console, yet we don't have full console 
support, so we can't replace the native R3 one by e.g. Console2 or 
some other version ...


- DBAccess - forget R2 protocols available. The rescue is ODBC extension 
for R3


- CGI - no native CGI support in R3, though it should not be difficult 
to emulate


- Sorting & Unicode - althought we have Unicode strings available, 
sort is not adapted to that, and the question is, if it can be easily 
done ...

In general, doing math with char! values without explicitly converting 
them is kind of bad form; it leads to developer confusion. The main 
reason you'd do this is because of the awkwardness of combining operator 
and prefix expressions without parentheses. It's interesting that 
it still works in some cases, but not in others. Considering characters 
to be number-like is a bit weird, a bit too C-like for my tastes.

Ladislav is the one who would likely be doing the work, and he seems 
to need some convincing

 - I do agree, that LESSER? etc. functions having two versions (or 
 a refinement, or something) would be useful.

Macros make a lot more sense in compiled languages like Red, Topaz 
(to JS) and World (to bytecode) than they do in interpreted code-is-data-at-runtime 
languages like R3, where most functions are like macros.

I guess, it has something to do with, how lucky the compiler is maybe 
to get data on 64bit boundaries and make code parts/data fit in cache 
and such technical things.

Its tracking newly "created" words in the user context after a binding. 
It's maybe not what you're trying to do but it was in response to 
Cyphre.

Steeve... I guess Ladislav is looking for something like this R2 
helper script:
gbl-test: func [
    code
    /all
    /init {returns string with all global variables set to none}
    /local gbl-list words str_init
][
    words: make block! 50
    str_init: make string! 1000
    gbl-list: query/clear system/words
    do code
    if block? gbl-list: query system/words [
        foreach item gbl-list [
            if any [all value? item] [
                insert tail words to-word item
                if init [
                    insert tail str_init join to-word item ": "
                ]
            ]
        ]
    ]
    if init [
        write clipboard:// join str_init "none"
    ]
    words
]
>> gbl-test [a: 1]
== [a]
>> f: func[a][b: a + 1] gbl-test [f a: 1]
== [a b]