World: r3wp

Not really. MOLD is used as a way to generate script source (which 
would be loaded with DO); MOLD/ALL is for data (which would be loaded 
with LOAD). Both have their strengths, so there has been no talk 
of removing one or the other.

ah, I was confusing it with something else, sorry.

Thanks Y'all for the info. I guess I'll have to fake it.

If you make sure that all references to the object are through the 
same word or block, no aliasing, then you can just reassign to a 
new object based on the old.

James;  I haven't experimented much, nor really thought about it 
other than to know there are (many) issues  Using path notation may 
help.

>> o: context [a: [name "Bob"]]
>> o/a/name
== "Bob"
>> append o/a [address "Main St"]
>> o/a/address
== "Main St"
>> o/a/adress: "New Adress"
>> o/a/adress
== "New Address" 


So you are not adding elements to an object!, just adding key value 
pairs to a block and using path notation.  It might not suit what 
you need, or it might just look like it   :)  Enough to get yourself 
coded into a corner.

And just so ya know ... I wouldn't do that.   I'd  o: make o [address: 
none]

Is there a way to sandbox a function in a sense such as if I have 
a block defined such as:

block: [ ]

and then I have a function that is as such:

if equal? arg1 arg2 [append block arg2]


How can I intercept what is going to be passed to block before it 
is allocated to do some other processing.

Is it always append?   Append is a mezzanine in R2 so if you redef/wrap 
it, you'll not be penalized much on performance.

Could be insert alter or any other function that would populate data 
into a block.

Yeah append is a mezz for insert though if I recall.

SOURCE APPEND  for more info, but hmm, you might have to write a 
wrapper then ... performance for REBOL isn't too too horrible at 
the mezz level as long as tight loops aren't involved.

how do you pass a lit-word to a function argument and have the function 
still see it as a lit-word?

Check in and around http://rebol.com/docs/core23/rebolcore-9.html#section-3.2
  but note the backtick  `var is really just a single quote.

don't see anthing helpful there.

f: func ['a] [type? :a]

Note the ' on the spec and the : get in the func.    REBOL is one 
tricky little business  :)

that is a direct reference.  But try something like this:

blk: ['word]

f: func [arg][lit-word? arg]

then try it:

f blk/1

And you will see the problem.

Just for fun ... check out http://rebol.net/wiki/Glossaryand http://rebol.net/wiki/Glossary_rebols_view
for how confused I am in this area.  :)

>> d: ['junk]
== ['junk]
>> f: func [a] [type? :a]
>> f d/1
== lit-word!


You need the : get inside the func to avoid evaluating arg inside 
the function.

Of course....why didn't I think of that....  I was racking my brain 
and didn't even think of the simple stuff.  let me see if my litlle 
function works now.

potential?: function [arg][][either all [word? :arg not lit-word? 
:arg][true][false]]

>> blk: [print 'print "print"]
== [print 'print "print"]
>> potential? blk/1
== true
>> potential? blk/2
== false
>> potential? blk/3
== false

works good!

Do we already have a function that does this? If not a similiar function 
should probably be thrown in REBOL3 don't you think?  Could be useful

Paul;  I get so lost in the REBOL trees so often ... that "obvious" 
isn't in my REBOL vocabulary yet.  It's partly why I post helper 
notes;  knowing someone else will correct me and I'll learn that 
little bit more about concise REBOL.  ;)

Like from TRETBASE, I didn't even think to test   that   false = 
none  is false  and I was so glad Anton posted the "obvious".

My problem is that I forgot many things because I haven't done them 
in so long.  Plus I forget what changes were made so I find myself 
doing something complicated that has now been simplified.

I rarely use FALSE actively, more relying on that many functions 
like ALL and ANY work best with NONE. This shortens many functions.

potential?: func [arg][all [word? :arg not lit-word? :arg]]

However, I think the function would work better like:

potential?: func [arg][all [any-word? :arg not lit-word? :arg]]

Yeah I just threw it out there as I had it in the console at the 
moment but feel like it could be of benefit to have it built into 
R3 as a mezz or something.

Your functions are returning none so I don't think we want that.

;Mabye this:


potential?: func [arg][if all [any-word? :arg not lit-word? :arg][return 
true] false]

Seems to work ok:

>> blk: [print "print" 'print]
== [print "print" 'print]
>> potential? blk/1
== true
>> potential? blk/2
== false
>> potential? blk/3
== false

potential?: func [arg][found? all [any-word? :arg not lit-word? :arg]]


blk: [print 'print "print"] print potential? blk/1 print potential? 
blk/2 print potential? blk/3
true
false
false

... just to be part of the game ;-)

There you go Ingo!

I forgot about found.

Just when I was starting to think there was no longer a use for it.

I admit, I had to look it up, too.

lol - I kept thinking in my head what I can return this back with 
that would explicitly evaluate to true or false and not give none 
but you FOUND it - pun intended.

So does anyone else think potential? should be a mezz function?  
If so, what should the name of it be proposed as?

I'm not sure it's needed often enough to warrant its inclusion, first 
take at a name: 

non-lit-word?

But it that really doesn't give an indication of what the function 
is for which I believe the function is for is to find if an argument 
has a potential to be evaluate

Your functions are returning none so I don't think we want that.

 <-- my point was that NONE can be more useful than FALSE and gives 
 simpler code, if you are not using NONE as a specific value.

Can you provide an example Henrik?

I gave it above. Simplified code.

Yeah but that is a trade off to useability in my opinion.  For example 
I can say pick [this that] potential? arg

true, if you need to do that.

but what if you don't? :-)

I think we will have to do that more than the situation where we 
would desire it to return none is why I mention it.

ok, then ignore my suggestion :-)

I didn't ignore it - I just want to make sure if we propose it then 
it meets the highest amount of usability.  I'm interested in all 
ideas.