-
Notifications
You must be signed in to change notification settings - Fork 685
[Design Task] Guidelines and tooling support for Move code portability #100
Comments
I think you might want to flip tier 4-5? I feel like you might want to itnroduce storage concepts before you do entry points I think the tier system definitely seems expressive, but maybe overkill for a package system.
I the short term we could at least enforce a "library" annotation in the package system, that checks against natives (outside of those in the stdlib?), globals, entries, etc. |
How to define the tier is a challenge. Option 1: Like Rust, a project is a workspace, which corresponds to an address in Move, and there are many crates in a project which correspond to packages in Move. A project can depend on another project's sub-crates. Option 2: Like Solidity, we distinguish between Before finding a good tier solution, we can figure out how to share stdlib. Currently, Move stdlib is embedded in the x-framework in different projects and shares the 0x1 address with the framework. Maybe stdlib can use the reserved address 0x0 and load it directly from the VM. Using the 0x0 address also can avoid module name conflicts between stdlib and x-framework. |
Factor out essentially identical code in translation of operations Operation::{Lt,Le,Gt,Ge,Eq,Ne} into translate_comparison_impl.
Factor out essentially identical code in translation of operations Operation::{Lt,Le,Gt,Ge,Eq,Ne} into translate_comparison_impl.
* Add pseudo metering for type to type tag computation to bound the time and space of the result (#94) * Apply patch * Add override * Set timestamps (#99) * Use charge method (#100) * Apply patch * add header --------- Co-authored-by: gerben-stavenga <54682677+gerben-stavenga@users.noreply.github.com> GitOrigin-RevId: 907c45b6dcf2c2128670a5144b852383f44e0bc8
* Add pseudo metering for type to type tag computation to bound the time and space of the result (#94) * Apply patch * Add override * Set timestamps (#99) * Use charge method (#100) * Apply patch * add header --------- Co-authored-by: gerben-stavenga <54682677+gerben-stavenga@users.noreply.github.com> GitOrigin-RevId: 907c45b6dcf2c2128670a5144b852383f44e0bc8
Move compatibility in general. There were already some compatibility challenges due to differences in frameworks (e.g., libraries that depend on
DiemAccount
aren't compatible with ones that depend onStarcoinAccount
), and Sui Move's data model that differs from core Move's global storage will throw another wrench in the works. Some incompatibility is to be expected given the nature of Move (a platform-independent language that gives platform designers a lot of flexibility to customize both the Move runtime and libraries for their platform). But of course, we should still strive for as much compatibility as possible and suggest best practices that will help with this.Some early thoughts on this:
Math.move
module). They must (transitively) only depend on other tier 1 packages. These are fully generic and can be used by any platform.ASCII::String
in the stdlib). They must (transitively) only depend on other tier 1-2 packages. These can be used by any platform in principle, but there's nothing that stops two platforms from (e.g.) defining and reusing type-incompatible versions ofUTF8::String
. We should try to avoid this by working as a Move community to build canonical libraries of these types.borrow_global
,Table
). These must (transitively) only depend on other tier 1-5 packages. These are only reusable across platforms with the same entrypoint structure and global storage.I'm not sure whether this tiering system should just be an informal guideline, or also something that we try to enforce programmatically in the package system and/or linters. It's worth noting that packages are not organized according to this tiering system today, although some are close (e.g., there's very little global storage used in the Move stdlib). But the overwhelming tendency is toward monolithic tier 6 packages, which I think we should change.
Once we have reorganized packages using these principles, I think there will be a lot more boxes in your diagram above, but the tiering system will make it easier to figure out where we can/should draw dependency arrows and where we shouldn't.
(copied from original discussion in diem/move#91)
The text was updated successfully, but these errors were encountered: