fun opacity

[Peter-Henry Mander]

On Mon, 10 Jan 2005 08:04:12 -0500
Vance Shipley <vances@REDACTED> wrote:

> }  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.

I'm beginning to think the same. It allows some flexibitity that pure
funs deny. The arguments can be submitted to other functions besides
M:F, while still preserving a default behaviour. A fun locks this up in
an opaque type and I don't think it's practical to disect a fun instance
to recover the arguments. May I suggest using something simpler like:

  {tag(),args()}
  tag() -> atom()
  args() -> [term()]

Like that there are no assumptions made about what the 'package' does,
just an indication what kind of data it is.

Pete.

P.s. sorry fot the *** SPAM *** subject prefix, my ISP makes wild
assumptions about what is unsolicited garbage and what is intelligent
discourse. Please don't take it personally!

-- 
"The Tao of Programming
 flows far away 
 and returns 
 on the wind of morning."