lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


So you want to add the "is" keyword?

- It would not be evident and friendly for adding new statement types, or for adding new operators, or for various directives.
- And it would break existing valid programs: "local is=0; ...; is = is + 1" or "function is(x) ...end; y = x is 0" (meaning "y=x(is(0))")

Short terms like "is", "of", "to", "on", "off", "out", "as", "has", "no", "yes", "si", "ja", "non" are frequently found as convenient variable names (frequently they are abbreviations of longer names) because they were not reserved in Lua (Lua did not use any 1-letter reserved keyword for this reason, but 2-letter or 3-letter keywords cause problems, including "for", "in", "do", "begin", "end"... forcing programmers to chose other names, or to use tricky syntax like ['keyword'] with quotation marks to transform the keyword in a string literal and then surround it with square brackets to interpret the string as a key indexing the variable name, but this does not even work as [...] is also an operator in _expression_, just like "<...>" is two operators).

But then the notation of square brackets (if it's used to allow free identifiers) does not work for distinguishing "t[x]" (table indexing) with "t(x)" or t x" (function call). So identifiers for variables are already constrained (simply because of "t x" for curryfied function calls (without parentheses), which has added its own syntaxic ambiguities...

At the same time table constructors forced us to used the completely needless "[...]" for most keys (except *some* literal string values that are convertible to identifiers woutout the bracket and literal quotation, but strangely not for a simple numeric key): for keys in table constructors, the "[]" brackets are just an escaping mechanism, it is not at all related to the table indexing operator used in expressions.

Lua did not always chose the best solution to be a **really** universal language. Its syntax already suffers (like C++ or Java) from exceptions and ambiguities, solved arbitrarily (and not always with good alternatives with a strictly equivalent meaning).

Using a keyword for extensions is worse than just using a prefix or suffix which is not allowed in any identifier or any other syntaxic context where it could have a role.

Other languages chose other approach meant to be universal for identifiers without restriction (notably Postscript using "/" prefix for all identifiers distinguished from strings, TeX using "\" prefix, you can also look at Forth) and still allowing the language to use its own keywords for its own syntax.

Finally let's not forget that any decent language still needs a convention for variable naming to avoid clashes (if it intends to support reusable libraries), or the language should support at least namespaces (something that Lua still does not have, unlike C++ or XML), or a way to import a library while also permitting to rename the imported objects, or place/isolate all existing imported names in a local namespace (like the "using" clause in C#).






Le dim. 24 mai 2020 à 20:40, Andrea <andrea.l.vitali@gmail.com> a écrit :
Xavier

But I doubt the "<" and ">" symbol: Lua is a language that less use
symbols, we use "if ... then" but not "

local pi in const = math.pi
local fh in close = assert(io.open(fn))
local const in const, handler in close = a, b

I totally agree: Lua is nice and friendly because use less symbols than other languages. 

Your proposal seems quite good. I would like to be able to write 

Local pi is const = 3.14
Local handle will close = fopen()

No weird bracket angles. And the occasional reader of the code would be able to guess the meaning!

Maybe LHF and RI can give a feedback on that?

    Andrea 

--
Andrea Vitali