TypeHoles: unbound variables as named holes

Sean Leather leather at cs.uu.nl
Fri Oct 5 23:30:58 CEST 2012

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121005/4cf31be2/attachment.htm>

More information about the Glasgow-haskell-users mailing list