Joachim Durchholz wrote: > Marshall schrieb: > > Joachim Durchholz wrote: > >> Marshall schrieb: > >>> I can see the lack of a formal model being an issue, but is the > >>> imperative bit really all that much of an obstacle? How hard > >>> is it really to deal with assignment? Or does the issue have > >>> more to do with pointers, aliasing, etc.? > >> Actually aliasing is *the* hard issue. > > > > Okay, sure. Nice explanation. > > > > But one minor point: you describe this as an issue with "imperative" > > languages. But aliasing is a problem associated with pointers, > > not with assignment. > > Aliasing is not a problem if the aliased data is immutable.
Okay, sure. But for the problem you describe, both imperativeness and the presence of pointers is each necessary but not sufficient; it is the two together that causes the problem. So it strikes me (again, a very minor point) as inaccurate to describe this as a problem with imperative languages per se. > > One can have assignment, or other forms > > of destructive update, without pointers; they are not part of the > > definition of "imperative." > > Sure. > You can have either of destructive updates and pointers without > incurring aliasing problems. As soon as they are combined, there's trouble. Right. To me the response to this clear: give up pointers. Imperative operations are too useful to give up; indeed they are a requirement for certain problems. Pointers on the other hand add nothing except efficiency and a lot of confusion. They should be considered an implementation technique only, hidden behind some pointerless computational model. I recognize that this is likely to be a controversial opinion. > Functional programming languages often drop assignment entirely. (This > is less inefficient than one would think. If everything is immutable, > you can freely share data structures and avoid some copying, and you can > share across abstraction barriers. In programs with mutable values, > programmers are forced to choose the lesser evil of either copying > entire data structures or doing a cross-abstraction analysis of who > updates what elements of what data structure. A concrete example: the > first thing that Windows does when accepting userland data structures > is... to copy them; this were unnecessary if the structures were immutable.) I heartily support immutability as the default, for these and other reasons. > Some functional languages restrict assignment so that there can exist at > most a single reference to any mutable data structure. That way, there's > still no aliasing problems, but you can still update in place where it's > really, really necessary. Are we speaking of uniqueness types now? I haven't read much about them, but it certainly seems like an intriguing concept. > I know of no professional language that doesn't have references of some > kind. Ah, well. I suppose I could mention prolog or mercury, but then you used that troublesome word "professional." So I will instead mention a language which, if one goes by number of search results on hotjobs.com for "xxx progammer" for different value of xxx, is more popular than Java and twice as popular as C++. It lacks pointers (although I understand they are beginning to creep in in the latest version of the standard.) It also posesses a quite sophisticated set of facilities for declarative integrity constraints. Yet for some reason it is typically ignored by language designers. http://hotjobs.yahoo.com/jobseeker/jobsearch/search_results.html?keywords_all=sql+programmer Marshall -- http://mail.python.org/mailman/listinfo/python-list