Symbiotic relationship of declarative and imperative systems
cputney at whistler.com
Fri Feb 28 07:35:19 UTC 2003
On Monday, February 24, 2003, at 10:15 AM, Stephen Pair wrote:
> In a database system, the declarative spec might be the full
> logs that could be used to recreate the data. If the logs were
> sufficiently general (i.e. they had no direct schema knowledge)...then,
> you could conceivably upgrade a database by simply creating a new db
> with the new schema and then applying the logs.
> A declarative spec is nothing more (or less) than a sequence of
> operations that transition a system from one state to another (not
> unlike an atomic update in the database world). And, when given some
> beginning state, applying those operations will always yield the same
> final state.
This is tricky stuff, so I may not be grasping the subtleties of your
explanation. As I understand it, however, "a sequence of operations
that transition a system from one state to another" would be an
A declarative specification would be a description of the final state
of (part of) the system, with the actual sequence of operations
required to bring that state about left as an exercise for the reader.
That reader might be a progammer such as myself, a simple program
loader like SqueakMap, or a version control system like Envy.
For me, the hard part of this is that we're really talking about
"meaning" which is a very difficult thing to pin down. In my own work I
try to be very clear about what the abstractions that I'm dealing with
actually mean. Usually this involves making sure that my OO model
corresponds the real world in some meaningful way. A step up the scale
of reflection though, it also requires some concept of what's going on
inside the machine, not at a bit level, but at an abstract level that's
both very clear and difficult to describe. Maybe I need more math.
As Alan mentioned, a program, whether specified imperatively or
declaratively, is only meaningful in relation to some interpreter. The
tricky thing about Smalltalk is that that interpreter, the VM, is as
small and simple as possible. The semantics of interpretation are
largely moved into the program its self; the program is the whole image.
Now, in practice we don't deal with the whole image during development.
It's to big to comprehend, and most of it doesn't change much anyway.
So the Smalltalk programs that we develop and distribute are only the
set of classes and methods that implement the additional functionality
needed for the program we're interested in.
From a tool-making perspective, however, these programs are difficult
to deal with in a safe way, because their meaning relies on an
interpreter with variable semantics. They have the ability to modify
the way they are interpreted. If the interpreter is a human reader,
that's not a problem, because we're (generally) smart enough to notice
this and take it into account as we manipulate the program.
If we want to have tools to help us manipulate the program, though, we
need to make some distinction between regular operations that follow
the "conventional" interpretation, and meta-level operations which may
alter the semantics of interpretation. Better fences, as Alan called
them, would be very helpful for several projects in the Squeak
community - Monticello, Islands/Squeak-E, SqueakMap etc.
It seems to me that a declarative representation for Smalltalk programs
is a step in the right direction, though it's not a complete solution.
The program object model that Allen's paper presents would also be
quite useful for manipulating programs. I haven't been able to digest
the ideas behind Squeak-E yet, but is seems like the E folks are a long
way down the road the solving these problems. You can't have security
without safety, so it will be interesting to see what sort of fences
get put up as a result.
More information about the Squeak-dev