Maybe Perl 7.
On Mon, Aug 19, 2013 at 2:30 PM, Parrot Raiser <1parr...@gmail.com> wrote: > 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. > > >
