World: r3wp

end! is the block end marker, you should never see that. list! is 
bugged, and noone ever used it, that's why it's not even in R3.

When you say that list is buggged in what way?  I would like to know 
what to watch out for when using it.

I thought this was actually mentioned in the docs. I read some place 
once that sorting and some other functions were never meant to be 
used with list!. I think it's in the appendix of the Core documentation 
somewhere.

perhaps it would be cleaner to simply disallow SORT to work on list! 
?

Was just thinking the same thing if that is indeed the case.

Thanks Anton and Graham. My bad. I started checking to see if my 
nested objects were even working (behaving as objects) after I appended 
them (and before saving them). Lo and behold they were so no wonder! 
Thanks for your time and tips.

Maybe it would be a good idea to make SORT work on list! instead, 
even if it needs to be special-cased.

;Is this a bug with list also?

>> list: to-list [1 2]
== make list! [1 2]
>> index? list
== 1
>> remove find list 1
== make list! [2]
>> index? list
** Script Error: Out of range or past end
** Where: halt-view
** Near: index? list
>>

Seem the indexing is not what I expected on that.

gotta find those docs. indexing for list! is not the same as for 
block!

Design difference, not bug. It's not a problem with indexing - you 
just deleted the node that 'list was referring to.

I looked at the docs for it but it still seems like strange behavior.

Ahh I see BrianH.  Thanks.

INSERT for list! behaves like APPEND for block! I think list! was 
made for appending large amounts of data using INSERT much quicker 
than block!

Yes I understand that and that is its strength because it is always 
at tail after an insert.  But what struck me was why it went to out 
of range after the remove of the first item.  But BrianH's statement 
makes sense.

It's an aliasing thing. A list doesn't keep its own list of the words 
that are referring to it, so changes to one reference can affect 
other references in unpredictable (without dataflow analysis) ways.

Strangely enough, my main uses for list! have been the same as yours: 
for database tables. If you use list! then aliased references to 
the list will still be valid when you delete nodes, as long as the 
node you are deleting is not the one you are referencing. This has 
advantages when making indexes, which can be a hash! of such references.

When you keep aliased references to blocks rather than lists, any 
inserts or deletes could invalidate all of the references because 
the offsets could change. Not a problem with lists, since the references 
are pointers, not offsets.

Good info - thanks BrianH.

Slight change of subject but here I  am all happy saving/all  and 
loading my objects and then it hits me: Just what is this "serialized" 
data? How is it different (outside of that fact that it's ascii representation 
is different.) I don't know if I need to know to use it but in case 
I'm ever on TV I want to answer it correctly.

Umm, I get this wrong - conciseness wise - but 

>> mold none
== "none"
>> mold/all none
== "#[none]"

If you load   "#[none]" you get the value none, type none!   if you 
load "none"  you get a word none with the word! none in it.  The 
serialized or lexical form tells REBOL exactly what the value type 
is while loading, alleviating the need for and evaluation.  Umm, 
again...there are more concise descriptions of this.

you get the word with the word! none in it  ... what?  :)   "you 
get the word! none which needs to be evaluated to get the value none 
type none!"

Thanks, btiffin. Someday I'll ask what that has to do with the word 
"all" as in mold/all -perhaps it refers to saving everything including 
the type.


Here's another thing I just ran in to: How does one add to an object? 
Say I have this object o: make object! [name: ""] and I want to later 
add  'address: ""'  (while the program is running of course).

Thanks in advance.

you can't.

you have to create a new object with the new field.

R3 will let you. But, as Graham says, no suhc luck in  R2.
R3 discussion here:
http://www.rebol.net/r3blogs/0073.html

I don't think I use MOLD very often, only MOLD/ALL. MOLD lies too 
closely to FORM. I believe also there was a discussion about changing 
this in R3?

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".