Marshall wrote: > Andreas Rossberg wrote: > > > > And note that even with second-class state you can still have aliasing > > issues - you just need mutable arrays and pass around indices. Keys in > > databases are a more general form of the same problem. > > So for array a, you would claim that "a[5]" is an alias for > (a part of) "a"? That seems to stretch the idea of aliasing > to me.
Not at all, I'd say. In my book, aliasing occurs whenever you have two different "lvalues" that denote the same mutable cell. I think it would be rather artificial to restrict the definition to lvalues that happen to be variables or dereferenced pointers. So of course, a[i] aliases a[j] when i=j, which in fact is a well-known problem in some array or matrix routines (e.g. copying array slices must always consider overlapping slices as special cases). > > 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. > > Hmmm. Can you elaborate just a bit? Logic variables immediately become aliases when you unify them. Afterwards, after you bind one, you also bind the other - or fail, because both got already bound the other way round. Unfortunately, unification also is a deep operation, that is, aliasing can be induced into variables deeply nested into some terms that happen to get unified, possibly without you being aware of any of this (the unification, nor the variable containment). To avoid accidental aliasing you essentially must keep track of all potential unifications performed by any given predicate (including transitively, by its subgoals), which totally runs square to all concerns of modularity and abstraction. I've never been much of a logic programmer myself, but our language group has a dedicated LP and CP background, and people here have developed very strong opinions about the adequateness of unrestricted logic variables and particularly unification in practice. I remember somebody calling Prolog "the worst imperative language ever invented". - Andreas -- http://mail.python.org/mailman/listinfo/python-list
