lua-users home
lua-l archive

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


As more and more quirks are found, all is not lost, but there's now a greater chance of a language fork to occur (just like the forke between C and C++ that are no longer compatible. or the second fork with C# (C++ is in my opinion a slowly dying language which has failed all its objectives, while _javascript_ has succeeded a lot and solved all its practical problems by retaining an excellent upward compatibility for its evolutions and still resisting to changes needed for security issues)

Lua is still young, and may leed to Lub for a second corrected major version fixing its major inconsistencies and removing some spurious legacy that were not really useful:

- e.g. long-bracket string literals,
- inconsistancies created by curification, to be solved by either making the semicolon required to separate _expression_ statements or by adding syntaxic distinction between newlines and other whitespaces

and adding a few other things like

- the integration of metatables and function environment in the syntax, 
- a specification for other types of literal constructors than just basic strings,
- integration of annotations in the syntax,
- integration of cyclic table constructors (using either tags, or local variables which could also be added inside expressions),
- integration of ternary conditional expressions or n-ary switch expressions without having to use complex anonymous functions syntax,
- suppression of the [] notation of keys in table constructors,
- better semantics for variable scopes and references to values
- better specification for the lifecycle of values themselves

and in the proposed default implementation, fixing:

- the broken table indexing,
- the costly representation of tables using too much memor
- the weak string hashes .


Le dim. 24 mai 2020 à 22:49, Dibyendu Majumdar <mobile@majumdar.org.uk> a écrit :
On Sun, 24 May 2020 at 18:39, Xavier Wang <weasley.wx@gmail.com> wrote:
> We just need change BNF from:
> attrib ::= [‘<’ Name ‘>’]
>
> To:
> attire ::= ['in' Name]
>
> e.g.
> local pi in const = math.pi
> local fh in close = assert(io.open(fn))
> local const in const, handler in close = a, b
>
> maybe "of" is a better word for keyword (I'm not native English
> speaker ), but IMHO the keyword prefixed is better than the symbol
> "<>".
>

Hi,

I don't if people realize but the ship's already sailed with regards
to 5.4, it was due for final release last week I think (but maybe got
delayed due to bug reports?). There is zero chance of any changes at
this stage IMO.

Regards