World: r3wp

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

thx

You appear to be doing a very good job of it, overall, don't get 
me wrong. I wish you'd see my point of view with respect to other 
(future) users who will view the code in the console, not in some 
source file locatable somewhere if you're lucky and the RebDev chat 
server is still running.

DevBase is where the source will be, with full history. It's one 
of the primary features of R3. It's not going away.

I mean, we'll probably have source packages and we will have DocBase 
and the manual, but DevBase is where the source is.

what does assert return when all is ok?  true?

Yes. If it's not OK it throws an error. After an assert you can count 
on the conditions being true.

is there a none returning version of assert... a bit like first vs 
pick ?

all intersting stuff btw.

Yeah. ALL.

And FIRST returns none in R3. We're trying to make the errors more 
useful and meaningful in R3.

that would mean less errors? but better ones?

Yup :)

cool.

does ALL also support the /type refinement in R3 ?

now you see... I'm all fired up on R3 and I've stoped working for 
the past hour.... ;-)  glass is now an hour behind schedule ;-)

Nope, but SWITCH TYPE?/word does (effectively).

Or FIND typeset! value.