The Bounding Problem ( was Re: A declarative model of Smalltalk)

shane at shaneroberts.com shane at shaneroberts.com
Wed Feb 26 05:28:31 UTC 2003


Isn't all this about the "bounding problem"?

How do you decouple an object from a runtime environment so that 
it is
explicitly 
complete semantically, and yet provide it with underlying services it 
can
rely on, and 
make it an encapsulated re-usable component of a larger system?

Particularly in the case of a distributed component system, you 
want
persistent 
objects that remain semantically correct over time, can be relied 
upon to
provide 
correct services, and also that they can find and rely on correct 
services
for their 
own operation.

The .DLL hell problem, and JRE versioning issues, etc. all relate to 
these
bounding 
issues.  How do you declare an "interface" for components ( ala 
data
definition 
languages, etc. ) such that components remain viable indefinitely?

Where do you define the boundaries which specify discrete objects, 
yet
integrate 
them into a larger whole,
so that large complex systems may evolve over time and remain
comprehensible, 
as well as semantically correct?

Where do you set the boundaries? Are "Meta Fences in here 
somewhere?
How do you decouple objects from "initial state sensitivity" and the 
side
effects of a 
dynamic system evolving over time?

When are the semantics of an object explicit and when are they 
implicit?

The class hierarchy of object oriented systems provide a schema 
which
makes 
reflection possible, as well as providing an explicit semantics for 
the
objects of the 
hierarchy.  But now the objects are tightly bound to the hierarchy, 
and
the semantics 
of an object are IMPLICIT in the class which defines it.  For any 
instance
of the 
class, the instantiated object is bound to the class factory that 
produced
it, in the 
same way that any old fashioned static data is bound to the code 
that
"understands" 
how to process it.

How do you distribute that object without it being bound to schema
versioning 
systems that "place it" according to the initial conditions that 
produced
it.

This issue of explicit and implicit is akin to executable files in
traditional 
environments that are compiled with or without symbol tables.  
With a
symbol table 
the object file (.exe if you will), is debuggable with a debugger.  Its
code and data 
are still defined explicitly via the symbol table.  It carries its schema
with it.  When 
the symbol table is not output with the object file, the stucture of the
code and data 
is implicit in the execution of it, but there is no reflection
capabilities left.  It is in a 
way a "dead object."

These are not idle questions for me considering the problems I 
have
already had 
with Squeak versions, and whether SqueakMap will handle Squeak 
modules
written 
for different versions of Sqeak.

Shane



On 22 Feb 2003 at 13:21, Nevin Pratt wrote:

> Over the years I have read Allen's papers (and read his posts) 
> concerning a declarative Smalltalk, and I've tried to weigh in and
> form my own opinion.  Over all of those years, Allen has not convinced
> me of the value of the declarative approach, but then again, I have
> not been convinced he is wrong either.  I am simply undecided.
> 
> However, I *do* take issue to the implied assertion that the current
> imperative approach used by the major Smalltalk's  necessitates any
> less (or even any more) reproducable "programs" than the declarative
> approach.  But let me briefly introduce some definitions of the
> components of a declarative "program" before I attempt to defend the
> belief:
> 
> 1. A "word" is a sequence of non-white space tokens within the 
> declaration of the "program" (and "white space" has the classic 
> definition we are all used to).
> 
> 2. A "vocabulary" is a unique set of words.
> 
> 3. A "language" is a vocabulary coupled with a unique meaning of each
> word of that vocabulary.
> 
> 4. Any program declaration is necessarily written in a "language", as
> defined above.
> 
> Since above I said a vocabulary is a *unique* set of words, this means
> that adding or removing a word to or from the vocabulary creates a new
> language, per the above definitions.
> 
> Since above I said a language is a vocabulary coupled with a *unique*
> meaning of each word, this means that changing the meaning of a given
> word creates a new language, per the above definitions.
> 
> Given the above definitions, then, one of the first things we discover
> is that the act of programming is the same thing as the act of
> "language designing".  You are extending an existing language in a
> domain-specific direction (i.e., introducing new words to the
> vocabulary, whether they are functions, prodedures, methods, or
> whatever), and in so doing, you are creating a new language as a
> side-effect, for the simple reason that your "new" language has a
> greater (and sometimes lessor) set of words than what you started
> with, and you may have even altered the "meanings" of some of the
> existing words in the process.  Either of these acts result in a new
> "language" (using the definition of "language" from above), even
> though you may be starting from a given base language when you do it. 
> Your existing "base" language might be the native instruction set
> understood by the CPU you are programming on, or on some Virtual
> Machine, or any other form of a "language", but you will always be
> building on a base language of some sort.
> 
> Now, as we know, many languages differentiate intrinsic words within
> the vocabulary of the language from the programmer-defined words.  But
> many languages (such as Smalltalk) do not differentiate them.  
> 
> Given the above definitions, a Smalltalk "program" (or any other
> program in any language) consists of *every* word of the vocabulary of
> the "program", coupled with the meaning of every word.  And because
> Smalltalk does not differentiate *who* introduced the word into the
> vocabulary (intrinisic or programmer defined), it is irrelevent
> whether "Programmer A" introduced the word to the vocabulary, or
> "Programmer B". 
>  Likewise, it is irrelevent whether "Company A" introduced it, or
> "Company B".  Thus, a complete "program" necessarily has to either (1)
> include *every* word of the vocabulary of the program, and the
> definitions of those words, or (2) assume that such a program is
> merely an extension of an existing language (or program).  Actually,
> two paragraphs above I argued that you will always be building on a
> base language, which would mean that #1 isn't even possible, and that
> your only option is to assume that such a program is merely an
> extension of an existing language (or program).  But I won't actually
> make that assertion (yet).
> 
> Now, if such a "program" includes every word of the vocabulary of the
> program (assuming that it is even possible to do this, and I suggested
> above that this option isn't even possible), together with the
> definitions of those words, I personally don't see any advantages (or
> disadvantages) of comparing this with an image-based approach, since
> everything has to be included anyway.
> 
> And, if it is just an extension of an existing language, then it
> necessarily has the same "initial state sensitivity" that the
> imperative approach has, because it is expecting to extend a known,
> existing (i.e., "static" and unchanging) base language.  If the base
> language that it is extending is different from that which it was
> designed to extend, you have exactly the same state-related problems
> that you see with the imperative approach.  And, in the imperative
> approach, if you start from a known base "language", then a known
> sequence of expressions applied to that base *will* reliably reproduce
> the "program", just as the declarative approach will.
> 
> When merely "extending" an existing base language, both approaches
> require that you know where you are starting from, consequently
> neither approach results in any theoretical advantage towards program
> reproducability.  That's my opinion.
> 
> I could say more, but suffice it to say that I remain unconvinced that
> any declarative approach has any theoretically advantage (or
> disadvantage) over the classic Smalltalk imperitave approach.
> 
> Nevin
> 
> 
> Allen Wirfs-Brock wrote:
> 
> > 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
> >
> >
> >
> >
> 
> 
> 




More information about the Squeak-dev mailing list