Re: Proposal: Lua should have arrow operators

[Russell Haley <russ.haley@...>]

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