Data transparency notes

The following is JAR's reverse engineering of what VKM has said, and of the Metaprob design as inherited from Alexey. It is not something JAR has committed to or necessarily even cares about personally. It is offered as a way to draw other people out regarding this idea, which I have not seen spelled out with enough explicitness to be actionable.

• Roughly speaking, data transparency means that all data bottoms out in scalars (things with simple structure, like numbers). There are no encapsulations (e.g. functions) that can't be broken by some hammer that is provided (perhaps behind glass).
• Another word might be 'first-order'. Functions can take grounded values as arguments and return them as values, but they don't take functions. (ADT instances are a kind of function.) They can take representations of functions, which they then interpret, but not the functions themselves. Examples of first-order programming languages are machine code, Lisp 1.5, 3-Lisp, TRAC, Pascal, SNOBOL3.
• I think it might be nice to have full data transparency - 3-Lisp, for example, has it - but if there is no application for it that we care about, then it is foolish to spend much time thinking about it.
• First, observe that a formal semantics (see above) will have a domain or 'uber-type' for all possible data values (expressible values), and it will have an enumeration of all of its possibilities. For each type, For a semantics in the operational style, the language will have introduction and elimination primitives. which have to be reversible (you can reconstruct (introduce) any compound datum from its (eliminated) parts), and which the semantics will specify. The denotational style is a bit more general but relies on a fixed set of irreversible mathematical constructions such as lambda abstractions - not arbitrary data abstraction. So...
• We might imagine the possibility that some meta-circular interpreters will share this aspect of the structure of a formal semantics - it will have an uber-type grounded. (I'm just trying to repeat something I thought I heard VKM say about the connection between semantics and data - just the unreliable messenger.) That is, it will reflect not only on interpreter states, but on data that might in other setting be encapsulated.
• To understand this idea, consider a few common operations that would be enabled by data transparency:
  • equality checking
  • 'diff' (summarizing the differences between two data values)
  • 'patch' (the inverse of 'diff')
  • search - does a given scalar occur in a given datum?
  • debuggers, inspectors
  • serialization
  • garbage collection
• In languages like Java, these operations are provided without being comprehensive over all types, and when they are provided they require special methods on those classes that participate. This is very different from how a formal semantics works: the semantics is comprehensive - it knows about everything.