Description
Multiple editable modules
Dependencies
#320, as actions will need to say which module to add a definition to etc.
Spec
We let a given program have multiple editable modules.
This will change the serialisation of programs into the DB. However, since the DB sees it as just a json blob, there are no schema changes. A migration will be needed in order to load existing programs however. (Though I expect we will decide not to bother since we currently have no programs we care about migrating, similar to #293.)
We will need to change the API to account for modules (this will also change the serialisation, since we record actions in our "undo list"):
- We will change
viewProg to return a list of Modules. I.e. we will always emit the entire program. This could obviously be revisited later when we discover what access patterns our frontend will have.
- We will change the notion of a
Selection to include a module identifier, so our "cursor" will point to a particular definition in a particular module.
- Most API calls are local-to-the-cursor (or at least, local to the definition the cursor points within) and do not have to change.
- The ones that are not (
MoveToDef, RenameDef, CreateDef, AddTypeDef, CopyPaste*, VariablesInScope, GenerateName) mostly already take an identifier of a definiton: these will also need a module identifier (probably simply by dint of being part of the definition identifier); those "creation" ones that do not will have to somehow change — see "Implementation details below"
Implementation details
We need a better name than "editable". I'll start calling these "home" modules, by analogy with ghc's "home packages". (We considered "local", but that word is already used elsewhere, and could have first-class-module connotations)
Whilst we only require generated IDs to be fresh within one module, it will be easier to implement one shared ID generator for all editable modules.
How does CreateDef and AddTypeDef know what module to target? We could either expand our notion of "selection" to be able to select a module (rather than a definition in a module), and use that; or we could just give an extra argument to these API calls. We will use the second, as it is simpler and not stateful and I feel the cursor abstraction works well only for a series of local actions "create an application, then in its first child do ...". (It may be less bandwidth-efficient, but we expect to not use these actions often enough that this should matter)
Not in spec
Deleting editable modules and/or imports (we will tackle this after we tackle the same issue with type definitions)
Most not-in-spec things from #265 and #320 apply (but are obviously orthogonal).
Discussion
None
Future work
Revisit how to get a program listing from the API. We may want to be able to ask "what is the contents of module X", rather than just "show me all definitions across all modules". However, this will be easy to change later and it is not yet clear what would be best (I don't know the access pattern of the frontend or how worried about large HTTP responses we need to be).
See "Not in spec"
Description
Multiple editable modules
Dependencies
#320, as actions will need to say which module to add a definition to etc.
Spec
We let a given program have multiple editable modules.
This will change the serialisation of programs into the DB. However, since the DB sees it as just a json blob, there are no schema changes. A migration will be needed in order to load existing programs however. (Though I expect we will decide not to bother since we currently have no programs we care about migrating, similar to #293.)
We will need to change the API to account for modules (this will also change the serialisation, since we record actions in our "undo list"):
viewProgto return a list ofModules. I.e. we will always emit the entire program. This could obviously be revisited later when we discover what access patterns our frontend will have.Selectionto include a module identifier, so our "cursor" will point to a particular definition in a particular module.MoveToDef,RenameDef,CreateDef,AddTypeDef,CopyPaste*,VariablesInScope,GenerateName) mostly already take an identifier of a definiton: these will also need a module identifier (probably simply by dint of being part of the definition identifier); those "creation" ones that do not will have to somehow change — see "Implementation details below"Implementation details
We need a better name than "editable". I'll start calling these "home" modules, by analogy with ghc's "home packages". (We considered "local", but that word is already used elsewhere, and could have first-class-module connotations)
Whilst we only require generated IDs to be fresh within one module, it will be easier to implement one shared ID generator for all editable modules.
How does
CreateDefandAddTypeDefknow what module to target? We could either expand our notion of "selection" to be able to select a module (rather than a definition in a module), and use that; or we could just give an extra argument to these API calls. We will use the second, as it is simpler and not stateful and I feel the cursor abstraction works well only for a series of local actions "create an application, then in its first child do ...". (It may be less bandwidth-efficient, but we expect to not use these actions often enough that this should matter)Not in spec
Deleting editable modules and/or imports (we will tackle this after we tackle the same issue with type definitions)
Most not-in-spec things from #265 and #320 apply (but are obviously orthogonal).
Discussion
None
Future work
Revisit how to get a program listing from the API. We may want to be able to ask "what is the contents of module X", rather than just "show me all definitions across all modules". However, this will be easy to change later and it is not yet clear what would be best (I don't know the access pattern of the frontend or how worried about large HTTP responses we need to be).
See "Not in spec"