TypeHoles: unbound variables as named holes

[Edward Kmett]

On Fri, Oct 5, 2012 at 10:22 AM, Sean Leather <leather at cs.uu.nl> 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. ;)

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.


> 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.

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