World: r3wp

you can't really catch all possible variations of things like: do 
reduce [ to-set-word "tadam"  44]

You can since R3 words are not bound by default.

no I have so litle time to play with R3... I barely have time to 
chat here...  life, work, kids, music, glass, et al... life is full 
enough withough R3 yet  ' :-/

Some of the asserts are commented out in the release version, but 
all testing is done with all asserts enabled.

wow, that's a pretty massive func!  :-)

I wrote it last weekend.

Though some of it was around before from my previous versions.

I guess a lot of what load used to do is now in the transcode native?

what!!  a command version!?!?   ;-)

{Force file to be a dynamic library. (Command version)}

Yup. And also some stuff that R2's LOAD never had.

No command version. That is just a reminder.

reminder of rebol's past?

Neither of those options will ever be in LOAD again, I think.

/unbound   YAY!

Reminder of missing functionality that will need to be implemented 
somewhere. Untiil last weekend, /next was commented out too.

does load/header/next only give back a header object?

If you read the source you might notice that if you don't specify 
/unbound, the code has to *explicitly* bind the loaded code.

LOAD/header/next gives back [header-object [the rest of the code]]

The /header and /next options are *much* stronger in R3.

cool... I've had issues in the past with them. :-)

LOAD/next %dir/ gives you [%file1 [%file2 %file3 ...]]

Also, the "required" REBOL header isn't so required anymore :)

LOAD/header %file.jpg returns [default-header-object image!]

LOAD makes interesting reading.
(I don't like the meaningless name of the TMP variable.)

strange although symmetric.

wrt "If you read the source you might notice that if you don't specify 
/unbound, the code has to *explicitly* bind the loaded code."  

didn't you mean IF you specify /unbound   ?

What I don't like is the 'val variable - I'm goinng to rename it 
to 'hdr next version.

That would be a good change.

yeah... I guess its val for historic reasons.

Uh oh - I've just noticed TMP is being used for different purposes. 
It's meaning is different at different parts of the function, making 
it harder to understand and reason about the function.

brian, still a bit puzzled by you last /unbound comment

possibly just optimisation of recycling words, not to clutter up 
the number of locals for nothing?

Yes, but cluttering up our heads with a muddle of confusion instead.

I think it's inexcusable in this context.

(That's a bit of a strong word. I should say the function should 
not be considered complete until such variable names are removed.)

No, to-block and transcode make unbound words. If you *don't* specify 
LOAD/unbound, LOAD won't bind the words, which it actually has to 
do explicitly with that BIND/new statement.

(sorry, went offline for a moment)

I do word recycling myself, but only in repeatedly used functions... 
but load being used just a few times per script, such optimisations 
seem a bit excessive, but then if that code was taken from Carl, 
he does pretty excessive optimisations all the time.

TMP is just that, a temporary variable. It has no special meaning 
that isn't mentioned in comments.

The code wasn't taken from Carl, I wrote it from scratch. I write 
LOAD.

Carl's code was less optimal.

hehe  carl's style is growing on you   ;-D

I've been the main writer of the non-GUI mezzanine changes for thhe 
last year. My code tends to be more strict than Carl's :)

I think VAL has a right to exist (with that name), because just after 
it is first set, you don't know whether it's a header block or not. 
You have to check. At the moment you have determined that its value 
is a script header, then you can do:

	hdr: val


which does mean you now have two locals, HDR and VAL, but I don't 
know any other way of preserving the clear and unambiguous meaning 
of a variable.

actually, most rebolers tend to grow the same habits in time :-)

If you think the code is bulletproof now, wait until after I do the 
ASSERT review of the entire codebase :)

BrianH, I'm very glad you put those comments around the use of the 
TMP variable. But keep in mind, when quickly checking the source 
of a function in the console, the comments are lost. Not very convenient 
for quickly understanding how something works and returning to your 
workflow.

I was going to ask what assert is about?

Well, this is one of those functions that *has* to be as bulletproof 
and efficient as possible. Even Carl defers to my judgement on LOAD. 
I try to make it easy to read, but there's no point about worrying 
about lost comments when the source is a CHAT 26 LF away.

ASSERT: http://www.rebol.net/r3blogs/0178.html