Re: Lua has reached a local optimum

["szbnwer@..." <szbnwer@...>]

2018-07-05 16:03 GMT+00:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>> 2018-07-05 14:52 GMT+02:00 szbnwer@gmail.com <szbnwer@gmail.com>:
>>
>> > 'str':fun() and {}:fun() would be nice to see. i
>> > can only remember that the reasoning against this was 'cuz the refman
>> > says so' :D (probably that was you, Dirk, you are the local refman
>> > guru (that i like to see! :) ))
>>
>> I can't find the thread but the clincher for me was a demonstration
>> (not by myself) that a syntax ambiguity could arise.
>
> A syntax ambiguity is already there; these cases would make it worse:
>
>   -- already ambiguous:
>   a = b + c
>   ('str'):fun()
>
>   -- new ambiguity:
>   a = b + c
>   'str':fun()
>
>   -- new ambiguity:
>   a = b + c
>   {}:fun()
>
> -- Roberto

if `c` is a callable, then it can be called w/o parenthesis just as
well the same way. there is already the need for semicolons here and
there in some corner cases, but i'd feel this more consistent around
the "luaverse"

however if any1 can find past talks, or give new pro-contra, then
don't hold back nothing :) i think it was around late 2017, but this
can be misleading if not, and i'd guess it came from Soni, or maybe
someone who is rare around, and i even have an impression that a yahoo
mail was involved, cuz ive got the vision that i've found this in my
spam folder with additional suggestions for some sugar... and fine, i
will do my part of research as well, and throw a pointer if i have it
:)

btw an another stuff that came into my mind is that we need an `if`
block or a `local _=` for an expression like `option and fun()` or
`fun1() and fun2()`... the `local _=` is just too ugly to use, however
we already can call functions without capturing any value that it
returns, and it is not rare at all, and i never had to use a
semicolons cuz of this, however i think its not that rare. so this is
something else that we could think about :D

anyway my use case for the error messages without being trimmed is to
show the place of an error with some extra lines around, however it
can be ambiguous anyhow, like
a/longpath/x.lua --> ...ongpath/x.lua
b/longpath/x.lua --> ...ongpath/x.lua
this way a traceback can be hard to follow in some cornercases...
however even giving fast access can be hard/impossible :/
currently my best guess is to wrap require and co. to keep the paths,
and the worse is when there are more places to visit in some rare
cases, so it's kinda fine to live with, just like a splay-foot :D

if im right, then none of these 3 suggestions would make impossible to
hold compatibility, but there are other points of view for evaluating
these possibilities, but that is the business of the community to
autopsy whatever comes here :D