[NoW] About to-be-closed new syntax

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[NoW] About to-be-closed new syntax

Egor Skriptunoff-2
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

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
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

Reply | Threaded
Open this post in threaded view
|

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

Daurnimator
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.

Reply | Threaded
Open this post in threaded view
|

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

pocomane
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.

-- Egor

I 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.


Reply | Threaded
Open this post in threaded view
|

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

Philippe Verdy
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) cl2

And 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).

Reply | Threaded
Open this post in threaded view
|

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

Italo Maia
Actually, auto-S2N coercion _has been removed_ from the current work
version 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) cl2

And 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 Maia
Co-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
===========================
Reply | Threaded
Open this post in threaded view
|

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

Rena
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) cl2

And 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.
Reply | Threaded
Open this post in threaded view
|

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

Coda Highland


On Sat, Feb 23, 2019 at 11:04 AM Rena <[hidden email]> wrote:
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) cl2

And 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.

Python, Java, and Javascript all have fairly similar decorator syntax. C# has a decorator syntax that looks different but works similarly. C++ has an attribute system that provides this general kind of advisory thing but it's not very flexible. So there's definitely precedent.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

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

Egor Skriptunoff-2
In reply to this post by Italo Maia
On Fri, Feb 22, 2019 at 6:56 PM Italo Maia wrote:

Where can I read more about 6) ?



Here: