Re: [PROPOSAL] [PATCH] simple method call

[Nagaev Boris <bnagaev@...>]

On Fri, Jun 12, 2015 at 11:20 AM, Rodrigo Azevedo <rodrigoams@gmail.com> wrote:
> Some explanation about my personal view of Lua function call:
>
> Actually there are three different ways to call a function, with the
> *suffix* notation (, { or ", covering three different cases:
>
> (1) name ( args ) -- *general suffix* that means: pass args to name and call
>
> (2) name "string" -- particular, and usefull, suffix call that means: pass
> "string" (only) to name, and call.
> (3) name {table} -- particular, and usefull, suffix call that means: pass
> {table} (only) to name, and call.
>
> Such that,
>
> A) The argument that parentheses *looks* like a functional call is
> unfounded, since (2) and (3) do not *look* like a function call, as just
> argumented in this thread.

Please do not!

In my opinion, something *looks* like a functional call if it has
something after function/method name:

Functions:
- foo() is a call, "foo" is not
- foo 'xxx' is a call, "foo" is not
- foo {xxx=yyy} is a call, "foo" is not

Methods:
- foo:bar() is a call, "foo:bar" is not
- foo:bar 'xxx' is a call, "foo:bar" is not
- foo:bar {xxx=yyy} is a call, "foo:bar" is not

If "foo:bar" were a call, then why "foo" would not be a call? In Basic
and Pascal, "foo" is a call, if foo has no arguments.

> In fact, I really think in (2) and (3) as unary (broad sense), suffix,
> operators.
>
> B) The syntactic sugar ":" is cleary a *prefix* call, such that
>
> (4) foo : bar ( args )  -- implies pass foo as first argument followed by
> args to bar, and call.
>
> (5) foo : bar "string" -- means pass foo as first argument followed by
> "string" (and only these two) to bar, and call.
> (6) foo : bar {table} -- means pass foo as first argument followed by
> {table} (and only these two) to bar, and call.
>
> This way (5) and (6) are particular cases of (4). We can also interpret (5)
> and (6) notation as a generic binary operator [1], with arguments foo and
> "string", or foo and {table}, and bar operator.
>
> PROPOSAL
>
> We also have a third, particular and common case of (generic) unary
> operators [2]. At the time this is more easily accomplished by the notation
>
> (7) foo : bar ()
>
> where the *suffix* () pass nothing to bar, it is only redundant. In this
> case the *preffix* function call
>
> (8) foo : bar
>
> is completely defined, means pass foo (only) to bar, and call. Very simply
> indeed, and completely compatible with the Lua *look* just implemented
> capabilities. Compare with the comments of (2) and (3) above, and [2].
>
> If you do not feel confortable with (8) then use (7), since it is only
> syntactic sugar! If you really want to be (not so) expressive in the Lua way
> use
>
> (9) foo.bar(foo)
>
> it is only convenience, as well as (2), (3), (5) and (6), but the
> expressiveness increases a lot.
>
> [1] example: we can think of 5 : + (6) as simply as 5 + 6 .
> [2] real(imaginay number) as z : Re, as well as Re (z), the *prefix* and
> *suffix* versions.
>
>
> 2015-06-11 9:26 GMT-03:00 Rodrigo Azevedo <rodrigoams@gmail.com>:
>>
>> REASONING
>>
>> There are uncountable examples of "methods" that do not need an argument,
>> for example
>>
>> led[1]:blink
>> arm[2].pos[3]:go
>> z:abs
>> z:Re
>> polynomial:diff
>> etc
>>
>> PROPOSAL
>>
>> Raise the "methods" syntactic sugar ":" to a function call without
>> arguments, with the exception of the ubiquitous "self", namely, call
>> "methods" without the common usage of  '(' ')', or '{' '}' or ' " ' ' " '.
>>
>> PATCH
>>
>> This patch applies a minimalist update of lparser.c to implement the
>> described behaviour.
>>
>> For Lua 5.3.0
>>
>> EXAMPLE USAGE
>>
>> unpack, istable = table.unpack, function(t) return type(t) == 'table' end
>>
>> t = {}
>> t.name = "testing ... "
>> function t:prt (str) print(self.name .. ((istable(str) and str[1]) or str
>> or "") .. " OK") end
>>
>> t:prt -- NEW!
>>
>> t:prt ()
>> t:prt "string"
>> t:prt {"table"}
>>
>> t:prt
>> ("ambiguity")
>>
>> t:prt
>> (print("OI"))
>>
>> print("c'est fini")
>>
>> --
>> Rodrigo Azevedo Moreira da Silva
>
>
>
>
> --
> Rodrigo Azevedo Moreira da Silva



-- 


Best regards,
Boris Nagaev