A declarative model of Smalltalk (was Re: [DOCS] SUnit tests)
John W. Sarkela
sarkela at sbcglobal.net
Sun Feb 23 15:30:16 UTC 2003
On Sunday, February 23, 2003, at 06:52 AM, Nevin Pratt wrote:
> Colin Putney wrote:
>>> The same warning likewise applies for the declarative approach as
>>> well, which typically creates such artifacts as "DLL-hell", "JRE
>>> version proliferations", "glibc version mismatch", etc. All of
>>> those real-world artifacts (and I'm sure quite a few more) have, as
>>> their underlying root cause, the same "initial state sensitivity"
>>> issues that the imperitive approach has. It is the specific way
>>> that those language designers chose to meet the "initial state
>>> sensitivity" challenge that produced those artifacts.
>> These problems have nothing to do with declarative representation vs
>> imperative representation.
> Not directly, no. They instead are artifacts of the way the various
> language designers chose to meet the challenge of "initial state
> sensitivity". They also are common artifacts of the declarative
> design choices commonly made these days. They don't necessarily need
> to be, though. I gave a reference to David Simmons work as a
> potential counter example.
David's work depends absolutely upon a declarative model. His whole
system is possible precisely
because the semantics of a program may be described independently of
the runtime implementation,
or the concrete language syntax.
This allow his system to host multiply VM's (ie .NET and AOS) on the
bottom surface of his runtime
architecture and multiple programming languages on the upper surface of
In this conversation it is really, really important that we have clear
and consistent distinctions between
1. a module that is a semantic declaration with a concrete syntax
(TeamV, ginsu, etc)
2. a module that is a set of injunctions to be performed in a runtime
context (change set, file in, etc)
3. a module that is a runtime component (.dll, .lib, java bean, squeak
environment, squeak project, etc)
Without seeing these three things as being absolutely distinct and
separable, it is impossible
to understand point of a declarative approach and the participants
never properly respond to
each others messages.
Of course, each of these approaches to modularity may serve a common
user intent, thus we
tend to confuse them as being "the same thing", merely because we can
use them to
achieve "the same effect". The difference is that each of these
approaches has a different
path to the fulfillment of a given user intent. Our job is to be
discriminating and choose the
approach that best fits a particular intent.
More information about the Squeak-dev