Basic proglang naming schemes

NOTE HXA7241 2016-07-24T11:27Z

Programming languages can be classified into two well-known naming schemes (tacit, and non-), but from there one can see a third – naming from intrinsic structure – which seems interesting and underexplored.

The characteristic feature of tacit languages – eschewal of names – brings with it a clearly definable disadvantage. This weakness is rooted in the data-structure of function parameters: with tacit languages it has a vacuous ordering – it has ordering but that ordering is meaningless, a dead weight.

For tacit languages, any single set of parameters can have multiple forms – because of the ordering flexibility. Think of stacks in Forth and Joy. But that opens the possibility that two pieces of code using the same function could be handling the data in different forms/orders, for whatever reason, and that means that to join them together will require bridging that mismatch – shuffling the stack in Forth or Joy. But the ordering/arrangement property is wholly empty, meaningless: the arrangement changes nothing about the meaning of the collection of parameters. And so the ‘wiring-together’ work it gives rise to is wholly otiose.

Normal, non-tacit, languages avoid this problem because they present the data-structure of function parameters as dictionaries, which have no ordering/arrangement. This eradicates the whole difficulty, the whole extra labour, which tacit languages fall into.

(Yet tacit languages can still work well: those which work best confine themselves to unary and binary functions. There, the arrangement of the program text can itself show the connexions – consider J, with its arithmetic phraseology – and that form can maintain clarity while dispensing with clutter, and be powerfully succinct.).


Looking closer, you could say that the difference between tacit and non-tacit is in the style of naming. Both language kinds must address function parameters – that is, select from them – but they do so differently. Normal non-tacit languages distinguish data with names which come from outside: names made up by humans. Tacit languages distinguish data by the arrangement: each item is named relative to the others, as with an array and its indexing. (The non-tacit style you could call ectonominative (ecto = external), and the tacit style you could call internominative (inter = among)).

Non-tacit languages' ectonominativity is bad because it drags in the great mess of human culture: the logical software structure is polluted and distracted with undisciplined shapeless stuff, and consequently choosing names seems an eternal conundrum. Tacit languages' internominativity is decidedly preferable in avoiding all that, but it has its own serious shortcoming: the useless extra wiring-together work.

What we want, perhaps, is another naming style: where names are made from the object itself (endonominative (endo = internal)).

Deriving a name from a thing is about what the thing is. What is a piece of data? Data is really the process which made it: that is what it is. The full name of a data object is the text of the sub-program which produced it – but that would be far too long. So you need a way of compressing that – which seems like a hash. You could have some coherent structured hash, in a neat encoding, and rendered into pronounceable form (‘structural naming’) ... is that the way? ... Or maybe some mixture of the styles? ...

(The only remaining naming scheme alternative besides ecto-, inter-, and endo-, seems to be randomness, like UUIDs (version 4), but that seems very unergonomic.).