RFC: "in place" return from imperative function calls

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

Re: append to list operator

Sergey Kovalev
чт, 15 авг. 2019 г. в 11:00, Oliver <[hidden email]>:

>
> On 13.08.19 06:45, Sean Conner wrote:
> >   Well, another pain point is
> >       veryLongNmae[complexLValue] = veryLongName[complexLValue] + 1
>
> a similar and common use case is appending an element to an array: it's also
> painful to write:
>
>         complexLValue[#complexLValue + 1] = newElement;
>
I can reduce your pain. Just write:

table.insert(complexLValue,newElement)

Reply | Threaded
Open this post in threaded view
|

Re: += operator

Egor Skriptunoff-2
In reply to this post by Oliver Schmidt
On Wed, Aug 14, 2019 at 9:32 PM Oliver wrote:
I would
prefer simple +=. I know from time to time this comes up in this list but I
never understood why Lua does not have +=.



Problem #1
+= could not be added alone.
There are a lot of similar operators:
-=
*=
/=
%=
//=
^=
|=
&=
<<=
>>=
..=
Should new metamethods be introduced?
PRO: they would be useful for DSLs
CON: too many metamethods to implement in regular user classes.
 
 
 
Problem #2
I guess XOR is the second popular operator (after addition) used in such short notation.
But we can't introduce short notation for XOR "a = a ~ b", because "~=" is already used for non-equality.
"^=" in Lua would be raising to the power, not XOR
 
 
Problem #3
Why only right addition/multiplication/division/etc?
"a *= b" means "a = a * b", but how to write "a = b * a"?
This might be important, for example, for matrices.
 
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "in place" return from imperative function calls

Egor Skriptunoff-2
In reply to this post by Soni "They/Them" L.
On Wed, Aug 14, 2019 at 11:11 PM Soni "They/Them" L. wrote:

how about @self (returns the currently executing function object), @var
(returns the value of the variable being assigned to) and @table
(returns the table being currently constructed)?

(@table would be particularly useful for some DSLs. note that all of
these only affect the local lexical scope and don't work across
modules/function call boundaries.)



Oh, yes!  Tables!  I like the idea of referencing the table being constructed:
   local vec = {x = get_x(), y = get_y(), len = (@.x^2 + @.y^2)^.5}
 
Positional references might also be useful:
   local a, b = {name = "a", next = @2}, {name = "b", prev = @1}
 
What about more crazy things?
   local function getxy() return x, y end
   local len = (@2^2 + @3^2)^.5, getxy()
(x = @2 and y = @3 are returned by getxy() but not assigned to variables)
 
 
This might be good if it didn't look so Perl-ish :-)

Reply | Threaded
Open this post in threaded view
|

Re: RFC: "in place" return from imperative function calls

Soni "They/Them" L.


On 2019-08-17 1:34 p.m., Egor Skriptunoff wrote:

> On Wed, Aug 14, 2019 at 11:11 PM Soni "They/Them" L. wrote:
>
>
>     how about @self (returns the currently executing function object),
>     @var
>     (returns the value of the variable being assigned to) and @table
>     (returns the table being currently constructed)?
>
>     (@table would be particularly useful for some DSLs. note that all of
>     these only affect the local lexical scope and don't work across
>     modules/function call boundaries.)
>
>
>
> Oh, yes!  Tables!  I like the idea of referencing the table being
> constructed:
>    local vec = {x = get_x(), y = get_y(), len = (@.x^2 + @.y^2)^.5}
>
> Positional references might also be useful:
>    local a, b = {name = "a", next = @2}, {name = "b", prev = @1}
>
> What about more crazy things?
>    local function getxy() return x, y end
>    local len = (@2^2 + @3^2)^.5, getxy()
> (x = @2 and y = @3 are returned by getxy() but not assigned to variables)
>
>
> This might be good if it didn't look so Perl-ish :-)
>

here's the thing tho, all the things I listed already exist through the
debug library.

Reply | Threaded
Open this post in threaded view
|

Re: += operator

Philippe Verdy
In reply to this post by Egor Skriptunoff-2


Le sam. 17 août 2019 à 18:34, Egor Skriptunoff <[hidden email]> a écrit :
On Wed, Aug 14, 2019 at 9:32 PM Oliver wrote:
I would
prefer simple +=. I know from time to time this comes up in this list but I
never understood why Lua does not have +=.



Problem #1
Should new metamethods be introduced?
PRO: they would be useful for DSLs
CON: too many metamethods to implement in regular user classes.

Why methamethods ? Just define them as syntaxic sugars that make them equivalent to a standard assignment (including its existing methamethod) combined with the binary operator (including its existing methamethod). Adding new metamethods for them would confuse even more the task of programmers with unexpected behaviors if such new methemethod is implemtend but not coherently with the two other metamethods.
Problem #2
I guess XOR is the second popular operator (after addition) used in such short notation.
But we can't introduce short notation for XOR "a = a ~ b", because "~=" is already used for non-equality.
"^=" in Lua would be raising to the power, not XOR

For that we need another syntax like "~|=" (initially parsed as unary "~" but before the binary assignment-operator "|=" that it modifies).

Other useful sugars: "and=", "or=". The second one is useful to replace the common situation: x = x or 'default value'; which could be written: x or= 'default value';
Once again, don't introduce them with metamethods: the compiler will internally use a hidden (intrinsic) local variable for the reference to the left-hand "variable" (which may be an expression returning a table-member reference, possibly a member of a table/object returned by a function call), and then will use the standard assignment (without any shortcut for "or=" or "and=": the assignment must be performed in all cases, even if the right-hand side is not always evaluated if the left-hand variable is already true (i.e. not false and not nil), causing the assignment metamethod being still called (even if the value assigned is the same as the existing one if the variable is already not false and not nil).
 
I don't favor adding new metamethods for all them (let's not reproduce the nightmare of C++ operator overrides that forces programmers to define both the operator and the operator-assignment and trying to "play" with complex accessors whose inheritance is hard to track). In summary, only the compiler will be updated, but compiled code at run time and metatables will not be modified with additional members.

Problem #3 
Why only right addition/multiplication/division/etc?
"a *= b" means "a = a * b", but how to write "a = b * a"?
This might be important, for example, for matrices.

I agree: if one adds such operator-assignment syntax, it must be added for all operators.

Another useful sugar: not=x; equivalent to x=not x (using the unary "not" operator): in that case add not only "not=", but also "!=" (binary complementation, different from "not=" which is the logical operator testing for nil or false values), however, "!= x;" could still be written as "x ^|= -1" (using binaryxor-assignment) with the same effect as "x = x ~ -1" (except that the reference to "x" is computed only once if "x" is a member of table returned from complex subexpression).


Reply | Threaded
Open this post in threaded view
|

Re: += operator

szbnwer@gmail.com
hi there! :)

i dunno why `~=` came into lua, i believe it have historical
background, but i think the best would be to delay any of these sugar
operators to 6.0 (if ever, but im not against them, just the
unresolved syntax collision...) while provide a converter only for
`~=` --> `!=` (preferably written in lua, 5.x and 6.0 both in case of
need) that can be either bulletproof, or suggestive, where it tells
1st what it would change, and then people can check if its fine or
not.... otherwise the language will become ugly if we must go around
the existing syntax for extending lua... probably this can be a thing
to consider also about `--` (comment/decrement) but that won't be as
smooth as `~=`, cuz `--` can and will appear in more unexpected forms,
like in different stylings...

the better alternative is still a preprocessor that i suggested
earlier, that will save some keypresses but wont make lua better in
functionality... the key point there was selectable conversions that
is a manner of a lua table that can arrive with different projects, so
everyone can use their most beloved set of syntax sugar while the
translation base will still be our beloved current lua, or even just
an another file that waits for the preprocessor but with different
settings... :D

bests! :)

12