JuliaLang/julia — pull request #5280 by malmaud (2014-01-02 07:48:08+00:00)
Title: RFC: Don't complain about redefining types when the type hasn't actually changed

This PR is intended to make it easier to reload modules and re-execute scripts which define types. If the definition of a type hasn't changed in any way since the script was last evaluated (as determined by the new jl_equiv_type function), then the type declaration is safely reevaluated. Changing a type definition is still not allowed (I have a hacky way of accomplishing that in https://github.com/malmaud/Autoreload.jl, but I don't think it's appropriate for core Julia).

This is a simple fix for a problem that has consistently annoyed interactive Julia users, who have been forced to take precautions such as defining types in a module instead of in the top level. Many users who come from a Matlab or IPython background are used to a workflow of constantly tweaking scripts in a single interactive session.

Additionally, this PR disables warnings when a constant is redefined to the same value it had previously. This prevents spurious warnings about redefining constants when reloading packages (e.g., reloading DataFrames causes dozens of unhelpful warnings about constant redefinitions).

It is not fully functional yet because for unclear reasons, the 'rhs' parameter in jl_checked_assignment (which contains the new type definition) often has NULL for its `types` and `super` fields, even when the data type does in fact have fields and a parent. Thus jl_equiv_type cannot reliably determine whether the new type definition has the same field types and the same parent as the old type definition. I was hoping someone else might have insight into that, but I'll keep looking into it. Otherwise, this patch seems to work smoothly.