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