World: r3wp

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 :) ?

shave my neighbor's unclean dog?  ;-P

I'm more for making coffee, but that's not too bad an idea either 
:)

Hi, I corrected http://www.fm.tul.cz/~ladislav/rebol/evaluate.r(I 
omitted a USE-RULE call for the last rule in the script), and renamed 
the accumulator 'a in accordance with industry standards.


Also, I added an efficiency note related to R3 protection disallowing 
us to use a simple binding method to create the USE-RULEs during 
function initialization (creation) instead of creating the USE-RULEs 
every time the respective function is called, which is inefficient.


I wonder, whether we should consider a way how to allow the creator 
of the function to perform some additional initialization during 
function creation.

As I demonstrated in the %use-rule.r script, such an initialization 
is possible using a method to circumvent the protection R3 uses, 
but it looks neither simple, nor very efficient.

Some bugfixing for A108 - http://www.rebol.com/r3/changes.html

This is probably the least "cryptic" way how to be able to initialize 
functions:

func-with-init: func [
	init [block!] {initialization code}
	spec [block!] {
		Help string (opt) followed by arg words 
		(and opt type and string)
	}
    body [block!] "The body block of the function"
] [
	spec: copy/deep spec
	body: copy/deep body
	insert body compose/only [
		if init? (init)
		init?: false
	]
	body: use [init?] reduce [
		first [init?:] true
		body
	]
    make function! copy/deep reduce [spec body]
]


>> fr: func-with-init [initialized: now] [] [print ["this function 
was initialized:" initialized]]
>> fr
this function was initialized: 22-Sep-2010/9:36:22+2:00

The initialization has to occur in the function body, unfortunately, 
otherwise the R3 protection does not allow BIND to be used, which, 
on the other hand, means, that the IF call is done every time the 
function is called, which means additional overhead

But, anyway, this solution looks less "cryptic" than the one used 
in the %use-rule.r script, I guess

Another disadvantage is, that for this version to work, the 'init? 
variable must not be an argument (local variable) of the new function.

http://www.fm.tul.cz/~ladislav/rebol/func-with-init.r