Re: blocks in Lua (was Re: [PROPOSAL] [PATCH] simple method call)

[Nagaev Boris <bnagaev@...>]

On Tue, Jun 16, 2015 at 3:46 PM, Coda Highland <chighland@gmail.com> wrote:
> On Tue, Jun 16, 2015 at 8:37 AM, Rodrigo Azevedo <rodrigoams@gmail.com> wrote:
>>
>>> >> > command = input:urldecode():lower():trim():split(' ')
>>> >
>>> >
>>> > You can do this:
>>> > command = filter.urldecode.lower.trim.split(' ')(input)
>>> >
>>> > One of the nice things about this is that the filter chain can be cached
>>> > easily:
>>> >
>>> > f = filter.urldecode.lower.trim.split(' ')
>>> > command = f(input)
>>> > command2 = f(input2)
>>
>>
>> I'm sorry, I would want to know if the patch I've proposed (the one in the
>> subject) can also solve this problem:
>>
>> f = function(str) -- do something with str
>>         return str:upper:lower .. "one"
>> end
>>
>> str = "Testing This "
>> str = f(str)
>>
>> f2 = function(str) -- example given
>>        return str:urldecode:lower:trim:split(' ')
>> end
>>
>> command2 = f2(input2)
>>
>> that also solves the problem?
>>
>> because with this you can easily understand that ":" are function calls, and
>> not confuse with "." syntactic sugar.
>>
>
> It should be noted that these chained filters are NOT function calls!
> They are not in fact operating on the value of their parameter.
> They're not invoked until you pass a parameter to the end result of
> the chain.
>
> Every filter is an object that possesses properties that are the
> result of certain transformations being performed upon the filter
> itself. These could be precomputed at time of construction except for
> the recursion, so they're constructed lazily, but they're not function
> calls in any practical high-level sense.
>
> It should also be noted that Boris Nagaev's implementation that
> requires the use of : for split can actually be fixed to not need it
> with a little bit of cleverness. (Specifically, it just needs to
> return a closure with the current filter as an upvalue, so the current
> filter doesn't have to be passed in as a parameter.)
>
> /s/ Adam

I think the use of . can introduce ambiguity.
Consider the following code:

y = filter.upper.sub(x)

Should y be a function-like object (1) or the result of applying
'filter.upper.sub' to x (2) ?

1) in this case y(z) means z:upper():sub(x)
2) in this case y is equal to x:upper():sub()


-- 


Best regards,
Boris Nagaev