Comment by michaelochurch | Hacker News Reader

Comment by michaelochurch | Hacker News Reader

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.

I like this as a more systematic starting point, with more direct application than the high-level conceptual approach I gravitate towards.

One quibble -- I would prefer non-negative(!) terminology, i.e., what is a "nonsymbol"? A collection? A monad? A duration? An event? A process? A closure? Some category that encompasses all of these? If so, can we find a positive semantic rather than negative?

>> 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.

Well, this gets back to the ancient problem of "The Third Man" and categories in general, right? One must categorize and "contain" meaning, trap it in language a moment in order for it to remain meaningful, but paradoxically the external thing that it symbolizes is always changing, so it's always escaping any semantic trap we set for it. This of course has practical (concurrent) implications in software as well as the high-falutin metaphysical stuff Plato was talking about.

These days I'm starting to wonder more about how we may not be using state-machines quite as effectively, or as often, as we might -- changing functionality more aggressively as the data changes, in order to move towards a better analogy with the ever-changing "real world" that software is trying to model. Might this be more self-aware starting place to integrate functional and object concerns -- both of which are necessary?

One quibble -- I would prefer non-negative(!) terminology, i.e., what is a "nonsymbol"? A collection? A monad? A duration? An event? A process? A closure? Some category that encompasses all of these? If so, can we find a positive semantic rather than negative?

Good question. I tend to think of it as a stateless (I haven't added state to the model yet, and there are myriad ways of doing it so I'm debating how to do it) object. To apply it to something (symbol or nonsymbol) is like sending a message, and the result of the apply is what it returns.

Nonsymbol is deliberately vague, meaning "we don't know what this is". We need a context to make sense of it (e.g. observe _size, then if that's a natural k, observe 0, ..., k-1; it it's not, it's not in the Vector context) and if it doesn't play by the rules of a known context, we're screwed. We continue to need context when we "array-ize" nonsymbols into natural numbers.

Nonsymbols are like functions; however, a function has a well-defined domain and non-symbols don't. However, the only useful nonsymbols are "function-like" in that some sequence of symbols and known nonsymbols will produce an observable (symbol).

Interesting, this seems very similar to Haskell at a very basic level.

A Haskell program consists of declarations of functions and constants. Constants belong to the class Eq

http://www.haskell.org/ghc/docs/latest/html/libraries/base/D...

Functions do not.

How is your notion of nonsymbol/symbol different from function/constant?

They're very similar. I would say the only difference is that I intend on using function for a specific subset of nonsymbols, and also that I intend for it to be a code construct (nonsymbols are not code; in fact, it's impossible to capture most nonsymbols in code). Pathological nonsymbols do not really feel like functions. However, one could construe nonsymbols as being HOFs (the worst of which would be ill-typed in any sane type system, such as Haskell's).

Reply on news.ycombinator.com