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

> 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

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

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 ;-))

Re: Re: Actual complexity in Scala that warrants simplification

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 ;-))

Re: Re: Actual complexity in Scala that warrants simplification

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 ;-))