The core logic will be written in F# that is ignorant of view/UI implementation details. The view/UI code will be written in C# (or should it be in F#?).
The view code should absorb the complexity of the translation between F# and C# and especially of the translation between Void's model of the view and the GUI library's model of the view.
The UI/View is to handle all logic which is closely coupled with the implementation details of the UI, but not its conceptual model, such as the details of a particular graphics library. The view model is to model the UI. However, this model is conceptually different than the total current state of the editor (in other words, there is not a one-to-one between everything in the editor's state and the screen, or everything on the screen and the editor's state). The model and view model should be written functionally (stateless) and wrapped in lightweight stateful (micro)services that talk by message-passing (though preferably without having to directly dependent on any messaging glue). Thus we are shooting for a sort of internally service-oriented, message-based architecture.
Loose coupling is to be maintained by the use of commands and events. The view model should be generated from events off the core model. It should not make direct calls to the core model.
TODO - talk about the Requests API
TODO - add stuff about the design of Command Mode and VoidScript.
- Should we use actors for the services?
- Concurrency?
Pending, but will imitate VsVim and other known good patterns.