A declarative model of Smalltalk (was Re: [DOCS] SUnit tests)
nevin at smalltalkpro.com
Sun Feb 23 03:59:32 UTC 2003
Colin Putney wrote:
> I find this definition of language unsatisfactory, for two reasons.
> For one, it ignores the notion of grammar, which is a key part of
> language. Also, the requirement for a unique meaning for each word
> directly one of the central notions of Smalltalk, which is that
> different objects respond to different messages differently.
I was brief. Brevity often causes lack of precision. My fault.
Consider a classical "Object Reference Manual". In such a manual, each
method of each class has an English-language description of the meaning
of that word in that context (i.e., for that receiver), and it targets a
human as the consumer of the definition. The implementation of each
such method is the description of the meaning of that word in that
context (i.e., for that receiver), and it targets the computer as the
consumer of that definition.
I realized my lack of precision during (and even after) posting, but
didn't worry about it, because...
> The point (snipped for brevity) that any program necessarily extends
> the capabilities of the base system is well taken, however. In fact,
> it's the main reason that a declarative model for Smalltalk programs
> is so useful.
...it didn't change the message I was trying to deliver with it, as your
comment above also illustrates.
Also, even my "addendum" above lacks precision. But I think most folks
will understand the message I am trying to deliver with it, and that's
good enough for me (for now).
> As an example consider a program that adds a class to the system. This
> class is a subclass of Object, a class that's already part of the
> system. The imperative model represents this by sending #subclass: to
> the object named 'Object'. If Object doesn't exist, you get a MNU
> error. An well-designed system will have facilities to catch these
> errors and react appropriately. Nevertheless, if the error occurs in
> the middle of the execution, the side effects of the execution up to
> that point will persist. This leads to an inconsistent system.
Not with GemStone Smalltalk. You simply "roll back" to your point of
origin. So, this proves it can be elegantly dealt with in an imperitive
Don't blame weaknesses of some specific implementation onto the
imperitive approach in general. 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. In fact, if
anything, I'd have to give the nod to the imperitive approach, because
I'm personally not aware of *any* approach that as elegantly deals with
the issue in the declarative model (without artifacts like the above) as
GemStone does with the imperitive model. If anybody *does* have an
elegant solution, I think it would be David Simmons with S#, but I
haven't looked deeply enough to judge.
But in either camp, the "initial state sensitivity" issue has to be
dealt with. Thus, I don't see any real difference, and so I remain
BTW, I quite like your description that "an imperative representation is
essentially a program that constructs a program". Of course, I think
you can see that it too lacks precision, as your definition is
recursive, and a fileout isn't recursive. But I still like your phrase,
and your inclusion of the word "essentially" gives you the needed wiggle
More information about the Squeak-dev