Re: Actual complexity in Scala that warrants simplification

Or to put it differently: Why should match only take a PartialFunction?

On Tue, Nov 22, 2011 at 1:12 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
On Tue, Nov 15, 2011 at 12:28 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
  (a) It seems like "re-invent |>" is the answer to a StackOverflow question about once a week.

If I'm not completely missing something, it seems that actually Scala has a limited, special version of |> --- called match. If we had |> would you ever need the 'match' keyword?
x match {  case n if n%2 == 0 => 2}
Isn't that roughly the same as
({ case n if n%2==0 => 2}) apply x
or
x |> { case n if n%2 == 0 => 2 }
?

Re: Actual complexity in Scala that warrants simplification

Added by Lars Hupel on 2011-11-22, 14:57

> Or to put it differently: Why should match only take a PartialFunction?

I wondered the very same thing. The difference between `x match { ... }`
and `{ ... } apply x` is that they generate different byte codes. The
former doesn't actually produce an instance of `PartialFunction` (where
the pattern match code has to be duplicated for `isDefinedAt`).

Re: Re: Actual complexity in Scala that warrants simplification

Added by Naftoli Gugenheim on 2011-11-25, 01:57
Okay but that's an implementation detail. It still seems that match is a limited case of |>.

On Tue, Nov 22, 2011 at 8:43 AM, Lars Hupel <hupel [at] in [dot] tum [dot] de> wrote:
> Or to put it differently: Why should match only take a PartialFunction?

I wondered the very same thing. The difference between `x match { ... }`
and `{ ... } apply x` is that they generate different byte codes. The
former doesn't actually produce an instance of `PartialFunction` (where
the pattern match code has to be duplicated for `isDefinedAt`).


Re: Re: Actual complexity in Scala that warrants simplification

Added by adriaanm on 2011-11-23, 00:27


On Tue, Nov 22, 2011 at 2:43 PM, Lars Hupel <hupel [at] in [dot] tum [dot] de> wrote:
> Or to put it differently: Why should match only take a PartialFunction?

I wondered the very same thing. The difference between `x match { ... }`
and `{ ... } apply x` is that they generate different byte codes. The
former doesn't actually produce an instance of `PartialFunction` (where
the pattern match code has to be duplicated for `isDefinedAt`).
a match generates a "quizzable" function (which some say would be a better name for a partial function)this allows implementing a method such as collect, which relies both on the result returned from the partial function, and whether there is such a result (well, whether it is defined) in the first place
also, Martin has just come up with an efficient yet elegant way to get rid of isDefinedAt -- more on that later (or check the commit logs for the last few hours ;-))
cheersadriaan

Re: Re: Actual complexity in Scala that warrants simplification

Added by ichoran on 2011-11-23, 00:47
If you mean the change I think you mean, are you sure the synchronization won't result in a substantial performance penalty for simple partial functions (if isDefinedAt is actually removed)?

  --Rex

On Tue, Nov 22, 2011 at 6:16 PM, Adriaan Moors <adriaan [dot] moors [at] epfl [dot] ch> wrote:


On Tue, Nov 22, 2011 at 2:43 PM, Lars Hupel <hupel [at] in [dot] tum [dot] de> wrote:
> Or to put it differently: Why should match only take a PartialFunction?

I wondered the very same thing. The difference between `x match { ... }`
and `{ ... } apply x` is that they generate different byte codes. The
former doesn't actually produce an instance of `PartialFunction` (where
the pattern match code has to be duplicated for `isDefinedAt`).
a match generates a "quizzable" function (which some say would be a better name for a partial function) this allows implementing a method such as collect, which relies both on the result returned from the partial function, and whether there is such a result (well, whether it is defined) in the first place
also, Martin has just come up with an efficient yet elegant way to get rid of isDefinedAt -- more on that later (or check the commit logs for the last few hours ;-))
cheersadriaan

Re: Re: Actual complexity in Scala that warrants simplification

Added by Viktor Klang on 2011-11-23, 00:37


On Wed, Nov 23, 2011 at 12:16 AM, Adriaan Moors <adriaan [dot] moors [at] epfl [dot] ch> wrote:


On Tue, Nov 22, 2011 at 2:43 PM, Lars Hupel <hupel [at] in [dot] tum [dot] de> wrote:
> Or to put it differently: Why should match only take a PartialFunction?

I wondered the very same thing. The difference between `x match { ... }`
and `{ ... } apply x` is that they generate different byte codes. The
former doesn't actually produce an instance of `PartialFunction` (where
the pattern match code has to be duplicated for `isDefinedAt`).
a match generates a "quizzable" function (which some say would be a better name for a partial function) this allows implementing a method such as collect, which relies both on the result returned from the partial function, and whether there is such a result (well, whether it is defined) in the first place
also, Martin has just come up with an efficient yet elegant way to get rid of isDefinedAt -- more on that later (or check the commit logs for the last few hours ;-))

Lol, already pushed? :-)
 

cheersadriaan



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland