Re: [Help-bash] Closure concept in bash

[Ken Irving]

On Tue, Jan 31, 2012 at 03:21:02PM -0600, Peng Yu wrote:
> On Tue, Jan 31, 2012 at 12:40 PM, Bob Proulx <address@hidden> wrote:
> > 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.
> 
> I don't see why closure can not live with current features of bash.
> JavaScript has both local, global variables and closure. I don't think
> that you statement that bash will be broken if closure is added is
> necessarily true. So I will ignore your any further arguments down
> below unless you can prove you statement.

I don't fully understand closures, but am interested in the discusion
and concepts.  If the shell could support them without impact to existing
code, and if some value could be demonstrated for them, then maybe they
could be useful.  I don't think you've demonstated the need or how they'd
be used, though.

Closures encapsulate an environment where variables continue to
exist within a function, but go out of scope outside of the function's
boundaries.  Most languages that support closures have garbage collection,
and keep a variable around as long as something is pointing to it.

I would note that the filesystem kind of handles inodes this way; perhaps
you can prototype your ideas by using a file to represent a variable,
e.g., create a file, add some content, then delete the file while keeping
it open.  The OS won't clean up the inode until your process is done
with it, even though no filename exists for it.  Or maybe you could use
named pipes for this.

Another thing to note is that bash uses dynamic vs the more common static
scoping for variables, e.g., see this thread:

  http://lists.gnu.org/archive/html/bug-bash/2010-11/msg00036.html

I'm not sure how, but this might impact your proposal.

> Also, my philosophy is that no language is static, to improve
> languages it is worthwhile to scrutinize the pros and cons of various
> features. Many languages have changed dramatically over the last a few
> years. Many code written for older versions has to be updated to catch
> up with latest development. There is no reason that bash should not be
> improved just because bash should be 100% backward compatible.
> 
> I'd like to contribute to bash by raising questions to discuss various
> potential features. No matter whether they will accepted or not, I
> believe it worthwhile for discussion, isn't it?

Can you provide a use case for closures in bash scripts?  I.e., assume
(pretend) they're supported and show us a simple program using them.

It's good to have the bash-help list to toss this stuff around,
much better than bash-bug, but maybe bash-wild-ideas might be more
appropriate. ;-)

Ken