feat(examples): add rolist

[moul]

• add avl/rolist
• add I... interfaces for avl/...'s main structs.

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 The pull request was created from a fork (head branch repo: moul/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[leohhhn]

What is list.list exactly? It's not obvious from this package.

[moul]

it's the gno.land/p/demo/avl/list.List struct.

[leohhhn]

I'm wondering if we're deviating from what we generally want with avl. If someone wants to use a tree, let them use avl and its helpers. If not, they're welcome to use the native slice. I think people won't understand when to use the native slice vs this kind of package, with an underlying avl tree.

If the point of using this kind of package because of the "safe" functionality, maybe this package should be named differently & not be under avl.

[moul]

Yes and no. For instance, I've opened an alternative version of an efficient structure to manage lists here: #3407.

However, the comments on my PR suggest there may be valid reasons to use the avl/list (the main one is about soft vs hard delete). Additionally, the alternative aims to embrace the Unix philosophy and Golang composability, demonstrating that we can build layers upon layers.

I plan to use my #3407 alternative in most cases. However, some people are still using a standard AVL map as a list; I believe you're doing this too for the hof realm, for example. Whenever you see someone using an avl.Tree with a seqid, there's a good chance they will prefer this package. For others, my ulist alternative might be a better fit.

I believe we should have such packages, but we need to:

1. Include great comments (let me know if I should improve them here or elsewhere).
2. Provide excellent examples—let's create more r/docs, including one comprehensive guide for all the data structures for easier comparison.