You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I'm suggesting is to have a way to specify that the order the cells are defined in matches the cell execution order. This can be an App parameter and a setting in the editor UI. Attempting to use globals defined in later cell would then cause an exception.
Introducing this restriction can allow unambiguous reassignment/shadowing of globals. Essentially, any external name used in a cell must come from the nearest preceding cell assigning to that variable. This also means any prior definitions have no relation and can be treated, for all intents and purposes, as different variables. Under the hood shadowed variables can be disambiguated by storing them at a key of (name, defining_cell_id).
The benefits of this approach are that it combines the user-facing convenience of redefining/shadowing globals (allowing to reason with simple constraints such as "df holds the current state of the dataframe" with the strict unambiguity of the underlying implementation. Since the semantics of shadowing match up almost perfectly with true variable redefinition (except shadowed variables continue to exist since the runtime maintains references to them like any other global), this is compatible with existing tooling (such as type checkers and IDE/LSP features), as well as established mental models. On the other hand, I reiterate, marimo's strict correctness guarantees are not compromised; the editor still can confidently link the variable reference with the corresponding assignment statement, and so on.
Another upside, beside variable redefinition, is that an in-order notebook is actually even easier to reason about than otherwise. I think this is in line with marimo's values of code that's easy to read and understand.
I know adjacent topics have been discussed already (mostly in #1477), but I haven't found any suggestions of this or similar approaches to it, so I decided to post this (as a discussion). I think this is a neat way to address a big pain point with marimo (at least for me) without any compromises. If this was already proposed somewhere and I just missed it, I'll appreciate if you tell me.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
What I'm suggesting is to have a way to specify that the order the cells are defined in matches the cell execution order. This can be an
Appparameter and a setting in the editor UI. Attempting to use globals defined in later cell would then cause an exception.Introducing this restriction can allow unambiguous reassignment/shadowing of globals. Essentially, any external name used in a cell must come from the nearest preceding cell assigning to that variable. This also means any prior definitions have no relation and can be treated, for all intents and purposes, as different variables. Under the hood shadowed variables can be disambiguated by storing them at a key of
(name, defining_cell_id).The benefits of this approach are that it combines the user-facing convenience of redefining/shadowing globals (allowing to reason with simple constraints such as "
dfholds the current state of the dataframe" with the strict unambiguity of the underlying implementation. Since the semantics of shadowing match up almost perfectly with true variable redefinition (except shadowed variables continue to exist since the runtime maintains references to them like any other global), this is compatible with existing tooling (such as type checkers and IDE/LSP features), as well as established mental models. On the other hand, I reiterate,marimo's strict correctness guarantees are not compromised; the editor still can confidently link the variable reference with the corresponding assignment statement, and so on.Another upside, beside variable redefinition, is that an in-order notebook is actually even easier to reason about than otherwise. I think this is in line with
marimo's values of code that's easy to read and understand.I know adjacent topics have been discussed already (mostly in #1477), but I haven't found any suggestions of this or similar approaches to it, so I decided to post this (as a discussion). I think this is a neat way to address a big pain point with
marimo(at least for me) without any compromises. If this was already proposed somewhere and I just missed it, I'll appreciate if you tell me.Beta Was this translation helpful? Give feedback.
All reactions