[<<][staapl][>>][..]
Thu Jul 10 16:21:51 CEST 2008

functional forms (FP in Coma)

So, embedding functional forms in Coma.

 Q: What is a functional form?

It is a macro which takes multiple macros as arguments. Elaborating on
the first example in Backus' FP paper: the inner product, this becomes

  inner = trans (*) map (+) insert

This is as much about datatypes as it is about functional
forms. 'trans takes a 2D vector and transposes it, 'map takes a 2D
vector and applies a function to each inner vector, returning a vector
of results. 'insert takes a vector and folds it with a binary
operator.

The thing which feels a bit strange here is to have unary
functions. All stack operations are automatically mapped to vector ->
scalar functions. We could use a vector -> vector lift too, for macros
with multiple return values.

Embedding FP in a concatenative macro language:

   * all functions are unary (arity 1 -> 1)
   * pure stack macros can be lifted to FP functions in 2 ways:
        vector -> scalar  (one result)
        vector -> vector  (one or multiple results)
   * functional forms have arity n -> 1 and operate on unary functions.

So, the trick is to somehow hide the lifting of unary stack ops ->
unary vector ops. The easiest way is to see the stack as the outer
vector wrapper. This however doesn't 'unpack things by default.

I.e., in FP, the '+ function behaves like:

      +:<1,2> = 3

and not

      +:<1,2> = <3>

Using only the top element seems a bit dirty (for the same reason that
'map feels dirty), but it does seem to be the most convenient
approach.


 Q: Does everything look like a nail?

Is this just a small gimmick, to have an embedded FP macrolanguage for
creating (inlined) expression evaluators, or is it genuinely useful to
construct (static) DSP structures in control applications where most
glue logic is Forth? I guess if I can re-implement Krikit I have a
proof of concept.



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