|Anonymous | Login | Signup for a new account||2014-03-07 04:37 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006070||OCaml||OCaml general||public||2013-07-09 14:27||2013-07-17 17:53|
|Target Version||Fixed in Version|
|Summary||0006070: There should be a warning for repeated variables even in curried arguments|
|Description||I've just spent half an hour bug hunting an issue that came from code of this form (greatly simplified):|
type error = E of string
let first_msg x (E x) = x
Obviously, this function is equivalent to fun _ (E x) -> x, which is silently the wrong interpretation of my intentions.
Basically, I would have spotted the error right away if instead I had written
let first_msg (x, E x) = x
but, since first_msg was being used in fold_left, I had to write it curried. The nature of this bug in my code took me on a complete wild goose chase as I hadn't assumed that the bug would be in my printing routine for errors.
Can there be a warning for shadowed variables in the arguments of curried function definitions? Note that this needs to be different from warning 27, which is way too annoying even to turn on, far less mark as error.
|Tags||No tags attached.|
Currently, "fun p1 p2 -> e" is treated exactly as "fun p1 -> fun p2 -> e". What would be the exact criterion to trigger the warning? Should it collect such immediately nested abstractions and check that they bind disjoint set of variables? What about the following:
let f x ?(a = x) x = a + x
Here we have a duplicated variable, but the instances are both used.
Personally, I find warning 27 quite useful (and it is turned into an error in LexiFi's code base). What's wrong with it?
I think that if the user writes "fun x x -> x", then it is nearly always something strange and possibly unintentonal. This is also true for "fun x ?(a=x) x -> x".
Warning 27 also complains about such as "let snd x y = y" and if it is an error then I have to constantly fiddle with initial underscore. I am sure one can get used to it, but I would rather differentiate between "repeated uses of variable in function arguments" and "unused variable in function arguments" as potential sources of errors in my code.
|Maybe the criterion could be "the variable is shadowed before it is ever used", without regard for the shape of the expression. I don't much like a special warning just for function definitions.|
I think I am OK with that interpretation.
In fact, that could just be a new case of "suspicious unused variable" (warning 26). Although, enlarging the scope of existing warnings risks breaking existing code that mark those warnings as errors.
|2013-07-09 14:27||kaustuv||New Issue|
|2013-07-10 14:45||frisch||Note Added: 0009743|
|2013-07-10 15:06||kaustuv||Note Added: 0009744|
|2013-07-17 16:57||doligez||Note Added: 0009801|
|2013-07-17 16:57||doligez||Status||new => acknowledged|
|2013-07-17 17:53||kaustuv||Note Added: 0009804|
|Copyright © 2000 - 2011 MantisBT Group|