isInvisible

Simon Peyton Jones simonpj at microsoft.com
Thu Jun 23 12:59:46 UTC 2016


Richard
I have just spent an hour plumbing the torrid swamp of binder visibility.  There is bad naming confusion.
We have

·         Visible

·         Specified

·         Invisible
The function isVisible returns True for Visible and False otherwise.  But isInvisible returns True for Invisible and Specified.  And partitionInvisibles, filterOutInvisibleTyVars, filterOutInvisibleTypes etc all treat Invisible and Specified the same.  That is, it’s really filterOutInvisibleOrSpecifiedTypes which is terribly clumsy.

Sometimes we need to pick up just the Inivisble args, and we don’t have a predicate for that (since isInvisible is taken), so you’ll see in Inst.top_instantiate we are reduced to saying (binderVisibility bndr == Invisible).
It’s all very smelly.  The trouble is that

·         In displayed types like (T a b), we display args that are Visible, but not Specified or Invisible

·         In visible type application like (f @t1 @t2) we can specify type args that are Visible or Specified but not Invisible.

Urgh. The trouble is that “invisible” is not the negation of “visible”, which leads to all kinds of confusion.
I wonder about changing to

·         Explicit

·         Specified

·         Implicit
Then for display we display Explicit args only; for VTA we can specify Explicit or Specified args.
So “not Explicit” doesn’t sound structurally like “Implicit” in the way that “not Visible” does sound like “Invisible”.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160623/b71940b1/attachment.html>


More information about the ghc-devs mailing list