World: r4wp

My first reaction was the same as Endo and Bolek, because I'm used 
to the way it is. I rarely have to alias a loop counter for access 
outside the loop, and I like the language being smart enough to help 
me, so I don't have to declare these things all the time, or worry 
about leakage.  However, my recent work on the idea of a new, general 
LOOP func (%mezz/new-loop.r here for those who didn't follow it) 
made me keenly aware of loop costs.


I've only had a few instances where it really mattered, but I've 
still almost always avoided FOR, for performance reasons.  Doc thinks 
things through carefully, and he has already said that FUNCTION could 
probably be smart enough to handle things for us, but we would have 
to consider how that works, to avoid environment dependent behavior. 
And how it affects very simple map/filter funcs. That is, do those 
one-liners now need /local specs.

Now is the time to discuss this, but it sounds like Doc has thought 
this through, and made his choice for clear reasons. If he's set 
on it, then we should look at what, if anything, needs to be done, 
to make Bolek, Endo, and others happy.

Right, it doesn't error out because `i` gets bound to global context, 
but we want `i` to be local, which should be the common use case.

Maybe this is where something like my new LOOP could be used. It 
would be a general purpose func that trades performance for flexibility 
and automatic localizing of loop vars.

Gregg, I'm still open to counter-arguments. If you want the language 
to do the job for you, FUNCTION should be able to provide you that.

Compiling the console works out of the box as described on my Macbook. 
I am impressed. The Repeat by Endo does what I read it that it should 
be doing. The Doc: is it intentional?
red>> repeat i 10 [  ]
== 10
red>> i
== 10

is what I expect it to be after the performing of the repeat. Unless 
you argue that i should only be valid inside of the repeat, but you 
should work with a function then not with a repeat. I do not see 
what is not to be liked about that?

In REBOL and Red it is the human way that is leading not the programmers 
mind that is used to bend along with the computers view of the world.
Again beautiful progress Doc.

Arnold, the point is that Rebol makes the loop counter a local word 
in a hidden context. It saves user from having to defining it as 
local manually (I have argued above about how I think this is, in 
practice, rather counter-productive).


We need to find the right balance between human-friendliness and 
efficiency/productivity.

Yes, so i should not be defined after performing the repeat. There 
is something to say about that.  On the other hand after performing 
the repeat, in my mind i is at the end of the range and thus has 
to be equal to the last value. Stupid humans ;)

so i should not be defined after performing the repeat.

 That's the Rebol way with the hidden context. In current Red implementation, 
 such context is not used.

The biggest problem I see right now is that it binds to the global 
context, which will confuse existing REBOLers. I still think it can 
be solved cleanly, and the performance gain is probably worth it. 
And you know how I hate premature optimization. :-)

The loop word is like any other word bound to the global context 
unless you declare it locally.

Right, what I meant was that LOOP, being dialected, could easily 
localize the counter word.

In %boot.red, UNLESS's second arg is called 'true-blk. Should it 
be 'false-blk? Or should both UNLESS and IF call it 'then-blk?

Good catch, `then-blk` sounds fine to me.

For conditionals, do you want to use TRUE as a shortcut? Rather than...

 "If condition is not FALSE or NONE ..."

 "If condition is not TRUE ..."

Let me see...

The shortcut version looks better.

OK.

Doc string question. Example:

if:	make native! [
	[
		"If	condition is TRUE, evaluate	block; else	return NONE."
		cond	 [any-type!] "Test condition."
		then-blk [block!] "Block to	evaluate."
	]
	#get-definition	NAT_IF
]


1) For simple funcs, do we want to include doc strings for params 
that seem self-explanatory?


2) Do we want to include periods at the end of param doc strings? 
REBOL includes them for function doc strings, but not param doc strings 
(it seems).

A simple suggestion: instead of "is TRUE"  I would suggest to use 
"is true" meaning anything distinct from FALSE and NONE.

1) Probably not.


2) No need to add dots everywhere, we can add them when rendering 
the doc-strings where adequate.

is true
 +1

Right, what I meant was that LOOP, being dialected, could easily 
localize the counter word.

Indeed, and it can already be done easily:

f: function [] [repeat i: 5 [print i]]
f

f: function [] [foreach i: [1 2 3] [print i]]
f

Gregg, thanks for working on the doc strings

I still prefer having FUNCTION take care of it and using simple word! 
values, else it looks odd and misleading (i: 5 looks like one expression, 
while it is two expressions in fact).

Same for i: [1 2 3].

Nice trick anyway. ;-)

I know, but I still think it's a fairly good compromise

Have you tried it in interpreter?

Yes, haven't checked the compiler

REBOL uses a dot when it's a full sentence, which is usually the 
case for the function description, but not for parameter descriptions

Is it correct to state that FUNCTION automatically localizes all 
refinement, get-word, and set-word values found in the function body? 
And that is all that makes it cifferent than FUNC?

If so, since I don't know, why not just set-words?

Or, rather, why all word types except word?

Have you tested that? As far as I know, it only adds set-words to 
the arguments and refinements

I haven't. I looked at the code.

Will have to wait until Doc rises again :-)

Shouldn't you be sleeping too? ;-)

Erm, yes

A lot of doc strings talk about "evaluating", which is a long word. 
Is it less clear, or less correct, so use "do" instead, at least 
in most cases?

function localizes only set-words. (refinements are local by default)

Gregg: only set-words are localized. What you saw in _function/collect-words 
is the the conversion of spec block elements to words for the ignore 
list. The collection of words from body block happens in collect-deep.

Thanks for clarifying Doc.

In %boot.red, SET's word arg is typed as any-word!, but it accepts 
a block of words. Should the type be [any-word! any-block!] ?

Right, but just block!.

OK.

Do you think we should allow paren! too?

R3 doesn't allow it.