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.
