alternative syntax for unapply extractors

[erikerlandson]

pattern matching with unapply extractors requires the creation of a containing object, for example:

    object namedDU:
        def unapply(using Quotes)(u: quotes.reflect.TypeRepr): Option[Expr[NamedUnit]] =
            import quotes.reflect.*
            Implicits.search(TypeRepr.of[DerivedUnit].appliedTo(List(u, TypeBounds.empty))) match
                case iss: ImplicitSearchSuccess => Some(iss.tree.asExpr.asInstanceOf[Expr[NamedUnit]])
                case _ => None

I have been wondering if it would be more direct to replace unapply with an explicit name, but instead annotate it with something like def extractor ..., like:

def extractor namedDU(using Quotes)(u: quotes.reflect.TypeRepr): Option[Expr[NamedUnit]] =
    import quotes.reflect.*
    Implicits.search(TypeRepr.of[DerivedUnit].appliedTo(List(u, TypeBounds.empty))) match
        case iss: ImplicitSearchSuccess => Some(iss.tree.asExpr.asInstanceOf[Expr[NamedUnit]])
        case _ => None

Adding new keywords is not cost free but would reduce boilerplate

[erikerlandson]

more accurately, def extractor name ... would be syntactic sugar for

object name:
    def unapply ...

[som-snytt]

Is this different from "name-based extractors"?
https://dotty.epfl.ch/docs/reference/changed-features/pattern-matching.html

Edit: I see they call it "Optionless". (No hyphen required for option-less.) "De-optioned."

[erikerlandson]

It is different: If I want to create an extractor named foo, the current syntax requires me to create an object foo

object foo:
    def unapply ...

IMO it seems a bit less boilerplate to declare the extractor directly

def extractor foo ...

or even

extractor foo ... 

[erikerlandson]

In other words, the object really only exists to give the extractor a unique name, which seems inelegant

[erikerlandson]

clearly one doesn't want to change the existing system, just proposing a new syntactic sugar for the existing system that captures the semantics a bit more clearly (in my opinion)

[erikerlandson]

yet another way to express it: "extractor" is really a first-class concept in scala, and quite powerful, which doesn't in principal need to be tied to an "object" - it is an entity in its own right, and I propose it merits its own keyword extractor. If it remains implemented as unapply underneath an object of a given name, that is just a smart design strategy

[som-snytt]

Thanks, I did have coffee this morning, didn't I? When I tried it, below, I see what you mean.

[nafg]

There could be a SAM that would let you create one with an ordinary function

…

On Fri, Jun 11, 2021, 12:44 PM Erik Erlandson ***@***.***> wrote: yet another way to express it: "extractor" is really a first-class concept in scala, and quite powerful, which doesn't in principal need to be tied to an "object" - it is an entity in its own right, and I propose it merits its own keyword extractor. If it remains implemented as unapply underneath an object of a given name, that is just a smart design strategy — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12793 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUGWNVVBZCJN3K5XPUTTSI4NPANCNFSM46Q74VEA> .

[erikerlandson]

What is SAM ?

[som-snytt]

"single abstract method". Extractor[A, B] would take an A.

[som-snytt]

I see the explicit object is required for extension method version, otherwise "constructor proxy object C cannot be used as a value". It would help to lift that restriction for this context.

class C(val i: Int):
  override val toString = s"C-of($i)"
object C
/*
object C:
  def unapply(x: Any): Option[C] =
    x match
    case y: C if y.i > 42 => Some(y)
    case _ => None
*/

extension (um: C.type) def unapply(x: Any): Option[C] =
  x match
  case y: C if y.i > 42 => Some(y)
  case _ => None

@main def test() = println {
  val z: Any = new C(55)
  z match {
    case C(c) => c
  }
}

[nafg]

Single Abstract Method. trait Extractor[-A, +B] { def unapply(in: A): Option[B] } val AsInt: Extractor[String, Int] = _.toIntOption "10" match { case AsInt(i) => i - 1 }

…

On Fri, Jun 11, 2021, 12:58 PM Erik Erlandson ***@***.***> wrote: What is SAM ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12793 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUDYKKGSYN2WRFMYDOLTSI6EZANCNFSM46Q74VEA> .

[erikerlandson]

would that allow the more complex curried parameter signatures, such in my original example at the top?

def unapply(using Quotes)(u: quotes.reflect.TypeRepr): Option[Expr[NamedUnit]]

[nafg]

No. Of course you could make AsInt a def that takes implicit parameters to create the extractor.

…

On Fri, Jun 11, 2021, 1:14 PM Erik Erlandson ***@***.***> wrote: would that allow the more complex curried parameter signatures, such in my original example at the top? def unapply(using Quotes)(u: quotes.reflect.TypeRepr): Option[Expr[NamedUnit]] — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12793 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUFXNKXYBJNXCRQESCDTSI76PANCNFSM46Q74VEA> .

[erikerlandson]

Here's yet a third idea: in any match statement:

// a is of type A, b is of type B
match a
    case foo(b) => ...

the compiler simply admits any function foo if it is of type A => Option[B] as an extractor.
Likewise for all the usual extractor varations A=>Boolean, A=>Option[(B, C, ...)], etc

[erikerlandson]

I say "simply" without knowing how simple it really is, but clearly it is already checking the signatures of any unapply extractors, and so extending that to checking the corresponding signatures of functions like foo seems superficially the same

[erikerlandson]

This seems like the right answer, the more I think about it. No new keywords or privileged types. The compiler allows any function/method of the proper signature to behave as an extractor when it is being used in such a context.

[erikerlandson]

lampepfl/dotty-feature-requests#218