I've been making projects avaible on Github for a while now. The last one was guitktk. What I didn't say much about is that all the repositories are intended to form one big project. (Most of them also have uses on their own.)
Go ahead and take a moment to guess how they're supposed to all fit together.
An extension of the last Forth in the tutorial provides the x86_64 assembly primitives for Flpc. Although Flpc is written in C, some of its interface is kept similar enough for a possible transition back to assembly.
Everything else is intended to be written in Flpc with custom sublanguages (DSLs but maybe very different from Flpc) once the runtime modifiable grammar is up and running. Desgin languages to keep descriptions to the point.
The parser, compiler and pretty printer for everything.
Prototype for the interpreter for Flpc (originally I didn't intend for it to also have a compiler but I think that's unavoiable now). At first, Flpc was going to be Forth only until its boot sequence got a parser and python_terp style interpreter running.
The graphical "backend" (or rather layer talking to other backends), written in Flpc (originally intended to be python_terp).
guitktk uses a tree based document and pyzdb is intended to store that in memory and to disk, with undo and redo operations.
The core of pyzdb. Subsumed by persistent_doc.
Replaces undoable with persistent data structures. Intended to have the same benefit: nested Python (or Flpc if it ever got there) objects with easy undo-redo.
persistent_doc is currently the underlying document in guitktk.
Once enough GUI objects are built in guitktk, they would be used to create an editor from themselves using some tkui style tree manipulation.
That's the end of what's available but not the end of the larger project!
Use tkui to create an environment in which to make editors.
Use the editor maker to make editors by binding (non-graphical) libraries to tkui to make tutorials and videos about itself.
Make another tutorial, but this one about rewriting a copy of the entire system itself from scratch.
And finally, finally use (and evolve) the editors to make other programs and live visualizations. Also connect an animation library.
Make an "editor" for search and viewing articles on topics pertinent for making itself. Quickly find and view important theoretical concepts from different scientific areas.
Hot replaces pieces of the project with better design made from these.
Have a simple enough VM so the entire system can be easily ported elsewhere. (Either that, or simplify the rebuilding from scratch steps enough that remaking a copy is less expensive than porting.)
But even when each piece is stretched, there are still large gaps between them.
At least all the parts under What's next in Flpc. Plus a way to connect to one or more graphics library. (Or even more wishfully, with a custom vector to raster rendered.)
A lot actually goes into the basics of a UI toolkit. Ideally, when making tkui from within guitktk, I want to think about how to do this in a way that matches guitktk's model (or modify that model) instead of just hammering away.
python_terp is too slow and needs to be made faster or replaced (if the upper layers will be written in it instead of Flpc, that is).
The x86_64 assembly in forth_tutorial doesn't quite match the C functions in Flpc. (And debugging at the C and asm level is hard for me.)
Running some estimates, that's at least 24 weeks full time to get a bare-bones combination of the current parts plus an editor.
That tries to account for testing and debugging but not potential design and architectural errors, which are likely especially in the less detailled parts. And estimates always underestimates anyways. Either way, its too much.
The original idea was to have programs created in some parts help makes programs in other parts and not just be used as libraries. While some programs can help with making themselves, they are still less useful than pre-existing tools, despite the flexibility and knowledge of the entire source.
Beside, the main point is to built things out of the final editor from this project so that'd been even more time. And their requirement on time isn't light either.
Some ideas for reducing the time needed.
Remove some restriction on what can be used in the host language for Flpc and allow creating and accessing a key-value pair storage as primitive (hash table or AVL tree or ...).
Make a skeleton visualizer straight from guitktk and use it as a visual debugger to make Flpc. This would mean making guitktk more complete first and using that version to later replace itself with a new version written in Flpc. Because of the potentially improved ergonomics, it might end up taking less time to do overall.
Maybe use a Python to Flpc dialect AST transformer in pymetater later on to avoid manually porting Python to Flpc.
Maybe its possible to cut everything below python_terp because of my erroneous estimate. I'd still need to have a better idea of the worst speed ratio from tree interpreted to bytecode interpreted. And potentially make up some of the difference later on by compiling to closures?
Posted on Mar 27, 2018