Fri May 23 11:23:18 CEST 2008
A plan to attract developers. What is necessary?
- it should work relatively flawlessly for 1 target
- it should be well-documented
- extensions should have a clear API
The first two are mostly perspiration. The real challenge is to
standardize some APIs. I am hesitant though about standardizing too
much: the aim of the project remains the construction of a tool for
'from scratch' development.
- Purrr language extensions
These are at library level, and can be developed separately from
the core project. Purrr standardization is mostly ad-hoc, but due
to PLT's module system, glue layers are fairly straightforward to
maintain, and standardization can be made the responsibility of
the system designer.
- Processor extensions:
Target-specific extensions can be separated entirely from the
Staapl core. The PIC18 architecture specification is an example of
this. It boils down to:
* Creating an assembler. This can be a layer on top of an external
assembler, or a specification in the assembler generator
language. (see pic18/asm.ss)
* Create a set of macros (compiler extension). Map the Purrr
language to the machine structure (data stack, return stack) and
implement the primitives. (see pic18/macro.ss)
The interfaces for these operations are now fairly standard.
- Internal compiler extensions:
Changes to Scat, Macro or the compiler would best be incorporated
as as core changes. Such changes can be temporarily forked, and
later merged into the main distribution. However, I expect this
part of the program to be relatively stable.
- Simulator extensions:
As an addon to the interactive part of Staapl, a simulator
(generator) would be nice. The interface for this still needs to
be developed. This could be written as a processor extension.
- Extra languages:
A future goal is to construct a static dataflow language to
supplement Forth code for building DSP applications. How to
structure this isn't clear yet.
- Application spin-off communities
I'm thinking about Sheep, CATkit and KRIkit: the applications that
have been used to battle-test the Purrr language. This would
involve some kind of Purrr library standard. I'm thinking about
writing something a bit closer to ANS Forth, but there is
insufficient project pull to do it atm.