On Fri, Oct 5, 2012 at 10:39 PM, Edward Kmett wrote: > 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. Regards, Sean
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
