You are right that the example given is not one where a
closure would be appropriate, which is why I pointed out
the overhead of entering a function.
I don't have the energy to write a real example to show you
what I mean, but I can point at a case which would have been
helped by it. Download Pod::Parser and in it look for the
implementation of parse_paragraph. There are a
lot of optional hooks provided, and the way it was done is
to pass all of the data through a series of functions then
keep on checking flags. But most of the time those
functions (like preprocess_line and
preprocess_paragraph) don't do anything.
I once looked at it closely, and couldn't tie out the
current API. But if you had an API where you created all of
the hooks you wanted then asked it to build a parser, it
could then create a function, and then once (and once only)
decide to only include lines with optional hooks if you were
using it. The result would do the same task several
times faster since optional hooks would not be present in
the final output. (Without having looked I would suspect
that Parse::RecDescent does this.)
As for why the eval, to do what I describe you would want
to build up
the string, as you walk through checking once for the hook
then including or not including bits of what could be part
of your sub, then call eval to have it return the final
subroutine for you.
