[Haskell-cafe] Hyper-recursion?

[David Turner]

Hi Lawrence,

I suspect you have stumbled onto the dual concept of corecursion: rather
than starting from a complex structure and recursively consuming it until
you reach a simple base case, you're starting from a simple base case and
corecursively producing more complex ones.

See also Event Sourcing.

Best wishes,

David


On 16 Jan 2017 04:43, "Lawrence Bottorff" <borgauf at gmail.com> wrote:

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

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170116/6a4af3c1/attachment.html>