Re: Patch for unicode in varnames...

[Dethrophes]

Instead of talking in terms of seriousness, it may be more use to think in 
terms of formality. 

Even in gramitically strong and formal languages variable and function names 
are restricted in the characters they may use. This is not just because it 
makes the parsing simpler but because it simplifies reading comprehension of 
the code. 

Now bash is already very difficult for most to appreciate the subtitles of how 
it is written. Supporting an almost endless number of characters in car and fun 
names would just make it endlessly more complex to understand.

This would be a bad idea in the same way that having control characters in 
filenames is a bad idea, just because you can do something doesn't mean you 
should.

This is also a question of the tco (total cost of ownership) of code. The 
flexible you allow the coding to be the more difficult it is to understand 
others code. Perl(need to be a guru to read someone else's code) vs python(a 
noob can figure it out pretty quickly with Google.).




On June 7, 2017 10:03:08 PM GMT+01:00, George <tetsujin@scope-eye.net> wrote:
>On Tue, 2017-06-06 at 10:20 -0400, Greg Wooledge wrote:
>> (OK, in reality, I am not taking any of this seriously.  This entire
>> proposal and discussion are like some bizarre fantasy land to
>me.  Bash
>> is a SHELL, for god's sake.  Not a serious programming
>language.  Even
>> serious programming languages are not ready for this; see the Python
>> proposal that was mentioned up-thread.)
>> 
>I don't think "shell" and "serious programming language" must be
>considered mutually exclusive.
>Shell scripting is "serious" in the sense that there are people who
>rely upon and actively develop shell scripts to keep their products
>working. If
>the language itself seems not "serious" I think that is because not
>enough effort has been made to extend and improve its functionality
>over time. (At
>least, not in the Bash project...  Korn Shell has done some good work
>along those lines.)
>But I think the "interactive" aspect is probably the most compelling
>argument for supporting something like this. The shell can serve as one
>of the
>primary tools for operating the computer. As such it should also aim to
>be a comfortable environment. If you tell a programmer that a shell
>only
>accepts ASCII in some contexts, there's a fair chance they'll
>understand why, and accept the limitation. For more casual users, this
>may not be the
>case. I think they'd be likely to wonder why they can't use accented
>characters, or other alphabets for parameter names. I don't think
>there's a
>particularly good reason not to allow it...  Though I'd personally like
>to see it implemented in a way that allows scripts to take advantage of
>that,
>and still work reliably regardless of the locale setting in which
>they're ultimately run.
>As a side note, I had expressed concern that Bash might not work
>correctly with GB-18030 encoding, but it appears that I was wrong. I
>set up a
>terminal to display the GB-18030 character set, set the locale within
>the terminal to GB-18030, and formed a string that I would expect to
>expose a
>parser bug (a string of multi-byte Chinese characters including 0x7C,
>the byte that corresponds to the ASCII vertical bar character), but it
>appeared
>to parse the string correctly according to the locale rather than break
>it up on the 0x7C byte. So that's good. :)

-- 
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.