Option.fold

Well, one could

  def fold[X](d: => X, f: A => X) = map(f).getOrElse(d)

but the right-hand side has the advantage of labeling what happens.

The tiny problem I see with fold is which one of these it is:

  def fold[X](d: => X, f: A => X)
  def fold[X](d: => X)(f: A => X)
  def fold[X](f: A => X, d: => X)
  def fold[X](f: A => X)(d: => X)

but given that these possibilities exist, I'm not too sorry to have to do it "longhand".

  --Rex

P.S. I miss fold on tuples much more:
  def fold[Z](f: (T1,T2,...) => Z)

P.P.S. I agree that from a theoretical standpoint, "fold" is a nice fundamental method that one would want to have, and also that it could be more efficient than map/getOrElse.

On Mon, Aug 23, 2010 at 12:43 PM, Alexey Romanov <alexey [dot] v [dot] romanov [at] gmail [dot] com> wrote:

Hello!

Why doesn't scala.Option have the catamorphism method

def fold[X](d: => X, f: A => X)

unlike Either or List? Of course, it can easily be added by pimping
the library, but it's fundamental enough that it deserves to be in the
standard library, I believe.

Yours, Alexey Romanov

On Mon, Aug 23, 2010 at 08:43:16PM +0400, Alexey Romanov wrote:
> Why doesn't scala.Option have the catamorphism method
>
> def fold[X](d: => X, f: A => X)
>
> unlike Either or List? Of course, it can easily be added by pimping
> the library, but it's fundamental enough that it deserves to be in the
> standard library, I believe.

Maybe I'm dense but it looks to me like it's in there not once but
twice. Or four times depending on how you count. The syntax might
leave something to be desired...

def fold[A, X](opt: Option[A], d: => X, f: A => X): X =
opt.foldLeft(d)((_, x) => f(x))
// or opt.foldRight(d)((x, _) => f(x)) ! the choice is yours!
// or for that matter /: or :\

That's just for illustrative purposes, of course the direct utilization
would be:

scala> (0 /: Some(5))((_, x) => x * 10)
res0: Int = 50

// unenviable type inference issue
scala> (0 /: (None: Option[Int]))((_, x) => x * 10)
res1: Int = 0

Not saying this is ideal.

Yours, Alexey Romanov

On Mon, Aug 23, 2010 at 9:14 PM, Rex Kerr wrote:
> Well, one could
>
>   def fold[X](d: => X, f: A => X) = map(f).getOrElse(d)
>
> but the right-hand side has the advantage of labeling what happens.

Yes, or define it by pattern matching. And this tends to be one of the
first methods I add to any new project, since I know I _will_ use it.
I doubt I am the only one.

> The tiny problem I see with fold is which one of these it is:
>
>   def fold[X](d: => X, f: A => X)
>   def fold[X](d: => X)(f: A => X)
>   def fold[X](f: A => X, d: => X)
>   def fold[X](f: A => X)(d: => X)
>
> but given that these possibilities exist, I'm not too sorry to have to do it
> "longhand".

Similarly, we have _eight_ options for List.foldLeft and
List.foldRight (since we can change order of arguments to the binary
operation). But one of them was picked.

>   --Rex
>
> P.S. I miss fold on tuples much more:
>   def fold[Z](f: (T1,T2,...) => Z)
>
> P.P.S. I agree that from a theoretical standpoint, "fold" is a nice
> fundamental method that one would want to have, and also that it could be
> more efficient than map/getOrElse.
>
> On Mon, Aug 23, 2010 at 12:43 PM, Alexey Romanov
> wrote:
>>
>> Hello!
>>
>> Why doesn't scala.Option have the catamorphism method
>>
>> def fold[X](d: => X, f: A => X)
>>
>> unlike Either or List? Of course, it can easily be added by pimping
>> the library, but it's fundamental enough that it deserves to be in the
>> standard library, I believe.
>>
>> Yours, Alexey Romanov
>
>

On Mon, Aug 23, 2010 at 9:15 PM, Paul Phillips wrote:
> On Mon, Aug 23, 2010 at 08:43:16PM +0400, Alexey Romanov wrote:
>> Why doesn't scala.Option have the catamorphism method
>>
>> def fold[X](d: => X, f: A => X)
>>
>> unlike Either or List? Of course, it can easily be added by pimping
>> the library, but it's fundamental enough that it deserves to be in the
>> standard library, I believe.
>
> Maybe I'm dense but it looks to me like it's in there not once but
> twice.  Or four times depending on how you count.  The syntax might
> leave something to be desired...
>
> def fold[A, X](opt: Option[A], d: => X, f: A => X): X =
>  opt.foldLeft(d)((_, x) => f(x))
>  // or opt.foldRight(d)((x, _) => f(x)) ! the choice is yours!
>  // or for that matter /: or :\
>
> That's just for illustrative purposes, of course the direct utilization
> would be:
>
> scala> (0 /: Some(5))((_, x) => x * 10)
> res0: Int = 50
>
> // unenviable type inference issue
> scala> (0 /: (None: Option[Int]))((_, x) => x * 10)
> res1: Int = 0
>
> Not saying this is ideal.

Compared with this, Some(5).map(_ * 10).getOrElse(0) is downright nice.

> --
> Paul Phillips      | The most dangerous man to any government is the man who
> Moral Alien        | is able to think things out [...] Almost inevitably he
> Empiricist         | comes to the conclusion that the government he lives under
> ha! spill, pupil   | is dishonest, insane, intolerable.   -- H. L. Mencken
>

On Mon, Aug 23, 2010 at 10:58:11PM +0400, Alexey Romanov wrote:
> Compared with this, Some(5).map(_ * 10).getOrElse(0) is downright nice.

See! There's always a bright side!

So...it's english versus bytecode :))) who wants to count the brakets? :)))

On 8/23/10, Alexey Romanov wrote:
> On Mon, Aug 23, 2010 at 9:15 PM, Paul Phillips wrote:
>> On Mon, Aug 23, 2010 at 08:43:16PM +0400, Alexey Romanov wrote:
>>> Why doesn't scala.Option have the catamorphism method
>>>
>>> def fold[X](d: => X, f: A => X)
>>>
>>> unlike Either or List? Of course, it can easily be added by pimping
>>> the library, but it's fundamental enough that it deserves to be in the
>>> standard library, I believe.
>>
>> Maybe I'm dense but it looks to me like it's in there not once but
>> twice.  Or four times depending on how you count.  The syntax might
>> leave something to be desired...
>>
>> def fold[A, X](opt: Option[A], d: => X, f: A => X): X =
>>  opt.foldLeft(d)((_, x) => f(x))
>>  // or opt.foldRight(d)((x, _) => f(x)) ! the choice is yours!
>>  // or for that matter /: or :\
>>
>> That's just for illustrative purposes, of course the direct utilization
>> would be:
>>
>> scala> (0 /: Some(5))((_, x) => x * 10)
>> res0: Int = 50
>>
>> // unenviable type inference issue
>> scala> (0 /: (None: Option[Int]))((_, x) => x * 10)
>> res1: Int = 0
>>
>> Not saying this is ideal.
>
> Compared with this, Some(5).map(_ * 10).getOrElse(0) is downright nice.
>
>> --
>> Paul Phillips      | The most dangerous man to any government is the man
>> who
>> Moral Alien        | is able to think things out [...] Almost inevitably
>> he
>> Empiricist         | comes to the conclusion that the government he lives
>> under
>> ha! spill, pupil   | is dishonest, insane, intolerable.   -- H. L. Mencken
>>
>