World: r3wp

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 :-)

I think that thw word GLUE would be better for joining objects together, 
than joining series like strings

But 3 people, who are not english natives, should not decide, which 
english names should be used:-))

I'll add a fourth non-english native; rejoin is fine with me, wasy 
to remember as reduce-join.

I had a few problems with 'join and 'rejoin in the beginning because 
I somehow expected them to be a bit like form and reform, using the 
same arguments as input. That's of course not logical, but I think 
that the 'word and 're-word naming of functions, doesn't entirely 
fit and actually limits the naming scheme, making it a disadvantage 
rather than an advantage.


Does 'recycle have anything to do with 'reduce? Or 'remove? No. One 
might think up a 'move function that does 'reduce. That would clash 
with 'remove, but 're- has two different meanings.


Words in rebol usually have sensible naming, something you can pick 
out of the dictionary and it'll make sense, except for those with 
're- in front of them. If you take them out of context and try to 
explain them, you have to know about 'reduce, but the dictionary 
meaning of the 're- words is something different. I don't have any 
suggestions on how to change this though, other than add a dash: 
re-form, re-join, re-mold...:-)

Which brings me to another topic: dash.


This can be a little painful in text editors, because a dash usually 
always has arithmetic meaning, no matter where you write it in other 
languages. But in REBOL, dashes not prefixed and postfixed with a 
space, have the same meaning as underscore or other word separation 
character. This means that in text editors, I can't double click 
to select a word and probably more importantly for some code editors, 
I can't autocomplete the word. Of course I could stop using dash 
myself, but there are a lot of system words with dashes in them, 
such as 'sendmail-pref-file or 'dsa-verify-signature.


So I sit in the code editor and type. But was it 'verify-dsa-signature 
or 'dsa-verify-signature? Darn it, have to look it up, because the 
text editor can't complete the word!

How about taking a page from Andrew Martin's book: rename REJOIN 
-> JOINS ? ie.  JOIN joins two arguments, JOINS joins any number 
of arguments.
Or it could also be ENJOIN (N-JOIN).

I think the Francophones would also like ENJOIN.

Why not simply get rid of rejoin and replace for the more useful 
DELIMIT?

delimit [1 2 3] ;== "123"
delimit/with [1 2 3] "," ;== "1,2,3"
delimit/quoted 
[1 2 3] ;== {"1","2","3"}
delimit/quoted/with [1 2 3] "|" ;== {"1"|"2"|"3"}

npa: 
703
nxx: 938
delimit [npa nxx] ;== "npa nxx"
delimit/reduce [npa 
nxx] ;= "703938"
delimit/reduce/with [npa nxx] "-" ;== "703-938"
delimit/reduce/quoted/with 
[npa nxx] "|" ;== {"703"|"938"}

Sorry for that it drives me nuts that Altme in OSX doesn't preserve 
newlines.

;; usage examples

delimit [1 2 3] ;== "123"
delimit/with [1 2 3] "," ;== "1,2,3"
delimit/quoted [1 2 3] ;== {"1","2","3"}
delimit/quoted/with [1 2 3] "|" ;== {"1"|"2"|"3"}

npa: 703
nxx: 938
delimit [npa nxx] ;== "npa nxx"
delimit/reduce [npa nxx] ;= "703938"
delimit/reduce/with [npa nxx] "-" ;== "703-938"
delimit/reduce/quoted/with [npa nxx] "|" ;== {"703"|"938"}

;; Here is my implementation, maybe in can be fine tuned.


delimit: func [data [block!] /reduce /quoted /with separator  [string! 
char!]  /local result quote][
  unless empty? data [
    result: copy {}
    unless with [separator: ""]
    quote: either quoted [
        func[x][rejoin [{"} x {"}]]
    ][
        func[x][x]
    ]

    insert result quote form either reduce [do first data][first data]
    foreach value next data [

    insert insert tail result separator quote form either reduce [do 
    value][value]
    ]
    result
  ]
]

It looks like a very fine function - *except* I would name it differently 
(I prefer GLUE).

I think the form use to produce the  reduce effect is incorrect. 
Most probablay it needs to written using DO/NEXT.