copy/deep is not working as expected when used on map! datatype

[Siskin-Bot]

Submitted by: Oldes

Current behavior:

>> m: make map! [] m/b: copy [1 2] n: copy/deep m same? n/b m/b
== true

Expected behavior:

>> m: make map! [] m/b: copy [1 2] n: copy/deep m same? n/b m/b
== false

Red is working properly. Ren-c is not supporting copy/deep on map!:

>> m: make map! [] m/b: copy [1 2] n: copy/deep m same? n/b m/b
** Script Error: incompatible or invalid refinements
** Where: copy
** Near: n: copy/deep m ?? same? n/b m/b

---

^{Imported from: metaeducation#2293}

Comments:

Oldes commented on Mar 1, 2018:

Implemented in commit: Oldes/Rebol3@fe0886f

>> m: make map! ["aa" [1 [2]]] n: copy/deep m
== make map! [
    "aa" [1 [2]]
]

>> probe same? (first words-of m) (first words-of n)
false
== false

>> probe same? (first values-of m) (first values-of n)
false
== false

>> probe same? m/("aa")/2 n/("aa")/2
false
== false

>> n: copy/types m block!
== make map! [
    "aa" [1 [2]]
]

>> probe same? (first words-of m) (first words-of n)
true
== true

>> probe same? (first values-of m) (first values-of n)
false
== false

>> probe same? m/("aa")/2 n/("aa")/2
true
== true

---

Oldes commented on Mar 1, 2018:

Needs also this fix: Oldes/Rebol3@259b252

---

Oldes commented on Mar 1, 2018:

@carls is it desired that the copy copies also map's keys? Red copies just values.

---

Hostilefork commented on Mar 1, 2018:

is it desired that the copy copies also map's keys? Red copies just values.

R3-Alpha has bugs related to mutable keys. Mutations can change how they hash. These changes mean they won't be found.

metaeducation#2295

FWIW, a deep copy in Ren-C would not need to make new deep copies of the keys, as they were guaranteed immutable on insertion.

There is no such thing as permanent irreversible deep LOCKing in R3-Alpha (only PROTECT, which can be UNPROTECTED). It doesn't have a parallel notion of immutability which is safe for keys. Hence copying keys in R3-Alpha wouldn't really help anything...either upon insertion, or upon a map copy.

---

Hostilefork commented on Mar 1, 2018:

COPY+/DEEP+/TYPES on MAP! implemented in Ren-C in this commit:

metaeducation/ren-c@fe1b6be

---

Hostilefork added the Ren.resolved on Mar 1, 2018

---

Oldes commented on Mar 1, 2018:

My initial need was to be able copy values. I don't care about keys so much and the lock requirement in Ren-c looks like performance issue to me.

---

Hostilefork commented on Mar 1, 2018:

the lock requirement in Ren-c looks like performance issue to me.

There are 3 read-only bits: HOLD (executing or held by frame), FROZEN (locked), and PROTECTED (user controllable on/off). They are all checked at the same time in one bit flag operation:

https://github.com/metaeducation/ren-c/blob/master/src/include/sys-series.h#L523

Setting the FROZEN bit on a string is setting one bit in the REBSER node. If you LOCK a BLOCK! then it does have to walk it deeply to do that, but since you can't use blocks as keys in Red or R3-Alpha, I assume you're not referring to that.

Red has to always copy an ANY-STRING! key the user passes in, to avoid hash corruption, and prevent you getting access to that internal key to mutate it. In Ren-C you get a choice of whether you feel like putting a locked copy of whatever you have into the map key, or just locking what you have if you don't plan to mutate it further.

So far Red doesn't let you enumerate MAP!s and get the keys, (e.g. with FOR-EACH [key val])...so I don't know how you'd get access to its copied keys to mutate them. But if you could, you could corrupt the hash.

In any case, Ren-C has the best case scenario for performance that doesn't involve using mutable strings the user passes in as keys directly, which gets you hash corruption, as demonstrated. So don't know what you mean.

---

Oldes commented on Mar 2, 2018:

My opinion is, that you are forcing user to lock or protect series values, which they want to use as a key in a map... I remember that I once needed to have a lot of string keys and was using map for fast access... I was pretty sure that I'm not modifying these strings. In Ren-c I would be forced to lock them, which is actually another function call for each newly created key.

If I would like to be safe, I could use in R3 mentioned protect on the string, which would work like your lock, but with a chance to unlock it too, if needed. To make it short.. I consider Ren-c map! behavior too repressive.

Btw.. I have nothing against permanently locked series. It may be useful in some scenarios.

I'm not able to build Ren-c now, as there were again some changes, so cannot test your modification. What I needed was being able to copy values in map and that is all. Good for Ren-c, that it have it now too. Btw... if I would be precise like you, there could be error if copy/part on map would be used (now it is just ignored).

---

Oldes commented on Mar 2, 2018:

Now I see, that Ren-c has the error on copy/part map. I knew you are precise;-)

---

Hostilefork commented on Mar 2, 2018:

Now I see, that Ren-c has the error on copy/part map. I knew you are precise;-)

I mentioned how this is done, which is that compiler warnings on unused variables is turned up. The macros like INCLUDE_PARAMS_OF_COPY; let you use names based on the definition in the C code, and when you fail to use one of those names you must react or the code won't compile. It helps find problems.

If I would like to be safe

My feeling is that if I make a MAP!, and search for a key, and it says the key is not in it when it is... or is when it isn't... that is very bad.

Obviously there are cosmic rays and life has no guarantees--so one must live with the idea that no system is perfect. But it seems to me that if you used a string to put a key into a map at one point, the odds of you later using that string again in a search are quite high. So getting demonstrably wrong answers from the map if you ever do mutate isn't a good tradeoff in my book. It means your tool is working against you.

I don't know what to tell you about performance if you are worried at the single-function call level when all that function does is set a bit. I might suggest not using an interpreted language, and there are some new ones around...not everything is as convoluted as C++ or as confined as Haskell. Maybe look at Rust, or Go?

---