Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!thucydides.cs.uiuc.edu!morrison
From: morrison@thucydides.cs.uiuc.edu (Vance Morrison)
Newsgroups: comp.lang.misc
Subject: Re: The Universal Language
Message-ID: <1990Aug20.220332.21135@ux1.cso.uiuc.edu>
Date: 20 Aug 90 22:03:32 GMT
References: <24384@megaron.cs.arizona.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: morrison@thucydides.cs.uiuc.edu.UUCP (Vance Morrison)
Organization: University of Illinois, Urbana-Champaign
Lines: 34

In article <24384@megaron.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>where there are direct correspondences between the various parts of
>the expression, and the Smalltalk expressions have no side-effects.
>However, any side-effecting operation in Smalltalk has no
>corresponding operation in ML.

I agree with you that it is far easier to write a ML to Smalltalk converter
the the reverse, and I agree that intuitively this means that Smalltalk is
a superset (more expressive) then ML.   I only wanted to point out that this
is not a rigorous statement since you can also write an Smalltalk to ML
converter.  Thus to make a rigourous statement we would have to precisely
define 'easier', which looks messy at best.

Also I wanted to point out that I believe the idea of finding 'bigger' and
'bigger' languages that encompass other languages in this way is not 
productive.  The reason (as I stated earlier), is that restricting a language 
is often a very useful thing.  It allows you to reason more simply about
your program.  

Sure there is a subset of Smalltalk that is isomorphic to ML.   But this does
not allow me to reason about my programs (type check etc) in the simple way
I can with ML unless I confine myself to that subset exclusively (in which
case I am really writing my program in ML!).   Introducing more general 
smalltalk code that causes side effects can destroy the simple properties
of the whole program INCLUDING the code written in the subset.   Thus having
a very expressive language alone is not the solution.

Thus I believe the problem to solve is learning how to nest languages
gracefully.   In this case of the imperative-functional issue, this defining
semantics in such a way that imperative parts of the program can not 
destroy the nice properties of the function parts.  

Vance Morrison
Univ of Illinois