On Fri, Oct 5, 2012 at 10:22 AM, Sean Leather wrote:

I also like the proposal; however, I think it only makes sense if the set of unbound variables with the same name is treated as referring to the same identifier. This was, after all, the main reason for named holes. Roman expected this, and I think everybody who uses the feature will expect it.

I for one wasn't expecting it, so I guess that makes me fall outside of the scope of everybody. ;)

Perhaps not everybody expects it, but I think it's quite natural to expect/want this feature. Once you find that you can get the type of _x (as opposed to _) in one place, why wouldn't you also want the type of _x when it's used in multiple places?

The main thing I like about Simon's proposal is that I could just drop an _foo in my file, and when I open it back up with vim or what have you /_foo to find my way back to it.

I'm not sure what you mean here. The point I was making was about having two (or more) _foo's in your file(s). So, you can still /_foo if you want or grep _foo if you prefer that.

Here's a thought that just occurred to me, though I'm not yet sure if it makes sense. Treat all expression identifiers _x as unique but report them as one hole with all possible types. Then, you can visually identify the patterns between the types. So:

> f x = _y
> g x = _y 'a'

with some warning like this:

Found hole `_y' in multiple locations with the possible types

File.hs:##:##: a0
File.hs:##:##: Char -> b0

Now, I know by looking at it that `a0' and `b0' are universally quantified per location, but I can do some mental unification myself.

There is the slight complication that the inscope variables shown for each location would be in different unification contexts as well, so your list gets a lot more cluttered, and the in scope variables probably should be grouped with each in turn, so I'm not sure this is any better than listing them separately by the time you factor in that clutter.

By "inscope variables," I guess you mean the "relevant bindings" in the hole report. Why would you group them with the different locations? I expect only one definition for _y. (If I didn't expect one definition for _y, then I would rename some of the holes.) So, I am only interested in variables that are available wherever that definition can be. If all the _y holes are in one top-level definition, then I probably prefer the local variables (so as not to be overwhelmed with other variables), and the context will make sense. If the _y holes are spread over multiple top-level definitions, then local variables won't help me there anyway.