Path: utzoo!attcan!utgpu!watmath!iuvax!mailrus!accuvax.nwu.edu!morrison From: morrison@accuvax.nwu.edu (Vance Morrison ) Newsgroups: comp.lang.misc Subject: Re: side effects Message-ID: <972@accuvax.nwu.edu> Date: 28 Jul 89 21:04:00 GMT References: <2270@ccncsu.ColoState.EDU> Sender: news@accuvax.nwu.edu Reply-To: morrison@accuvax.nwu.edu (Vance Morrison ) Organization: Northwestern Univ. Evanston, Il. Lines: 64 I have been thinking about the problem of programming languages for quite a while now and the problem of aliasing is a interesting one. The basic problem is that when a person writes code, he is often implicitly assuming he has exclusive access to all objects in the his namespace and that each object is unique (unaliased). When a language allows you to violate this principle, subtle bugs are possible (and are all too common in real life). Pure functional languages take the view of solving the problem by simply not permitting aliasing. When an object it created, it is given a value and that value never changes (referential transparency). Given this rather strong restriction it is amazing that a great deal of nontrivial code can be written in this manner. Now what happens in these languages is that every operation has to create a new operation (since it can't store the result in any old ones). If we implement this in a simple way, the resulting code is EXTREMELY inefficient. The way around this is to view the code as simply a description of what is to be done, not how to do it. Thus the compiler should recognise that certain variables are no longer uses and thus can be reused to hold new values (without the overhead of throwing it away, garbage collecting and reallocating it). Any viable functional language does this to some extent and it is a research topic as to how far it can go. The nice part about doing things this way (that is programming in a functional language and having it be converted to an efficient imperitive equivalent) is that all of the nice features of function languages (simpler to understand (no aliasing) program correctness proofs). The problem with this approach is that there is ALOT of code that really cant be programmed with a function language (as far as I can tell) and a bigger set that can be, but not efficiently. For example function languages really have no concept of a concurrent database, or resource allocation or other operating system concepts. And because aliasing is not allowed, you cannot make structures have aliasing implicit in their structure (any data structure with a loop, or things like queues, ADG's etc). (Actually you can make these structures but only by simulating a pointer and doing it that way, but pointers are just what we are trying to avoid). This is a major problem with functional languages in my option, so I believe prohibiting aliasing completely is too strong a condition. Instead, I believe a lesser constraint is better. In particular my present idea is that a language should guarentee 'effective exclusive use'. What that means is that as far as the programmer is concerned every variable name is unique and he has exclusive use over it. Now this is 'effective' exclusive use because the compiler may not give you excluseive use if you don't need it. (for example, from the programmers point of view the complete tree is locked, however the compiler only locks the part of the tree the program is currently working on). The key to making this work is for the programmer to specify to the compilier (by sutable language constructs) the properties that he whats at what place in the code. Using the code and the required properties the compiler can determine where exclusive use is necessary (actually it determines where it is not necessary and thus can optimize). These ideas are rough, but I believe they are workable. I am willing to listen to anyone's view on the subject. Vance