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

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.


:-}> John

More information about the Squeak-dev mailing list