Andreas Rossberg <[EMAIL PROTECTED]> writes: >Uh, aliasing all over the place! Actually, I think that logic >programming, usually based on deep unification, brings by far the worst >incarnation of aliasing issues to the table.
I agree that deep unification, as implemented in Prolog, brings with it lots of aliasing problems. However, these problems have been recognized from the seventies, and people have tried to solve them. There have been a huge variety of mode systems added to various dialects of Prolog over the years, which each attempt to tackle (various parts of) the aliasing problem, none of them fully successfully in my view, since their designers usually actually *wanted* to retain at least *some* of the expressive power of the logic variable. Some non-Prolog logic languages have departed from this approach, the earliest being the Relational Language. To tie this message to another thread, the Relational Language had a strict mode system that is as identical as possible to the notion of typestate in NIL and Hermes given the limitations of comparing declarative apples with imperative oranges, but significantly earlier, 1979 vs 1986 IIRC. Marshall wrote: >I have explored the OO path to its bitter end and am >convinced it is not the way. So what is left? Uniqueness >types and logic programming, I suppose. I enjoy logic >programming but it doesn't seem quite right. But notice: >no pointers there! And it doesn't seem to suffer from the >lack. Of course, the main logic programming language today that disallows the use of unification for arbitrary aliasing is Mercury. It enforces this through a strong mode system. Our motivation for the design of this mode system was precisely to eliminate the problems Andreas identified above. However it has also turned out to be an excellent foundation for Mercury's notion of unique modes, its equivalent of uniqueness types, which Mercury uses to express I/O. Zoltan Somogyi <[EMAIL PROTECTED]> http://www.cs.mu.oz.au/~zs/ Department of Computer Science and Software Engineering, Univ. of Melbourne -- http://mail.python.org/mailman/listinfo/python-list
