🚀 go-pugleaf

>>In article <24281@megaron.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>All of this is very nice, but it doesn't tell me that there is any
>substantial difference between Smalltalk and ML.  It only tells me
>that the in the traditional ways of viewing Smalltalk and ML, there
>are some features that are different.  However, any ML program can be
>translated into Smalltalk with a simple syntactic transformation.
>Furthermore, it is possible to select a subset of Smalltalk and impute
>an ML-like semantics to that subset, such that the ML-like semantics
>and the Smalltalk semantics agree.
>
>To the programmer, this means it is possible for a programmer to use
>Smalltalk for programming, but imagine that he is using a functional
>language with functional semantics.  The reverse is not possible.
				      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

I have to differ with you there.  Whenever you write semantics of a
language what you are doing is specifying a SYNTATIC transformation
from the source langauge to the semantic language.  Thus if I write
the sematics of smalltalk in ML (which certanly is possible), I have
just written a description that can be used to convert Smalltalk into
ML.  Thus the programmer 'thinks' he is writing smalltalk but is 
'really' writting ML.  

The bottom line is that EVERYTHING a computer does is syntatic, so
if a computer can convert from one langage to another, then one
language can be defined in terms of the other.  Unfortuately the
reverse is almost always true, so you can't say that one language
is 'better' or 'more expressive' based on that arguement.

I think an important point that is often overlooked is that what a
language prohibits is at least as important as what a language 
provides.  The more constrained a language is, the easier it is
to reason about.  For example, in ML I can be sure my program is
type safe, and that I will never have aliasing problems (without
EVER seeing the program).  I can't do this in Smalltalk.  Now
granted, you could restrict yourself to a restricted form of Smalltalk
so that you could guarentee these properties in your smalltalk program,
but what you have just done is convert Smalltalk to ML.  Either you
always use the subset in which case you might as well be using ML,
or you don't in which case you can no longer reason simply about 
the program.  

Thus there is a continuous tradeoff between expressiveness and the
abilty to reason easily about your code.  In general for a particular
application you want to use the most RESTRICTIVE language that allows
you to express what you want to describe.   This way you get the most
'free' information about the behavior of your code.  Obviously
one language can't do this, but you can imagine a family of 'nested'
languages that might provide a good approximation.

Vance Morrison
Univ. of Illinois, Urbana-Champaign