At 04:00 AM 2/22/2003 -0500, Jeff Read wrote:
>When the compiler and parser are tightly integrated with the runtime of 
>the language, instructing the language to add program parts to its 
>currently running program often becomes the norm, rather than crafting 
>everything declaratively in an editor and then running it through a compiler.

I think you half get and half miss the point.  Using a declarative approach 
to Smalltalk in no way implies using an editor to create source files. As I 
previously mentioned, Smalltalk browsers generally present a declarative 
model of Smalltalk programs to the programmer who creates and views class 
and method definitions/declarations (a class definition is (partially) 
presented as a message expression but to most users  that's 
just  syntax  which is  treated  as a declaration). The issue is more 
related to what happens when the user clicks "accept".  In a classic 
Smalltalk-80 system the browser uses the declaration to imperatively 
side-effect the  running system and then essentially forgets the 
declaration. In a declarative Smalltalk environment the  browser records 
the declaration  as a  primary archival artifact and then (perhaps 
optionally) side-effects the running system.

The two most widely used "team" Smalltalk development environments during 
the "golden age" of commercial Smalltalk were Digitalk's VSE(Team/V) and 
OTI's Envy. While OTI was less overt about it, both  systems 
were  essentially  declarative  in nature. Yet both presented  a complete, 
browser-based, interactive, incremental, reflective, "Smalltalk-style" 
development experience.

The issue is really all about reproducibility of programs. If I create a 
program I need to be able to hand it to you with  the expectation that you 
will receive the exact same program.  I need to be able to take that 
program and run it with a future version of the runtime system and know 
that it will still get the exact same results. I need to combine 
independently development "modules" into a common program and know  that 
each module  remains as originally defined.  I need to retrieve an old, 
archived version of a program and reconstruct it in its exact original 
form. To reliably do these things you need a declarative definition of 
the  program or a module rather than a sequence of state sensitive 
imperative operations. BTW, it is the initial  state  sensitivity that is 
the real killer.  That's why "file-outs" often  don't work when they  are 
"filed-in" and that's why you have to worry about the load order of change 
sets.

(I also take issue with the implied assertion that the Smalltalk/Squeak 
compiler is tightly integrated with the runtime system.  Removing  the 
compiler is quite simple.  Most commercial Smalltalk products have included 
the capability  (or even the requirement) to deploy applications without 
including the compiler.  Similarly, it is  quite possible to build a 
runtime compiler for Java that is capable of taking a  source code class 
declaration and dynamically loading it into a running application.)


>Smalltalk appears to borrow a lot from LISP in this regard, at least in 
>terms of philosophy if not implementation. In Scheme, for instance, the 
>keyword define means "Add this symbol to your currently running global 
>environment, and bind it to the following value..." LISPers tend to see 
>this as an advantage.

Not when  they want to create a maintainable, reproducible, deployable 
application. In that situation they create archival source code definitions 
that can reproducibly create the  runable  application.


>The difference, if I surmise correctly, is that every Scheme knows what 
>define means; the base semantics for the keyword are standardized -- 
>whereas each Smalltalk has a different protocol for creation of classes 
>and adding methods to the
>
>The Smalltalk situation is rather unfortunate, but I see not what having a 
>separate declarative syntax for Smalltalk affords us; with a standardized 
>imperative protocol for creation of classes, methods, and variables, the 
>declarative syntax comes for free.

It's not just an issue of protocol standardization. It's  more an issue of 
initial state  dependencies  and polymorphism. Syntactically you can use 
Smalltalk message syntax if you want.  However, if you want 
reproducibility, their semantic interpretation can't be dependent upon the 
happenstance  state  of the running system.  As you say, it isn't the 
syntax that is important.  However, a standard semantics is essential. ANSI 
Smalltalk doesn't even bother to define a concrete syntax for class 
declarations.  It just says that no matter what you use  for  a 
concrete  syntax, here is what it means.

Allen Wirfs-Brock


>--
>Jeffrey T. Read
>"I fight not for me but the blind babe Justice!" --Galford