World: r3wp

the repeat version, as this is what I would expect and call intuitive 
... the word 'i gets bound to the block and is always being reset 
- so an infinite loop 


so 'for seams to not care or at least keeps the state of 'i for it's 
own purposes - how should a user know this, even though some assignment 
like this might flag in most cases a programming error (and in the 
other case in a for loop one can't manipulate the state of 'i explicitely)

I would definitely prefer that 'i is bound to the block. You might 
want to do adjustments to 'i during the loop, although I don't really 
use that, but sometimes it can be useful with variable stepping or 
resetting.

Yes I prefer repeat too, (my initial thought, at least).
Were the bugs/issues with FOR ever fixed ? I can't remember now.

I also vote for the REPEAT behaviour.

Were the bugs/issues with FOR ever fixed ?
 - no

and will there be? :-)

maybe ;-)

well, surely, such thing is not main priority in such big task as 
R3 is :-)

Silly idea: how to use 'protect for the loop-var? is that to expensive?

I would like to know the difference between action! and native!. 
Thanks!

In Carl's REBOL 3 Blog Article #0039, he says that the ordinal functions 
(first, second, ...) are of the action! type in REBOL 2, and will 
be of native! type in REBOL 3.

actions are like "methods" (if you are familiar with OOP languages) 
for values.

i.e. insert series value is like  series.insert(value) in oop languages.

and series.insert(value) will not be true in the native instead of 
action type?

a native is more like a C function, an action is more like a C++ 
method. anyway it's mostly an implementation detail.

the distinction will make more sense once we get custom types.

so no speed differences?

what do you think about this:

    repeat i 3 [probe i i: "a"]

ladislav, I think that's OK. interestingly, you can skip with decimal! 
values to make a smaller step than 1. I noticed two funny things 
though:

>> repeat i 3 [probe i i: i - 0.5]
1
0.5
1.11022302462516E-16
-0.5
-1.0
-1.5
-2.0
-2.5


One is that 0 isn't exactly zero and the other thing is that it counts 
to the absolute value of 'i

funny, indeed

actually the "0 isn't exactly zero" says something else - there is 
an error in the computation, which is expectable e.g. for 0.3 - 0.1 
- 0.1 - 0.1 (binary floating point numbers cannot represent 0.1 exactly), 
but is not expectable for 1 - 0.5 - 0.5 , because such numbers are 
exactly representable using binary floating point

Humm. I don't like it. It violates  the contract for REPEAT.

USAGE:
   
	 REPEAT 'word value body

 

DESCRIPTION:
     
	Evaluates a block a number of times or over a series.
	REPEAT is a native value

.

ARGUMENTS:
	word -- Word to set each time (Type: word)
     

 value -- Maximum number or series to traverse (Type: integer series)
 
  ;;;;; This part of the contract is being broken by the example. 
  
	body -- Block to evaluate each time (Type: block)

In my opinion Rebol should prevent the programmer  from shooting 
himself in the foot.  Also there are other forms such as FOR and 
WHILE that can be used for loops with variable steps. Maybe CFOR 
should be added to the core language.  


The problem with [ repeat i 3 [probe i i: i - 0.5]] is that it obscures 
the intention of the programmer. Does he wants to iterate 3 times, 
or more? This is not clear with such code.

yes, Jaime, the example may be named "how to shoot yourself in the 
foot using REPEAT"

Henrik: well, actions need to look into a function table, but natives 
probably need to check the type. unless the code for the action/native 
is very small the speed difference is probably unnoticeable.

this is "a bit problematic":

all [true ()]
all [() true]

any thoughts?

actually, it *is* consistent, it only does not cooperate well with 
IF

>> true = all [true ()]
** Script Error: Operator is missing an argument
** 
Near: true = all [true ()]
>> true = all [() true]
== true

>> true = all [true ()]

** Script Error: Operator is missing an argument

** Near: true = all [true ()]

>> true = all [() true]

== true

Hmm. Why the breaking of symmetry?

IMHO the behaviors should be consistent.

It also seems that in the first case "all [true () ]" is not escaped 
after the first valid predicate and the parens are still evaluated 
which sort of explaings the error because unset! is returned. Maybe 
we need too allow do [()] should return none instead of unset!.

After some thoughts the breaking of symmetry is valid in this case. 
Still the error thrown due to the return unset! value is missleading.

Maybe unset! should be expelled from the  ALL and ANY natives. After 
all there is not much that you can do with unset!, but expelling 
it is going to be hard. Lad, I am curious about your opinion.

I think I'm happy with ALL and ANY as is.

Of that repeat example:   repeat i 3 [probe i i: "a"]

I think that repeat must be checking the datatype and breaking when 
it is wrong (ie. false = integer? "a"). This can be seen as protecting 
the user from infinite loops caused by such user mistakes. Jaime 
is right that this behaviour has not been written into the function 
description, though.

repeat i 3 [?? i i: 3.0]   ; different datatype, decimal instead 
of integer

My point of view is, that in this case REBOL behaves as Weakly Typed 
Language, because REPEAT considers any value to be integer.

Anbody with an inspiration having a perfect (or at least better) 
name for REJOIN?

why? maybe GLUE?

Re REPEAT once again - I should rather have said, that REPEAT was 
Type Unsafe in this case

GLUE - sounds interesting

but what's wrong with REJOIN?

why give rejoin different name? it is reduce join after all? Well, 
I know that "rejoin" sounds like once again joining something, but 
maybe re-join

not much except for the fact, that beginners don't know what it means

reduce-join

not short, but clear ...

I like REJOIN and never had problem to understand what it means and 
I don't like longer name for it, I write it too often

if we think in an object method/action fashion, it could be element.reduce 
element.join (or element.add) - simply it is not typical that you 
combine two methods in one ...

but JOIN is reducing as well
>> a: 1 b: 2 join "x" [a b]
== "x12"

interesting :-)