Sat Apr 9 10:38:31 EDT 2011

Parser-oriented programming

The USB driver is moving forward.  I found a way to use structs in
Forth, by turning them into streams, and writing parsers.  The golden
rule seems to be: don't use datastructures in Forth, use streams,
tasks and/or state machines.

The point-free style works better with ``parser-oriented''
programming.  Or Stream-oriented if you want.  Optimize the protocols
to make use of this.  I.e. a simple trick to reduce memory usage is to
always prefix the size of an array instead of using a termination
condition.  (Pascal strings vs. C strings)

If you think of it, data structures are only postponed execution.
This is very apparent in a language like Haskell: think of
deforestation optimization where constructors and pattern matching get
combined to eliminate the data structure entirely[1].

On an embedded platform this is even more true since you really are
more interested in process and IO than for a normal computer, which
would be data-storage central.

EDIT: Found something on LtU that advocates quite the opposite[2].

The thing is that time in computation is not of the same quality as
time: it doesn't support random access (until it's buffered,
i.e. "rotated" into space.

EDIT2: It's an implementation issue: what kind of high-level
description will produce a low-memory implementation?

[1] http://homepages.inf.ed.ac.uk/wadler/topics/deforestation.html
[2] http://lambda-the-ultimate.org/node/925