gnolang
Gno Realm and Ownership Spec
The issue is to follow up on the recently introduced document available here: https://docs.google.com/document/d/1eCgGPCJ8fMhNc_vc_pbgCxP10X7jGKLC89nBUGatsD4/edit
The ideal order to complete the GnoVM MVP (not only fixing bugs, etc.) is to at least finish and implement those breaking changes that should be shipped for the launch. These steps are ordered due to dependencies, and all of them are blocking the launch:
- Review and lock this document (the idea is to target a very high chance of not having to change anything, or just minor details)
- Once locked, open one or several "spec PRs" with all changes to structs and interfaces
- Review by Jae (at least) + anyone else who wants to
- Implementation
Additionally, this blocks things like pointer-based registries, see #2535, which is a pattern that deserves several rounds of experimentation before the launch, if possible. In other words, it's a high-priority blocking issue.
Assigning @thehowl and @ltzmaxwell to this, as discussed with Jae, so they can follow up on the topic and represent the EU and US teams. However, feel free to rely on the rest of the team, Jae, or me when needed.
The grantees and community are welcome to help, both on the Google Doc page or by proposing their spec PRs too; but for the sake of prioritization, the core team will directly work on it soon.
We recently discussed the possibility of not supporting local storage for remote realms. I understand this decision, as managing data would become more challenging and restrictive due to garbage collection, realm deprovisioning, or upgradeability. However, I appreciate this feature for its composability and the opportunities it offers. I'm currently brainstorming ways to adapt if we enable this additional inter-realm independence. The first experiment is underway in #3135.
Edit: #3135 is also adding several new gnovm/tests/files/... tests related to cross-realm functionality.
Quick reference of the rules from the google doc:
- Object: array, struct, maps, blocks, BoundMethods, HeapItem.
- has an ID
- other object referenced as RefValues.
- Blocks not persisted.
- Association: struct fields, array elements, map key/vals, closure captures, bound method values, associated with the containing object.
- by value: primitive, struct, array, map, function.
- by reference: slice, pointer.
- Attachment:
- != persistence (only done after a transaction is complete.)
- you can only attach once
- assigning to a global variable attaches any unattached object, recursively to all associated values
- associating something unattached to something attached, attaches it.
- both associations by reference and by value attach
- External types:
a<gno.land/r/demo/realm1> = realm2.Type{}-> panica<> = realm2.Type{}-> ok, but:b<gno.land/r/demo/realm1> = a<>panic.a<gno.land/r/demo/realm1>.Field = &realm2.Value<gno.land/r/demo/realm2>-> ok
Additional?
- Packages don't "attach"; but package values are immutable.
- Cannot
io.EOF = errors.New("...") - Can
a := &io.EOF, cannot*a = errors.New(...) a<gno.land/r/demo/realm1> = io.EOF<immutable>
- Cannot
