World: r3wp

I have done so in the past, specially for data files.

my own rule was, if its something you can edit and don't want to 
have to "look" for in the code, its ok.

its also (I find) a clean way of presenting end-user options to a 
script which shouldn't really be edited by the user.

So, like -- edit settings in the header, but don't touch the code?

(for your last example)

that's my way of seeing it

IMHO it should allow the user to "inject" code, unless its first 
parsed via a dialect.

oops  ...  should *NOT*

Eg:

	REBOL [
		factor: 1.5
	]

	multiply: func [val][val * header/factor]

yep... or default argument switches...

REBOL [
	verbose-lbl: ['error 'warning]
	confirm-deletes: true
]

....

But not:

	REBOL [
		modifier: [val ** 2]
	]

	multiplier: func [val] :header/modifier

That, I suppose, would depend on your target user?

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.