A subtle behaviour in accessing a Ring hashlist

[Mansour Ayouni]

Hello All,

Ring's hashlist is a powerful and flexible data structure, but it has a subtle yet dangerous behavior that can lead to hard-to-debug errors.

Read this narration to see why, and how Softanza solved it:

https://github.com/mayouni/stzlib/blob/main/libraries/stzlib/base/doc/narrations/Safe-Access-to-Ring-Hashlists-using-HasKey.md

Best,

Mansour

[Antonio F.S.]

Hello Mansour,

Impressive! So much programming knowledge comes from this forum!

Thank you very much.
Best regards,
Antonio F.S.
-----------------------------------------------------------------------

El 10/10/25 a las 21:59, Mansour Ayouni escribió:

[Ilir Liburn]

Hello Mansour,

The problem exists because you are using aHash + [ "age", 35 ] instead of aHash[:age] = 35. Hashlist is not really using hash, so by adding [ "age", 35 ] to aList, you are adding another key/value which stays invisible (unless you iterate over the key/values).

Greetings,

Ilir

[Mansour Ayouni]

Hello Antonio,

Thanks for your message! Indeed, a lot of learning happens together.

All the best,

Mansour

--

---
You received this message because you are subscribed to the Google Groups "The Ring Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-lang+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/5355129a-a96b-413a-b026-8d715af3e281%40gmail.com.

[Mansour Ayouni]

Hello Ilir,

Happy to read you.

The problem comes from the side effect caused by { if aHash[:age] = "" }, which adds an entry when it shouldn’t. This is contrary to common expectations and the behavior in most programming languages.

Softanza already handles this correctly, but I think Mahmoud should review this behavior and let Ring raise an error. In my case, I spent months trying to figure out why certain features in Softanza weren’t working. I never suspected this issue and tried several other approaches, which only complicated my code—until I finally discovered the root cause.

This illustrates how a single (undocumented) design decision can significantly complicate the programmer’s experience.

Best,

Mansour

--

---
You received this message because you are subscribed to the Google Groups "The Ring Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-lang+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ring-lang/1a1a6c3e-c8f4-4145-ba8f-013a94929b36n%40googlegroups.com.

[Ilir Liburn]

Hello Mansour,

an entry is added because aHash[:age] is a string index access, not hash access. I don't know why (and when) hashlist come into use while documentation is referring to string index access.

This is how it works: aHash[:age] needs to return list item object, otherwise assignment or comparison fails. That's why key is created holding empty value (where list item contains a list having both).

The problem is: lists are not arrays, e.g. lists are dynamic and item must exists prior the assignment or comparison.

 
Greetings,

Ilir

[Mansour Ayouni]

Hello Ilir,

All this is knowledgeable at the implementation level, and we should document, but Ring is high level and natural orientation is one of its design goals. I believe the syntax "if aList[:key]" means we want to make a check not change aList inside the condition...

All the best,

Mansour

To view this discussion visit https://groups.google.com/d/msgid/ring-lang/7f5edd40-f677-43e0-af02-6271d118e172n%40googlegroups.com.

[Ilir Liburn]

Hello Mansour,

alternative is to raise "index access out of range" error. Mahmoud decided to avoid this by creating the key and empty value instead. By simply following the rule: if aList[:key] = NULL aList[:key] = value ok, there is no need to raise an error.

The point is: aList + [:key,value] should be never used because it is an internal representation of the key/value pairs.

Greetings,

Ilir

[Mansour Ayouni]

Hello Ilir,

Any error raised will be fine, since people are not aware by default of this particular behavior of a condition that alters the data before we tell what action we want to take.

Thank you very much for those clarifications, we will wait for Mahmoud and other folks opinion.

All the best,

Mansour

To view this discussion visit https://groups.google.com/d/msgid/ring-lang/6258ab8c-4eaa-4d8c-b37b-c868bd4c865fn%40googlegroups.com.

[Ilir Liburn]

Hello Mansour,

You're Welcome. Raising error means: no comparison. Unless try-catch is used which is not performant.

Greetings,

Ilir

[Mansour Ayouni]

Hello Ilir,

I see the complexity. Perhaps the best solution is to simply return FALSE without adding anything. This way, a condition like if aList[:key] ... will not execute, preserving expected behavior.  

Best,

Mansour

To view this discussion visit https://groups.google.com/d/msgid/ring-lang/cdfb8e7d-4d9b-41b0-aa3a-ac8fc778a5f0n%40googlegroups.com.

[Ilir Liburn]

Hello Mansour,

returning FALSE (NULL) will work for  if aList[:key], but not for aList[:key] = value because value can't be assigned to NULL.

Remember, statement aList[:key]must return list item in order to work for both assignment and comparison.

In order to work in both cases, Ring parser needs to be modified to identify each case separately.

Greetings,

Ilir

[Mansour Ayouni]

I see! thank you a lot.

To view this discussion visit https://groups.google.com/d/msgid/ring-lang/89280d6e-266d-409a-bcee-6fe350656e8fn%40googlegroups.com.

[Antonio F.S.]

Hello Mansour.

You're welcome. :-)

Best regards.

Antonio F.S.

----------------------------------------------------------------------

El 11/10/25 a las 0:11, Mansour Ayouni escribió: