Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!uwm.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: <1990Aug22.021517.17736@ux1.cso.uiuc.edu> Date: 22 Aug 90 02:15:17 GMT References: <24384@megaron.cs.arizona.edu> <1990Aug20.220332.21135@ux1.cso.uiuc.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: 44 In article peter@ficc.ferranti.com (Peter da Silva) writes: >> 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. > >Couldn't you use the more restricted code to produce objects that can >be reasoned about in the way you're describing? This would let you build >reliable objects, which would eliminate a large potential source of bugs >in a larger program using the whole language? This is the idea of nesting I was talking about. Using a restricted language to specify the things you can in that subset, but using a more expressive superset when necessary. Unfortunately doing this is not as easy as you may think. The problem is that very often the restricted language enjoys the nice properties is has because of a GLOBAL constraint. Thus the minute you introduce ANY code that is not in the restricted language the reasoning gets more complicated. A example of this is functional languages. Any imperative feature can make otherwise completely functional code have side effects. Still it is not hopeless, by keeping track of what code is purely functional and what code is not, (which can be done at compile time) you can salvage alot (these are called effect systems, FX-80 is an example of such a system). Data structures pose a problem since we often want to reason about pieces of them differently, but there is hope. I guess my point is that the language support (type checking, effect checking and other compile time reasoning systems), are probably a lot more important than the language itself. Saying something like 'if you want to do applicative programming, simply use this subset' is not enough, because without compiler support, I will never know if what I wrote is really in the subset (perhaps I missed a crucial semicolon (:-). Even I am sure that what I wrote is in the subset I want to be SURE of its behavior when I combine it with more powerful constructs in the superset. Hopefully it and can be reasoned about as a black box abstraction in the larger language. We want to design languages carefully so they have this nice nesting feature. Vance