World: r3wp

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.

my first R3 func ....   valid?: func [spec][attempt [assert spec]] 
  ; -)

so I can assert within any/all blocks  ;-)

valid?: func [spec /type][attempt [apply :assert [:spec type]]]

yess apply that is a great addition to R3   8-D

Already backported to R2-Forward.

must be a bit slow though... is it?

R2-Forward is also in DevBase (and has *lots* of comments).

The R2-Forward APPLY is not as fast as the native, but I've found 
it fast enough for wrapper functions in R2.

Plus it disables the special treatment of 'a and :a declared parameters.

is that gone in R3?  (set word arguments)

Nope, they just work better.

Don't forget to keep it simple! As simple as possible, but not simpler.

Is there a way in R3 to "capture" error messages when using ATTEMPT, 
or some other command.
i.e.
>> WRITE %missing/File.txt to-binary "test string"
** Access error: Cannot open: %missing/File.txt reason: -3
** Where: WRITE
** Near: WRITE %missing/File.txt to-binary "test string"

>> ATTEMPT [WRITE %missing/File.txt to-binary "test string"]
== none

Is there any way to get the error message from the ATTEMPT?

Found it!

>> probe disarm try [WRITE %missing/File.txt to-binary "test string"
make object! [
    code: 500
    type: 'Access
    id: 'cannot-open
    arg1: %missing/File.txt
    arg2: -3
    arg3: none
    near: [WRITE %missing/File.txt to-binary "test string"]
    where: [WRITE try]
]
== make object! [
    code: 500
    type: 'Access
    id: 'cannot-open
    arg1: %missing/File.txt
    arg2: -3
    arg3: none
    near: [WRITE %missing/File.txt to-binary "test string"]
    where: [WRITE try]
]