Fern Development Roadmap

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.

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.

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.