Fern Development Roadmap

This will be done to look more like what was in the The Power of Structure article, but cleaner. In fact, all of the API can be minified and reduced in various ways.

An example of meta info: the list of local-only slots. There will be some other stuff too, like advice, probably. But garnet provides some other declarations via it's :declare syntax, and each thing there will have to be looked into carefully, case-by-case.

Right now, that kind of info is held as part of the kr object and has a special interface. It would be better to just hold these within the slots of the object itself. This would simply be more beautiful, so to speak.

How this is done might depend on the meta info itself. The usual :declare syntax (to be ditched) is read before the slots themselves are read. So, losing the order might mean some things might have to be done dynamically now (some already were).

It's yet to be seen how this is done exactly. Generalized selectors might come in handy here. Some meta slots might be needed early on (like local-slots) and so this feature might have to be implemented soon, but at least in part.

Advice like in Emacs. That usually implies: adding a pre-hook, or a post-hook, or around-wrapping. It should be easy to inspect the existing advice and remove/redefine it. Emacs uses named advice to that end.

Several kinds of advice were identified (the following + the constraints). The interface should be as uniform as possible.

Clojure does the reasonable thing with its multimethods: it recognizes that it may be really useful to dispatch based on some function of the value, rather than just on its type. I am still thinking through the mechanics of this, but it's clear to me that CLOS/MOP is not to be used for the simple reason of its complexity beyond reason. But I don't find Clojure's approach fully satisfactory either.

As of this moment, I think that a decision tree should be built, where the slots are ordered, and each slot contains a user-supplied decision function. And defining a method would simply add to this tree. Such trees could of course be modeled as schemas, and that will yield a free, easy and inspectable interface to these functions.

Of course, such dispatch won't readily yield good performance, but probably no worse than CLOS. But it can be achieved via declarations where necessary (I am wondering if declare can be reused for custom stuff, but it's not strictly necessary).

Later on, these functions can be used in constraints as well.

This feature also allows custom containers to be used along/in place of the default hash-map. The runtime option of slot addition/removal should always be preserved though, but that might simply be a requirement for any new user-supplied data structure.

Edit: this would be nice to have, but this complicates things needlessly, even though I have a pretty good idea of how to do it. The parametrizable pointer variables will have to be done seperately anyway, and working with containers can be done without this. So, unless I encounter some really good use-cases, I will assume this feature is not needed. It is quite an entertaining idea, however.

This will be done to look more like what was in the The Power of Structure article.

Requires generalized selectors.

A very important usability feature. How hard this one will be is yet to be seen. At a glance, screwing with the constraint engine shouldn't be necessary.

These will have to modify the constraint objects themselves. I imagine the constraint object could hold some kind of a kr object within that would contain all the advice info.

In fact, I am thinking, it might be useful to turn the constraint objects into KR objects. Then you could just store functions in KR slots and advice them like you would advice any other function. This would solve the advice problem, and it would allow constraint inheritence, which is arguably a more serious problem. Currently the constraints are simply copied. Instead they could use the mechanism of contextual inheritence (where the slot isn't copied, but instead the object is instead inherited from the parent slot; the semantics of this is yet to be fully specified).

But doing this would also expose a simple, familiar way of modification and inspection.

Might come in handy for lengthy operations.

If a constraint output is defined as async, then the constraint simply spins off a thread for its execution. Once the execution is over, then the structure is locked and modified.

It should be possible to sync all such outputs, so that their modifications are applied all at once (once they are all finished). In this case, all outputs need to be executed asynchronously.

Whenever a constraint calculates an output, it will write the value to the output slot, which may trigger further recalculations. This may be wasteful when the output is the same as the previous value.

The user should be able to supply an equality predicate that indicates whether the value is the same as the last one or not.

Syntactically, this will be done like the async stuff, and maybe even like advice: just by storing this type of info in some kr-object of the constraint.

For geometry, that would be KR equivalents of geometric objects.

Linear algebra just needs to be tested in the course of the development, just to see that everything holds up right.

See Fern Overview + KR and Constraints for details.

Just kr-objects that hold information about some event like a mouse click or a keypress.

These don't have to be comprehensive, e.g. stuff like joystick input can be safely skipped for now. The window events might not be necessary either: they backend should modify the appropriate properties of the top-level cell directly.

• SDL2/CategoryEvents - SDL Wiki

The interface for this will be inspired by Pango. Maybe even simpler (aka skewed or bent text is not exactly a requirement). Only proportional fonts are.

Backend-wise, Pango works well with Cairo, and there's a way to use and SDL surface for Cairo. There is a way to draw Pango directly to an SDL2 texture too, via SDL2_Pango, but the work for that has to be tested as it seems to be pretty new. It shouldn't matter too much for a backend at this point, but the Cairo variant might be easier to install, and is probably better-tested.