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

> <..snip..>


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

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

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.

Nevin