Re: Proposal: Lua should have arrow operators

[Alexander Schulz <aiqpost@...>]

Thanks for the comments so far.

The solution with debug.setmetatable can cause, like the mentioned
monkey patching, to much side-effects.

I know a chain function from underscore.lua[1] and other util libraries and tried
to use it, but it just didn’t feel right.

Sorry for the spam problem you can find the full discussion at:
http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html

The archive[2] does not show the newest entries.

[1] http://mirven.github.io/underscore.lua/#chain
[2] http://lua-users.org/lists/lua-l/


> Am 04.07.2017 um 22:16 schrieb Russell Haley <russ.haley@gmail.com>:
> 
> On Tue, Jul 4, 2017 at 2:06 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
>> On Mon, Jul 3, 2017 at 11:22 PM, Alexander Schulz <aiqpost@yahoo.com> wrote:
>> 
>>> In all other cases you have to use a function as a free function with the
>>> value as a parameter. While it is not a big deal for single function calls,
>>> the chaining of functions will always lead to a reverse call order:
>> 
>>> This is inconvenient to read and the only thing that is required in this
>>> case is to pass the result of the function as the first parameter to the
>>> following function.
>> 
>> It is the other way around. Most people doing programming in any language
>> have at least some background in mathematics and usually in other
>> programming languages, and are familiar with functional syntax and the
>> characteristic "reversal". It is the proposed syntax that is unfamiliar and
>> confusing. This is best illustrated by this very thread.
>> 
>> Your email address is @yahoo.com, and yahoo.com does not follow common
>> anti-spam practices, so emails from yahoo.com are routinely blocked. Your
>> email was no exception, all I could see were replies to your email, and it
>> was not easy to understand what the discussion was about. I had to go to my
>> spam folder to understand your proposal.
> 
> 
> I also had to resort to the archive to see what was happening in the
> conversation. I then had to switch back to gmail for the rest of the
> conversation because it doesn't seem to be archived yet. lolz
> 
> I was playing with the LuaRocks API and wanted to create a way to do
> the following:
> - Read all the require statements within a directory
> - Resolve everything local to said directory
> - Figure out what Luarocks already had
> - Install the list of everything else I needed.
> 
> In the end, my API looked aweful due to the 'reverse call order' as
> outlined as problematic in this 'Arrow Operator' proposal.
> 
>    -- You get the idea
>    GetAllRocks(OtherFunction(ResolveLocal(GetRequires("."),true)1,
> true),false, t)
> 
> While I am sure there are many fixes, the proposal would have solved my issue:
> 
> --Not much prettier I must confess. But readable.
> GetRequires(".")->ResolveLocal(true)->OtherFunction(1,true)->GetAllRocks(t)
> 
> I personally don't like the idea of varying the number of parameters
> via number of <character here>. It smells like a debugging nightmare
> to me. However, the paradox of how to also include other parameters in
> the call itself seems to be only solvable by automagically packing the
> return values in a table when the -> is used. Which means we're right
> back to tables. XD
> 
> I noted the use of Chain in the moses library and see it now
> referenced again in this email. Is this all coming from
> http://lua-users.org/wiki/MethodChainingWrapper? This 'Arrow Operator'
> proposal seems to be a similar mechanism to Chaining for overcoming
> 'reverse call order' issues? If the two subjects are similar, Mr LHFs
> ... er, I forget the lex parser-wrapper name... could be used with
> chaining to bash this together for testing? Once again, I think this
> is in the same direction I was looking to go with a 'Linq like' syntax
> DSL, however I would lean towards 'descriptive phrasing' rather than
> 'mathy notation'.
> 
> -- Not a proposal, just off the top of my head as an alternative
> Chain
> Returns GetAllRocks(t)
>   By OtherFunction(1,true)
>   By ResolveLocal(true)
>   By GetRequires(".")
> End
> 
> 
> 
> Cheers,
> 
> Russ