World: r3wp

wasn't there supposed to be kind of formatting dialect at one time? 
IIRC Carl never added it to rebol. Maybe 'form could be used even 
for joining, although its purpose is slightly different.

I think, there are more important issues than renaming rejoin

:-)

Well, I agree, but it's worth consideration when taking a break from 
work. Rejoin is pretty close to the core. So if we can improve it, 
that would be great.

as for us, there are no issues, unless we have something to test 
in our hands .... which seems being slipped to some late fall imo 
....

adjoin: func [
	data [block!] 
	/literal 
	/quoted 
	/local result
][
	unless literal [data: reduce data]
	result: copy {}
	foreach value data compose [
		insert tail result (
			either quoted [
				[rejoin [{"} form value {"}]]
			][
				[form value]
			]
		)
	]
	result
]
; test
adjoin []
adjoin [1 + 2 3 + 4]
adjoin/quoted [1 + 2 3 + 4]
adjoin/literal [1 + 2 3 + 4]
adjoin/literal/quoted [1 + 2 3 + 4]

conjoin: func [
	separator [string! char!] 
	data [block!] 
	/literal 
	/quoted 
	/local result process
][
	unless literal [data: reduce data]
	result: copy {}
	process: func [x] either quoted [
		[rejoin [{"} form x {"}]]
	][
		[form x]
	]
	unless empty? data [
		insert result process first data
	]
	foreach value next data [
		insert insert tail result separator process value
	]
	
	result
]

; this way inlines more code, could be faster
conjoin: func [
	separator [string! char!] 
	data [block!] 
	/literal 
	/quoted 
	/local result process
][
	unless literal [data: reduce data]
	result: copy {}
	process: func [code][
		compose/deep either quoted [
			[rejoin [{"} (code) {"}]]
		][
			[(code)]
		]
	]
	unless empty? data compose [
		insert result (process [first data])
	]
	foreach value next data compose [
		insert insert tail result separator (process [form value])
	]
	result
]

;test
conjoin "," []
conjoin "," [1 + 2 3 + 4]
conjoin/quoted "," [1 + 2 3 + 4]
conjoin/literal "," [1 + 2 3 + 4]
conjoin/literal/quoted "," [1 + 2 3 + 4]

Anton, I really don't see the need for having ADJOIN and CONJOIN. 
There is a lot of code repetition for little gain in expresiveness.

Besides enlarging the lexicon.

Also, your implementation is slower than DELIMIT, by an order of 
magnitude.

>> time-block [conjoin "," []] 0.05  ;
== 4.953515625E-5

>> time-block [delimit/with [] ","] 0.05  ;
== 2.453125E-6

to-string does joining already, but not reducing. How about restring? 
Looks ugly, but clearer?

I like conjoin, although I'd put the delimeter after the data block. 
I don't like restring as I'd use this to build blocks too.

Jaime, I think my second version of conjoin performs much better 
with non-empty input blocks. :)  I don't see how my inlined code 
can be slower than your function call overhead, except for very short 
input data.

I still feel I would enjoy having two functions here (adjoin, conjoin), 
so I think we just have to agree to disagree. It is a matter of taste. 
But, since there are benefits and advantages to each choice, and 
the choices are closely matched (to my eyes, at least :), then it 
does not matter which we choose. Flip a coin, or keeping arguing 
until the other guy gets tired. :)

When I said I like conjoin, I meant the word "conjoin". I think it 
woud be a good name for the ONE function that would perform a useful 
subset of all of the tasks that have been specified here as part 
of the various functions suggested here, starting with Jaime's delimit, 
but with the delimiter mandatory. We already have a verson of delimit 
without the delimiter - it's called rejoin.

Yes, actually my ADJOIN doesn't look as useful as my CONJOIN; it's 
quoted refinement would probably not be useful as is. It can be improved 
but since CONJOIN does everything, maybe better ADJOIN be dropped.

In particular, I would need to be able to process blocks or lists 
or some such and have results of the same type. Basically the same 
behavior as rejoin, but with a delimiter. "Conjoin" means "join with". 
That /quoted refinement seems interesting though, when you are conjoining 
strings.

To me, delimit would intersperse the delimiter in the block but not 
join it. That what the word suggests, at least.

Anton, I'd drop the word "adjoin" because it means basically the 
same thing as "join".

Jaime, your /reduce refinement would seem to be less efficient than 
reducing the data before passing it to your function, by one comparison.

CONJOIN is good, and Brian maybe  right regarding droping the reduce 
refinement. So that [conjoin/reduce...]  becomes the idiom [conjoin 
reduce ...]

One thing though Ladlislav is suggesting to remove REJOIN.

Either by replacment or renaming.

So the suggestion of globing all the DELIMIT features into the new 
function.

Right, otherwise you are adding a comparison nd a path decode to 
every conjoin/reduce call.

I am currently rewriting delimit and conjoin to implement a few of 
my own ideas for it. You do yours and we'll compare.

As far as I'm concerned, delimit and conjoin are separate concepts.

I wait an see yours. In my opinion the are just one. They basically 
join values into a string, with a maybe some delimiter in between. 
Default behaviour doesn't adds anything.

Like I said before, the word "delimit" doesn't imply joining, while 
"conjoin" does. I'm expecting to make my conjoin function use my 
delimit.

(I'll be back in a bit - must help with diagnosis of electrical problems...)

Oh. I am not arguing about the name. I am like the CONJOIN choice.

Hw about replacing 'rejoin with 'join and rename 'join to something 
else? Maybe a name for joining two things is easier to find?

We have also the issue if  the joins should return a string all the 
time. We could use old 'join for typed joins, by gibing the type 
as the first argument, and 'rejoin always returns a string. then 
it would be called 'join and join something with type in the name, 
join-as or something.

join-as tcp:// [host ":" port]

mybe allow datatypes too, join-as url![ "http://server/"rel-path]

Volker, joins don't return strings all of the time, they return series. 
If the first value is a series, the result will be a series of the 
same type. Since your urls there are series types, join will join 
them as-is.

I know, but there was some talk to enforce strings because that is 
by far the typical usage.

And if you need the old, source is in rebol2 :)

Strings are not the typical usage for me. I saw those functions posted 
above and none of them would work for me. I'm writing my own right 
now, for posting here. I have delimit so far, and am now working 
on conjoin.

I'm trying out a new control flow technique that is really fun to 
use, and devilishly efficient.

As an example, here is delimit. I'll post conjoin soon.

delimit: func [
    "Put a value between the values in a series."
    data [series!] "The series to delimit"
    delimiter "The value to put into the series"
    /only "Inserts a series delimiter as a series."
    /copy "Change a copy of the series instead."
] [
    while either copy [
        copy: make data 2 * length? data
        either empty? data [[false]] [[
            copy: insert/only copy pick data 1
            not empty? data: next data
        ]]
    ] [
        copy: data
        [not empty? copy: next copy]
    ] either only [[
        copy: insert/only copy delimiter
    ]] [[
        copy: insert copy delimiter
    ]]
    head copy
]

Note that the options build the while statement without using compose, 
that no blocks are rebound, and that delimiter can be a thunk.

This is an excellent example of the kind of code that would be really 
difficult to compile, but is really fast to interpret. :)

It could be tightened up a little in the empty data case, so I'm 
going to do that and post it again when I post conjoin.

I would classify this into obscure Rebol. But it does the job ;)

Some benchmarking should be done to see how much speed it is actually 
gained, while trading for clarity.

BTW not using the /copy is not changing the series directly.

Sorry bad testing on my part.

Well, it will be a little hard to check against your delimit since 
that will be more comparable to my conjoin. Still, building the while 
statement this way is no slower than calling one of several different 
while statements depending on options, and it is a lot less redundant. 
Plus it's fun.

Here's a slightly faster version: