Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add line numbers to ambiguity warnings? #1658

Closed
johnmyleswhite opened this issue Dec 3, 2012 · 8 comments
Closed

Add line numbers to ambiguity warnings? #1658

johnmyleswhite opened this issue Dec 3, 2012 · 8 comments

Comments

@johnmyleswhite
Copy link
Member

Can we report the line numbers in source code that generate ambiguity warnings? This would make it easier to track them down and fix them.

@StefanKarpinski
Copy link
Sponsor Member

@JeffBezanson: what do you think of the idea of inserting error methods for ambiguities so that they are only a problem if they're used? That would automatically give the line number too :-)

@JeffBezanson
Copy link
Sponsor Member

Line numbers: very good idea and easy to do.

Automatic error methods: interesting idea, but depends somewhat on #265 to better handle replacing the method. It might also be too strict to require adding a definition before you can try your code. 99% of the time it's fine if one of the existing methods is called, and at least you can start testing things that way.

@StefanKarpinski
Copy link
Sponsor Member

I feel like it's less strict – since most of the time you don't care about the ambiguous case because it never happens. If it does, at least you have an example to figure out how it should be disambiguated. But yes, it probably interacts with #265 (which I've been meaning to talk to you about).

@JeffBezanson
Copy link
Sponsor Member

Stopping your program is not really less strict, but it's a good point that the reason the disambiguating definition doesn't exist is often that you don't intend for it to happen.

@johnmyleswhite
Copy link
Member Author

I actually agree that it would help if the existence of ambiguities causes a program-stopping error.

I'm sure it's too late to change this, but I personally kind of wish that the most general definitions of functions could come first after then be overwritten by more specific cases, rather than the other way around. That's how humans reason after all (see for example the very long literature in development psychology on language learning).

@StefanKarpinski
Copy link
Sponsor Member

I agree with that. It seems like your recent experience with ambiguity warnings indicates that they are quite helpful for improving program design, indicating that maybe we shouldn't do away with them. The idea I had to address this was to give the programmer until the end of file to resolve ambiguities (or in the case of modules, maybe until end of module?), so that you could, within a file, order method definitions arbitrarily without affecting warnings.

@johnmyleswhite
Copy link
Member Author

Being able to order methods arbitrarily (even in the case of ambiguity) would be a big win.

@JeffBezanson
Copy link
Sponsor Member

See #270.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants