Re: [Help-bash] Closure concept in bash

[Bob Proulx]

Peng Yu wrote:
> The conclusion is that bash doesn't have closure.

Correct.  Full stop.  Proceed no further.

> As of now, I think that closure is missing in bash and it could be a
> useful feature to be added.
>
> Bash need not be a language lacking advanced languages features. Bob
> mentioned perl, python etc. These language can never beat bash in
> terms calling shell commands. It will be cool to merge some good
> features from other languages to bash to make bash better.

But this MUST NOT HAPPEN.  Bash /does not/ implement functions in the
same way as these other languages.  If bash were to change so that it
did implement these features then IT WOULD NO LONGER be the shell.  It
would be SOMETHING ELSE.  It would be incompatible with forty years of
shell scripts.

This is exactly what perl did for example.  It was written as an
improved shell.  But it is not the shell.  The natural progression of
your endless requests for features is something like perl.  Instead of
trying to mutate the shell into something different and breaking
everyone else's use of it you should simply start out using a program
that is already what you want.

Are you familiar with "I love you.  You are perfect.  Now change."
That seems to be happening here.  You find a tool.  The tool works
well.  You say you love this tool.  You say it is perfect.  Then you
say you want to change everything about it and make it something
completely different.  If this were allowed then it would completely
break the tool.

Doing this is alike a "scorched earth" policy.  The tool was there and
available when it was needed.  But if completely changed into another
tool it then will no longer be available for the next generation of
users.  It will have been burned to the ground in the name of
progress.  When that is allowed to happen it is always a tragedy.

> The best that I can use is set -a, which is like making variables "global"

It isn't "like" making variables global, it *does* make variables
global.  It makes variables global beyond the lifetime of the shell
process.  They haunt the environment like zombies shambling down the
street in some cheap horror movie.  If anything another description
could be that they become super-global.

Making variables global has no connection to the use of closures.  It
is only an accident of the example that made them seem remotely
similar.  If anything closures promote use of more closely scoped
variables and closer modularity which is exactly the opposite of
promoting the use of globals.  Asking for exported functions to
implement closures is an irony because these target opposing design
goals.  Like using salt to clear land for farming it will clear the
land but you won't be able to farm there afterward.

> (it, of course, has shortcomings).

Yes.  It has many shortcomings.  These are like kitchen knives.  A
well stocked kitchen has many knives, pots, pans, and utensils.  These
are a joy to use to cook.  For any given task the right knife can be
selected.

But that doesn't mean that the biggest sharpest knife must always be
used.  Often the small less sharp one is the right tool to use.

To cook is more than just to blindly use the biggest pot and the
biggest knife and the hottest flame.  To cook well is to use the best
one.  And being a matter of taste, to cook with some variety.  And it
is to learn what things cook together well and what combinations
should be avoided.

> Closure could be a feature that may help in these cases, but it may
> be not easily implemented in bash.

A shell that implemented closures would be a different program and
therefore it would need a different name from bash so as not to break
previous programs.  A shell that implemented closures could be called
"clash" the closure shell.  If someone were to implement such a
program I am sure there would be users for it.

Bob