World: r3wp

exactly.  this is dangerous.  cause someone might do:

REBOL [
	modifier: [val + 2]
]
and then your whole script crumbles.

for such a simple effect its trivial, but if you start using the 
header for code, it might become a habit and then you'll open a door 
you didn't realise.

can be as simple as a binding error, which uses a global value instead 
of a local one, and bam, instant very hard to tackle bug.

Although, it's an expression, but it could still be considered a 
setting.  Expecially if you trust the competence of the user...

in this simple case, its still pretty harmless, and you can still 
argue that its still a "setting", but I do think going to far is 
a dangerous can of worms.

rebol's binding and mutable series has a tendency to whip you in 
the face sometimes.  and a overly competer user might "assume" more 
than he should and create a bug he can't really understand.

I used to put history editing commands in the headers, and changed 
to a specification + data in the header, then parsed via a dialect. 
 seems cleaner and pretty in the end, and the user has to properly 
understand the spec in order to do anything, so its like forcing 
proper documentation and learning.

self-imposed order  ;-)

its also much easier to parse the header when there are only values, 
for any header management scripts.

It's certainly not something I would choose to do lightly (I wouldn't 
be asking if I didn't feel a little trepidation in using it), however, 
in REBOL, code is data, data is code.  It may well be a way to solve 
a certain problem...

I can see it being used properly for well documented call-backs.

lightly, or inappropriately.

Yes, that's kind of what I was driving at with Sample C...

Callbacks.  One instance I'm thinking of is to have a file containing 
only a parse dialect -- parse "text" load %rule.r -- and having some 
callbacks specific to the rule - eg. on-success and on-fail.  Feels 
like it could be a natural way to do it.

It aids one type of file maintenance - a folder full of parse rules...

But, yes, binding has to be apparent and understood in order not 
to screw up.

like a rejoin spec which builds the TD of table:

REBOL [

 news-spec: [foreach item news-list [append output rejoin [<TR> <TD> 
  <P class="news-title"> item/date ": " item/title </P> </TD> </TR>] 
 ]]
]

remarks v2 binds parse rules to html and functionally rebuilds a 
page, much like what you describe.

the rules are linked dynamically, so can come from anywhere.

The type and exports header fields are used by R3 modules, in much 
the same way as your's Chris. Same with Gabriele's modules. In general, 
it is best to not put executable code in a header unless it is executed 
by the script itself. Don't assume that any word values assigned 
to fields in the header will be bound at all in R3, let alone bound 
to the same context as your script. Dialect code should be OK to 
assign to header fields, as long as it is not executable code.

I don't put config data in headers, just metadata.

How to easily wait for a keypress in console? I used following code 
in a loop, but it wait only once:

press: open console://
wait press
close press

ah, we have 'ask function :-)

Pekr, if you need single keystrokes:

http://www.rebol.net/cookbook/recipes/0060.html

thanks! I just run some data printing in a loop, and I want to stop 
at each iteration, and press enter to get another row ... 'ask served 
very well for me ...

I am once again amazed with REBOL - I feel like king when working 
with csv. My parse/all item ";" is common idiom :-)

I wonder if we could have iteration via two blocks? I have two blocks 
- first with field names, second with values. I could write some 
map function and put it into object, but field names have spaces, 
so I did something like following:

stock: read/lines %stav-zasob.csv

forskip stock 2 [

  fields: parse/all stock/1 ";"
  values: parse/all stock/2 ";"

  i: 1
  foreach name fields [
   print [name ": " value/:i]
   i: i + 1
  ]

 ask "Press any key to continue ..." 


]

I wonder if we could make 'foreach to cycle in two arrays (blocks?) 
:-)

I've asked for this for R3 a long time ago, but I honestly forgot 
what came of it.

The problem here is, that traversing two blocks, what would be the 
policy (syntax), to set your variables?

http://www.rebol.net/wiki/Foreach

The problem is what to do when the sizes of the two blocks don't 
match.

I can also see a problem when you don't want to increment all blocks 
at the same time.

BrianH: it has to mach, or you end with the shortest one's end :-) 
.... hmm, I can imagine someone wanting quite the reverse (SQL LEFT 
OUTER equivalent) behaviour ...

it has to match

 - That's the problem. What happens if it doesn't? Is an error thrown? 
 Do you just go as far as you can? Do you fill in the missing data 
 with none placeholders (my preference)? This needs to be decided.

Ah, but this was not real feature request, was it? :-) It just was 
handy for me for this one case, dunno if it would be generally useful?

BrianH, we would have to handle each case specifically. Doing it 
"smartly" would be bad.

This function sounds more like MOVE than FLATTEN. We had a debate 
about both of those functions, and MOVE was included while FLATTEN 
wasn't. It all came down to three factors:
- Is this function generally useful, or would it be used rarely?
- Is there consensus about what it should do?

- Is the function so difficult to get right that it makes sense to 
include it for that reason alone?


In the case of MOVE and FLATTEN, both were considered useful, but 
only MOVE had consensus and was tricky enough to be worth including, 
especially since the features had to be carefully restricted for 
it to work safely. FLATTEN was considered useful, but no two people 
requested the same behavior, and every implementation was so simplistic 
that it was hard to get wrong.


This multi-series loop function seems more like MOVE in this regard, 
but only if we can agree on what it should do.

For one thing, it would not be FOREACH that does this - it would 
be another function.

Gabriele has an NFOREACH func that iterates over multiple blocks.

http://www.mail-archive.com/[rebol-list-:-rebol-:-com]/msg18682.html
http://www.rebol.it/giesse/utility.r

I was thinking that would make a good start, yes :)

Pekr, I was thinking that the outer join approach would fit in the 
best with the R3 treatment of series changes and none. There are 
fewer occasions where errors are triggered in R3, and those occasions 
are carefully chosen (except for bugs, of course).

btw, i had the same need than Pekr, several in the past. I think 
it's common pattern. should be studied IMHO.

the question might also be whether to include an NFORALL.

tried to made nforeach for R3: 
- missing do/next to evaluate functions in the data block

- probably speed optimizations can be made (not probably, certainly)

nforeach: func [
	data [block!] body [block!]
	/local vars
][
	vars: make block! (length? data) / 2
	data: copy data
	forskip data 2 [
		append vars data/1 			;* extract vars

  change/only data to block! data/1 	;* convert vars to block (if needed)

  if word? data/2 [poke data 2 get data/2];* get serie from word (do/next 
  much relevant if available) 
	]	

 vars: bind? first use vars reduce [vars]	;* create a context with 
 vars
	bind head data vars
	while [
		also not tail? second data: head data 
		forskip data 2 [
			poke data 2 skip set data/1 data/2 length? data/1
		]
	] bind/copy body vars
]

>> nforeach [a [1 2 3] [b c] [4 5 6 7 8 9]] [print [a b c]]
1 4 5
2 6 7
3 8 9

Nothing about a function like nforeach should require DO/next. If 
it does, that would be the first thing to fix.

The next thing to fix would be having the words and data interleaved 
- they should be separate for easier data processing.

Brian, right, if we had DO in PARSE, there would be no need for DO/NEXT.

If you prefer using 'a instead of a in the example above, thus being 
different from FOREACH, then you can just use reduce.