isInvisible

[Richard Eisenberg]

On Jun 23, 2016, at 8:59 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> 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.
> 

Here is another design I considered:

> data VisibilityFlag
>   = Visible
>   | Invisible SpecifiedFlag
>
> data SpecifiedFlag = Specified | Inferred

That might make this all a bit clearer. I avoided this extra layer of indirection, though, as overly ornate. Perhaps I was wrong.

isVisible and isInvisible (the functions) are indeed opposites of each other. That's good, in my book. But it is confusing that Specified is lumped in with Invisible here.

>  
> 
> 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
> 

True.

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

No. We can't use visible type application with Visible arguments. If they're Visible, then you don't need the @.

>  
> 
> 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”.
> 

I don't see the improvement here. "Invisible" and "visible" are antonyms, just like "implicit" and "explicit". Yes, it's true that "implicit" isn't just a prefix put on "explicit", but I hardly think that matters.

How about
 * Required
 * Specified
 * Inferred

A Required argument is just that: it must be provided at all call sites. A Specified argument is one whose order we know about and can be given by visible type application. An Inferred argument is invented by GHC and cannot be affected by the user. With this phrasing, no word is an antonym of another.

Richard

> Simon
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160623/7af5a1c8/attachment-0001.html>