I’ve been loving 1.4 for a few weeks now, but I am bugged by the new warning:
warning: variable "int" does not exist and is being expanded to "int()", please use parentheses to
remove the ambiguity or change the variable name
Partly it is because it makes my code a lot uglier. For example, in quixir, instead of
test "two plain types" do
ptest a: int, b: list do
assert is_integer(a)
assert is_list(b)
end
end
I now have to write:
test "two plain types" do
ptest a: int(), b: list() do
. . .
Ugh. Even worse, the premise of the warning seems wrong. It assumes int
is a variable, which doesn’t exist. But it does know that int
is a function, because if I misspell it and put ()s on, I get a compilation error. So why can’t it just do that: is a bare name is encountered that isn’t a variable, just internally tack on the ()s are see what happens. Which I think is the old way.
Basically, what compelling problem drove this change? It isn’t an issue I ever had before, and the change seems to make my code worse.
Dave
Cheers,
Louis
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/22ad983c-0917-4425-abbe-a6e954ae3b61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM-pwt7JgYzWnC6y1-ELHj%2BOeaJDuDCamAxJmktdeYRdLaYFEA%40mail.gmail.com.
setup do
{:ok, conn: conn(:get, "/foo/bar")}
end
test "can do a get request" do
assert SomePlug.call(conn, []).path_into == ["foo", "bar"]
end
int = 42
ptest list: list(length: int, of: atom) do
assert ...
end
ptest list: list(length: int, of: choose(atom, int)) do
assert ...
end
I've been living with 1.4 for a few weeks now.
I am bugged by the new warning:
~~~
warning: variable "int" does not exist and is being expanded to "int()", please use parentheses toremove the ambiguity or change the variable name
test/generators/int_test.exs:10~~~
Partly it is because it makes my code a lot uglier. For example, in quixir, instead of
~~~elixir
test "two plain types" doptest a: int, b: list doassert is_integer(a)assert is_list(b)endend
~~~
I now have to write:
~~~ elixir
test "two plain types" doptest a: int(), b: list() do
assert is_integer(a)assert is_list(b)endend
~~~Ugh.Even worse, the premise of the warning seems wrong. It assumes `int` is a variable, which doesn't exist. But it _does_ know that `int` is a function, because if I misspell it and put ()s on, I get a compilation error. So why can't it just do that: is a bare name is encountered that isn't a variable, just internally tack on the ()s are see what happens. Which I think is the old way.
Basically, what compelling problem drove this change? It isn't an issue I ever had before, and the change seems to make my code worse.Dave
--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/924b70db-79f1-43c1-afc7-49a94cd541e5%40googlegroups.com.
I'm dead against this warning. Sure, I've tripped over this issue a few times, but the benefit of this change is not worth the cost IMHO. I'll have to update all my commercial projects, my open source projects, and likely fork/submit PRs on some of my 3rd party dependencies. Until all that is done, I'll have numerous compiler warnings generated which is a distraction from noticing "real issues" warnings. Without the ability to disable specific warnings in the compiler, I think this warning is a terrible idea.
--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ca61db5a-34d3-4bae-a263-0cddafe6418e%40googlegroups.com.
On Saturday, December 3, 2016 at 10:12:30 AM UTC-6, José Valim wrote:
> Basically, what compelling problem drove this change? It isn't an issue I ever had before, and the change seems to make my code worse.There were a couple scenarios that I either personally ran into or were frequently reported. One of those came from Plug test suite. In Plug it is common to pass the connection named as "conn" around between setup/tests:
So we lose things like this?
iex(2)> v
warning: variable "v" does not exist and is being expanded to "v()", please use parentheses to remove the ambiguity or change the variable name
iex:2
There’s a simple cure for variable/function ambiguity—choose good names and write trivial functions. This kind of thing typically bites when your code is struggling in some extended swamp of names. Maybe being bitten on those occasions is just what the developer needs to stop doing it :)
Even if you really, really want to do this (please reconsider), could we at least not warn if the ambiguity can be resolved at compile time—if there’s a function/0 available with the given name, just compile it as a call and move on?
Dave
Could we warn only if both a function and a var exist, as in the Plug test case?
I think the narrowest warning that would still happen on your examples of bad behavior is where we should start.
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KPq2UyFF2qP-FwFAagG-KCoKam_GfHgwztC0sm9j3NgQ%40mail.gmail.com.
> could we at least not warn if the ambiguity can be resolved at compile time—if there’s a function/0 available with the given name, just compile it as a call and move on?That's exactly the behaviour we had before. After all, if you do not have a variable nor a function name, it wouldn't compile with reason no variable or function named x.
Is it possible to detect if a variable shadows a function, and warn in that case? I really, really, REALLY don't want to write v() in iex... :)
I really, really, REALLY don't want to write v() in iex... :)
But if it is desirable in iex, and acceptable in pipelines, why not other code?
I just don’t get why this is such a problem. Having
setup do
{:ok, conn: conn(:get, "/foo/bar")}
end
seems to be just bad naming. They are deliberately choosing to have a key with the same name as a function. That seems to be confusing in its own right. If this causes a test to fail, I think that’s a good thing, as it might spur the writer to rethink the naming.
I think the same thing applies with
int = 42
ptest list: list(length: int, of: int) do
assert ...
end
All the arguments I’ve seen so far have nothing to do with function/variable ambiguity. They are simply to do with name clashes. They are no different to
size = 42
# some code ...
size = &String.length/1
ptest list: list(length: size, of: choose(atom, int)) do
assert ...
end
Both this and the function/variable case fail because a name was used twice. It’s a case of Caveat Coder.
Dave
The more I explain this, the clearer it becomes to me variables and functions have no business in stepping on each other's namespaces.
--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/61d33cd3-23e8-4606-a27a-fb0bc9d7f1ad%40googlegroups.com.
I just want to throw in my two cents. I don't think a warning should be generated if there is no ambiguity about a name.
I find it a little difficult to understand why always warning is preferable to warning conditionally for this one.
OK, one more try. If I say `Mod.a`, then 1.4 (correctly) treats it as a call—I don't need the ()s. A bare function call means the current module. So could we also support `.a` as a function call in the default module?
We compile our code with warnings as errors so it's very important for us to have warnings that point out problems in our code.
I feel like the sentiment about being able to use zero arity function without parentheses is pretty split in this thread. If there was a consensus about this warning I would be fine with it.
Regards,
Olaf
--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/874996b8-6759-4a77-be31-d7e050cd6123%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a9fd5f51-f302-49ff-b228-04ff2ff248bd%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a9fd5f51-f302-49ff-b228-04ff2ff248bd%40googlegroups.com.
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 view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/F70227D9-DD4A-4962-9330-8F3DD3283B3E%40chrismccord.com.To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6DC06C31-5933-4980-A9B3-69C83276A4C8%40binarynoggin.com.
The reason this feels unconvincing to me is because the situations
where this comes up would be very infrequent for me.
José, you mentioned that this warning was originally slated for 1.3 and then was pushed back to 1.4, which makes me wonder: do you have a roadmap for future warnings you plan to add to Elixir? If there are things you plan to warn on in the future, it would be nice if they were documented so we can begin avoiding them now.
I’ve been loving 1.4 for a few weeks now, but I am bugged by the new warning:
warning: variable "int" does not exist and is being expanded to "int()", please use parentheses to remove the ambiguity or change the variable name
Partly it is because it makes my code a lot uglier. For example, in quixir, instead of
test "two plain types" do ptest a: int, b: list do assert is_integer(a) assert is_list(b) end end
I now have to write:
test "two plain types" do ptest a: int(), b: list() do . . .
Ugh. Even worse, the premise of the warning seems wrong. It assumes
int
is a variable, which doesn’t exist. But it does know thatint
is a function, because if I misspell it and put ()s on, I get a compilation error. So why can’t it just do that: is a bare name is encountered that isn’t a variable, just internally tack on the ()s are see what happens. Which I think is the old way.
Basically, what compelling problem drove this change? It isn’t an issue I ever had before, and the change seems to make my code worse.
Dave
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/d8f5e848-2fc9-460b-8b55-e8dfc00ced56%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/fd313358-1f3c-49ff-924e-3f67025628e7%40Spark.
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 <mic...@muskala.eu> 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ł.
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,JulianOn Tuesday, December 6, 2016 at 12:51:32 PM UTC-6, Michał Muskała wrote:
> On 6 Dec 2016, at 19:48, jbo...@wistia.com 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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/d8f5e848-2fc9-460b-8b55-e8dfc00ced56%40googlegroups.com.
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/fd313358-1f3c-49ff-924e-3f67025628e7%40Spark.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/Otz0uuML764/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
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.