- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Actual complexity in Scala that warrants simplification
Tue, 2011-11-22, 07:13
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 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 }
?
Wed, 2011-11-23, 00:27
#2
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?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
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`).
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
Wed, 2011-11-23, 00:37
#3
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?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
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`).
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
Wed, 2011-11-23, 00:47
#4
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:
--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?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
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`).
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
Fri, 2011-11-25, 01:57
#5
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:
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`).
> 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`).