fun opacity

Peter-Henry Mander erlang@REDACTED
Mon Jan 10 15:28:20 CET 2005

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() -> atom()
  args() -> [term()]

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


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

More information about the erlang-questions mailing list