Redefinition of a constant should be an error, rather than a warning

[pao]

[Originally posted on -dev by Fermat 618: https://groups.google.com/d/topic/julia-dev/MOt74gNrc9E/discussion]

When I assign a lambda to a function,

julia> f(x) = x + 2

julia> f = (x) -> x + 20
Warning: redefinition of constant f ignored.
#<function>

julia> f(3)
5

I find neither an Error is raised nor the assignment take effect.

It is very dangerous to ignore an error. A program that returns a wrong
answer is much more worse than a program that fails.

When I write something, I expected it to take effect. If it do not, I
expect an error. A warning is reasonable when someone write

     if (a = b) { xxx; }

in C. Even though if (a == b) is likely what one want, one can still
ignore the warning when he/she is sure if (a = b) is wanted. But this
is definitely not the case.

In my opinion, a well designed programming language should give as less
[warnings] as possible.

[pao]

I'm pretty sure this would cause follow-on problems for reloading files, since an error would halt processing. In general I'm OK with errors being preferred over warnings, but I'm not sure now this would have to work in this case.

[StefanKarpinski]

One possible option is to check that the redefinition is identical to the previous definition and throw an error if they're not the same but proceed with just a warning if they're equal. The tricky part here would be comparing type definitions.

[timholy]

This actually does sound useful.

Nitpick: if they're equal, you wouldn't even need (or want) the warning.

[StefanKarpinski]

I thought about that, but wouldn't you want to be warned if you accidentally did this:

const FOO = 1

# ...

const FOO = 1

[staticfloat]

Other than trying to let you know of duplicated work, why would warning you when you redefine a constant be useful?

[pao]

Because changing one of them without changing the other will cause a predictable error in the code. At the very least, it indicates a miscomprehension of the environment you've set up.

[StefanKarpinski]

Other than trying to let you know of duplicated work, why would warning you when you redefine a constant be useful?

It's a weird and probably ill-advised thing to do, hence the warning. If you're in the repl, the warning is easy to ignore.

[timholy]

I thought about that, but wouldn't you want to be warned if you accidentally did this:

Yes, I think I would like to be warned about that. Good point.

[ViralBShah]

It could be annoying if this is an error, because a common workflow is to change .jl files and keep reloading them within the same REPL instance. Since constants will keep getting reloaded, an error will require restarting.

One thought is that constant redefinition could throw an extension, which is caught in the REPL to issue a warning, but is otherwise an error, when not running from the REPL.

[toivoh]

I guess one thing to consider if you want to give an error when trying to redefine a constant is the notion of sameness.
Would that be EGAL? (is()) Does it currently handle all the cases of interest?

Also, you would have to reevaluate the right hand side to know if it's a new value that you are trying to assign,
which might have unintended side effects? Or do attempts to redefine a const always evaluate the rhs before refusing to assign it?

One possibility might be to give an error only in cases that are surely wrong, which could hopefully catch the majority of problems. I e trying to create a non-const under a name that is bound to a const in the current module should definitely be an error, probably trying to assign a value of a different type to a const too?

[fermat618]

REPL environment is an interactive environment, which is much different, and
should be treat differently.

A example is when you type an expression in most REPL these days, the value is
printed, but when you put just an expression in a file and execute it, it's
value will not be printed. Matlab behaves bad on this point; when you script
in matlab, you must remember to add semicolon to every sentence that you don't
want to the value to be echoed.

An error in a script file should cause the interpreter quit, but it should not
quit the entire REPL since it is unnecessary. When one write something in
script, seldom will one sit in front of a screen, staring the screen to find
the warning, recall where warning is caused, decide whether the warning is
reasonable, and then determine whether to cancel the program. One just expect
it to be correct. And if it is not correct, the program should be terminated
and an explanatory error message be given.

Some people said the problem comes from loading a file containing constant
definition that violent the existing constant. In Haskell where everything is
a constant, this is not a problem, then there should be no problem in Julia.
One expect reloading a file to succeed, so it should succeed. Not only should
the entire file be loaded, but also constant be redefined. If just the warning is
given and the constant not redefined correctly, the code after that which relies
on the constant to be correct will all fail and give incorrect answers. This is
the worst case.

[JeffBezanson]

I must say you are right. I really want to fix this. The easy approach is to throw away the module with the old constant, and replace it with a new module with the same name. But, that won't work if you are entirely within Main and want to keep some of your REPL variables and reload others. Then I am not sure yet how to distinguish an allowed const redefinition from an erroneous one.

[staticfloat]

Is there any case other than Main where you wouldn't want to throw away the entire module?

Also, you would only throw away the old module if it conflicted with the new module, right? Otherwise, when you have a module spanning multiple files things would go badly wrong. The way I've been envisioning it is that you would have multiple "pieces" of the module defined in different files, and they would be integrated into a single, whole module when they had all been load()'ed.