Pattern matching -- translation
brian.goetz at oracle.com
Wed Jun 14 15:32:53 UTC 2017
On 6/14/2017 11:21 AM, Dmitry Petrashko wrote:
> Hello Brian,
> It would be very nice to see if the technology you are developing can
> simplify pattern matching in Scala and\or help us
> expose out pattern matching capabilities to other JVM languages.
Bridging an existing unapply method to a __Pattern should be trivial,
meaning that existing Scala classfiles, without recompilation, still
have a path to playing. For newly compiled classfiles, you further have
the option of generating __Pattern factories as well. So there should
be a clean story for both old code and new.
> Scala has an additional specced requirement to the patterns:
> |unapply|-s should be pure, not mutate any environment of the objects
> that they are given. This means that we can potentially remove calls
> to them if we know that they won’t match and not worry about removing
> side-effects. It would be nice to know our opinion of if you’d like to
> have a similar limitation on your |predicate|s.
While we can't enforce this, we can tell people that they get no
guarantees about the ordering or execution arity of side effects. So,
yes, basically the same deal, just in different language.
> On a minor note your Scala examples are slightly outdated. We
> currently have a scheme that commonly does not allocate any new objects:
Can you post a more detailed translation scheme for the non-case-class case?
> The most important part is that case classes in Scala automatically
> synthesise those methods on the class instance.
> This allows for |unapply| to be an identity method, that does not
> require any allocations! No options or topples get allocated.
This sounds like it has a similar effect to the optimization where we
use an object as its own carrier, at least for case classes?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts