Re: question on <const>

[Francisco Olarte <folarte@...>]

Philippe, were you replying to something I said?  Not sure due to top posting.

FOS


On Sun, May 24, 2020 at 11:44 AM Philippe Verdy <verdyp@gmail.com> wrote:
>
> I did not propose the language marker as a suffix, only as a prefix. But a suffix could work as well if you don't like "!const" (only because you want to read a lua program as if it was a NOT, while Lua uses only "~" for NOT), use "const!". What is important is that this syntax indicates this is not a programmable identifier but a syntax of the language.
>
> And really I chose "!" only because it was easy to type on any keyboard. So the notation with inverted exclamation marks is certainly just a sarcasm, itr's not serious as most keyboards don't have it (Lua should not be reserved for Spanish users only)
>
> Other languages choose other notation syntax to separate the namespaces, like "#" prefix (C/C++ preprocessor), "$" prefix or suffix. "\" prefix (TeX), "/" prefix (PostScript)... Using prefix/suffix with a single character not used for other operators (if whitespace separation of tokens for operators is not required, as is the case in C/C++/Java/Lua/PHP...) is not something new.
>
> But any comment to say "please no" is non-sense if you confuse the languages. I'm speaking just about Lua, and Lua only, which has its own notation and where "!" never means a "logical not". As well "~" never means a "binary not" or "match".
>
> I just argued that the choice of "<" and ">" creates syntax difficulties and it is not general enough to create a non-ambiguous syntax for general extension of the language with new reserved keywords (notably it does not allow any extension inside expressions), and that it had the same syntaxic problem as the use of "<" and ">" in C++ and Java templates, where the syntax cannot be disambiguated without semantic analysis, i.e. it becomes fully contextual and incompatible with a generic dynamic type system (which was still the goal of C++ and Java for their type templates to create generics): this was already an unfortunate choice that Java should have never chosen by mimicing what was chosen for C++ (C++ had to do this choice only because there did not remain any free ASCII character, all was already taken for identifiers, operators and delimiters, so the extension was very difficult, and C++ has then inherited many constraints for naming identifiers with lot of reserved prefixes/suffixes and a nightmare with naming conventions that can become incompatible with lot of extensions).
>
> What I'm arguing is that Lua should reserve now a prefix or suffix for its own evolutions and a way to preserve the backward compatiblity of existing programs, without having to use separate compilers or compiler flags to indicate how to parse the source....
>
>
>
> Le sam. 23 mai 2020 à 20:41, Francisco Olarte <folarte@peoplecall.com> a écrit :
>>
>> Andrea:
>>
>> On Sat, May 23, 2020 at 7:54 PM Andrea <andrea.l.vitali@gmail.com> wrote:
>>
>> > Is there a reason to have opening and closing mark? Or one could get away with something like !close or close! as Philippe was proposing?
>>
>> Or use ¡const! ( they are portuguese speakers, I'm not sure if they
>> have taht like in spanish ) (sarcasm, in case someone does not notice
>> )
>>
>> > Actually I like the use of the exclamation mark as it draws attention to something peculiar.
>>
>> Seriously. NO PLEASE. Many people read "!const" as "NOT CONSTANT",
>> specifically if you have a C / perl / many other languages background
>> ( and many of us do mixed C[++]-lua projects ).
>>
>> It's bad enough for me they chose ~ for not ( I used  ~=  a lot for
>> approximately equal ( very frequent in my writings ) in the
>> CP/M-messydog times, then came perl where I found ~ natural for match,
>> along with its variants due to this, then comes lua where it means
>> not, I have to correct != and ! in the lint stage of nearly every lua
>> module I write ( exception being the ones where ~= and ~ are not used
>> ). I'm constantly tempted to tweak my interpreters to allow it, and/or
>> preprocess every source to change it on save.
>>
>> Francisco Olarte.