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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to