World: r3wp

Must think about that.

I should not that I am not attached to DELIMIT. It stated like with 
a different purpose, but now I see that is more generic than REJOIN. 
So I offer it after modifying it a bit.

I like the CONJOIN word.

Currently we use REJOIN for most things, and sometimes we miss being 
able to add delimiters, after that, the next functionality is probably 
the quoting.

But CONJOIN is not very common. I thinkn CONCAT will be more mnemonic 
for newbies.

Picking names is very hard. I kind of like to have all the functionality 
cram in one function, less words to remember. So I left the naming 
decision to the community, just hope the features of delimit are 
include in R3.

So I would drop the /WITH refinement and make it implicit in a DELIMIT 
or CONJOIN function... (maybe..)

1) rejoin/quoted [...]   ; <-- this is most similar to rejoin, or 
delimit without the /WITH

2) conjoin/quoted "," [...]    ; <-- this is like delimit/with/quoted 
 (and the non-optional "with" argument is specified first)

I dislike CONCAT because it is an abbreviation.

me too, but a lot of people knows it.

I am not sure I follow your points.

The first function, REJOIN, is like the current rebol REJOIN, except 
it now has your /QUOTED refinement.

I don't really see the reason for splitting features of the function.

The second function, CONJOIN, is like your DELIMIT, except with WITH 
refinement implicit.

I think is better to keep Rebol's lexicon short.

I think the /REDUCE refinement usually isn't needed (I could be wrong), 
because if you are not going to reduce the block then you already 
know what the result is.

>> delimit [1 1 / 2 ]  ;
== "11/2"

>> delimit/reduce [1 1 / 2]  ;
== "10.5"

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.