Symbiotic relationship of declarative and imperative systems

Colin Putney cputney at
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 
> transaction
> 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 
imperative specification.

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 mailing list