World: r3wp

I think functions that are used very often with certain combinations 
of refinements ought to be split.

That can be changed easily.

If we make the right decisions about which functions are important 
enough to have their own word, we free ourselves with clearer code 
etc. Imagine if there was no DO function, but that functionality 
was a refinement of LOAD or REDUCE   --->    We would write REDUCE/DO 
 all the time.

The default behaviour could be to reduce.

That might be an idea. Closer to current rebol behaviour too.

delimit [1 1 / 2] ;== "10.5"
delimit/literal [1 1 / 2] ;== "11/2"

Yes, I think that's better. That refinement is the "weakest" of the 
three.

Please excuse me if I'm a little hazy today. Feeling a bit quantum 
mechanical today.

I like 'conjoin

anton, don't go phase into higher dimensions jus yet. :-)

it is ... too late... for me...

but then also think about form vs reform

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.