Re: syntax sugar for functions

[eugeny gladkih <john@...>]

the good syntax surge exists to write a common things is the short and expressive way. just like a table of methods or a list of execution order.

> On 15 Oct 2021, at 21:17, Philippe Verdy <verdyp@gmail.com> wrote:
> 
> If the syntaxic sugar is just a different way to express the same thing without adding any facility, it offers no interest at all. It gets interest only if if adds some behavior (e.g. avoiding repeating a subexpression, without having to declare a temporary variable, or create a separate block of statement to isolate that temporary variable (this is the case for example with the for statement) and programmatically have to handle the scope (so that the abbreviated form also gives hint to the compiler or optimizer about which temporary variable is no longer in use or must no longer be used, and so that common subexpressions can be evaluated only once and their result kept in an implicit variable/register); the same is true for the colon-syntax for functions to pass an implicit "self" argument: the code is clearer in that case, and less errorprone, so the syntaxic sugar has demonstrated benefits.
> 
> However a basic "sugar" changing the syntax of a simple function declaration offers no benefit, except possibly to provide additional hints or restrictions on the outer variables  in scope that are explicitly allowed to be used in the closure, and make these variables being explicitly named (yes in that case, it provides a clear code, and allows better isolation so that additional vairables which may be present in the closure would be implicitly hidden/inaccessible: the compiler can then use it to optimize these hidden variables to not pass them inside the closure, and the compiler can then reorganize the storage order and allocate the hidden variables only inside the parent function/block, possibly only on the stack and not adding any key in the table of variables for the parent scope, and closures can then be optimized and reduced in size, while enforcing a good programming style where dependencies are explicited; another interesting extension would be for these closures to have local name bindings: local names used inside the function would no longer have to be changed inside the function even if the outer scope has changed the name or its own binding; allowing as well easier refactoring of the code, including for testing local changes to an implementation). Note that function declarations already embed some existing syntaxic sugars (including for the declared name, which in facts hides a declaration of a local variable initialized with an anonymous function, and hides the hidden parameter pointing to the closure structure built with upvalues.
> So a syntaxic sugar must just be made to add other missing facilities (that are otherwise too complex to write without being errorprone): it should be used because it allows clear code and easier detection of programming errors (notably an accidental use of an outer variable in scope of the enclosing closure, whereas the function code should have declared its own local variable: in Lua there's no protection and it's easy for a programmer to corrupt unexpected variables in the enclosing scope, just because of a simple typo in a variable name and even linters won't help until there's a manual human scrutiny of the function's code: here a syntaxic sugar would help by offering a stringer isolation of the valid scopes, enforced by the scanner or the compiler). Other sugars could provide additional facilities for debugging or introspection/reflection and could also offer additional features like declaration attributes.
> 
> 
> 
> 
> 
> Le mar. 12 oct. 2021 à 17:08, SH <sebastian.horlebein@gmail.com> a écrit :
> function(b) a=a+1 return a+b end — <?(b) a=a+1 -> a+b ?>
> 
> Looking at this I'm wondering if you understood the idea behind syntactic sugars.
> 
> You just turned a simple statement into a clutter of special characters that is both harder to read and type imho.
> If you don't want to type Lua keywords so desperately, why not use auto-completion?
> 
> Sebastian
> 
> 
> Am Di., 12. Okt. 2021 um 15:03 Uhr schrieb eugeny gladkih <john@drweb.com>:
> re,
> 
> well. small improvement for someone interested in
> 
> function() a=a+1 return a end — <? a=a+1 -> a ?> 
> function(b) a=a+1 return a+b end — <?(b) a=a+1 -> a+b ?> 
> function() a=a+1 end — <?a=a+1?>
> 
> 
> > On 8 Oct 2021, at 17:28, Paul K <paul@zerobrane.com> wrote:
> > 
> >>> good for small functions passing as parameter. the idea is that list in {{ }} returns the last calculated expression (or the list)
> >> both are worse
> > 
> > There is "Short Anonymous Function" syntax page
> > (http://lua-users.org/wiki/ShortAnonymousFunctions), which includes
> > "do end" power patch for functions
> > (http://lua-users.org/wiki/LuaPowerPatches) and short anonymous
> > function syntax (http://lua-users.org/wiki/LuaPowerPatches), like
> > |param| param + 2. The latter is also implemented by GSL shell
> > (https://github.com/franko/gsl-shell) and LuaJIT lang toolkit
> > (https://github.com/franko/luajit-lang-toolkit).
> > 
> > Paul.
> > 
> > On Fri, Oct 8, 2021 at 3:04 AM eugeny gladkih <john@drweb.com> wrote:
> >> 
> >> 
> >> 
> >>> On 8 Oct 2021, at 09:49, Robert Burke <sharpobject@gmail.com> wrote:
> >>> 
> >>> Hello,
> >>> 
> >>> Indeed, the syntax proposed is currently valid:
> >>> 
> >>>> a = setmetatable({}, {__call=function(_,x) print(x[1][1]) end, __add=function(a,b) return b end})
> >>>> (a){{ a + 2 }}
> >>> 2
> >> 
> >> JS way:
> >> 
> >> (a) => a + 2
> >> () => b + 2
> >> => b+2
> >> 
> >> LISP like
> >> 
> >> ` b+2
> >> (a) ` a+2
> >> 
> >> both are worse
> >> 
> >>> 
> >>> On Thu, Oct 7, 2021 at 6:59 PM Spar <developspartv@gmail.com> wrote:
> >>>> 
> >>>> Your syntactic sugar basically adds entirely new syntax which is not used anywhere in language. These {{ }} are crazy and ambiguous
> >>>> On 7 Oct 2021, 12:56 +0300, eugeny gladkih <john@drweb.com>, wrote:
> >>>> 
> >>>> hi,
> >>>> 
> >>>> what about funny syntax sugar for functions definition, lazy people are welcome to upvote
> >>>> 
> >>>> function( a ) return a + 2 end -> (a){{ a + 2 }}
> >>>> function() do-something end -> (){{ do-something }}
> >>>> {{ do-something }}
> >>>> 
> >>>> good for small functions passing as parameter. the idea is that list in {{ }} returns the last calculated expression (or the list)
> >>>> 
> >>>> --
> >>>> Yours sincerely, Eugeny.
> >>>> +33 6 38 52 27 93
> >> 
> >> 
> >> --
> >> Yours sincerely, Eugeny.
> >> +33 6 38 52 27 93
> 
> 
> -- 
> Yours sincerely, Eugeny.
> +33 6 38 52 27 93


-- 
Yours sincerely, Eugeny.
+33 6 38 52 27 93
+7 (911) 999-74-25