World: r3wp

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

Map keys get hashed when the map gets large enough. No, I don't know 
how large that is :)

but the object pointers can be hashed? no?

Bring it up with Carl :)

he'll ask me for an example of usage... now I have to scan my brain 
for the last 10 years of REBOL usage... and remember when I'd used 
this... hehe

The advantage of map keys is that they don't have to be the SAME? 
as the key, they can just be EQUAL? and the hashing speeds things 
up. With objects you either have a reference to it or you don't. 
If you have a reference, you can extend it with new fields, which 
can refer to the values you want to associate with the object. If 
you don't have a reference you need to specify a key within the object 
that you are searching for, and hashing won't help there, but we're 
going to add a mezzanine to do that kind of searching.

the EQUAL? note is very important to mention in the docs... and its 
important for the difference between them to be very explicitely 
defined for all types, somewhere.

the difference between EQUAL? and SAME?

I believe there is a blog conversation about that now :)

yep... I just meant... it has to be very precisely/explicitely documented 
 :-)


btw, I added other qualitative word examples for equality-likeness-sameness 
on the post...  might give you ideas for a better scalling of the 
four levels

Just updated my article about my early R3 porting adventures.  Highlights 
of changes:

-- shout outs to Ladislav and Steeve -- thanks, guys
-- fix of to-pair issue

-- aside about the largest prime discoverable prime number in REBOL 
-- I suggest any discussion on that goes into [Puzzle answers]

-- problem with parse --- see ISSUE under rse-ids.r  -- Can anyone 
help diagnose the issue? Thanks!

http://www.rebol.org/art-display-article.r?article=j26z

Some tweaks:
- OR~, not ~OR

- AND~, OR~ and XOR~ work in R2 as well, and should be used instead 
of AND, OR and XOR for prefix use.

Interesting article :)
It's great to see how easy porting from R2 to R3 is :)

sunanda, in insert-compact, replace:
>>prev: pick here -1
by
>>prev: pick here 0

for RSE-IDS source

Thanks Steeve -- will try that later.

Thanks Brian -- though it's early days yet. I've deliberately picked 
the nursery-slope scripts. I have others I'll build up to that regularly 
acted as R2 stress-testers.

As Brian pointed, it's not difficult to port to R3 but it's not optimized 
for R3 and to do so; it will need more rewrite.

Sunanda: Correction! I told you, that it was the largest INTEGER! 
prime in R3, I did not claim a larger one is not findable

back from business trip. So what's the binary conversion status? 
Is it just a test how it turns out, or are we definitely going that 
direction?

conversion done, you can download A62

Sunanda: your alphametics problem is caused by bug#851

Apologies and thanks, Ladislav -- I'll update the article again probably 
tomorrow.

We could use more opinions on two short-term decision blogs:
- http://www.rebol.net/r3blogs/0211.htmlLevels of equality

- http://www.rebol.net/r3blogs/0212.htmlCopying and/or making objects

Please chime in! We need more opinions than just those of Ladislav, 
Maxim and I :)

Especially since Ladislav and I agree about levels of equality - 
it's usually scary when we agree :)

Well, but then there are those, who's opinion is irrelevant, as mine 
:-) As for equality, I think you are directing a good direction, 
as well as for copying. I do agree with Max, that we need max flexibility 
to decide what gets copied and what not. Some things can then be 
pre-set, other set by users at will.  We need good memory management 
...

Well, if you agree, it is cool. Make a decision and move on - we 
have still tonnes of issues to solve :-) You know - half functional 
modules, no concurrency, no upper layer networking, still no plugins, 
no GUI (and Flash is going to be everywhere by the end of the year) 
... that seems like a really lot of catch-up we need to play ...

Max is missing that I already proposed a more flexible solution than 
he is proposing. He is so focused on the behavior of MAKE that he 
missed that I also made proposals for COPY andf COPY/deep.

We imo need to quickly proceed to Beta. I want to start using R3 
as an R2 replacement soon. I need SQLite and then GUI, but I can 
wait with the GUI.

ouch, meeting in 4 minutes ... starting my preparation work :-)

I am overdue to go to sleep - it's 3am here. I expect to wake up 
and find more comments, darnit :)

I haven't been following too closely, but I'm against copy making 
a new object from an old one.  I'd have to look at the suggestions 
more to have more comments

Without rebinding, both shallow and deep copy of objects can have 
problems. That's why MAKE is the sensible default, the easy thing.

However, you can't have MAKE do a shallow copy: Spec blocks would 
explode in size. So you need another way to do a shallow copy.

And if you have MAKE do a deep copy (as it does now in R3), memory 
explodes and you can't do graph references. So you need a way to 
make a deep copy too, in case you need to.

So I'm suggesting that the things that would normally be bound in 
an object spec get BIND/copy when you MAKE from an object prototype, 
but otherwise referenced. That means BIND/copy of blocks, words, 
functions and closures. The rest can be copied by the init spec if 
you need to, or not.

Keep in mind that BIND/copy is more efficient in R3, and in theory 
doesn't even need to be a copy: It could be copy-on-write.,

(I went to sleep right after my last comment, hence the lag)


On equality:  Ladislav's idea sounds good, but I don't exactly see 
the point for having the bottom level in there.  What use would it 
be for?  How/where would the range for "approximate" be set?


On objects:  I think I may have misread it earlier - my comment was, 
"copy/deep [object1 object2]" should return a new block that still 
points at object1 and object2, rather than creating two duplicates 
of them.  But from the comments it certainly doesn't sound like I 
was thinking.  (Although make/deep or "copy/deep/types foo [object! 
series!]" suggestions sound like they may help..?)

Another update of my R2--->R3 porting adventures. Highlights of new 
stuff:
  -- pick 0 vs pick -1
  -- hash vs map

  -- examples of version sniffing to ensure one source works in R2 
  and R3 (thanks to Ladislav
     for the method of distingishing R2 from R3)
http://www.rebol.org/art-display-article.r?article=j26z

Izkata, when refering to Ladislav's levels, please number them (as 
he should have). I'm not sure what you mean by "the bottom level". 
If you mean the first level, that is an exact description of the 
behavior of EQUAL? or = in R2.

Adding a refinement to MAKE would be a bad idea, since it is a very 
low-level action that all datatypes support. COPY/types though... 
:)

I meant the one he labeled "the bottom level", the non-transitive 
one  ;)

I'll call "the bottom level" level 1, then increase to 4, for now. 
 Generally I only use EQUAL? in R2, which appears to me to be level 
2 (although you named it level 1?), but can see why the stricter 
levels 3 and 4 are helpful - I just don't see where level 1 can be 
used right now.


As far as naming goes, my only question is the need for negatives. 
 Why isn't NOT sufficient? ("not equal?" rather than "not-equal?", 
etc)


I forget MAKE can be used with things other than object!, I use it 
that way so rarely.  So yeah, /deep doesn't make sense now that I 
think about it   =P

EQUAL? in R2 is level 1. Changing it to level 2 would break a lot 
of code, particularly for word equivalence :(

You need a NOT-EQUAL? action so you can have a != operator. Every 
op! maps to an action!, no exceptions.

Mmk, I must have just never run across a case where I would have 
seen that by coincidence.

and I didn't know about the op! mapping

Yeah, it's why there is no NOT-SAME? function - no operator needs 
it.

How do you convert a Map! to a Block! in R3? The obvious way doesn't 
seem to work:

>> a: map! [a 1 b 1 c 1]

== [a 1 b 1 c 1]

>> b: to block! a
== [map!]

You are missing a TO (or  a MAKE)
    a: TO map! [a 1 b 1 c 1]
    to-block a
    == [a 1 b 1 c 1]

Thanks, Sunanda