This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Actual complexity in Scala that warrants simplification

5 replies
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
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 }
?

Lars Hupel
Joined: 2010-06-23,
User offline. Last seen 44 weeks 3 days ago.
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`).

adriaanm
Joined: 2010-02-08,
User offline. Last seen 31 weeks 4 days ago.
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 ;-))
cheersadriaan
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
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 ;-))

Lol, already pushed? :-)
 

cheersadriaan



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
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 ;-))
cheersadriaan

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
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`).


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