Path: csiph.com!au2pb.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!usenet.stanford.edu!not-for-mail From: Linda Walsh Newsgroups: gnu.bash.bug Subject: Re: minor language RFE(s) Date: Thu, 08 Oct 2015 10:48:02 -0700 Lines: 84 Approved: bug-bash@gnu.org Message-ID: References: <5615ACEF.4040804@tlinx.org> <56168F51.1010207@case.edu> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1444326547 23732 208.118.235.17 (8 Oct 2015 17:49:07 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Andreas Schwab , Chet Ramey To: bug-bash Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <56168F51.1010207@case.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11591 Chet Ramey wrote: > These change the syntax of the shell in incompatible ways. --- I think I had the feeling of ensuring compatibility as being important and changing things in incompatible ways . "That's not easily changed w/o potential chaos..." > The arithetic `for' command takes arithmetic expressions, not shell > commands, and the `for' command takes a name (identifier), not a > shell command. Aside from any syntactic sugar (`int', `my'), these > are not consistent with how the shell grammar is formed, and this > isn't a good enough reason to change the grammar that dramatically. --- Yeah, I think I mentioned that case: I've no idea of the difficulty level to do this, but was thinking if not too difficult... and if it is... well keep it on a pile of ideas if bash ever got refactored such that implementation became easier..? I understand the problems of working with 10+ year old code that's been patched through the roof and trying to add _anything_ to the design. Thus the proposal of keeping the idea around if bash was ever refactored such that implementing a change like this wouldn't be a big deal.... Andreas Schwab wrote: > If you want perl you know where to get it. --- Actually I have no idea where to get a version of perl that could even process POSIX compatible shell-script, let alone bash's extensions (not to mention having a mechanism to write in perl as well). Perhaps you could enlighten me. There are things about perl that I don't fancy as well -- much of what I want to change in bash or perl involves reducing repetitive typing -- as in this minor language RFE, but perl is way too fossilized with maintenance being dominated by an even more conservative core team. So to think that Perl might be extensible to allow for greater language efficiency or compatibility is very unlikely, as they can't even keep new versions of perl backward compatible with older versions. Bash has several fairly good reasons for slow evolution -- one maintenance of POSIX compatibility, and the fact that maintenance and development are still being coordinated by the original author. Compared to the perl case that has a constantly changing cast, no standards to adhere to (though some have been published, they aren't followed), and a coordination effort that is reminiscent of trying to herd cats. It's obvious that suse is moving away from simplicity with most of the commands to manage the system being 2-3 times as long as previously. So I wouldn't expect language efficiency to rate high on your priority list. However, consider this: "the number of bugs in code is proportional to the number of source lines, not the number of ideas expressed." -- So being able to express ideas in 1 line are maybe 2x more reliable than a language that forces splitting. There are several articles on programming language conciseness the benefits to the programmer of being able to express and write more concepts in less space and faster time (APL, for example, is thrown out as being to slow to program in due to needing a specialized character set -- so conciseness down to special symbols isn't considered a good thing). Besides doing your own search, I thought this article did a fairly good job of comparing various factors: http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/ *cheers* -l