r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

BrianH
14-Sep-2006
[1434]
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.
Anton
15-Sep-2006
[1435]
By "better at dataset export", do you mean retaining the structure 
(sub-blocks etc.) of the input?
BrianH
15-Sep-2006
[1436x2]
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.
Anton
18-Sep-2006
[1438x3]
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 ?
Ladislav
18-Sep-2006
[1441]
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.
Volker
18-Sep-2006
[1442]
i do not like that a break can break function-nesting.
Ladislav
18-Sep-2006
[1443]
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.
Volker
18-Sep-2006
[1444]
except for control-structs, as it is now. and that should break the 
control-struct, so not lexically.
Ladislav
18-Sep-2006
[1445]
Volker: regarding the [throw] function attribute - it is not able 
to influence to which loop the BREAK belongs
Volker
18-Sep-2006
[1446]
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?
Ladislav
18-Sep-2006
[1447]
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
Volker
18-Sep-2006
[1448x2]
f: func[][break/return 2]
probe loop 1 [probe f]
Hmm, no error. I do not like that.
Ladislav
18-Sep-2006
[1450]
:-)
Volker
18-Sep-2006
[1451x4]
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..
Ladislav
18-Sep-2006
[1455]
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
Volker
18-Sep-2006
[1456x2]
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 :)
Ladislav
18-Sep-2006
[1458]
yes
Anton
18-Sep-2006
[1459x2]
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 ?
Ladislav
18-Sep-2006
[1461]
1 = loop 1 [
			f: does [break/return 1]
			f
			2
		]
Volker
18-Sep-2006
[1462x2]
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)
Ladislav
18-Sep-2006
[1464]
regarding optimization: for the interpreter the dynamic way is faster, 
but it leads to "unexpected effects" sometimes as I and Volker agreed
Anton
18-Sep-2006
[1465]
What is wrong with the control-struct-test example ?
Ladislav
18-Sep-2006
[1466x2]
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
Anton
18-Sep-2006
[1468x2]
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.
BrianH
18-Sep-2006
[1470]
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.
Ladislav
18-Sep-2006
[1471]
Brian: the problem is not with the function, the problem is with 
loops - the loop should either pass along break or not
BrianH
18-Sep-2006
[1472]
Sorry, I get it now. I was mixing up break and return.
Ladislav
18-Sep-2006
[1473]
the code is complicated, sorry ;-)
BrianH
18-Sep-2006
[1474]
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.
Ladislav
18-Sep-2006
[1475]
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
BrianH
18-Sep-2006
[1476]
What's the problem with using the real throw function here?
Ladislav
18-Sep-2006
[1477x2]
the real throw function does not pass along BREAK
(I just want to have one cycle function able to pass along BREAK 
when needed)
BrianH
18-Sep-2006
[1479]
Can you use the same solution that throw/catch uses to handle the 
same problem, naming the destination that you are breaking to?
Ladislav
18-Sep-2006
[1480]
no, because in the case I am programming a control function I do 
not want to force the users to specify the destination just because 
they are using my control function
BrianH
18-Sep-2006
[1481]
There are function attributes to prevent a function from catching 
a return or throw, should there be one for break?
Ladislav
18-Sep-2006
[1482]
no, because this is a loop business, function attributes cannot help
Anton
18-Sep-2006
[1483]
I understand. That sounds like the way to go.