This is something I'm attacking right now. I'm undecided how far I want to take the series, but this is Post #1:
http://michaelochurch.wordpress.com/2013/05/06/constructing-...The starting point of this computation model is:
1. There are symbols and nonsymbols.
2. Symbols can be equality-compared (eq'd).
3. Nonsymbols can be observed for behavior (in symbols returned) but not eq'd.
The set of symbols is countable and includes:
1. Natural numbers.
2. Unique symbols for arbitrary "dictionary words", e.g. _error.
Nonsymbols represent mappings that take nonsymbols or symbols and input and return nonsymbols or symbols. That's not well-defined (and it's not even a
set) but we are only concerned with those that return symbols (i.e. can be observed) after certain input patterns. For example, A : {_ => A} and B : {_ => B} are both nonterminating but behave identically based on what we can actually observe; it's meaningless to argue about whether they are "the same" and since nonsymbols can't be eq'd, also unanswerable.
Code (as in source) is essentially a process that takes a natural number (viewed as an array of bounded natural numbers) and converts it into something that behaves as a nonsymbol, at least over inputs we care about. Of course, there are many nonsymbols that we can't represent in code, such as one corresponding to the Halting Problem,
{$sym => 0, $nsym => 0 if exists k s.t. apply^k($nsym, 0) is a symbol,
1 otherwise.}
Maps, vectors, and sets give us tools for describing extremely well-behaved (finite support; returning _error on the not-found case) nonsymbols in code; functions give us a language to describe well-behaved infinite-support nonsymbols.
The neat thing about traditional functional programming is that it carries an implicit will to focus on well-behaved nonsymbols. Object-oriented programming hasn't stepped away from the full space of nonsymbolness-- and that's a big part of why it's so damn hard to reason about it.
The starting point of this computation model is:
The set of symbols is countable and includes: Nonsymbols represent mappings that take nonsymbols or symbols and input and return nonsymbols or symbols. That's not well-defined (and it's not even a set) but we are only concerned with those that return symbols (i.e. can be observed) after certain input patterns. For example, A : {_ => A} and B : {_ => B} are both nonterminating but behave identically based on what we can actually observe; it's meaningless to argue about whether they are "the same" and since nonsymbols can't be eq'd, also unanswerable.Code (as in source) is essentially a process that takes a natural number (viewed as an array of bounded natural numbers) and converts it into something that behaves as a nonsymbol, at least over inputs we care about. Of course, there are many nonsymbols that we can't represent in code, such as one corresponding to the Halting Problem,
Maps, vectors, and sets give us tools for describing extremely well-behaved (finite support; returning _error on the not-found case) nonsymbols in code; functions give us a language to describe well-behaved infinite-support nonsymbols.The neat thing about traditional functional programming is that it carries an implicit will to focus on well-behaved nonsymbols. Object-oriented programming hasn't stepped away from the full space of nonsymbolness-- and that's a big part of why it's so damn hard to reason about it.