fun opacity

[Vance Shipley]

On Mon, Jan 10, 2005 at 12:46:28PM +0000, Peter-Henry Mander wrote:
}  
}  Would a reference serve your purpose, or is there something in the
}  input-context you wish to preserve?

Sure I could create a local lookup table but that would be too much 
trouble.  The alternative would be an {M, F, A} which is fine really 
however it seems that a fun is the preferred way of doing things these 
days.

}  What would happen if the originating module was reloaded with a modified
}  version? Will the old version of the code still remain resident until
}  the fun returns home to execute? I suspect that the code loading logic
}  may not know about the itinerant fun. The results may be undetermined.
  
Well it is the preferred way for short lived processes at least.

In my case since all the processes are within the same distributed 
application a release upgrade script would either do the work necessary
to handle things smoothly or just let it fail and continue.

}  I'm curious to know because I tend to use funs where, upon reflection,
}  simpler data types would suffice with less potential unanticipated
}  results, and more potential to expand capability, because fewer usage
}  assumptions are made too early.

In this application I've almost come to the conclusion that {M, F, A}
may be the way to go since while the processes may be short lived the
procedure defined by either Fun or {M, F, A} is static over a large
number of runs.

	-Vance