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