Let's get the basics nailed down and working so that we can learn
them, before wandering any further into theoretical CS.

On 8/18/13, James Bowery <jabow...@gmail.com> wrote:
> Of the two key conceptual gaps in current programming language philosophy
> -- commensurability and change propagation -- commensurability, if filled
> with due rigor, has the greatest potential for clearing up confusion by
> recasting other core features as derivative.  Change propagation (eg:
> properly voiding memoization in lazy functional evaluation aka incremental
> tabling maintenance in relational evaluation) is something I attempted to
> address in Perl back in 1999 but was blocked by a bug in recursive use of
> the tie machinery.  However, since that time I've come to the conclusion
> that as important as change propagation is to put into the core machinery,
> it isn't nearly as fundamental as is commensurability.
> Let me introduce commensurability with the seemingly trivial example of
> "units conversion".
> Units conversion is normally tacked on as an after-thought in programming
> languages.  (Digression: One programming language that had units built into
> the compiler was the PLATO system's "TUTOR" programming language -- a
> generally nasty language which I encountered while programming
> Spasim<http://en.wikipedia.org/wiki/Spasim> -- that,
> nevertheless, pioneered some interesting concepts due to the relative lack
> of precedent in programming languages targeting "ordinary people" like
> teachers.) However, while doing real world calculations, correct handling
> of units via automatic conversion is, in fact, more important than "type"
> checking.  Underlying units checking (and conversion) is commensurability.
>  For example, apples are not, in general, commensurable with oranges:  a
> ton of apples should _not_, in general, be added to 3000 kg of oranges --
> although adding a ton of apples to 3000kg of apples makes sense as we are
> dealing with commensurable quantities although in differing units.
>  Moreover, by incorporating dimensional analysis into the arithmetic
> machinery, not only can units conversion be automated, but arithmetic
> expressions themselves can frequently be automatically inferred from the
> inputs provided along with the units of the output demanded (see the
> semicolon ';' operator of the Calchemy units
> calculator<http://www.testardi.com/rich/calchemy2/>
> ).
> While well-designed type machinery, based on things like assertions and
> coercions, can be adapted to implement automatic units conversion (hence
> checking), that is getting the cart before the horse.  Here's why:
> If we accept the idea that the higher level of expression we allow the
> programmer, the better (as it leads to more disciplined separation of 'how'
> pragmas from 'what' specification during the authoring process) then we
> should recognize that relational expression should be core since functions
> are (sugarably) degenerate (many to 1) relations and procedures are
> (sugarably) degenerate (state-transition) functions.  If we have relational
> expression as core, commensurability, hence units handling, falls out of
> what Bertrand Russell called "relation arithmetic" in Principia Mathematic
> volume IV.  The most advanced work in applying relation arithmetic to
> programming language design was done by the late Tom Etter while at Paul
> Allen's thinktank "Interval Research", with Tom's follow-on work at HP
> funded under my (very limited) authority there.
> Tom's paper, "Relation Arithmetic
> Revived<http://www.boundaryinstitute.org/bi/articles/Relation-arithmetic_Revived_v3.pdf>"
> documents Russell's conflation of relational similarity with relational
> congruence as the mistake that blocked practical application of relation
> arithmetic in Codd's work on relational algebra -- hence things like "the
> object relational impedance mismatch".  However, if we look deeper into
> what was going on, we find that the very idea of "sets" -- hence the normal
> notion of "data types" -- is similarly ill founded, as we can, and should,
> bootstrap "set theory" from a more fundamental theory of relative (or
> relational)
> identity<http://www.boundaryinstitute.org/bi/articles/Three-place_Identity.pdf>
> .
> Just how far do the implications of this go?
> Well, for starters, the core laws of quantum mechanics fall out as
> completely general theorems of relation arithmetic generalized to include
> "negative" relationships (opt cit).  Among the implications of this are
> core programming language constructs for quantum information systems.
> Sorry if this throws a monkey-wrench at, if not into, the works -- but the
> Perl culture is one of the few places that is has the philosophical
> equipment to take such a lofty concept as commensurability and commit just
> enough Ockham's Chainsaw Massacre to retain much of its value in practical
> programming systems.

Reply via email to