Road-Map which way to the beach?

I have a lot of plans and a lot of things that I want to do with FELT. I've listed some of them here and why they are important to the project...

Converting FELT to FELT...

This is by far the biggest thing that I want to do with it in the immediate future. Once it is re-expressed in FELT, then in theory, with the help of the back-end coders I should be able to produce a working FELT system on any supported platform. Android is my first target; I am an Android developer and the proud of owner of a lovely Sony tablet "S". There is a wonderful project called AIDE which lets you actually develop Android applications on your device; impossible on a phone (I tried it!) but on a tablet with a keyboard plugged in it's actually not too bad despite the small screen. Takes me back to when the height of technology was a 14" IBM monitor in four colours!

My plan for the Android port would be to create a simple IDE (web based using web-kit on the device) that allows one to edit FELT code and then save it and, either as a function of the IDE or as a possible new "preprocessor" instruction, cause that file to be translated into Java to a location within the AIDE project. Then the AIDE would just build-and-go. Developing Android applications in FELT is def. my next step but it's a bit of a way off yet!

I am also an (as yet unpublished, long story) iOS developer too but I lapsed my paid annual membership. Apple, greedy? I still would like to be able to code the non-visual non-framework specific parts of an application for both platforms in FELT and then use XCode to build or for Android I use "SBT" as I wrote my first application with Scala,, a beautiful language indeed.

More unit tests, especially in FELT for Node.js / JavaScript

The current rather small set of units tests "are just enough" for me to know that I've not broken anything internally or to do with PHP code generation. I think that FELT is stable enough now for some brave soul to (a) learn FELT and (b) code unit tests using one of the Node.js frameworks to the extent that reasonable confidence can be asserted that the code generation is sound. I have tested it as I go and building the site has also helped but I'd be happier with it being more formal in the repository. You can't have enough unit tests with things like PHP and Javascript.

Node.js Site

To further improve and test the capability of the process I want to be able to reproduce the entire site as a Node.js site so that all you have to do to see this site on your local machine instead of installing a web-server etc. is this:

svn co ...
cd ..
node feltsite.js

That would be a good test of the Javascript coder and the Node.js coder and would also be a good exercise in creating a coherent set of "language neutrality guidelines" which would be a best-practice reference for writing portable code across languages, for example, how to manage sprintf between PHP and Javascript.

Emacs Integration or <your-editor-here/> ;)

This one I hope to finish pretty soon. In Emacs (and most other editors) you can install a save hook which means that every time you save you can plug in some extra behaviour. Imagine hitting save and having two files saved, your FELT code and the language-X code straight into a build process! That's pretty slick I reckon. It means that the caching system that I built to maximise PHP byte-coding and slow ISP-s wouldn't be an issue. I actually think this is important enough to maybe become more important than coding it in FELT because for most developers, being able to develop "on the device" isn't really an issue; we all have development machines and a bunch of devices to work with.

I think I may well pursue this pretty soon! I like the idea of working in FELT, then hitting "save" and knowing that my PHP / Javascript / Node.js / CSS / etc file is already waiting to execute and it means that you don't need the caching policy at all. The only reason I wrote the cache was to make it more "dynamic" in nature and also of course because:

• it was interesting
• it had to be done!
• to prove FELT can do anything!

I haven't yet decided to use Emacs local mode variables or to create a new instruction in FELT that passes commands to the render process, something like:

(#f:on-render [
    {save-as: "/project/path/myfile.php"}
    {exec:     "some-update-script"}])

Which basically tells the code generation process where to save the rendered output when you run it through the system and then run a script etc. This means that you can have a web site that is developed with FELT but it will not be powered by it at run-time. This serves to once again reduce the installation headaches on existing sites... you get to use FELT but don't need to install it on the already live site, just upload the rendered code and that's it.

LLVM

I am still not sure if this is a road I want to go down for the simple reason that, if I did produce an LLVM back-end, FELT "collapses the wave-function" and becomes an executable beast in its own right. I have played with LLVM and it would mean quite a bit of extra baggage around FELT, after all, it would now be responsible for all those things that it currently just lets the chosen target language do best... it would be something interesting to take on but if it does happen I think it won't be me that does it, I have far too many other things I want to be doing than becoming too familiar with graph-colouring register allocation and all the other wizardry that goes along with this sort of exercise. Not this decade anyway.

Open-GL

Having a fair bit of experience with Open-GL on various things, I have realised that for game writers, being able to code an "ideal form" of Open-GL and then have it ported to the Apple or Android variety, adjusting calls, values etc during translation using the expressive power of PHP (for now) might actually be quite useful. It also means that, for the most part, you can stay way from the peculiarities of any particular UI framework; once the Open-GL loop is up and running, because Open-GL is that cool, your code is already pretty portable in terms of I/O etc. That's putting it simply of course; multi-touch is fiddly at best!

And finally Version 2.0

To some extent I have already started fleshing out ideas for "FELT 2.0" and it won't be called FELT and it will be written in LISP or Haskell, I haven't made up my mind yet! I have already started sketching out a modified LISP reader that can translate FELT code into proper LISP code so that's for the coming winter evenings. It will be good I am sure to get back to LISP. But then there's "parsec" too...