Typed holes limited to a context of 5 values?

I am in progress of learning purescript, and quite enjoying it so far.

Recently I discovered that purescript has typed holes, similar to the typed holes in Idris which I played a little with a few years ago.
I find typed holes very helpful when learning and I use them constantly. Most often, though, I just put a hole at the return value in order to get type insight into the values in the context scope, because the purescript-vim plugin that I am using doesn’t seem to be able to show type information (when coding F# in vim I am used to being able to get the type of a value by putting the cursor on the value and pressing shift-k).

… Anyhow, when using typed holes I have noticed that it seems to be limited to only showing types for 5 (arbitrary?) values in the context. I have been wondering if this is a hard limitation or if it is something that I somehow can configure to show more values?

example:

instance Apply (Parser e) where
  apply :: forall a b. Parser e (a -> b) -> Parser e a -> Parser e b
  apply p1 p2 =
    Parser \s -> do
      Tuple s1 fx <- parse p1 s
      Tuple s2 x <- parse p2 s1
      let bar = 42
      ?foo

type hole info:

1.   Hole 'foo' has the inferred type
   
       Either e0 (Tuple String b1)
   
     in the following context:
   
       bar :: Int
       fx :: a2 -> b1
       p1 :: Parser e0 (a2 -> b1)
       p2 :: Parser e0 a2
       s :: String
   
   
   in value declaration $applyParser5
   
   where e0 is a rigid type variable
           bound at (line 0, column 0 - line 0, column 0)
         a2 is a rigid type variable
           bound at (line 0, column 0 - line 0, column 0)
         b1 is a rigid type variable
           bound at (line 0, column 0 - line 0, column 0)

It doesn’t show type info for s1, s2 and x… Of course I am able to deduce the types in my head for this kind of case, but I worry that at some point I will come across a case where I will be struggling to ‘manually’ deduce the types.

1 Like

I’ve also found the limitation frustrating. I can’t remember if there are configurations, but one way to hack around this is to create a temporary record with the values you’re interested in. The fields of this record let us go beyond the 5 value limitation

2 Likes

just found another nice workaround as well…
example

instance Apply (Parser e) where
  apply :: forall a b. Parser e (a -> b) -> Parser e a -> Parser e b
  apply p1 p2 =
    Parser \s -> do
      Tuple s1 fx <- parse p1 s
      x <- parse p2 s1
      ?foo (map fx x)

type hole info

1.   Hole 'foo' has the inferred type
   
       Tuple String b0 -> Either e1 (Tuple String b0)
1 Like

Hard-coded, I’m afraid; been that way since 2016 when displaying the context was first implemented. Nothing special about the number 5, though; want to propose a higher limit?

1 Like

Do we need a limit here? Alternatively, some do blocks could get really large and it would be annoying if the ones in which you’re most interested are at the bottom. Perhaps the list should be reversed and then we take the first N from that?

2 Likes

Issue opened here: https://github.com/purescript/purescript/issues/4340

PR opened here: https://github.com/purescript/purescript/pull/4341

Since we weren’t sure if bumping the number would cause problems, I released PureScript v0.15.3 without this change. I then immediately merged the above PR, so that v0.15.4-0 was released. v0.15.4-0 is v0.15.3 with this one change.

Once you’ve tried out v0.15.3 and verified that it doesn’t have any issues, please try out v0.15.4-0. If you encounter any issues, please let us know so we can fix it before v0.15.4 is officially released. You can install v0.15.4-0 via npm i purescript@next.

2 Likes