9 messages
Open this post in threaded view
|

 Hi! This is "Nitpicking on Wednesdays".   1) Lua 5.4 (as of 2019-Jan-30 on Github) Visual Studio 2010 warning lfunc.c(141) : warning C4244: 'function' : conversion from '__int64' to 'int', possible loss of data   2) A constant defined in lopcodes.h is never used    #define MAXARG_Cx    ((1<<(SIZE_C + 1))-1)   3) There is a typo in "manual.of" in section "To-be-closed Variables" in Lua 5.4 on Github "\emph" -> "@emph"   4) OP_CALL is described as R(A), ... ,R(A+C-2) := R(A)(R(A+1), ... ,R(A+B-1)) The note says:  (*) In OP_CALL, if (B == 0) then B = top. Probably, "B = top" should be replaced with "A+B = top"?   5) The S2N-coercion (from string to number) is somewhat anarchic:    local x = "2" | 3   -- coercion fails    local x = "2" + 3   -- coercion results in integer value    for x = "2", 3 do   -- coercion results in float value The coercion logic is unexpected and non-obvious. Even disabling of auto-S2N-coercion would be a lesser surprise  :-)  The coercion creates an illusion that in Lua you could use strings instead of numbers. But it's difficult to describe when you can rely on such coercion and when you can not. S2N-coercion isn't consistent across all the numeric operations:    "10" - "9" > 0             -- true    "10" > "9"                 -- false    math.max("10", "9")=="10"  -- false S2N-coercion is full of traps, using it is considered a bad practice, and it is becoming more complicated. Is it the right moment to remove auto-S2N-coercion from Lua?   6) The new syntax "local * toclose" is weird. Of course, such syntax would be useful if other modifiers (words after asterisk) are expected to be introduced in future Lua versions. Otherwise, more simple syntax for "to-be-closed" variables might be nicer.  Currently:    local n, str = 42, "abc"    local * toclose cl = obj  Possible suggestions:    local n, *cl, str = 42, obj, "abc" or    local n, (cl), str = 42, obj, "abc"  A pun: to mark a variable "to-be-closed", we make its name enclosed in parentheses. -- Egor
Open this post in threaded view
|

Re: [NoW] About to-be-closed new syntax

 Op Wo. 20 Feb. 2019 om 23:44 het Egor Skriptunoff <[hidden email]> geskryf: > This is "Nitpicking on Wednesdays". > 1) > Lua 5.4 (as of 2019-Jan-30 on Github) If is only on Github, not in the latest work version, it does not belong on lua-l, not even in NoW. There is a Github "issue" mechanism that should be used. > 5) > The S2N-coercion (from string to number) is somewhat anarchic: >    local x = "2" | 3   -- coercion fails >    local x = "2" + 3   -- coercion results in integer value >    for x = "2", 3 do   -- coercion results in float value > The coercion logic is unexpected and non-obvious. > Even disabling of auto-S2N-coercion would be a lesser surprise  :-) > > The coercion creates an illusion that in Lua you could use strings instead of numbers. > But it's difficult to describe when you can rely on such coercion and when you can not. > S2N-coercion isn't consistent across all the numeric operations: >    "10" - "9" > 0             -- true >    "10" > "9"                 -- false >    math.max("10", "9")=="10"  -- false > S2N-coercion is full of traps, using it is considered a bad practice, and it is becoming more complicated. > Is it the right moment to remove auto-S2N-coercion from Lua? Actually, auto-S2N coercion _has been removed_ from the current work version of Lua 5.4. All that remains is a sample set of metamethods. Your first two examples invoke the __bor and __add metamethods. In the 'for' statement, granted, it still is just old-fashioned coercion. Maybe we could have a __tonumber metamethod too, to give control in that situation? If the metamethod does not behave the way you expect or want, change it.  You don't even need the debug library for that: the metatable for strings already exists. Just assign nil to _bor and __add etc, and even the simulation of S2N will be disabled. For example, it would be straightforward to replace the supplied metamethods by wrapping a library supporting arbitrary-length integers. Or to have a Rebol-like ability to recognize many kinds of literals and manipulate tem sensibly. e.g. make sens of expressions like    "£3/6/8" * 3 -- Dirk
Open this post in threaded view
|

Re: [NoW] About to-be-closed new syntax

 On Thu, 21 Feb 2019 at 18:51, Dirk Laurie <[hidden email]> wrote: > > Op Wo. 20 Feb. 2019 om 23:44 het Egor Skriptunoff > <[hidden email]> geskryf: > > > Lua 5.4 (as of 2019-Jan-30 on Github) > > If is only on Github, not in the latest work version, it does not > belong on lua-l, not even in NoW. There is a Github "issue" mechanism > that should be used. That is not true. Github issues are turned off for the lua repository, as this mailing list is the correct place to report+discuss them.
Open this post in threaded view
|

Re: [NoW] About to-be-closed new syntax

 In reply to this post by Egor Skriptunoff-2 Il giorno mer 20 feb 2019, 21:25 Egor Skriptunoff <[hidden email]> ha scritto:6) The new syntax "local * toclose" is weird. Of course, such syntax would be useful if other modifiers (words after asterisk) are expected to be introduced in future Lua versions. Otherwise, more simple syntax for "to-be-closed" variables might be nicer.  Currently:    local n, str = 42, "abc"    local * toclose cl = obj  Possible suggestions:    local n, *cl, str = 42, obj, "abc" or    local n, (cl), str = 42, obj, "abc"  A pun: to mark a variable "to-be-closed", we make its name enclosed in parentheses. -- EgorI think we already have enough things to close, in any programming language. We close files, connections, blocks, scopes, transactions, ports, and so on.Please,please, please, please,consider a less overloaded term. "Defer" is the first one that comes to my mind.Pocomane,Ciao.
Open this post in threaded view
|

Re: [NoW] About to-be-closed new syntax

 I also think that the "*" syntax in declarations is very tricky, and in fact confusing (for most C/C++ programmers).I would much prefer a syntax using annotations (like in Java and other languages, using "@" instead, or like in C/C++ using a keyword in the declarator, with a parameter specifying the annotation/usage we want.The use of "*" alone does not allow any further development or generalization for annotations.So I suggest instead:  local n, @toclose cl, @toclose(options...) cl1, @todo(things) cl2And then create a object-oriented framework for these annotations (not just this syntax but a way to declare each "@identifier" as a sort of "metaclass" with properties, methods, metatable, and specify those "@identifier" that are ignorable, and those that are builtin and will become part of the language later (and may be checked at compile time, or load time, or run time...These annotations can augment the type system, can help compilers to find useful hints, can help code generators or code refactoring tools in source editors, can help document the objects/classes, can specify implementations limits, contracts, and check them when reusing components, can be used to infer proxing objects, can specify the transactional model (for transaction coordinators, working with both loal and remote objects).
Open this post in threaded view
|

Re: [NoW] About to-be-closed new syntax

 Actually, auto-S2N coercion _has been removed_ from the current workversion of Lua 5.4.This is really good news!Where can I read more about 6) ?Em sex, 22 de fev de 2019 às 14:54, Philippe Verdy <[hidden email]> escreveu:I also think that the "*" syntax in declarations is very tricky, and in fact confusing (for most C/C++ programmers).I would much prefer a syntax using annotations (like in Java and other languages, using "@" instead, or like in C/C++ using a keyword in the declarator, with a parameter specifying the annotation/usage we want.The use of "*" alone does not allow any further development or generalization for annotations.So I suggest instead:  local n, @toclose cl, @toclose(options...) cl1, @todo(things) cl2And then create a object-oriented framework for these annotations (not just this syntax but a way to declare each "@identifier" as a sort of "metaclass" with properties, methods, metatable, and specify those "@identifier" that are ignorable, and those that are builtin and will become part of the language later (and may be checked at compile time, or load time, or run time...These annotations can augment the type system, can help compilers to find useful hints, can help code generators or code refactoring tools in source editors, can help document the objects/classes, can specify implementations limits, contracts, and check them when reusing components, can be used to infer proxing objects, can specify the transactional model (for transaction coordinators, working with both loal and remote objects). -- "A arrogância é a arma dos fracos."===========================Me. Italo Moreira Campelo MaiaCo-fundador do Grupo de Usuários Python do CearáSecretário ForHacker (fb.com/ForHackerSpace)Desenvolvedor Full-Stack, Escritor, Empresário, Visionário-----------------------------------------------------Meu Livro, Site, Blog===========================
Open this post in threaded view
|

Re: [NoW] About to-be-closed new syntax

 In reply to this post by Philippe Verdy On Fri, Feb 22, 2019, 08:54 Philippe Verdy <[hidden email] wrote:I also think that the "*" syntax in declarations is very tricky, and in fact confusing (for most C/C++ programmers).I would much prefer a syntax using annotations (like in Java and other languages, using "@" instead, or like in C/C++ using a keyword in the declarator, with a parameter specifying the annotation/usage we want.The use of "*" alone does not allow any further development or generalization for annotations.So I suggest instead:  local n, @toclose cl, @toclose(options...) cl1, @todo(things) cl2And then create a object-oriented framework for these annotations (not just this syntax but a way to declare each "@identifier" as a sort of "metaclass" with properties, methods, metatable, and specify those "@identifier" that are ignorable, and those that are builtin and will become part of the language later (and may be checked at compile time, or load time, or run time...These annotations can augment the type system, can help compilers to find useful hints, can help code generators or code refactoring tools in source editors, can help document the objects/classes, can specify implementations limits, contracts, and check them when reusing components, can be used to infer proxing objects, can specify the transactional model (for transaction coordinators, working with both loal and remote objects).This sounds a lot like Python's decorators.