Toward Good Transparent Persistency
Overview
I'm trying to design a programming language (or language-replacing technique,
or language-underlying abstraction) to fulfill the two purposes outlined
in the following subsection.
Purposes
Serve as the "native language" of a persistent store.
The conventional
view of a persistent store is from the viewpoint of the world outside of it.
From that view, the store looks like a passive object, to be manipulated
by outside forces, and then queried for its content.
I had rather turn that convention on its head, and say that to understand and
program the interactions between a persistent store and the outside world,
I will adopt a viewpoint inside the
persistent store and see the outside world from there.
The store receives stimuli from the outside world (perhaps from clients
there), and operates on the outside world by producing output.
So that the store will have a way of reacting to
stimuli that arrive from the outside world, it needs a programming language.
It could support multiple programming languages, but there would have to be
a common underlying semantics (or virtual machine if you will)
so that processes written in the different
languages could communicate to each other within the persistent store.
I suppose the way to design an appropriate virtual machine is to
start with the type of high level language, among those I would want
to consider programming the system in, that is most difficult
to implement and most stringent in its world view, and make sure
the virtual machine is appropriate to that language. Other languages
can cope.
So, my primary
purpose in designing this language is it should be the native language
for persistent stores.
Respect the priorities of human beings.
I think the programming languages in wide use lead the
programmer to fail to respect the time priorities of human beings
with whom the computer interacts. A human-computer interface
should not freeze on account of the computer's attention being
diverted.
Biases
The languages shall be declarative.
Why not have referential transparency? Some people seem to think it makes
reasoning easier.
Fully lazy evaluation seems worth while, at least at some level.
Relational languages (like ToonTalk) may have a place alongside functional languages. But
the fundament maybe should be functional? The functional view of relational
execution should be as smooth as possible.
Questions
Linear logic, or not? Should the syntax support fan-out other than by copying?
Translate lazy to eager? How to express computing money, and its consumption?
How do I tell the story of hot code update?
Can I avoid a reflective tower?
Alternative Solutions