🚀 go-pugleaf

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