World: r3wp

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.

Brian, by separating words and data, do you mean this format ?
>> nforeach [a [b c]]  [[123][456789]]  [print [a b c]]

Yes, Steeve. The implementation wouldn't need DO/next at all, or 
anything like it.

Gabriele, if we had DO in PARSE we would still need DO/next. Just 
not for nforeach - neither DO/next nor DO in PARSE would be appropriate 
there. Nor would REDUCE be needed. All you'd need would be BIND/copy 
and SET, and some loop function.

We would probably want to skip the set-word behavior of R3's FOREACH, 
but if we need it it can be compiled - I did so for MAP in R2.

Gabriele, I'm having a little trouble finding your request for the 
DO operation in R3 chat, under the R3/Parse heading (28). I already 
added your DO proposal to the official Parse Proposals page months 
ago (with some semantic cleanup) but if you don't speak up in the 
discussion forum then I will have more trouble convincing Carl. Any 
requests for it here might as well be thrown away - they will be 
long gone before we get to PARSE.

Was lazzy, so  i made the nforeach brian's version.

nforeach: func [
	vars [block!]  data [block!] body [block!]
	/local ctx n 
][
	data: copy data
	vars: copy vars
	ctx: make object! 5

 forall vars [change/only vars bind/new to block! vars/1 ctx]   ;** 
 convert all vars to blocks of vars (set need it)
	while [
		n: 1
		also not tail? first data
		forall vars [

   poke data n skip set first vars pick data ++ n length? first vars
		]
	] bind/copy body ctx
]

this is Ladislav's function to find out if your PC is out.

get-nist-correction: func [/local nist-time cpu-time mjd hms] [
 nist-time: read daytime://time.nist.gov
 cpu-time: now

 parse/all nist-time [skip copy mjd 5 skip 2 thru " " copy hms 8 skip]
 nist-time: 17/Nov/1858 + to integer! mjd
 nist-time/time: to time! hms
 nist-correction: difference nist-time cpu-time
]

it basically parses the text string returned by the daytime server, 
and works out what utc is ( nist-time )

it then displays the difference between utc and your pc time.

now, when I set my pc clock to canadian time, or EDT ( -0400 ), on 
vista, Rebol says timezone is -3 and not -4

Dunno what it does in XP ...

anyway, now the nist correction is now 1 hour out :(

connecting to: time.nist.gov
== 0:00:03

XP x64

what time zone?

US Mountain time (-6:00 right now)

what happens if you change to EDT ?  Does Rebol report the time zone 
correctly?

on my system, with the patch installed yes.

(XP)

what patch?

the XP fixing of timezones...

if you have updates, it should have been rolled in a long time ago.

the tz rules have to be updated every few years...

it seems.

I'm on Vista

so are you at -3 or -4 now?

since vista crapped on reboot... I have turned away.  I mean destroying 
your own MBR while booting is a pretty bad bug... It was partway 
booting.

-4

Last year was the big TZ update here.

so I installed XP  (30 hours of work mind you)

Hmm..  so why when I change to canadian time in vista, does Rebol 
say I'm at -3 ?

when it normally takes me 1-2 hours...

EST?