TypeHoles: unbound variables as named holes

Thijs Alkemade thijsalkemade at gmail.com
Wed Nov 21 12:46:07 CET 2012


Hey all,

To report on the current situation:

I'm myself still not sure which of the options of sharing/not sharing
is the most useful. I can't really estimate which I would want to use
the most, so I wouldn't dare to predict which most users would want.

However, the module-wide sharing is hard, and as Simon mentioned is
problematic with polymorphism. We've looked at this before, and right
now I think I don't have the time to finish that.

No sharing, the way Simon proposed it, was rather easy to add. What I
have now works like this: When -XTypeHoles is on, any unbound
identifier that starts with _ is also turned into a hole, with an
appropriate message. For example, the module:

f = _a _b _

Gives (these are warnings, because -fdefer-type-errors is on):

---

holes2.hs:1:5: Warning:
    Found hole with type: `t0 -> t1 -> t'
    Arising from: an undeclared identifier `_a' at holes2.hs:1:5-6
    Where: `t0' is an ambiguous type variable
           `t1' is an ambiguous type variable
           `t' is a rigid type variable bound by
               the inferred type of f :: t at holes2.hs:1:1
    Relevant bindings include f :: t (bound at holes2.hs:1:1)
    In the expression: _a
    In the expression: _a _b _
    In an equation for `f': f = _a _b _

holes2.hs:1:8: Warning:
    Found hole with type: `t0'
    Arising from: an undeclared identifier `_b' at holes2.hs:1:8-9
    Where: `t0' is an ambiguous type variable
    In the first argument of `_a', namely `_b'
    In the expression: _a _b _
    In an equation for `f': f = _a _b _

holes2.hs:1:11: Warning:
    Found hole with type: `t1'
    Arising from: a use of `_' at holes2.hs:1:11
    Where: `t1' is an ambiguous type variable
    In the second argument of `_a', namely `_'
    In the expression: _a _b _
    In an equation for `f': f = _a _b _

---

I think this is a good compromise that gives you named holes and
easily allows you to turn unbound identifiers into holes. What do you
think?

Regards,
Thijs Alkemade



More information about the Glasgow-haskell-users mailing list