Symbiotic relationship of declarative and imperative systems

Stephen Pair spair at acm.org
Fri Feb 28 16:48:30 UTC 2003


Colin Putney wrote:

> 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.

Yes, I guess the point here is that the real difference between an
imperative and declarative program construction is that the imperative
approach is not capturing the operations that evolve the system from a
beginning to a final state.  It would be sort of like applying a
declarative spec, and then throwing away that spec.  And, even if the
imperative approach did capture the operations, there would be lots of
intermediate steps captured which wouldn't be appropriate in a
"declarative spec."
 
> 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. 

But I think that's the problem.  Many people think of a declarative spec
in that way, but that is in fact an illusion.  A declarative spec cannot
possibly describe final state in the absence of the "interpreter" of
that declarative spec.  I think that was Alan's point. 

You could think of a declarative spec as a single operation rather than
a sequence.  It makes no difference...the declarative spec is an
instruction given the interpreter to make it transform the state of
system.

The benefit of having a declarative spec is that it makes the state
transition repeatable given some interpreter of that spec.  There are
other ways to accomplish similar results and we should be mindful that
there may be a common approach that accomodates this and other use
cases.

> 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.

Yes, "interpreter" does not mean the VM...it means the VM plus the
current state of the image.  For example, a VM alone cannot comprehend a
Smalltalk class definition.

- Stepehn



More information about the Squeak-dev mailing list