Re: minor language RFE(s)

[Linda Walsh]

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