World: r3wp

the issue is that as it is a commonly used feature, although easy 
to fix within glayout... many references to in my apps will break... 
ahh...

The order does not change after the initial SET.

yes.

>> set 'var-1 1
== 1
>> set 'var-2 2
== 2
>> set 'var-1 3
== 3
>> print mold skip tail first system/words -4
[Comments in-obj var-1 var-2]

how the hell did I not realise I was overiding such a core word? 
 sometimes the obvious just slips by...  when you're looking the 
other way   ' :-/

yes anton, which is why I discovered where it was being set... after 
a func called 'layout (this one voluntarily being an override)

It would be nice in R3 if we could remove things from an object when 
deriving with make... (we can , sort of, using the 'THIRD accessor 
on an object and editing it....)

but when the object is being created by another controler (like in 
view) then we can't really...

So you'd really like Rebol to have the equivalent of JavaScript's 
Delete operator?

hum don't know about it... but if I could do 

obj: make/without ref-obj [] [select]

We could already shrink our objects, when its needed.

binding would then have to replace any object-local bindings of select 
to the global context and raise an error if it doesn't exist, as 
it would if you had tried to define a new object with select undefined 
in any place.

One think that I like in JavaScript is the flexibility to freely 
add and remove members from object instances and object prototypes 
.

think -> thing

it is usefull only when it is something which is not automatic like 
in python, where its nightmarish.

if you inadvertently typo , then you create a new member!  talk about 
hard to debug errors!!

how does the path native work ? I couldn't find it in the rebol dictionary

Joe, that native is an accidently exposed internal function. It has 
no use externally.

If I'm calling a function with many different refinements and the 
function has to work recursively and all refinements must be maintained 
throughout recursion, is there an easy way to get the function call 
with all refinements?

I'm using:


>> f: func [/a /b] [to-path remove-each p reduce ['f all [a 'a] all 
[b 'b]] [none? p]]

>> f
== f
>> f/a
== f/a
>> f/b/a
== f/a/b ; lose refinement order

I'm not sure if this helps but I sometimes make a wrapper function 
which calls the actual recursive function. The wrapper could take 
the refinements and set some flags in a context shared by all calls 
to the inner recursion function.

Oh hang on, your question indicates that your example code above 
is currently working, but you are looking for a better way. Is that 
correct ?

A "how was this function called ?" function. I don't think there 
is a way. (although in recent discussion on BIND?....)

ooh.. actually....

1. it currently works but is clumsy, I think
2. "how was this function called ?" = yes

How about this:
>> f: func [/a /b][print mold second bind? 'a]
>> f/a/b
[true true]
:)

there is something about that you don't know the actual function 
name inside the function? if only the refinements and their order 
could be managed.

testing...

That's right, since several words can refer to the same function, 
it has no "one" word.

(it also could be an anonymous function)

well, that only brings up a block and the refinement order is still 
off, which would be a problem if your refinements have arguments

I see.

I think you must pass in the code which is used to launch the function 
as a function argument :)

nasty!

yep :)

I wonder how hard this would be to implement in a single function. 
Probably very hard if functions internally are unaware of refinement 
order

very hard = impossible :-)

Well, given a function
f: func [code /a /b][print mold second bind? 'a]
do append/only copy code: [f/b] code
--->  [[f/b] none true]

Since I've passed in the code to call the function, it knows how 
it was called, and the order of refinements. The refinements are 
listed in spec order in the function context though.

What's the actual application for this recursive function, by the 
way ?

it's a file packing function. refinements are used to determine which 
files should be skipped and which files should be processed with 
other external functions

And why does it need to be recursive ? Recursing directories ?

I use it in many places for slightly different purposes

yes

ok, so more an abstract general idea.

I think you must pass in the code which is used to launch the function 
as a function argument :)
 no need, pass-args can handle everything

, but a native APPLY handling refinements transparently would definitely 
help

Henrik: why is the refinement order important to you? (since there's 
no way to know it from inside a function)

if you have control over the function, write a (recursive) function 
without refinements and a wrapper with refinements that calls it. 
(this is the best solution)

if you don't have control over the function, Ladislav's pass-args 
or similar techniques are the most general way to solve the problem. 
easier/faster solutions may be available in specific cases.

a native APPLY would solve all of this elegantly... hopefully we'll 
get one :)

aye, I look forward to apply too :)