World: r3wp

Otherwise, here is one, feel free to optimize:

delete-dir: func [dir /only criteria] [
	dir: clean-path dir
	foreach file read dir [
		if any [not only do func [file] criteria file] [
			file: dir/:file
			if dir? file [delete-dir file]
			delete file
		]
	]
]

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

R3 may be different as I see it's an action now.

I have a version that redefines delete that I wrote for QM: http://www.ross-gill.com/r/brutal-delete.html


It has an optional /pare refinement that deletes empty parent folders 
too.

It's defined only to take URLs (as QM doesn't access files directly) 
but I think should work adding a file! argument.

Also not sure if it works the same way with R3 file ports.

Nup, guess not:
** Script error: cannot use clear on port! value

Interesting. I think that's a bug, as CLEAR's spec is as follows:

clear: make action! [[

    {Removes all values. For series, removes from current index to tail 
    and returns tail.  (Modifies)}
    series [series! port! map! gob! bitset! none!]
]]

Well, guess it's just the error message that is misleading, as CLEAR 
still works on file ports.

(Not on directory ports, though.)

That explains it.  Wonder why not?

I guess 'remove doesn't either.

I think it's basically "just not implemented". :)

this should be reported on CC, if its not there already (just so 
its not forgotten)

From a quick glance at the host kit, I think implementing it would 
be rather easy (basically another special case for RFM_TRUNCATE for 
RFM_DIR in Write_File in dev-file.c). But wiring it up to the directory 
port actor is beyond our freedoms with the hostkit, I think.

Would it make sense, or even be possible, for RT to do all the internal 
wiring for port actors, with a default TBD stub that people replace 
when working on their host kit?

Yes, it probably would. At least in this specific case that's quite 
possible to do. But in general it would make more sense if the flexibility 
to define and wire "native" ports would move to the hostkit completely.

Is it perhaps intentional that 'remove and hence 'clear don't work 
as 'delete is now the action! type responsible for this task?

am I correct that quotes are lost in system/script/args? I need some 
testing here.

the workaround is to do something like:

launch/args %something mold to-binary mold/all [my-data: "test"]

which doesn't seem particularly pretty

Use system/options/args to get the list of arguments as they come 
from the operating system.


system/script/args is more like a rejoin of system/options/args. 
LAUNCH seems to not be doing much more than what CALL does, which 
means there is no escaping of the operating system's shell special 
characters. If CALL/INPUT did not imply /WAIT, it could have been 
a better way to pass REBOL data to a new process.

(not sure if any of this is going to be changed for R3)

LAUNCH is undergoing revision in R3 these days and is a mezz, not 
a native, but the problem seems not to be on the side of LAUNCH.

>> a
== make map! [
    e 4
]

>> a/b: func [][print 3]
>> a/b
3

shoudn't it return a function type?

I mean... I though maps where for storage rather than evaluation...

though=thought

docs just say "not documented"
    http://www.rebol.com/r3/docs/datatypes/map.html
Use select a 'b to return the function itself
Use curecode to get the behaviour normalised :)

hehe

ah didn't think of select... doh.  but I will CC it, just to get 
Carl's feedback.

Maxim: "shoudn't resolve have a refinement called /bind  making it 
easier to rebind data to target context in a single pass?"

There is a REBIND internal function that hasn't been exported yet. 
Ask Carl or request in CureCode for the function to be exported.

Now for the other binding stuff:


* SET is a low-level function that would be slowed down immensely 
by adding any refinements.

* SET does handle the unbound scenario: It triggers an error. You 
can then handle the error.

* R2 and R3 get their speed from the direct binding model. The core 
speedup of that model is that SET doesn't bind.


* LOAD in R3 is a high-level mezzanine function. It is meant to be 
as fast as possible given its purpose, but being fast is not its 
main goal; user-level flexibility is. Most of the overhead of LOAD 
is in handling all of its various options, as refinements, file extensions 
and script header settings. If you know what you are doing, you can 
always optimize your code by doing it directly instead of having 
LOAD try to figure out that is what you want to do. LOAD is not meant 
for use in tight loops.


* Henrik, ChristianE, the R3 standard answer to the question of how 
to make BIND TO-WORD "a" more efficient or friendly in R3 is this: 
You are encouraged to not program that way in R3. Converting strings 
to words is something you should do once, not all the time in tight 
loops. Your code will be much more efficient if you work in REBOL 
data rather than storing your code in strings and converting at runtime. 
Strings are for data, or script source, not for containing scripts 
at runtime. This is a good rule for all REBOL versions, but especially 
for R3 with its Unicode strings vs. shared UTF-8 words.


* I have recently refactored LOAD so that it is broken into smaller, 
more efficient functions. You might find that those functions would 
work better for you in lower-level code. But this was done to let 
us make LOAD *more* powerful, not less, so the same advice I gave 
above about not using LOAD in tight loops still applies. I don't 
yet know if the new LOAD is faster or slower, but it is safer and 
easier to understand and modify, and you can make your own LOAD replacement 
that calls the same low-level functions if you like. Plus, you get 
compressed scripts :)

Maxim, maps are meant to be used like objects, but with different 
tradeoffs. The evaluation that you show is not a bug, it is by design, 
and it works for functions stored in blocks as well.
>> a: reduce ['b func [] [3]]
== [b make function! [[][3]]]
>> a/b
== 3

Use get-paths if you don't want evaluation:
>> print mold :a/b
make function! [[][3]]

So the evaluation has nothing to do with maps, it's a path evaluation 
thing. You can still store stuff in a map, but as with storing active 
values anywhere you have to be careful.

yeah, ok, so its not a map thing... that is now obvious, since the 
select doesn't evaluate it..

Welcome to the wonderful side effects of increased language consistency 
:)

I like the fact that you are modularizing LOAD... I did try to modify 
it before and well... I thought you where brave of even getting it 
to work at that point  :-)

I had forgotten about get paths... thanks... that is what I need.

Carl requested the modularization. And I definitely wanted to do 
it because the whole module and script system didn't pass the hit-by-a-bus 
requirement.

hehe... I agree  ;-)

I can't help but wonder if we'll ever get maps that are meant to 
be used like maps ...

actually the cultprit is the path walking here... but I agree that 
using them as objects within path notation is strange.

brianH can you tell me *why* path notation evaluates map lookups?

(I have no gripe with the path notation. It's the old strict-equal? 
issue the above was hinting at.)

brianH  " increased language consistency" if this where true, then 
we couldn't store object in blocks without evaluating them by default 
either. 


IMHO maps are just hash tables, just like a block.... storage, not 
vector jump tables.   but that might just me my skewed view of the 
world.

oops... sorry my last statement was a bit messed up... ignore the 
first line...

Well, it sure _is_ more consistent to always have paths which ultimately 
refer to a function! make the function an "active" value.

Wether that consistency is desirable or worth anything is on another 
page.

But it generally simplifies things if you don't have to re-define 
the semantics of all path variations.

anyways, we do have get paths now... so I guess I'll just shut up 
and stop stirring air  ;-)

Yeah, and that illustrates the consistency argument: if paths with 
a map! as underlying would be redefined to behave like get-paths 
per default, what should get-paths on maps do :) ?