Re: minor language RFE(s)
On 10/8/15 1:48 PM, Linda Walsh wrote: >> 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 You misunderstand. The implementation difficulty, such as it is, is secondary to whether or not changing the grammar like that is a good idea in the first place. I don't think it is, and I don't think that adding syntactic sugar is a compelling reason to change that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: minor language RFE(s)
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
Re: minor language RFE(s)
On 10/7/15 7:38 PM, Linda Walsh wrote:
> I was thinking ... lets say we had 1 or 2 abbreviation
> keywords, at least 1 being "int=declare -i",
> and ease-of-use "my=declare"
>
> that could then allow the "declare" of the 'for' iterator
> as local, in-line.
>
> i.e. instead of predeclaring them w/'declare -i' or 'declare'
> one could write:
>
> for((int i=0; i<10; ++i)); do : done
>
> or 2)
>
> for int i in {1..10}; do : done
> for my i in {a..z}; do : done
These change the syntax of the shell in incompatible ways. 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.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: minor language RFE(s)
Linda Walsh writes:
> If I am using a var as an index in a for loop
> as in:
>
> for((i=0; i<10; ++i)); do : done
>
> or 2) as an iterator as in
>
> for i in {1..10}; do : done
>
> **and** such usage is in a function,
>
> the default is to promote 'i' to 'global' status,
This behaviour is shared with all uses of shell variables.
> which is usually not needed nor desired (that doesn't mean
> there aren't cases where one wants it global,
> but I'm referring to the most common case).
>
> The common workaround is to put the onus on the user
> of 'i' to first declare it as local. That's not easily
> changed w/o potential chaos... however,
>
> I was thinking ... lets say we had 1 or 2 abbreviation
> keywords, at least 1 being "int=declare -i",
> and ease-of-use "my=declare"
>
> that could then allow the "declare" of the 'for' iterator
> as local, in-line.
>
> i.e. instead of predeclaring them w/'declare -i' or 'declare'
> one could write:
>
> for((int i=0; i<10; ++i)); do : done
>
> or 2)
>
> for int i in {1..10}; do : done
> for my i in {a..z}; do : done
If you want perl you know where to get it.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
minor language RFE(s)
If I am using a var as an index in a for loop
as in:
for((i=0; i<10; ++i)); do : done
or 2) as an iterator as in
for i in {1..10}; do : done
**and** such usage is in a function,
the default is to promote 'i' to 'global' status,
which is usually not needed nor desired (that doesn't mean
there aren't cases where one wants it global,
but I'm referring to the most common case).
The common workaround is to put the onus on the user
of 'i' to first declare it as local. That's not easily
changed w/o potential chaos... however,
I was thinking ... lets say we had 1 or 2 abbreviation
keywords, at least 1 being "int=declare -i",
and ease-of-use "my=declare"
that could then allow the "declare" of the 'for' iterator
as local, in-line.
i.e. instead of predeclaring them w/'declare -i' or 'declare'
one could write:
for((int i=0; i<10; ++i)); do : done
or 2)
for int i in {1..10}; do : done
for my i in {a..z}; do : done
---
Note: "int" and "my" would be
equivalent to "declare -i" and "declare" -- NOT
"local -i" or "local" so that such statements
could be moved in or out of functions w/out removing
the declaration.
Note2: 'my' is for convenience -- so one wouldn't
have to spell out
for declare i in {a..z}...
which looks a bit ugly IMO...
Anyway was just thinking about this when writing
such loops, and renaming the iterator a few times -- and
having to make sure the declaration was changed in line
with the 'for' usage: requiring 2 separate lines of code
(that may or may not be adjacent to each other) in sync
is always a pain, not to mention occasionally error prone.
Anyway -- just a thought?
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..?
