I agree, it's an inherently subjective issue as well, which means no solution will make everyone happy. Additionally, at this point, the change has pretty well propagated throughout the community, so the "damage is done" so to speak (though in my opinion the current solution is the best given the language constraints).
Understanding the Lisp 1 vs 2 debate is also critical here - fundamentally something has to give, you either need a way to syntactically determine whether a name belongs to a function or variable, and thus be able to have separate namespaces, or share a namespace and define rules which resolve the ambiguity with zero-arity functions. The latter is the best option in my opinion, and what led to the current solution. Doing nothing is the least desirable option here. Paul On Wed, May 31, 2017 at 4:36 PM Michał Muskała <[email protected]> wrote: > To be honest, I don't think this is a big issue or a problem that needs > changes. The biggest proof, it's not a problem in practice is the fact that > it's almost 6 months since elixir 1.4 introduced this warning. After first > couple weeks, when most libraries were upgraded to get rid of the warning, > there aren't many complaints. As far as I can remember, it hasn't come up > even once last couple months on either Elixir Slack or IRC. > > Michał. > > On 31 May 2017, 20:46 +0200, [email protected], wrote: > > First, sorry to re-open an old thread and thanks for all the awesome work > done on Elixir. I humbly think I might have 1 or 2 original thoughts on the > matter. > > I am in the camp of either (1) getting back to 1.3 behavior or less > ideally (3) narrow down to only the cases when we have a function and a > variable with the same name. > > The original issue seems to be poor variable and function naming coupled > with some unexpected pollution from imports. I don't think it's an issue > with the language itself. If you take the case of the `conn` and > `Plug.Test.conn/0` collisions, renaming the function to > `build_connection/0` seems more straightforward than requiring everyone to > use `()` for zero parameter function calls. > > Furthermore, having namespaces of variable and function mixing together > seems to be the original intent of the language. Same way Ruby allows to > not care if an object come from some code or it's already there. Of course, > José Valim would know better what was the original intentions, but bare > with me! If we want a strict separation of these 2 namespaces with the end > goal of reducing cognitive load, shouldn't we have a different way of > naming variable like other languages are doing with for example > `$variable`? I know Dave Thomas wasn't serious, but I even like the idea of > adding a dot in front of every functions - `.function` - keeping variables > untouched. It feels embracing even more the functional way. It seems too > late to make this kind of changes though. > > Finally, my main point will be to make the parallel with Python `3.0` > changes. Adding brackets to every function calls in order to be more > explicit. The scope was larger, and Python `3.0` added also some other > controversial changes in the way strings were handled that weren't liked by > everyone. But, the push to require brackets was the main point of discord > and it resulted in a schism in the community. Even after almost a decade, > Python 2.7 is still there and Python 3.5 still has trouble making his nest > despite being now faster and more features rich. I think we all want Elixir > to succeed. It means more people will be using it resulting in less bugs > and more libraries. However, this kind of changes - that seems trivial and > reasonable - can hurt a community a lot more than it seems. > > However, at the end of the day, this is not a democracy, and we'll all > respect whatever you will decide. > > Thanks, > Julian > > On Tuesday, December 6, 2016 at 12:51:32 PM UTC-6, Michał Muskała wrote: >> >> >> > On 6 Dec 2016, at 19:48, [email protected] wrote: >> > >> > Would it be possible to have a flag attribute to disable warnings on >> particular modules or something? Not the greatest solution, but it could >> potentially be enough to support DSLs and IEx helpers >> > >> >> In DSLs you could manually upgrade the variable into a function call >> instead of relying on the compiler to do so (and emit a warning). >> >> The AST of a variable is {name, meta, context}, while AST of a function >> call is {name, meta, args}, in case of 0-arity calls the last argument >> would always be an empty list. >> >> Michał. >> >> -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/d8f5e848-2fc9-460b-8b55-e8dfc00ced56%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/d8f5e848-2fc9-460b-8b55-e8dfc00ced56%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/fd313358-1f3c-49ff-924e-3f67025628e7%40Spark > <https://groups.google.com/d/msgid/elixir-lang-core/fd313358-1f3c-49ff-924e-3f67025628e7%40Spark?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TtgE4Y9mgbaShoUedM-psuJfMtk95jVDiFa2yFZwmxcsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
