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