[<<][staapl][>>][..]
Fri May 23 11:23:18 CEST 2008

Community bootstrap

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.



[Reply][About]
[<<][staapl][>>][..]