World: r3wp

It's not another (secret) Pekr's name? :)

The bug fixes just keep coming -- Alpha 59 out barely a day after 
A58:

http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.59_23-June-2009


Curecode #961 was fixed in less than 24 hours....That must be a record!

Notice Meijeru's daytime work... must be a fruitful hobby.

I think I ran into him before (may be virtually), I remember him 
as a very kind and nice person.

pekr: well, I did add new posts, but I think everyone MUST participate. 
 this is such a core issue, it can make / break many systems out 
there.

in my case, it breaks every single API I have.

that is unless you consider a 100x (thats 10000%) increase in RAM 
usage and script slowdown acceptable.

http://www.rebol.net/r3blogs/0213.html- A60 special release.

The link in the blog does not work [has /rebol3/ not /r3/ ]

This link does work:
http://www.rebol.com/r3/downloads/r3-a60.exe

http://www.rebol.org/art-display-article.r?article=w24v- porting 
INCLUDE to R3

brian I would like your comments on the deep object copy issue ( 
http://www.rebol.net/r3blogs/0212.html)

I have been trying to think think it through - there are advantages 
and disadvantages to either way. It is harder to undo a copy than 
not...

exactly, which is why I think we should not be bound by one or the 
other .... 

did you see my posts... I provide some alternatives.

I'm still thinking. I'll comment after I narrow down this parse bug.

Plus all that binding takes MASSIVE amounts of time for nothing.

(and ram too)

Either way you need constructor code. The real question is balance.

IMO we need choice.  this is such a fundamental part of data management 
that we cannot let the compiler decide.


would you code in C if all structure copies behaved this way?  if 
this where the case an OS would probably need 1TB of RAM to run.

allowing COPY on objects makes much more sense to me.

I added a fairly comprehensive comment, with tests. I had to generate 
3 CureCode tickets as a result :(

what is the replacement for first context []  in R3  I can't remember 
the function's name

the why? in R3 is a fabulous idea!

WORDS-OF, but the 'self word is not included.

no self ...   COOL  :-)

And the returned words are bound to the object.

oh that is cool.

I see unbind is now part of R3  :-D

WORDS-OF works on any-object!, any-function! and map! too, though 
it's only bound to any-object!.

I could see the binding to map being usefull, it might be impossible 
due to the inner implementation of map

I'm trying to backport UNBIND to R2, but it's really tricky.

I've tried several times... I usually end up doing:     load mold 
myblock

You can't bind to a map! because the keys are handled differently, 
with the keys going away when assigned none.

You can't bind to something that might go away :)

yep  :-)   I guess asking for a word in a map which isn't there returns 
none  ?

Yup :)

Most of map!'s behavior was my idea.

it makes me think of the array type in AREXX  ;-)

are only words supported in map! or are other types usable for the 
key?

Other types too, but not all other types.

so scalars, pairs, tuples, strings, words at least?

Yup.

a trick question... are set and get words enabled? and are they differentiated 
from lit-words?

to me an unbound word is a lit-word in the context of the map...

I'm not sure what I wrote above makes sense.. hahaha

Binaries too, but not block, object or vector types. Word types are 
converted to word!.

All types can be used as values though, except #[none] which will 
make the key disappear.

yep this means we can use the map exactly like in AREXX, very usefull 
for sparse arrays  :-)

if you used the object's pointer in the map internally, we could 
use objects too, it would actually be very usefull and not that much 
heavy to implement.

like find with blocks is very fast.  it only maps the exact same 
object, not a similar object AFAIK.

You can use objects as the values, but the keys need to be hashable 
:)