Newsgroups: comp.lang.scheme,comp.lang.functional
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: when to use state?
Message-ID: <hbakerD1Az2w.DDw@netcom.com>
Organization: nil
References: <3dfv8i$ifp@nkosi.well.com>
Date: Sat, 24 Dec 1994 06:52:08 GMT
Lines: 81
Xref: glinda.oz.cs.cmu.edu comp.lang.scheme:11649 comp.lang.functional:5453

In article <3dfv8i$ifp@nkosi.well.com> amyc@well.sf.ca.us (Amy Caplan) writes:
>bh@anarres.CS.Berkeley.EDU   Brian Harvey writes:
>...
>    If the program you are trying to write is a simulation of a real-world
>    situation in which a sequence of events modifies the state of things,
>    then an object-oriented approach is clearly the most natural, and will
>    result in the most readable program implemented most quickly.
>
>    On the other hand, if you are trying to compute some value derived from a
>    depth-first traversal of a tree, you would be crazy not to write a
>    recursive function.
>
>OK... if I am writing a program that simulates an elephant, yes, the
>elephant's current mass/velocity/mental state/whatever are clearly "state".

The elephant's 'current' velocity in that particular 'world' or 'point
in time'.  Its 'state' is a _function_ of the context.

>A more realistic example for many people would be writing a database or
>image library.  These are human concepts.
>
>How much state should be put into an "image" object?
>One extreme: at most keep the resolution of the image.
>The other extreme: i've seen at least one library that keeps all manor of
>things as state.
>
>I was hoping that responses to my post would reveal some objective tools/ideas
>for evaluating how much state one should use (e.g. I would imagine that
>some more advanced compiler theory has something to say about state?)

You can rest assured that whatever you put in as 'state' will have to
be abstracted out by the next guy who maintains your code and made
dependent upon some context object -- i.e., made 'virtual'.  The
single disk becomes one of many; the single frame buffer becomes one
of many (each of which may be different); etc.  So 'state' is merely
a cache for some more abstract functional context scheme.

>We have the concept of referential transparency.  Is there any reason
>anyone can give why R.T. is a good thing?  So far the only thing that
>persuades me either way (state or not) is the random number example,
>which suggests that R.T. is not worth striving for.

Some papers which might give you a new perspective:

"'Use-Once' Variables and Linear Objects--Storage Management,
Reflection and Multi-Threading".
ftp://ftp.netcom.com/pub/hb/hbaker/Use1Var.html (or .ps.Z)

"Linear Logic and Permutation Stacks".
ftp://ftp.netcom.com/pub/hb/hbaker/ForthStack.html (or .ps.Z)

Although the titles may not indicate it, the first part of these
papers is quite apropriate to your question.

You might also find the following useful:

"Worlds in Collision: A Mostly Functional Model of Concurrency Control
and Recovery".
ftp://ftp.netcom.com/pub/hb/hbaker/TreeShadow.ps.Z

"Shallow Binding Makes Functional Arrays Fast".
ftp://ftp.netcom.com/pub/hb/hbaker/ShallowArrays.html (or .ps.Z)

They discuss 'state' as simply a convenient cache for a path in
a tree-shaped environment.

Finally,

"Equal Rights for Functional Objects or, The More Things Change,
The More They Are the Same".
ftp://ftp.netcom.com/pub/hb/hbaker/ObjectIdentity.ps.Z

Traditional 'object identity' is _defined by_ objects with (visible)
state.

Henry Baker
Read (192.100.81.1) ftp.netcom.com:/pub/hb/hbaker/README for ftp-able papers.
WWW archive: ftp://ftp.netcom.com/pub/hb/hbaker/home.html
************* Note change of address ^^^        ^^^^
(It _is_ accessible, but Netcom is loaded; keep trying.)

