Using Refined for Retry?

Question

Using refined, I attempted to define f:

import eu.timepit.refined._
import eu.timepit.refined.api.Refined
import eu.timepit.refined.auto._
import eu.timepit.refined.numeric._

// if action 'succeeds', return 'good'; otherwise re-try, subtracting count by 1
scala> def f[A](action: => A, success: A => Boolean, count: Int Refined Positive): String = 
     |   if( success(action) ) "good" else f(action, success, count - 1)
<console>:32: error: compile-time refinement only works with literals
         if( success(action) ) "good" else f(action, success, count - 1)
                                                                    ^

Since that did not work, I resorted to:

def fEither[A](action: => A, success: A => Boolean, count: Either[String, Int Refined Positive]): String = { 
  println(count)

  if( success(action) ) "good" 
  else {
    count match {
      case Right(c) => fEither(action, success, refineV[Positive](c - 1))
      case Left(_)  => "bad"
    }
  }
}

scala> fEither[Int](42, _ => false, Right( refineMV[Positive]( 2 ) ) )
Right(2)
Right(1)
Left(Predicate failed: (0 > 0).)
res2: String = bad

Ideally, I'd like to convert this Idris program into Scala:

f : (action : a) -> (success: a -> Bool) -> (n : Nat) -> String
f action success (S n) = if (success action) then "good" else f action success n
f _       _      Z     = "bad"

*scratch> f 42 (const False) 2
"bad" : String
*scratch> f 42 (const False) 0
"bad" : String

but I'm not sure of any pattern match on Nat capability.

Answer 1

• The refinement you want to use is NonNegative, so 0 is a valid value.
• Idris code discriminates essentially on whether n - 1 is still a natural number or not, so you can do it directly, using runtime version refineV:

---

def f[A](action: => A, success: A => Boolean, count: Int Refined NonNegative): String =
  refineV[NonNegative](count - 1) match {
    case Right(n) => if (success(action)) "good" else f(action, success, n)
    case Left(_)  => "bad"
  }

P.S. You might want multiple parameter lists b/c Scala is likely to fail to infer the type of A correctly at the call site