World: r3wp

conjoin inserts delemiters too, did i get that right? How about a 
simple 'list, i feel its a good match, listing things. But not native 
speaker.. Another idea: it icould be related to csv (this spreadsheet-format, 
got i the letters right), a conjoin is close to exporting?

we have already list-dir, so list is a good match imo ...

The word "concat" is usually used for a function similar to join 
rejoin.

The word "conjoin" means "join with", and is the shortest appropriate 
word we could come up wth for the concept of joining with delimiters.

We were thinking of CSV files when we added the /quoted refinement, 
but the conjoin function could probably be refined to be better at 
dataset export.

By "better at dataset export", do you mean retaining the structure 
(sub-blocks etc.) of the input?

Well, REBOL blocks can double as datasets, with either nested blocks 
or fixed-length records. You could probably do a variant on conjoin 
that could convert either of these types to a CSV file, even with 
one that has its records delimited by something other than a comma, 
like a tab. Creating a new function to do this based on the techniques 
in conjoin would currently be easier than using conjoin to perform 
this task.

On the other hand, if you don't want a full copy of the CSV fie in 
memory and would rather just convert to disk, conjoin should work 
just fine. It might be a good idea to add a /part option for fixed-length 
record blocks.

Ladislav wrote:
what would you prefer this expression to return, 1 or 2?:

		loop 1 [
			f: func [x] [
				either x = 1 [
					loop 1 [f 2]
					2
				] [break/return 1]
			]
			f 1
		]

Ladislav, I'm not sure what the main question is. Could you explain 
the control flow that would lead to a 1 result ?

Are you wondering if BREAK/RETURN should break out of the outer loop 
as well as the inner loop ?

if I take the BREAK/RETURN above lexically, then it does not "belong" 
to the loop 1 [f 2] loop but rather to the loop 1 [ f: func ...] 
loop. This approach is called lexical binding and leads to 1 being 
returned as the result.

i do not like that a break can break function-nesting.

If I take BREAK/RETURN "dynamically" - i.e. when did it occur, it 
"belongs" to the loop 1 [f 2] and therefore the dynamic approach 
leads to 2 being returned as the result.

except for control-structs, as it is now. and that should break the 
control-struct, so not lexically.

Volker: regarding the [throw] function attribute - it is not able 
to influence to which loop the BREAK belongs

I see 'break and 'return as kind of catch/throw. So to me its clear. 
But i may miss something. The old way to build
  my-loop[break]
would still work lexically?

i do not like that a break can break function-nesting.

 - you can always "break out of a function", unless the BREAK implementation 
 is faulty

f: func[][break/return 2]
probe loop 1 [probe f]

Hmm, no error. I do not like that.

:-)

If i want to obfuscate things, i remember that..

In that case lexically could make sense. Easier to see what is broken.

But it would break cleanup-code?

But the current way does too..

except for control-structs, as it is now. and that should break the 
control-struct, so not lexically.

 - actually, in case of control-structs what you really want is lexical 
 break as you pointed out above and as can be demonstrated by:


    control-struct-test: func [control-struct [any-function!] code [block!]] 
    [loop 1 [control-struct code 2]]

>> control-struct-test :do [break/return 1]
== 1

I think lexically. if i pass a closure with a break, it should at 
least break into my code, and not inside some foreign code where 
it creates havoc.

we typed the same conclusion at the same time :)

yes

I am happy with break breaking functions.

I like the dynamic way, but maybe there is some compiler-optimization 
possible when doing it the lexical way ?

1 = loop 1 [
			f: does [break/return 1]
			f
			2
		]

But we need a way to enforce cleanup? something like 'finally? If 
a module provides an
  open-do-close [my-code]
my code should not be able to avoid the close?

(independend of the scroping-question, the current way is broken 
too)

regarding optimization: for the interpreter the dynamic way is faster, 
but it leads to "unexpected effects" sometimes as I and Volker agreed

What is wrong with the control-struct-test example ?

Nothing, it just demonstrates, that we may lexically expect 1 to 
be the result, but what if somebody did:

    my-control-struct: func [code] [loop 1 code]
>> control-struct-test :my-control-struct [break/return 1]
== 2

so in REBOL2 we cannot (at least not in a simple way) use loop when 
implementing a control struct

Seems to me to be just one of the side-effects of dynamic code.

I see the problem, but I am just cautious of making just one part 
of rebol non-dynamic.

So, you aren't specifying that your function f should pass along 
breaks, and you want it to pass along breaks? Even lexically the 
break is inside the f function, not the outer function. I don't get 
it, Ladislav.

Brian: the problem is not with the function, the problem is with 
loops - the loop should either pass along break or not

Sorry, I get it now. I was mixing up break and return.

the code is complicated, sorry ;-)

I would normally be on the side of dynamic break - it would be easier 
to teach, and the rest of REBOL follows that model. What would be 
the major advantage of lexical break in a non-compiled language? 
REBOL code blocks aren't really lexically associated with their control 
structures in the DO dialect, as my conjoin and delimit functions 
above demonstrate. This isn't rebcode you know.

right. OK, in case we will use dynamic BREAK in REBOL3 (highly probable), 
I will propose to introduce a new /THROW refinement for the WHILE 
cycle to "pass along" BREAK and that is all

What's the problem with using the real throw function here?

the real throw function does not pass along BREAK

(I just want to have one cycle function able to pass along BREAK 
when needed)

Can you use the same solution that throw/catch uses to handle the 
same problem, naming the destination that you are breaking to?