this was an experiment to create a terminal-based structure editor for proto3. the goal was to overcome the limitations of computer languages and textual representation, to present a user interface that makes invalid input impossible, and try to create a modal keyboard control mechanism that is effective and convenient.

Go was chosen for this prototype because it is the one statically typed language I am fluent in. it is obviously not an optimal tool for a safe implementation, and hence much swearing was involved in the process. Python was used for a first draft, but due to its dynamic typing and lack of module isolation it is obviously not up to the task of actually making errors in API client implementation impossible. while Haskell or Idris may be much more suitable for a safe, type-driven design, I simply lack the proficiency. it looks like it is too much of a hassle to work with graphs and user interfaces. Rust seems to have a most suitable combination of strong static type system and reference handling, but no practical experience with the language was too much of a risk to build something explorative.

that experiment failed due to the wrong approach and tight time constraints which did not allow for a second attempt. instead of inspecting the protobuf compiler to see how my idea may fit in, I tried to reconstruct the semantics from mostly the language specification and some trial-and-error with the compiler as a blackbox. the result is therefore only a fraction of the desired goals: a core library for safe document construction on the semantic level, which still does not account for many corner cases and does not handle string representation properties such as item order. if that had been successful quickly, the next step would have been a wrapper around it, which behaves closer to how documents are handled in text editors, and eventually at least a minimal keyboard-driven terminal user interface to showcase how to work on such a non-textual document.

a more reasonable way would have been to reuse the descriptor.proto intermediate representation from protoc and closely mimic how DescriptorBuilder converts it into an interlinked data structure. then the library's core would be a bidirectional converter between the protobuf and in-memory representation of a (collection of) document(s), with appropriate validation when parsing the protobuf. as a side effect any guessing about operational semantics would be unnecessary. with additional validating setter methods on the descriptors (as outlined already in the current implementation) this library would essentially constitute an incremental protobuf compiler (by design without a syntactical front-end!), as opposed to the fundamentally batch-oriented protoc. eventually this strategy would make interoperation with existing documents and tooling almost trivial: binary code generator plugins such as protoc-gen-go, which consume a CodeGeneratorRequest, would directly get the output from the converter via stdin. native generators would either require a C++ wrapper that preprocesses the input with DescriptorBuilder or may be invoked through protoc by simply passing a print-out in proto3 syntax. existing documents can easily be imported by acting as a plugin to protoc and take a CodeGeneratorRequest with the parsed and pre-validated document collection.

this project is mainly inspired by a discussion I had with the developers of samak. if you are working (or just tinkering) in the area of incremental compilation - ideally of some relatively simple declarative language such as Dhall - or non-linguistic computer program construction tools^[1] I would like to hear from you!

[1]: ...lacking a better term. while the unsuitably named "graphical programming languages" usually do not present opportunities for syntax errors, a program construction tool does not need to be graphical. "structure editor" is mostly the right thing, but its conventional meaning does not coincide with my intentions, as the structure editors I am aware of only allow to work on some syntax tree, but not the underlying graph structure. what I mean here is a generic user interface to some model of computation.