Tue May 4 21:05:17 EDT 2010
It was quite a trip today. A lot of fuss, but what are the remaining
* The single assignment procedure (a procedure that receives
variables that can be assigned to once) is a key concept.
It allows decoupling of variable declaration (storage allocation)
and definition (computation and result storage). Both are
combined in `let' expressions.
Separate allocation seems to be necessary for maintaining
efficiency and real-time behaviour for DSP apps: it allows static
This separate allocation mechanism works well for different levels
in the memory hierarchy and works all the way down to the RISC
instructions. At some point the static references (i.e. static
addresses, registers) can be replaced with indirection (pointers)
: this is where we can move from macros to run-time composition
* An arrow is something that behaves as a function (i.e. it has
composition) but can have other structure in addition. I.e. it
could be used to represent a data structure that represents a
* It's possible to interpret the Pd patch format in a way that makes
"connect" an _abstraction transformer_. An abstraction without
connections starts out as a union of sub-abstractions and
subsequent connections eliminate inputs. Independently of
composition throuch connections, inputs and outputs can be
exported, where un-exported inputs and outputs are respectively
defaulted and ignored.
* Memoization over channels: might need to see that first before I
believe it. I had a vague optimistic picture in my head this
afternoon, but not any more.. The problem is "merging" of
environments. Been there. Failed. The right approach seems to
be a fold over term tree structures to restore the "straigt line"
(as in ai/Shared.hs)
* Unification is what we really want in the end. But it seems that
this can't be easily embedded in Haskell, mabye also due to the