r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

BrianH
3-Apr-2009
[12562]
You can since R3 words are not bound by default.
Maxim
3-Apr-2009
[12563]
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  ' :-/
BrianH
3-Apr-2009
[12564]
Some of the asserts are commented out in the release version, but 
all testing is done with all asserts enabled.
Maxim
3-Apr-2009
[12565]
wow, that's a pretty massive func!  :-)
BrianH
3-Apr-2009
[12566x2]
I wrote it last weekend.
Though some of it was around before from my previous versions.
Maxim
3-Apr-2009
[12568x2]
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)}
BrianH
3-Apr-2009
[12570x2]
Yup. And also some stuff that R2's LOAD never had.
No command version. That is just a reminder.
Maxim
3-Apr-2009
[12572]
reminder of rebol's past?
BrianH
3-Apr-2009
[12573]
Neither of those options will ever be in LOAD again, I think.
Maxim
3-Apr-2009
[12574]
/unbound   YAY!
BrianH
3-Apr-2009
[12575]
Reminder of missing functionality that will need to be implemented 
somewhere. Untiil last weekend, /next was commented out too.
Maxim
3-Apr-2009
[12576]
does load/header/next only give back a header object?
BrianH
3-Apr-2009
[12577x3]
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.
Maxim
3-Apr-2009
[12580]
cool... I've had issues in the past with them. :-)
BrianH
3-Apr-2009
[12581x3]
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!]
Anton
3-Apr-2009
[12584]
LOAD makes interesting reading.
(I don't like the meaningless name of the TMP variable.)
Maxim
3-Apr-2009
[12585x2]
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   ?
BrianH
3-Apr-2009
[12587]
What I don't like is the 'val variable - I'm goinng to rename it 
to 'hdr next version.
Anton
3-Apr-2009
[12588]
That would be a good change.
Maxim
3-Apr-2009
[12589]
yeah... I guess its val for historic reasons.
Anton
3-Apr-2009
[12590]
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.
Maxim
3-Apr-2009
[12591x2]
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?
Anton
3-Apr-2009
[12593x3]
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.)
BrianH
3-Apr-2009
[12596x2]
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)
Maxim
3-Apr-2009
[12598]
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.
BrianH
3-Apr-2009
[12599x3]
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.
Maxim
3-Apr-2009
[12602]
hehe  carl's style is growing on you   ;-D
BrianH
3-Apr-2009
[12603]
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 :)
Anton
3-Apr-2009
[12604]
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.
Maxim
3-Apr-2009
[12605]
actually, most rebolers tend to grow the same habits in time :-)
BrianH
3-Apr-2009
[12606]
If you think the code is bulletproof now, wait until after I do the 
ASSERT review of the entire codebase :)
Anton
3-Apr-2009
[12607]
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.
Maxim
3-Apr-2009
[12608]
I was going to ask what assert is about?
BrianH
3-Apr-2009
[12609x2]
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
Maxim
3-Apr-2009
[12611]
thx