A declarative model of Smalltalk (was Re: [DOCS] SUnit tests)
cputney at whistler.com
Sun Feb 23 07:01:22 UTC 2003
Nevin Pratt responded to me thusly:
>> 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 model.
Using GemStone's transactional capabilities to keep file-ins from
hosing your image is neither elegant nor simple. There's a reason
GemStone is so expensive. Implementing transactions correctly and
efficiently is *hard*. It's complete overkill for something as
fundamental as loading a program, something which should be quite
> Don't blame weaknesses of some specific implementation onto the
> imperitive approach in general.
The weakness of the imperative approach is that it's hard to implement
well. Ok, so Gemstone doesn't suck. How many Smalltalks have there been
over the years? How many have had fullblown transactions? More to the
point, what is the easiest and best way to bring, say, decent revision
control capabilities to Squeak? Stephen Pair's Chango project provides
some hope for a transaction engine, but I'm pretty sure a declarative
representation of Smalltalk code will be an easier way to achieve it.
> 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. They are the result of an attempt to link
incompatible chunks of executable object code into a single process
space. If you compile some code against one version of a library and
try to link it against another version, it's no surprise if it doesn't
The point is that we're (or a least I am) concerned with representing
and manipulating source code, not byte code or object code.
> 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.
Compilation of declarative code fails if its dependencies are not met
by the system at the time it is compiled. It's that simple. Sure, if
you tried to run the resulting bytecode in a different environment than
it was compiled in, it might not work. But that's always true, no
matter how you represent the source code.
As for elegant approaches that use a declarative model, how about
Ginsu, Envy, and VSE?
> 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
Suit your self...
> 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 room, IMO.
Yes, this is subtle stuff. I said "essentially" because I'm not sure
that a series of DoIts constitute a program. In fact, a definition of
the word "program" would help this discussion immensely. I don't think
my description is recursive, though, as I'm not defining the word. The
program constructs another program, it doesn't construct its self.
More information about the Squeak-dev