A while back I worked at an assessor's office, i.e., the people responsible for handling properties as land parcels. I was brought in to do GIS. One of the things we wanted was to get a sense of the history of land use, specifically how property changed hands, and especially how property lines changed due to properties either merging or being split up. That is to say, how the parcel map changed over time. Problematic was how the rugged old mainframe system (IBM AS/400 and a Cobol app) simply updated the data -- with no concept of remembering how things used to be. My GIS system (ESRI) also lacked any state memory -- other than simply snapshooting everything ad nauseum. Years later I become familiar with the world of functional programming. Somewhere in the functional paradigm, specifically recursion, would seem to be a model for this issue. That is, the whole issue of parcels changing through merges or splits might be a simple question of recursion. If functional is "beyond state," then changes in a map would only be stages, places in a never-ending outward-growing recursion. Seen as "infinite mirrors," one map change would simply be a mirror layer -- click on it to call it up. So in chapter 1 of any functional programming tutorial is the factorial calculation function done with recursion. We beginners see the recursion "going out" to the "last one," then "coming back," adding up the results of each stage as it returns . . . like a yo-yo winding out, then winding up again. But what I'm describing with changing parcels maps would seem to be a process that never comes out of recursion, rather, lives inside a "hyper-recursion." That is to say, an overarching recursion is the whole world. However, today's mentality would simply say, *Obviously, you want to save off each change you make to your parcel map *. . . again, the whole snapshot idea. This thinking is typical data management coupled, perhaps, with the human penchant to see things in terms of time and timelines. So, again, the standard solution would be to timestamp a parcel change and save it off, i.e., a "change" is a tick on the timeline, mark it, make note of it. But again, couldn't we see this whole issue of parcel changes as (using my yo-you analogy) just levels in what seems like a continual winding out -- which in a topological sense doesn't even need to be seen as geographical? This would seem to put the *process in a recursion,* rather than *recursion(s) in a process.* Haskell being the most pure functional language, is, hence, my starting point on this question. I'm a bright enough person, but I can't believe I'm the first person to notice this Alice in Wonderland situation. . . BTW, we could see a chess game in a similar light. . . . if not many, many other evolving phenomena of supposed (cumulative, consequential?) change. Thanks, Lawrence Bottorff