Option...aly bored

Have you tried using them in a more functional style?for-comprehensions and map/flatmap/filter instead of getOrElse

2009/12/22 Razvan Cojocaru <razie@razie.com>

I got big on using Option with Some/Null - I thought it's an awesome idea
when I first saw it...now I'm getting bored however.

Isn't it the same as a checked exception, really? It started to either
require x match {  case Some(x) => ... }

everywhere or messes up my interfaces now, when passing stuff around...

I figured this when I found myself using OrElse more often...



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

--
View this message in context: http://old.nabble.com/Option...aly-bored-tp26893316p26893316.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Tue, Dec 22, 2009 at 11:49:20AM -0800, Razvan Cojocaru wrote:
> Isn't it the same as a checked exception, really?

Pretty much! And if you prefer unchecked wild roaming exceptions,

implicit def lifeissafe[T](x: Option[T]): T = x.get

And then you can work with optional values without the tedium of
articulating code paths for both outcomes.

I have found None / Some(x) to be useful when I wish to defer the branching of code paths depending on whether or not something was successful.  Often, it's easier to just carry the None around than to deal with the problem locally.  (Either is useful in this regard also, if you need to carry information about what went wrong.  Throwing an exception is useful too.)

Option is not all that different from an exception in concept--or from returning null--but it occupies a less "exceptional" place than an exception (i.e. it handles a common case for which you could potentially use exceptions, leaving exceptions for truly exceptional things), while being more demanding of your attention than null (which is usually good, since inattention to null trips people up all the time).

I'm sure it's possible to overuse Option.  For example, I would almost always not want division to return an Option[Int], even though 1/0 does not return an integer.  I would likely want user interface code that is supposed to interpret the user's entry into a text field as an Option[MyDataType], with None if the user entered something uninterpretable.  (Alternatively, I might use an Either[String,MyDataType] in this case, so downstream code could have access to the raw input.)

getOrElse and forall are quite handy when dealing with Option.

  --Rex

On Tue, Dec 22, 2009 at 2:49 PM, Razvan Cojocaru <razie@razie.com> wrote:

I got big on using Option with Some/Null - I thought it's an awesome idea
when I first saw it...now I'm getting bored however.

Isn't it the same as a checked exception, really? It started to either
require x match {  case Some(x) => ... }

everywhere or messes up my interfaces now, when passing stuff around...

I figured this when I found myself using OrElse more often...



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

--
View this message in context: http://old.nabble.com/Option...aly-bored-tp26893316p26893316.html
Sent from the Scala - User mailing list archive at Nabble.com.

Kevin Wright-4 wrote:
>
> Have you tried using them in a more functional style?
> for-comprehensions and map/flatmap/filter instead of getOrElse
>
Yes, I know - it works out but I don't always deal with collections of
stuff...

Rex Kerr-2 wrote:
>
> I'm sure it's possible to overuse Option. For example, I would almost
> always not want division to return an Option[Int], even though 1/0 does
> not
> return an integer. I would likely want user interface code that is
> supposed
> to interpret the user's entry into a text field as an Option[MyDataType],
> with None if the user entered something uninterpretable. (Alternatively,
> I
> might use an Either[String,MyDataType] in this case, so downstream code
> could have access to the raw input.)
>

Yes - I generally use it for containers/Home etc.
+1 on input formLike fields - interesting idea.

Paul Phillips-3 wrote:
>
> implicit def lifeissafe[T](x: Option[T]): T = x.get
>
+1 -except that this would get rid of all Options...

I am mainly complaining about me using it in my containers/interfaces. I'm
fine with the MapLike library collections.

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

The point of Option is that you _can't_ use it without checking first.   That said, as Kevin has suggested, it works nicely with a functional style. For instance, I'm used to doing maps and flatMaps on option, and only checking the final result for Some/None. If it was None from the outset, then it just doesn't apply any of the functions. And, then, there's foreach, which doesn't even require checking for anything.
On Tue, Dec 22, 2009 at 5:49 PM, Razvan Cojocaru <razie@razie.com> wrote:

I got big on using Option with Some/Null - I thought it's an awesome idea
when I first saw it...now I'm getting bored however.

Isn't it the same as a checked exception, really? It started to either
require x match {  case Some(x) => ... }

everywhere or messes up my interfaces now, when passing stuff around...

I figured this when I found myself using OrElse more often...



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

--
View this message in context: http://old.nabble.com/Option...aly-bored-tp26893316p26893316.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

I travel to the future all the time.

Paul Phillips wrote:
> On Tue, Dec 22, 2009 at 11:49:20AM -0800, Razvan Cojocaru wrote:
>> Isn't it the same as a checked exception, really?
>
> Pretty much! And if you prefer unchecked wild roaming exceptions,
>
> implicit def lifeissafe[T](x: Option[T]): T = x.get

Well, the problem I have with Option is that it erases its type argument, and
implicits like the one above aren't helping you out with having an implicit
from some T to S...

-Martin

2009/12/22 Razvan Cojocaru <razie@razie.com>

Kevin Wright-4 wrote:
>
> Have you tried using them in a more functional style?
> for-comprehensions and map/flatmap/filter instead of getOrElse
>
Yes, I know - it works out but I don't always deal with collections of
stuff... 

 Sure you do!Option is a collection of size either 0 or 1, you could just as easily use a list and ensure you never put more that one item in.

Rex Kerr-2 wrote:
>
> I'm sure it's possible to overuse Option.  For example, I would almost
> always not want division to return an Option[Int], even though 1/0 does
> not
> return an integer.  I would likely want user interface code that is
> supposed
> to interpret the user's entry into a text field as an Option[MyDataType],
> with None if the user entered something uninterpretable.  (Alternatively,
> I
> might use an Either[String,MyDataType] in this case, so downstream code
> could have access to the raw input.)
>

Yes - I generally use it for containers/Home etc.
+1 on input formLike fields - interesting idea.


Paul Phillips-3 wrote:
>
>   implicit def lifeissafe[T](x: Option[T]): T = x.get
>
+1 -except that this would get rid of all Options...

I am mainly complaining about me using it in my containers/interfaces. I'm
fine with the MapLike library collections.



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

--
View this message in context: http://old.nabble.com/Option...aly-bored-tp26893316p26893904.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Tue, Dec 22, 2009 at 03:42:01PM -0500, Martin S. Weber wrote:
> Well, the problem I have with Option is that it erases its type
> argument, and implicits like the one above aren't helping you out with
> having an implicit from some T to S...

I thought it was a safe bet that if you're really willing to use an
implicit like that you won't mind writing it with a cast. No half
measures! We're at war, pick a side!

Paul Phillips wrote:
> On Tue, Dec 22, 2009 at 03:42:01PM -0500, Martin S. Weber wrote:
>> Well, the problem I have with Option is that it erases its type
>> argument, and implicits like the one above aren't helping you out with
>> having an implicit from some T to S...
>
> I thought it was a safe bet that if you're really willing to use an
> implicit like that you won't mind writing it with a cast. No half
> measures! We're at war, pick a side!

At war? Which sides? Scala vs. user? Imo we should be fighting on the same side!!

Either is more like a checked exception. Your enlightenment does make
the "checked versus unchecked exception" "debate" look rather amusing in
its futility. Join me on the sidelines as a spectator.

Razvan Cojocaru wrote:
> I got big on using Option with Some/Null - I thought it's an awesome idea
> when I first saw it...now I'm getting bored however.
>
> Isn't it the same as a checked exception, really? It started to either
> require x match { case Some(x) => ... }
>
> everywhere or messes up my interfaces now, when passing stuff around...
>
> I figured this when I found myself using OrElse more often...
>
>
>
> -----
> Razvan Cojocaru,
> Work: http://www.sigma-systems.com
> Me: http://feeds.razie.com/RazvanTech
> Playground: http://wiki.homecloud.ca
>
>

Option is a collection (a list with a maximum of length 1), however, not
all things with map/flatMap/filter are a collection. Having been trying
to educate on this matter for quite some time, I have become quite
aversive to using analogies such as "collections" to describe "things"
(type constructors) with map/flatMap/filter.

Here is an example of a not-collection for which both map and flatMap
can be written:
case class IntFunctor[+A](f: Int => A)

Razvan Cojocaru wrote:
>
> Kevin Wright-4 wrote:
>
>> Have you tried using them in a more functional style?
>> for-comprehensions and map/flatmap/filter instead of getOrElse
>>
>>
> Yes, I know - it works out but I don't always deal with collections of
> stuff...
>
>
> Rex Kerr-2 wrote:
>
>> I'm sure it's possible to overuse Option. For example, I would almost
>> always not want division to return an Option[Int], even though 1/0 does
>> not
>> return an integer. I would likely want user interface code that is
>> supposed
>> to interpret the user's entry into a text field as an Option[MyDataType],
>> with None if the user entered something uninterpretable. (Alternatively,
>> I
>> might use an Either[String,MyDataType] in this case, so downstream code
>> could have access to the raw input.)
>>
>>
>
> Yes - I generally use it for containers/Home etc.
> +1 on input formLike fields - interesting idea.
>
>
> Paul Phillips-3 wrote:
>
>> implicit def lifeissafe[T](x: Option[T]): T = x.get
>>
>>
> +1 -except that this would get rid of all Options...
>
> I am mainly complaining about me using it in my containers/interfaces. I'm
> fine with the MapLike library collections.
>
>
>
> -----
> Razvan Cojocaru,
> Work: http://www.sigma-systems.com
> Me: http://feeds.razie.com/RazvanTech
> Playground: http://wiki.homecloud.ca
>
>

On Tue, Dec 22, 2009 at 4:44 PM, Martin S. Weber <martin.weber@nist.gov> wrote:

Paul Phillips wrote:

On Tue, Dec 22, 2009 at 03:42:01PM -0500, Martin S. Weber wrote:

Well, the problem I have with Option is that it erases its type argument, and implicits like the one above aren't helping you out with having an implicit from some T to S...

I thought it was a safe bet that if you're really willing to use an implicit like that you won't mind writing it with a cast.  No half measures! We're at war, pick a side!

At war? Which sides?

Options vs. exceptions!  Take this, try-catch block!

 def trycatch[A](f: => A): Option[A] = {
  try { Some( f ) }
  catch { case _ => None }
}

scala> trycatch { "3".toInt }
res0: Option[Int] = Some(3)

scala> trycatch { "wolf".toInt }
res1: Option[Int] = None

  --Rex

This function (corrected to use Either) has been requested several times
by users in #scala, though interestingly, not for a while.

Rex Kerr wrote:
> On Tue, Dec 22, 2009 at 4:44 PM, Martin S. Weber
> > wrote:
>
> Paul Phillips wrote:
>
> On Tue, Dec 22, 2009 at 03:42:01PM -0500, Martin S. Weber wrote:
>
> Well, the problem I have with Option is that it erases its
> type argument, and implicits like the one above aren't
> helping you out with having an implicit from some T to S...
>
>
> I thought it was a safe bet that if you're really willing to
> use an implicit like that you won't mind writing it with a
> cast. No half measures! We're at war, pick a side!
>
>
> At war? Which sides?
>
>
> Options vs. exceptions! Take this, try-catch block!
>
> def trycatch[A](f: => A): Option[A] = {
> try { Some( f ) }
> catch { case _ => None }
> }
>
> scala> trycatch { "3".toInt }
> res0: Option[Int] = Some(3)
>
> scala> trycatch { "wolf".toInt }
> res1: Option[Int] = None
>
> --Rex
>

The either version has merits too (even if erasure makes a type-aware version nontrivial).  Hmm, maybe I should start using these two more routinely.  They do have some nice use cases.

def trycatch[A](f: => A): Either[Throwable,A] = {
  try { Right( f ) }
  catch { case e => Left( e ) }
}

def attempt[A](f: => A): Option[A] = {
  try { Some( f ) }
  catch { case _ => None }
}

I prefer the latter in most situations where I just want a value and if it fails I don't care why.  I've not found many cases where the former is better than a standard try/catch--I still need to deal with the exception eventually, and unless there's a compelling reason not to deal with it right away, I may as well deal right away and not drag along the Left-wrapped Throwable.

  --Rex


On Tue, Dec 22, 2009 at 5:08 PM, Tony Morris <tonymorris@gmail.com> wrote:

This function (corrected to use Either) has been requested several times
by users in #scala, though interestingly, not for a while.

Rex Kerr wrote:
> On Tue, Dec 22, 2009 at 4:44 PM, Martin S. Weber
> <martin.weber@nist.gov <mailto:martin.weber@nist.gov>> wrote:
>
>     Paul Phillips wrote:
>
>         On Tue, Dec 22, 2009 at 03:42:01PM -0500, Martin S. Weber wrote:
>
>             Well, the problem I have with Option is that it erases its
>             type argument, and implicits like the one above aren't
>             helping you out with having an implicit from some T to S...
>
>
>         I thought it was a safe bet that if you're really willing to
>         use an implicit like that you won't mind writing it with a
>         cast.  No half measures! We're at war, pick a side!
>
>
>     At war? Which sides?
>
>
> Options vs. exceptions!  Take this, try-catch block!
>
>  def trycatch[A](f: => A): Option[A] = {
>   try { Some( f ) }
>   catch { case _ => None }
> }
>
> scala> trycatch { "3".toInt }
> res0: Option[Int] = Some(3)
>
> scala> trycatch { "wolf".toInt }
> res1: Option[Int] = None
>
>   --Rex
>

--
Tony Morris
http://tmorris.net/

Capturing exception handling in an algebraic data type has merits in
terms of its usage. Either is closer to a function that "returns R but
may throw T" or to play on the word, "A function that returns either R
or T".

When the value is in an algebraic type you have the higher-order
functions that abstract the structure i.e. no more low-level "pattern
matching" (the equivalent of try/catch) in favour of higher abstractions.

Rex Kerr wrote:
> The either version has merits too (even if erasure makes a type-aware
> version nontrivial). Hmm, maybe I should start using these two more
> routinely. They do have some nice use cases.
>
> def trycatch[A](f: => A): Either[Throwable,A] = {
> try { Right( f ) }
> catch { case e => Left( e ) }
> }
>
> def attempt[A](f: => A): Option[A] = {
> try { Some( f ) }
> catch { case _ => None }
> }
>
> I prefer the latter in most situations where I just want a value and
> if it fails I don't care why. I've not found many cases where the
> former is better than a standard try/catch--I still need to deal with
> the exception eventually, and unless there's a compelling reason not
> to deal with it right away, I may as well deal right away and not drag
> along the Left-wrapped Throwable.
>
> --Rex
>
>
> On Tue, Dec 22, 2009 at 5:08 PM, Tony Morris > wrote:
>
> This function (corrected to use Either) has been requested several
> times
> by users in #scala, though interestingly, not for a while.
>
> Rex Kerr wrote:
> > On Tue, Dec 22, 2009 at 4:44 PM, Martin S. Weber
> >
> >> wrote:
> >
> > Paul Phillips wrote:
> >
> > On Tue, Dec 22, 2009 at 03:42:01PM -0500, Martin S.
> Weber wrote:
> >
> > Well, the problem I have with Option is that it
> erases its
> > type argument, and implicits like the one above aren't
> > helping you out with having an implicit from some T
> to S...
> >
> >
> > I thought it was a safe bet that if you're really willing to
> > use an implicit like that you won't mind writing it with a
> > cast. No half measures! We're at war, pick a side!
> >
> >
> > At war? Which sides?
> >
> >
> > Options vs. exceptions! Take this, try-catch block!
> >
> > def trycatch[A](f: => A): Option[A] = {
> > try { Some( f ) }
> > catch { case _ => None }
> > }
> >
> > scala> trycatch { "3".toInt }
> > res0: Option[Int] = Some(3)
> >
> > scala> trycatch { "wolf".toInt }
> > res1: Option[Int] = None
> >
> > --Rex
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

AH-HA...my simpleton OO mind didn't comprehend this before... of course, now
it makes sense and yes, it should help.

Tony Morris-4 wrote:
>
> Option is a collection (a list with a maximum of length 1), however, not
> all things with map/flatMap/filter are a collection. Having been trying
> to educate on this matter for quite some time, I have become quite
> aversive to using analogies such as "collections" to describe "things"
> (type constructors) with map/flatMap/filter.
>

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

Razvan Cojocaru wrote:
>
> I got big on using Option with Some/None - I thought it's an awesome idea
> when I first saw it...now I'm getting bored however.
>
> Isn't it the same as a checked exception, really? It started to either
> require x match { case Some(x) => ... }
>
> everywhere or messes up my interfaces now, when passing stuff around...
>
> I figured this when I found myself using OrElse more often...
>
>
>

You probably already know the canonical source of all Option-Fu for novices,
but just in case:
http://dibblego.wordpress.com/2008/01/16/scalaoption-cheat-sheet/

Cheers,
Daniel

There is also
http://blog.tmorris.net/debut-with-a-catamorphism/ (Option without case
class/object).

Landei wrote:
>
> Razvan Cojocaru wrote:
>
>> I got big on using Option with Some/None - I thought it's an awesome idea
>> when I first saw it...now I'm getting bored however.
>>
>> Isn't it the same as a checked exception, really? It started to either
>> require x match { case Some(x) => ... }
>>
>> everywhere or messes up my interfaces now, when passing stuff around...
>>
>> I figured this when I found myself using OrElse more often...
>>
>>
>>
>>
>
> You probably already know the canonical source of all Option-Fu for novices,
> but just in case:
> http://dibblego.wordpress.com/2008/01/16/scalaoption-cheat-sheet/
>
> Cheers,
> Daniel
>

Try this instead. It renders better and the old one is no longer maintained.
http://blog.tmorris.net/scalaoption-cheat-sheet/

Landei wrote:
>
> Razvan Cojocaru wrote:
>
>> I got big on using Option with Some/None - I thought it's an awesome idea
>> when I first saw it...now I'm getting bored however.
>>
>> Isn't it the same as a checked exception, really? It started to either
>> require x match { case Some(x) => ... }
>>
>> everywhere or messes up my interfaces now, when passing stuff around...
>>
>> I figured this when I found myself using OrElse more often...
>>
>>
>>
>>
>
> You probably already know the canonical source of all Option-Fu for novices,
> but just in case:
> http://dibblego.wordpress.com/2008/01/16/scalaoption-cheat-sheet/
>
> Cheers,
> Daniel
>

Personally, I would be completely happy with Option iif,

1) there were implicit boxing functions in Predef from (T <: AnyRef with NonNull) and (T <: AnyVal) to Some[T]

(you could still write Some(null) explicitly if that's what you really want -- caveat emptor)

2) the Scala compiler properly inferred NonNull for all non-null AnyRef literals

3) we had the "!" operator on Option to shorten foreach

someOption ! _.doSomething

4) we had the "*" operator on Option to shorten map/flatMap

val result = someOption * _.computeSomething

5) we had a "?" operator on Option to shorten map/flatMap .... getOrElse

val result = someOption ? (_.computeSomething) (somethingElse)

6) we had a "|" operator on Option to return the first Some value (or None if no Some

val firstSome: Option[T] = someOption | someOtherOption | defaultValue

Notice how I didn't have to write Some(defaultValue) ;)

7) (bonus points) we had a "+" operator for T <% Monoid[T] to flatMap multiple monoids.

val result: Option[T <% Monoid[T]] = someOption + anotherOption + yetAnotherOption

This would cover 99+% of my very-frequently-used Option code, would make Option very pleasant to use and I wouldn't have to worry about my PowerOption implicit conversions eating up CPU cycles.

Power (Option) to the People!!

alex

Yep, these have been *very* useful. I consulted that page a lot.

Thanks Tony.

Francisco

2009/12/23 Tony Morris :
> Try this instead. It renders better and the old one is no longer maintained.
> http://blog.tmorris.net/scalaoption-cheat-sheet/
>
>
> Landei wrote:
>>
>> Razvan Cojocaru wrote:
>>
>>> I got big on using Option with Some/None - I thought it's an awesome idea
>>> when I first saw it...now I'm getting bored however.
>>>
>>> Isn't it the same as a checked exception, really? It started to either
>>> require x match {  case Some(x) => ... }
>>>
>>> everywhere or messes up my interfaces now, when passing stuff around...
>>>
>>> I figured this when I found myself using OrElse more often...
>>>
>>>
>>>
>>>
>>
>> You probably already know the canonical source of all Option-Fu for novices,
>> but just in case:
>> http://dibblego.wordpress.com/2008/01/16/scalaoption-cheat-sheet/
>>
>> Cheers,
>> Daniel
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

On Wednesday December 23 2009, Tony Morris wrote:
> Try this instead. It renders better and the old one is no longer
> maintained. http://blog.tmorris.net/scalaoption-cheat-sheet/

I may render better (or may not), but it doesn't seem to render well
enough:

Scalaz has many of your "shortenings" by virtue of the fact that Option
is a Functor, Monad and has three different Monoids.

Alex Boisvert wrote:
> Personally, I would be completely happy with Option iif,
>
> 1) there were implicit boxing functions in Predef from (T <: AnyRef
> with NonNull) and (T <: AnyVal) to Some[T]
>
> (you could still write Some(null) explicitly if that's what you really
> want -- caveat emptor)
>
> 2) the Scala compiler properly inferred NonNull for all non-null
> AnyRef literals
>
> 3) we had the "!" operator on Option to shorten foreach
>
> someOption ! _.doSomething
>
> 4) we had the "*" operator on Option to shorten map/flatMap
>
> val result = someOption * _.computeSomething
>
> 5) we had a "?" operator on Option to shorten map/flatMap .... getOrElse
>
> val result = someOption ? (_.computeSomething) (somethingElse)
>
> 6) we had a "|" operator on Option to return the first Some value (or
> None if no Some
>
> val firstSome: Option[T] = someOption | someOtherOption | defaultValue
>
> Notice how I didn't have to write Some(defaultValue) ;)
>
> 7) (bonus points) we had a "+" operator for T <% Monoid[T] to flatMap
> multiple monoids.
>
> val result: Option[T <% Monoid[T]] = someOption + anotherOption +
> yetAnotherOption
>
> This would cover 99+% of my very-frequently-used Option code, would
> make Option very pleasant to use and I wouldn't have to worry about my
> PowerOption implicit conversions eating up CPU cycles.
>
> Power (Option) to the People!!
>
> alex
>
>

WordPress :( Sorry, I've gave up trying to get it any better long ago.

Randall R Schulz wrote:
> On Wednesday December 23 2009, Tony Morris wrote:
>
>> Try this instead. It renders better and the old one is no longer
>> maintained. http://blog.tmorris.net/scalaoption-cheat-sheet/
>>
>
> I may render better (or may not), but it doesn't seem to render well
> enough:
>
>
>
> ------------------------------------------------------------------------
>

Yes, I'm aware of that and while I do appreciate Scalaz, it's like jumping to a parallel universe -- warping between dimensions can be exhausting ;)

My preference would be to improve the convenience of the standard Option trait.

alex

On Wed, Dec 23, 2009 at 11:59 AM, Tony Morris <tonymorris@gmail.com> wrote:

Scalaz has many of your "shortenings" by virtue of the fact that Option
is a Functor, Monad and has three different Monoids.

Alex Boisvert wrote:
> Personally, I would be completely happy with Option iif,
>
> 1) there were implicit boxing functions in Predef from (T <: AnyRef
> with NonNull) and (T <: AnyVal) to Some[T]
>
> (you could still write Some(null) explicitly if that's what you really
> want -- caveat emptor)
>
> 2) the Scala compiler properly inferred NonNull for all non-null
> AnyRef literals
>
> 3) we had the "!" operator on Option to shorten foreach
>
> someOption ! _.doSomething
>
> 4) we had the "*" operator on Option to shorten map/flatMap
>
> val result = someOption * _.computeSomething
>
> 5) we had a "?" operator on Option to shorten map/flatMap .... getOrElse
>
> val result = someOption ? (_.computeSomething) (somethingElse)
>
> 6) we had a "|" operator on Option to return the first Some value (or
> None if no Some
>
> val firstSome: Option[T] = someOption | someOtherOption | defaultValue
>
> Notice how I didn't have to write Some(defaultValue) ;)
>
> 7) (bonus points) we had a "+" operator for T <% Monoid[T] to flatMap
> multiple monoids.
>
> val result: Option[T <% Monoid[T]] = someOption + anotherOption +
> yetAnotherOption
>
> This would cover 99+% of my very-frequently-used Option code, would
> make Option very pleasant to use and I wouldn't have to worry about my
> PowerOption implicit conversions eating up CPU cycles.
>
> Power (Option) to the People!!
>
> alex
>
>

--
Tony Morris
http://tmorris.net/

The aversion to abstraction has always baffled me.

Alex Boisvert wrote:
> Yes, I'm aware of that and while I do appreciate Scalaz, it's like
> jumping to a parallel universe -- warping between dimensions can be
> exhausting ;)
>
> My preference would be to improve the convenience of the standard
> Option trait.
>
> alex
>
> On Wed, Dec 23, 2009 at 11:59 AM, Tony Morris > wrote:
>
> Scalaz has many of your "shortenings" by virtue of the fact that
> Option
> is a Functor, Monad and has three different Monoids.
>
> Alex Boisvert wrote:
> > Personally, I would be completely happy with Option iif,
> >
> > 1) there were implicit boxing functions in Predef from (T <: AnyRef
> > with NonNull) and (T <: AnyVal) to Some[T]
> >
> > (you could still write Some(null) explicitly if that's what you
> really
> > want -- caveat emptor)
> >
> > 2) the Scala compiler properly inferred NonNull for all non-null
> > AnyRef literals
> >
> > 3) we had the "!" operator on Option to shorten foreach
> >
> > someOption ! _.doSomething
> >
> > 4) we had the "*" operator on Option to shorten map/flatMap
> >
> > val result = someOption * _.computeSomething
> >
> > 5) we had a "?" operator on Option to shorten map/flatMap ....
> getOrElse
> >
> > val result = someOption ? (_.computeSomething) (somethingElse)
> >
> > 6) we had a "|" operator on Option to return the first Some
> value (or
> > None if no Some
> >
> > val firstSome: Option[T] = someOption | someOtherOption |
> defaultValue
> >
> > Notice how I didn't have to write Some(defaultValue) ;)
> >
> > 7) (bonus points) we had a "+" operator for T <% Monoid[T] to
> flatMap
> > multiple monoids.
> >
> > val result: Option[T <% Monoid[T]] = someOption + anotherOption +
> > yetAnotherOption
> >
> > This would cover 99+% of my very-frequently-used Option code, would
> > make Option very pleasant to use and I wouldn't have to worry
> about my
> > PowerOption implicit conversions eating up CPU cycles.
> >
> > Power (Option) to the People!!
> >
> > alex
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

On Wed, Dec 23, 2009 at 12:00 PM, Alex Boisvert <alex.boisvert@gmail.com> wrote:

Personally, I would be completely happy with Option iif,

1) there were implicit boxing functions in Predef from (T <: AnyRef with NonNull) and (T <: AnyVal) to Some[T]

(you could still write Some(null) explicitly if that's what you really want -- caveat emptor)

It would be nice to be able to include this with enhanced Option handling.  (The exception-to-option function would be a good candidate to come along for the ride.)

I am wary of sticking low-performance implicits in Predef unless absolutely necessary.
 

3) we had the "!" operator on Option to shorten foreach

someOption ! _.doSomething

This is a bad idea for any standard package.  It's hard enough having ! mean "boolean not" and "send message to actor" without it meaning "foreach" also.
 

4) we had the "*" operator on Option to shorten map/flatMap

val result = someOption * _.computeSomething

This notation makes sense and is probably not overly confusing, but
 

5) we had a "?" operator on Option to shorten map/flatMap .... getOrElse

val result = someOption ? (_.computeSomething) (somethingElse)

this does basically the same thing with an extra option.  Why not overload the same method to take one or two arguments?  And of the two, I would prefer the ? so that the mathematical operators are free for people who want to extend math to work on Optioned numeric values.
 

6) we had a "|" operator on Option to return the first Some value (or None if no Some

val firstSome: Option[T] = someOption | someOtherOption | defaultValue

This would be nice.
 

Notice how I didn't have to write Some(defaultValue) ;)

7) (bonus points) we had a "+" operator for T <% Monoid[T] to flatMap multiple monoids.

val result: Option[T <% Monoid[T]] = someOption + anotherOption + yetAnotherOption

This would cover 99+% of my very-frequently-used Option code, would make Option very pleasant to use and I wouldn't have to worry about my PowerOption implicit conversions eating up CPU cycles.

Using all those options is already eating up lots of CPU cycles.  If Option is cheap relative to whatever you're doing, PowerOption will at most triple the cost, and triple something insignificant is probably also insigificant.  If Option is expensive relative to whatever you're doing, you should really consider whether you want efficiency or functional style.  There's a relatively narrow window in which it is important (where Option is already eating up perhaps 10-30% of your time or space).

  --Rex
 

On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr <ichoran@gmail.com> wrote:

On Wed, Dec 23, 2009 at 12:00 PM, Alex Boisvert <alex.boisvert@gmail.com> wrote:

Personally, I would be completely happy with Option iif,

1) there were implicit boxing functions in Predef from (T <: AnyRef with NonNull) and (T <: AnyVal) to Some[T]

(you could still write Some(null) explicitly if that's what you really want -- caveat emptor)

It would be nice to be able to include this with enhanced Option handling.  (The exception-to-option function would be a good candidate to come along for the ride.)

I am wary of sticking low-performance implicits in Predef unless absolutely necessary.

If the compiler can figure non-nullness, then there's no performance impact at all.  It's the same as explicitly calling Some().
 

 

3) we had the "!" operator on Option to shorten foreach

someOption ! _.doSomething

This is a bad idea for any standard package.  It's hard enough having ! mean "boolean not" and "send message to actor" without it meaning "foreach" also.

I use "!" here exactly because it means "send a message", with the recipient being the value of the Option.  OO is all about messaging sending and so from my POV, this makes a lot of sense.
 

 

4) we had the "*" operator on Option to shorten map/flatMap

val result = someOption * _.computeSomething

This notation makes sense and is probably not overly confusing, but
 

5) we had a "?" operator on Option to shorten map/flatMap .... getOrElse

val result = someOption ? (_.computeSomething) (somethingElse)

this does basically the same thing with an extra option.  Why not overload the same method to take one or two arguments?  And of the two, I would prefer the ? so that the mathematical operators are free for people who want to extend math to work on Optioned numeric values.

No, it's different than the above because it performs getOrElse.  It unwraps the value.  So it convert Option[T] to a U, provided both expressions are of type T => U.

 

6) we had a "|" operator on Option to return the first Some value (or None if no Some

val firstSome: Option[T] = someOption | someOtherOption | defaultValue

This would be nice.
 

Notice how I didn't have to write Some(defaultValue) ;)

7) (bonus points) we had a "+" operator for T <% Monoid[T] to flatMap multiple monoids.

val result: Option[T <% Monoid[T]] = someOption + anotherOption + yetAnotherOption

This would cover 99+% of my very-frequently-used Option code, would make Option very pleasant to use and I wouldn't have to worry about my PowerOption implicit conversions eating up CPU cycles.

Using all those options is already eating up lots of CPU cycles.  If Option is cheap relative to whatever you're doing, PowerOption will at most triple the cost, and triple something insignificant is probably also insigificant.  If Option is expensive relative to whatever you're doing, you should really consider whether you want efficiency or functional style.  There's a relatively narrow window in which it is important (where Option is already eating up perhaps 10-30% of your time or space).

You're sort of contracting yourself here.

In any case, my point is that if Options are (relatively) expensive to start with, let's no tack any more weight to them.  Let's provide the convenience directly in the Option trait so common idioms are not more expensive than they already are.

alex

On Wednesday December 23 2009, Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr wrote:
> > ...
>
> >> 3) we had the "!" operator on Option to shorten foreach
> >>
> >> someOption ! _.doSomething
> >
> > This is a bad idea for any standard package. It's hard enough
> > having ! mean "boolean not" and "send message to actor" without it
> > meaning "foreach" also.
>
> I use "!" here exactly because it means "send a message", with the
> recipient being the value of the Option. OO is all about messaging
> sending and so from my POV, this makes a lot of sense.

Even in the SmallTalk era, object-oriented programming was about
much more than message-sending! I personally have never liked the
presentation of method or member function invocation as "message
passing."

> ...
>
> alex

Randall Schulz

On Wed, Dec 23, 2009 at 5:43 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday December 23 2009, Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr <ichoran@gmail.com> wrote:
> > ...
>
> >> 3) we had the "!" operator on Option to shorten foreach
> >>
> >> someOption ! _.doSomething
> >
> > This is a bad idea for any standard package.  It's hard enough
> > having ! mean "boolean not" and "send message to actor" without it
> > meaning "foreach" also.
>
> I use "!" here exactly because it means "send a message", with the
> recipient being the value of the Option.  OO is all about messaging
> sending and so from my POV, this makes a lot of sense.

Even in the SmallTalk era, object-oriented programming was about
much more than message-sending! I personally have never liked the
presentation of method or member function invocation as "message
passing."

Well, I'm not going to be dragged into a bike shed discussion on method naming but I'll mention that I've picked operators because they are short (shorter than method names) and because you can use shorthand assignment with var's.

var foo: Option[_] = ...

foo *= (_.computeSomething)
foo |= defaultOption
foo += someOption

At this point, I'd be happier have any operator adopted than to have my exact choice of operators selected.

alex

Have some fun.

Loading initrepl...
import scalaz._
import scalaz.Scalaz._

Welcome to Scala version 2.8.0.r20247-b20091220020228 (Java HotSpot(TM)
Server VM, Java 1.6.0_17).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val s: Option[Int] = Some(7)
s: Option[Int] = Some(7)

scala> val n: Option[Int] = None
n: Option[Int] = None

scala> s ∘ (1+) // map
res0: Option[Int] = Some(8)

scala> s ∘ (1+) // map
res2: Option[Int] = Some(8)

scala> s ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res3: Option[Int] = Some(14)

scala> n ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res4: Option[Int] = None

scala> s ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res5: Option[Int] = Some(14)

scala> val s2: Option[Int] = Some(3)
s2: Option[Int] = Some(3)

scala> s2 ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res6: Option[Int] = None

scala> s | 9 // getOrElse
res7: Int = 7

scala> n | 9 // getOrElse
res9: Int = 9

scala> val s3: Option[Option[Int]] = Some(Some(4))
s3: Option[Option[Int]] = Some(Some(4))

scala> s3 μ // join/flatten
res10: Option[Int] = Some(4)

scala> val s4: Option[Option[Int]] = Some(None)
s4: Option[Option[Int]] = Some(None)

scala> s4 μ // join/flatten
res11: Option[Int] = None

scala> val s5: Option[Option[Int]] = None
s5: Option[Option[Int]] = None

scala> s5 μ // join/flatten
res12: Option[Int] = None

scala> s ➡ println // foreach
7

scala> n ➡ println // foreach

scala>

There is nothing particularly special here except that:
a) Many of these functions are defined once.
b) Many of these functions are not specific to Option.
c) There are many more interesting functions just like it, but they have
no equivalent in the standard library.

scala> List(1, 2, 3) ∘ (1+)
res15: List[Int] = List(2, 3, 4)

Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 5:43 PM, Randall R Schulz > wrote:
>
> On Wednesday December 23 2009, Alex Boisvert wrote:
> > On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr > wrote:
> > > ...
> >
> > >> 3) we had the "!" operator on Option to shorten foreach
> > >>
> > >> someOption ! _.doSomething
> > >
> > > This is a bad idea for any standard package. It's hard enough
> > > having ! mean "boolean not" and "send message to actor" without it
> > > meaning "foreach" also.
> >
> > I use "!" here exactly because it means "send a message", with the
> > recipient being the value of the Option. OO is all about messaging
> > sending and so from my POV, this makes a lot of sense.
>
> Even in the SmallTalk era, object-oriented programming was about
> much more than message-sending! I personally have never liked the
> presentation of method or member function invocation as "message
> passing."
>
>
> Well, I'm not going to be dragged into a bike shed discussion on
> method naming but I'll mention that I've picked operators because they
> are short (shorter than method names) and because you can use
> shorthand assignment with var's.
>
> var foo: Option[_] = ...
>
> foo *= (_.computeSomething)
> foo |= defaultOption
> foo += someOption
>
> At this point, I'd be happier have any operator adopted than to have
> my exact choice of operators selected.
>
> alex

On Wed, Dec 23, 2009 at 8:27 PM, Alex Boisvert <alex.boisvert@gmail.com> wrote:

On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr <ichoran@gmail.com> wrote:

I am wary of sticking low-performance implicits in Predef unless absolutely necessary.

If the compiler can figure non-nullness, then there's no performance impact at all.  It's the same as explicitly calling Some().

Yes, except that you don't notice that you explicitly need to call Some(x).
 

 

3) we had the "!" operator on Option to shorten foreach

someOption ! _.doSomething

This is a bad idea for any standard package.  It's hard enough having ! mean "boolean not" and "send message to actor" without it meaning "foreach" also.

I use "!" here exactly because it means "send a message", with the recipient being the value of the Option.  OO is all about messaging sending and so from my POV, this makes a lot of sense.

Except the message is a function, and the recipient is a value.  This is, except possibly in some functional programming circles, not the normal way to send messages.  (Messages are typically data.)

Anyway, if this is how you think about OO programming, ought not either map/flatMap or that plus getOrElse be "!?" like with actors?  (If "?" means "get message", so why do you want that combined with map/flatMap instead of just being a synonym for getOrElse?)
 

No, it's different than the above because it performs getOrElse.  It unwraps the value.  So it convert Option[T] to a U, provided both expressions are of type T => U.

My mistake--I was thinking of orElse.
 

This would cover 99+% of my very-frequently-used Option code, would make Option very pleasant to use and I wouldn't have to worry about my PowerOption implicit conversions eating up CPU cycles.

Using all those options is already eating up lots of CPU cycles.  If Option is cheap relative to whatever you're doing, PowerOption will at most triple the cost, and triple something insignificant is probably also insigificant.  If Option is expensive relative to whatever you're doing, you should really consider whether you want efficiency or functional style.  There's a relatively narrow window in which it is important (where Option is already eating up perhaps 10-30% of your time or space).

You're sort of contracting yourself here.

In any case, my point is that if Options are (relatively) expensive to start with, let's no tack any more weight to them.  Let's provide the convenience directly in the Option trait so common idioms are not more expensive than they already are.

My point is that if Options are (relatively) expensive to start with and you care about performance, you should think carefully about using them.  There are a bunch of use cases where Option is 50%-1000% slower than not using Option.

I'm all for faster Options, but JVM changes are the key to that.

  --Rex

Somewhere back in the archives you'll find a proposal I made where

foo*.bar(args)

would be sugar for

for.map( _.bar(args))

and

foo?.bar(args)

would be sugar for

foo.filter(_.bar(args))

This required language extension, and was meant to cover the same use case
as the Groovy *. operation. In addition to working sweetly with various
built-in collection types, the obvious uses with Option were mentioned. The
request was not well-received, but I still like the idea.

--Dave Griffith

On Wednesday December 23 2009, Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 5:43 PM, Randall R Schulz
wrote:
> > On Wednesday December 23 2009, Alex Boisvert wrote:
> > > ...
> > >
> > > I use "!" here exactly because it means "send a message", with
> > > the recipient being the value of the Option. OO is all about
> > > messaging sending and so from my POV, this makes a lot of sense.
> >
> > Even in the SmallTalk era, object-oriented programming was about
> > much more than message-sending! I personally have never liked the
> > presentation of method or member function invocation as "message
> > passing."
>
> Well, I'm not going to be dragged into a bike shed discussion on
> method naming ...

I objected to your characterization of object-oriented programming as
being "all about message sending."

The name you want for a method that is in all likelihood not going to be
added to Scala's Option class is of no concern to me.

> alex

Randall Schulz

> Date: Thu, 24 Dec 2009 08:18:10 +1000
> From: tonymorris@gmail.com
> Subject: Re: [scala-user] Option...aly bored
>
> The aversion to abstraction has always baffled me.
 
If one doesn't come from an FP background (or Comp Sci) then it's extremely difficult to understand the point of these scalaz constructs because I can't find any documentation on how to use them with examples, unless I'm looking in the wrong place (http://code.google.com/p/scalaz/).

It looks like there's a lot of dreadfully clever stuff in there and I've been frustrated a few times trying to understand in what scenario an Each (for example) might be a lovely and useful thing to use.

I have the impression that, for example with Tony's Option blog entry, a few examples might open a window into a new and more elegant world.

View your other email accounts from your Hotmail inbox. Add them now.

We've included quite a few examples in trunk [1] for the
in-development Scalaz 5. The examples in Tony's examples used this
version.

You can try it out in a REPL with the instructions below.

The import of scalaz.Scalaz._ brings many implicit conversions into
scope. For example all objects can be converted to Identity. One
argument type constructors (e.g. List, Option, Function[Int, _]) can
be converted to MA. Two argument type constructors can be converted to
MAB.

You can then use the plethora of methods on Identity, MA, and MAB,
provided requisite type class instances are available. In this way,
you normally don't call the methods from the type classes directly,
instead you the more O-O looking calls.

You can also direct any questions to the Scalaz Google group.

-jason

[1] http://code.google.com/p/scalaz/source/browse/trunk/example/src/main/sca...

Method 1: Download jar from
http://scala-tools.org/repo-snapshots/com/googlecode/scalaz/scalaz-core_...
and load with the :jar command in the Scala REPL

Method 2: Build from Source with SBT

$ svn co http://scalaz.googlecode.com/svn/trunk/ scalaz
$ cd scalaz
$ sbt update
$ sbt
>Scalaz
> project Scalaz Core
Set current project to Scalaz Core 5.0-SNAPSHOT
> console
...
Welcome to Scala version 2.8.0.Beta1-RC6 (Java HotSpot(TM) Client VM, Java 1.6.0
_14).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import scalaz._
import scalaz._

scala> import scalaz.Scalaz._
import scalaz.Scalaz._

scala> // explore!

On Thu, Dec 24, 2009 at 3:38 PM, christopher marshall
wrote:
>> Date: Thu, 24 Dec 2009 08:18:10 +1000
>> From: tonymorris@gmail.com
>> Subject: Re: [scala-user] Option...aly bored
>>
>> The aversion to abstraction has always baffled me.
>
> If one doesn't come from an FP background (or Comp Sci) then it's extremely
> difficult to understand the point of these scalaz constructs because I can't
> find any documentation on how to use them with examples, unless I'm looking
> in the wrong place (http://code.google.com/p/scalaz/).
>
> It looks like there's a lot of dreadfully clever stuff in there and I've
> been frustrated a few times trying to understand in what scenario an Each
> (for example) might be a lovely and useful thing to use.
>
> I have the impression that, for example with Tony's Option blog entry, a few
> examples might open a window into a new and more elegant world.

Tony,

I understand you regard FP as the one true way to build abstraction but understand that FP does not have a monopoly on abstraction and that they are many other ways to achieve it, each with their own set of tradeoffs.    FP abstraction scales nicely in the way of mathematical concepts but other abstraction mechanisms (such as object-orientation) have benefits in other areas.  For instance, there are good research papers now that demonstrate how Scala, with its mix of OO + FP, offers more elegant/expressive solutions to some computing challenges.  You may continue to ignore these but please do not disparage people who do not share your viewpoint.

regards,
alex

On Wed, Dec 23, 2009 at 2:18 PM, Tony Morris <tonymorris@gmail.com> wrote:

The aversion to abstraction has always baffled me.

Alex Boisvert wrote:
> Yes, I'm aware of that and while I do appreciate Scalaz, it's like
> jumping to a parallel universe -- warping between dimensions can be
> exhausting ;)
>
> My preference would be to improve the convenience of the standard
> Option trait.
>
> alex
>
> On Wed, Dec 23, 2009 at 11:59 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
>     Scalaz has many of your "shortenings" by virtue of the fact that
>     Option
>     is a Functor, Monad and has three different Monoids.
>
>     Alex Boisvert wrote:
>     > Personally, I would be completely happy with Option iif,
>     >
>     > 1) there were implicit boxing functions in Predef from (T <: AnyRef
>     > with NonNull) and (T <: AnyVal) to Some[T]
>     >
>     > (you could still write Some(null) explicitly if that's what you
>     really
>     > want -- caveat emptor)
>     >
>     > 2) the Scala compiler properly inferred NonNull for all non-null
>     > AnyRef literals
>     >
>     > 3) we had the "!" operator on Option to shorten foreach
>     >
>     > someOption ! _.doSomething
>     >
>     > 4) we had the "*" operator on Option to shorten map/flatMap
>     >
>     > val result = someOption * _.computeSomething
>     >
>     > 5) we had a "?" operator on Option to shorten map/flatMap ....
>     getOrElse
>     >
>     > val result = someOption ? (_.computeSomething) (somethingElse)
>     >
>     > 6) we had a "|" operator on Option to return the first Some
>     value (or
>     > None if no Some
>     >
>     > val firstSome: Option[T] = someOption | someOtherOption |
>     defaultValue
>     >
>     > Notice how I didn't have to write Some(defaultValue) ;)
>     >
>     > 7) (bonus points) we had a "+" operator for T <% Monoid[T] to
>     flatMap
>     > multiple monoids.
>     >
>     > val result: Option[T <% Monoid[T]] = someOption + anotherOption +
>     > yetAnotherOption
>     >
>     > This would cover 99+% of my very-frequently-used Option code, would
>     > make Option very pleasant to use and I wouldn't have to worry
>     about my
>     > PowerOption implicit conversions eating up CPU cycles.
>     >
>     > Power (Option) to the People!!
>     >
>     > alex
>     >
>     >
>
>     --
>     Tony Morris
>     http://tmorris.net/
>
>
>

--
Tony Morris
http://tmorris.net/

2009/12/24 Tony Morris <tonymorris@gmail.com>

Have some fun.

Loading initrepl...
import scalaz._
import scalaz.Scalaz._

Welcome to Scala version 2.8.0.r20247-b20091220020228 (Java HotSpot(TM)
Server VM, Java 1.6.0_17).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val s: Option[Int] = Some(7)
s: Option[Int] = Some(7)

scala> val n: Option[Int] = None
n: Option[Int] = None

scala> s ∘ (1+) // map
res0: Option[Int] = Some(8)

scala> s ∘ (1+) // map
res2: Option[Int] = Some(8)

 Why would you use '∘' instead of 'map'? Isn't that a domain specific already?

scala> s ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res3: Option[Int] = Some(14)

This construct is useful too:

for (n <- s if n > 5) yield (n * 2)

Why use '∗' instead of haskellish '>>='? Is '∗' known elsewhere? And how do you write these symbols in a convenient manner using a standard keyboard?
 

scala> n ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res4: Option[Int] = None

scala> s ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res5: Option[Int] = Some(14)

scala> val s2: Option[Int] = Some(3)
s2: Option[Int] = Some(3)

scala> s2 ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res6: Option[Int] = None

scala> s | 9 // getOrElse
res7: Int = 7

scala> n | 9 // getOrElse
res9: Int = 9

 

scala> val s3: Option[Option[Int]] = Some(Some(4))
s3: Option[Option[Int]] = Some(Some(4))

 I'd rather avoid to ever have to wrap an option in another option. Does that make sense in practice?

scala> s3 μ // join/flatten
res10: Option[Int] = Some(4)

scala> val s4: Option[Option[Int]] = Some(None)
s4: Option[Option[Int]] = Some(None)

scala> s4 μ // join/flatten
res11: Option[Int] = None

I find the '|' operator is very expressive but here I find 'flatten' simply more expressive than 'μ' or join.

Cheers,
Sebastien
 

scala> val s5: Option[Option[Int]] = None
s5: Option[Option[Int]] = None

scala> s5 μ // join/flatten
res12: Option[Int] = None

scala> s ➡ println // foreach
7

scala> n ➡ println // foreach

scala>

There is nothing particularly special here except that:
a) Many of these functions are defined once.
b) Many of these functions are not specific to Option.
c) There are many more interesting functions just like it, but they have
no equivalent in the standard library.

scala> List(1, 2, 3) ∘ (1+)
res15: List[Int] = List(2, 3, 4)


Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 5:43 PM, Randall R Schulz <rschulz@sonic.net
> <mailto:rschulz@sonic.net>> wrote:
>
>     On Wednesday December 23 2009, Alex Boisvert wrote:
>     > On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr <ichoran@gmail.com
>     <mailto:ichoran@gmail.com>> wrote:
>     > > ...
>     >
>     > >> 3) we had the "!" operator on Option to shorten foreach
>     > >>
>     > >> someOption ! _.doSomething
>     > >
>     > > This is a bad idea for any standard package.  It's hard enough
>     > > having ! mean "boolean not" and "send message to actor" without it
>     > > meaning "foreach" also.
>     >
>     > I use "!" here exactly because it means "send a message", with the
>     > recipient being the value of the Option.  OO is all about messaging
>     > sending and so from my POV, this makes a lot of sense.
>
>     Even in the SmallTalk era, object-oriented programming was about
>     much more than message-sending! I personally have never liked the
>     presentation of method or member function invocation as "message
>     passing."
>
>
> Well, I'm not going to be dragged into a bike shed discussion on
> method naming but I'll mention that I've picked operators because they
> are short (shorter than method names) and because you can use
> shorthand assignment with var's.
>
> var foo: Option[_] = ...
>
> foo *= (_.computeSomething)
> foo |= defaultOption
> foo += someOption
>
> At this point, I'd be happier have any operator adopted than to have
> my exact choice of operators selected.
>
> alex

--
Tony Morris
http://tmorris.net/

Tony Morrishttp://tmorris.net/

On Dec 25, 2009, at 5:07 AM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

2009/12/24 Tony Morris < (tonymorris [at] gmail [dot] com>

Have some fun.

Loading initrepl...
import scalaz._
import scalaz.Scalaz._

Welcome to Scala version 2.8.0.r20247-b20091220020228 (Java HotSpot(TM)
Server VM, Java 1.6.0_17).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val s: Option[Int] = Some(7)
s: Option[Int] = Some(7)

scala> val n: Option[Int] = None
n: Option[Int] = None

scala> s ∘ (1+) // map
res0: Option[Int] = Some(8)

scala> s ∘ (1+) // map
res2: Option[Int] = Some(8)

 Why would you use '∘' instead of 'map'? Isn't that a domain specific already?

Because it is a generalisation of map. Function composition (which is what the character means in denotational semantics) is the map of Function1. Take a look at the type signature of scala.Function1.compose and see if you can make it out.

scala> s ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res3: Option[Int] = Some(14)

This construct is useful too:

for (n <- s if n > 5) yield (n * 2)

Useful, but a different computation.

Why use '∗' instead of haskellish '>>='? Is '∗' known elsewhere? And how do you write these symbols in a convenient manner using a standard keyboard?

The symbol is from a Wadler paper iirc. I use operating environments that don't make typing difficult (with the exception of the device I am using right now -- I err). In any case all Unicode symbols have or will have ASCII aliases.
The composition operator is a special case because I have long held that "map" has far too many characters (by 300%!) that can be very distracting for some people.

 

scala> n ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res4: Option[Int] = None

scala> s ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res5: Option[Int] = Some(14)

scala> val s2: Option[Int] = Some(3)
s2: Option[Int] = Some(3)

scala> s2 ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res6: Option[Int] = None

scala> s | 9 // getOrElse
res7: Int = 7

scala> n | 9 // getOrElse
res9: Int = 9

 

scala> val s3: Option[Option[Int]] = Some(Some(4))
s3: Option[Option[Int]] = Some(Some(4))

 I'd rather avoid to ever have to wrap an option in another option. Does that make sense in practice?

Yes. Join is a very fundamental monad operation. I'd elaborate if not for the limitations of this device sorry.

scala> s3 μ // join/flatten
res10: Option[Int] = Some(4)

scala> val s4: Option[Option[Int]] = Some(None)
s4: Option[Option[Int]] = Some(None)

scala> s4 μ // join/flatten
res11: Option[Int] = None

I find the '|' operator is very expressive but here I find 'flatten' simply more expressive than 'μ' or join.

I find the distinction quite cumbersome. Nevertheless join is so rudimentary the it deserves it's own operator. The mu symbol is used in denotational semantics.
See Agda for some inspiration.

Cheers,
Sebastien
 

scala> val s5: Option[Option[Int]] = None
s5: Option[Option[Int]] = None

scala> s5 μ // join/flatten
res12: Option[Int] = None

scala> s ➡ println // foreach
7

scala> n ➡ println // foreach

scala>

There is nothing particularly special here except that:
a) Many of these functions are defined once.
b) Many of these functions are not specific to Option.
c) There are many more interesting functions just like it, but they have
no equivalent in the standard library.

scala> List(1, 2, 3) ∘ (1+)
res15: List[Int] = List(2, 3, 4)


Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 5:43 PM, Randall R Schulz < (rschulz [at] sonic [dot] net
> <mailto: (rschulz [at] sonic [dot] net>> wrote:
>
>     On Wednesday December 23 2009, Alex Boisvert wrote:
>     > On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr < (ichoran [at] gmail [dot] com
>     <mailto: (ichoran [at] gmail [dot] com>> wrote:
>     > > ...
>     >
>     > >> 3) we had the "!" operator on Option to shorten foreach
>     > >>
>     > >> someOption ! _.doSomething
>     > >
>     > > This is a bad idea for any standard package.  It's hard enough
>     > > having ! mean "boolean not" and "send message to actor" without it
>     > > meaning "foreach" also.
>     >
>     > I use "!" here exactly because it means "send a message", with the
>     > recipient being the value of the Option.  OO is all about messaging
>     > sending and so from my POV, this makes a lot of sense.
>
>     Even in the SmallTalk era, object-oriented programming was about
>     much more than message-sending! I personally have never liked the
>     presentation of method or member function invocation as "message
>     passing."
>
>
> Well, I'm not going to be dragged into a bike shed discussion on
> method naming but I'll mention that I've picked operators because they
> are short (shorter than method names) and because you can use
> shorthand assignment with var's.
>
> var foo: Option[_] = ...
>
> foo *= (_.computeSomething)
> foo |= defaultOption
> foo += someOption
>
> At this point, I'd be happier have any operator adopted than to have
> my exact choice of operators selected.
>
> alex

--
Tony Morris
http://tmorris.net/

I am strongly considering writing a "user manual" to appease this problem. Stay tuned.

Tony Morrishttp://tmorris.net/

On Dec 25, 2009, at 12:38 AM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

> Date: Thu, 24 Dec 2009 08:18:10 +1000
> From: (tonymorris [at] gmail [dot] com
> Subject: Re: [scala-user] Option...aly bored
>
> The aversion to abstraction has always baffled me.
 
If one doesn't come from an FP background (or Comp Sci) then it's extremely difficult to understand the point of these scalaz constructs because I can't find any documentation on how to use them with examples, unless I'm looking in the wrong place (http://code.google.com/p/scalaz/).

It looks like there's a lot of dreadfully clever stuff in there and I've been frustrated a few times trying to understand in what scenario an Each (for example) might be a lovely and useful thing to use.

I have the impression that, for example with Tony's Option blog entry, a few examples might open a window into a new and more elegant world.

View your other email accounts from your Hotmail inbox. Add them now.

I don't disparage people, only bad ideas, though I don't know where you refer to. Further you have misunderstood my position on the matter of abstraction on many levels. I'm also aware that it is widely misunderstood topic.
How odd. I wonder what you are talking about. Have a nice day.

Tony Morrishttp://tmorris.net/

On Dec 25, 2009, at 1:25 AM, Alex Boisvert <alex.boisvert@gmail.com> wrote:

Tony,

I understand you regard FP as the one true way to build abstraction but understand that FP does not have a monopoly on abstraction and that they are many other ways to achieve it, each with their own set of tradeoffs.    FP abstraction scales nicely in the way of mathematical concepts but other abstraction mechanisms (such as object-orientation) have benefits in other areas.  For instance, there are good research papers now that demonstrate how Scala, with its mix of OO + FP, offers more elegant/expressive solutions to some computing challenges.  You may continue to ignore these but please do not disparage people who do not share your viewpoint.

regards,
alex

On Wed, Dec 23, 2009 at 2:18 PM, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:

The aversion to abstraction has always baffled me.

Alex Boisvert wrote:
> Yes, I'm aware of that and while I do appreciate Scalaz, it's like
> jumping to a parallel universe -- warping between dimensions can be
> exhausting ;)
>
> My preference would be to improve the convenience of the standard
> Option trait.
>
> alex
>
> On Wed, Dec 23, 2009 at 11:59 AM, Tony Morris < (tonymorris [at] gmail [dot] com
> <mailto: (tonymorris [at] gmail [dot] com>> wrote:
>
>     Scalaz has many of your "shortenings" by virtue of the fact that
>     Option
>     is a Functor, Monad and has three different Monoids.
>
>     Alex Boisvert wrote:
>     > Personally, I would be completely happy with Option iif,
>     >
>     > 1) there were implicit boxing functions in Predef from (T <: AnyRef
>     > with NonNull) and (T <: AnyVal) to Some[T]
>     >
>     > (you could still write Some(null) explicitly if that's what you
>     really
>     > want -- caveat emptor)
>     >
>     > 2) the Scala compiler properly inferred NonNull for all non-null
>     > AnyRef literals
>     >
>     > 3) we had the "!" operator on Option to shorten foreach
>     >
>     > someOption ! _.doSomething
>     >
>     > 4) we had the "*" operator on Option to shorten map/flatMap
>     >
>     > val result = someOption * _.computeSomething
>     >
>     > 5) we had a "?" operator on Option to shorten map/flatMap ....
>     getOrElse
>     >
>     > val result = someOption ? (_.computeSomething) (somethingElse)
>     >
>     > 6) we had a "|" operator on Option to return the first Some
>     value (or
>     > None if no Some
>     >
>     > val firstSome: Option[T] = someOption | someOtherOption |
>     defaultValue
>     >
>     > Notice how I didn't have to write Some(defaultValue) ;)
>     >
>     > 7) (bonus points) we had a "+" operator for T <% Monoid[T] to
>     flatMap
>     > multiple monoids.
>     >
>     > val result: Option[T <% Monoid[T]] = someOption + anotherOption +
>     > yetAnotherOption
>     >
>     > This would cover 99+% of my very-frequently-used Option code, would
>     > make Option very pleasant to use and I wouldn't have to worry
>     about my
>     > PowerOption implicit conversions eating up CPU cycles.
>     >
>     > Power (Option) to the People!!
>     >
>     > alex
>     >
>     >
>
>     --
>     Tony Morris
>     http://tmorris.net/
>
>
>

--
Tony Morris
http://tmorris.net/

2009/12/25 Tony Morris <tonymorris@gmail.com>

Tony Morrishttp://tmorris.net/

On Dec 25, 2009, at 5:07 AM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

2009/12/24 Tony Morris <tonymorris@gmail.comtonymorris@gmail.com>

Have some fun.

Loading initrepl...
import scalaz._
import scalaz.Scalaz._

Welcome to Scala version 2.8.0.r20247-b20091220020228 (Java HotSpot(TM)
Server VM, Java 1.6.0_17).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val s: Option[Int] = Some(7)
s: Option[Int] = Some(7)

scala> val n: Option[Int] = None
n: Option[Int] = None

scala> s ∘ (1+) // map
res0: Option[Int] = Some(8)

scala> s ∘ (1+) // map
res2: Option[Int] = Some(8)

 Why would you use '∘' instead of 'map'? Isn't that a domain specific already?

Because it is a generalisation of map. Function composition (which is what the character means in denotational semantics) is the map of Function1. Take a look at the type signature of scala.Function1.compose and see if you can make it out.  

Ahhh, I started recently to realise that types where functions and this one was just under my nose.

scala> s ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res3: Option[Int] = Some(14)

This construct is useful too:

for (n <- s if n > 5) yield (n * 2)

Useful, but a different computation.

But even more reusable!

Why use '∗' instead of haskellish '>>='? Is '∗' known elsewhere? And how do you write these symbols in a convenient manner using a standard keyboard?

The symbol is from a Wadler paper iirc. I use operating environments that don't make typing difficult (with the exception of the device I am using right now -- I err). In any case all Unicode symbols have or will have ASCII aliases.
The composition operator is a special case because I have long held that "map" has far too many characters (by 300%!) that can be very distracting for some people.

Maybe an WYSIWYG IDE could just infer on the fly the conversion from map to '∘' or flatmap to '∗' depending on the evaluation context.

 

scala> n ∗ (n => if(n > 5) Some(n * 2) else None) // flatMap
res4: Option[Int] = None

scala> s ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res5: Option[Int] = Some(14)

scala> val s2: Option[Int] = Some(3)
s2: Option[Int] = Some(3)

scala> s2 ∗ (z => if(z > 5) Some(z * 2) else None) // flatMap
res6: Option[Int] = None

scala> s | 9 // getOrElse
res7: Int = 7

scala> n | 9 // getOrElse
res9: Int = 9

 

scala> val s3: Option[Option[Int]] = Some(Some(4))
s3: Option[Option[Int]] = Some(Some(4))

 I'd rather avoid to ever have to wrap an option in another option. Does that make sense in practice?

Yes. Join is a very fundamental monad operation. I'd elaborate if not for the limitations of this device sorry.

Ok. I was just wondering what would be the meaning of Some(None)

scala> s3 μ // join/flatten
res10: Option[Int] = Some(4)

scala> val s4: Option[Option[Int]] = Some(None)
s4: Option[Option[Int]] = Some(None)

scala> s4 μ // join/flatten
res11: Option[Int] = None

I find the '|' operator is very expressive but here I find 'flatten' simply more expressive than 'μ' or join.

I find the distinction quite cumbersome. Nevertheless join is so rudimentary the it deserves it's own operator. The mu symbol is used in denotational semantics.
See Agda for some inspiration.

I will.

Many thanks,
Sebastien

Cheers,
Sebastien
 

scala> val s5: Option[Option[Int]] = None
s5: Option[Option[Int]] = None

scala> s5 μ // join/flatten
res12: Option[Int] = None

scala> s ➡ println // foreach
7

scala> n ➡ println // foreach

scala>

There is nothing particularly special here except that:
a) Many of these functions are defined once.
b) Many of these functions are not specific to Option.
c) There are many more interesting functions just like it, but they have
no equivalent in the standard library.

scala> List(1, 2, 3) ∘ (1+)
res15: List[Int] = List(2, 3, 4)


Alex Boisvert wrote:
> On Wed, Dec 23, 2009 at 5:43 PM, Randall R Schulz <rschulz@sonic.netrschulz@sonic.net
> <mailto:rschulz@sonic.netrschulz@sonic.net>> wrote:
>
>     On Wednesday December 23 2009, Alex Boisvert wrote:
>     > On Wed, Dec 23, 2009 at 4:42 PM, Rex Kerr <ichoran@gmail.comichoran@gmail.com
>     <mailto:ichoran@gmail.comichoran@gmail.com>> wrote:
>     > > ...
>     >
>     > >> 3) we had the "!" operator on Option to shorten foreach
>     > >>
>     > >> someOption ! _.doSomething
>     > >
>     > > This is a bad idea for any standard package.  It's hard enough
>     > > having ! mean "boolean not" and "send message to actor" without it
>     > > meaning "foreach" also.
>     >
>     > I use "!" here exactly because it means "send a message", with the
>     > recipient being the value of the Option.  OO is all about messaging
>     > sending and so from my POV, this makes a lot of sense.
>
>     Even in the SmallTalk era, object-oriented programming was about
>     much more than message-sending! I personally have never liked the
>     presentation of method or member function invocation as "message
>     passing."
>
>
> Well, I'm not going to be dragged into a bike shed discussion on
> method naming but I'll mention that I've picked operators because they
> are short (shorter than method names) and because you can use
> shorthand assignment with var's.
>
> var foo: Option[_] = ...
>
> foo *= (_.computeSomething)
> foo |= defaultOption
> foo += someOption
>
> At this point, I'd be happier have any operator adopted than to have
> my exact choice of operators selected.
>
> alex

--
Tony Morris
http://tmorris.net/

I for one would invest in many a repeat read. Tuned and eagerly awaiting. (Not quite salivating but not far off)

On Dec 25, 2009 1:46 AM, "Tony Morris" <tonymorris@gmail.com> wrote:

I am strongly considering writing a "user manual" to appease this problem. Stay tuned.

Tony Morris http://tmorris.net/

On Dec 25, 2009, at 12:38 AM, christopher marshall <oxbow_lakes@hotmail.com> wrote: > > Date: Thu,...

I believe abstraction can help enormously but can also be overdone. And everyone has a different limit where more abstraction hurts rather than helps. For instance for me category theory is over the limit but for some others it's fine.
 -- Martin

Sent from my iPhone
On Dec 24, 2009, at 16:25, Alex Boisvert <alex.boisvert@gmail.com> wrote:

Tony,

I understand you regard FP as the one true way to build abstraction but understand that FP does not have a monopoly on abstraction and that they are many other ways to achieve it, each with their own set of tradeoffs.    FP abstraction scales nicely in the way of mathematical concepts but other abstraction mechanisms (such as object-orientation) have benefits in other areas.  For instance, there are good research papers now that demonstrate how Scala, with its mix of OO + FP, offers more elegant/expressive solutions to some computing challenges.  You may continue to ignore these but please do not disparage people who do not share your viewpoint.

regards,
alex

On Wed, Dec 23, 2009 at 2:18 PM, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:

The aversion to abstraction has always baffled me.

Alex Boisvert wrote:
> Yes, I'm aware of that and while I do appreciate Scalaz, it's like
> jumping to a parallel universe -- warping between dimensions can be
> exhausting ;)
>
> My preference would be to improve the convenience of the standard
> Option trait.
>
> alex
>
> On Wed, Dec 23, 2009 at 11:59 AM, Tony Morris < (tonymorris [at] gmail [dot] com
> <mailto: (tonymorris [at] gmail [dot] com>> wrote:
>
>     Scalaz has many of your "shortenings" by virtue of the fact that
>     Option
>     is a Functor, Monad and has three different Monoids.
>
>     Alex Boisvert wrote:
>     > Personally, I would be completely happy with Option iif,
>     >
>     > 1) there were implicit boxing functions in Predef from (T <: AnyRef
>     > with NonNull) and (T <: AnyVal) to Some[T]
>     >
>     > (you could still write Some(null) explicitly if that's what you
>     really
>     > want -- caveat emptor)
>     >
>     > 2) the Scala compiler properly inferred NonNull for all non-null
>     > AnyRef literals
>     >
>     > 3) we had the "!" operator on Option to shorten foreach
>     >
>     > someOption ! _.doSomething
>     >
>     > 4) we had the "*" operator on Option to shorten map/flatMap
>     >
>     > val result = someOption * _.computeSomething
>     >
>     > 5) we had a "?" operator on Option to shorten map/flatMap ....
>     getOrElse
>     >
>     > val result = someOption ? (_.computeSomething) (somethingElse)
>     >
>     > 6) we had a "|" operator on Option to return the first Some
>     value (or
>     > None if no Some
>     >
>     > val firstSome: Option[T] = someOption | someOtherOption |
>     defaultValue
>     >
>     > Notice how I didn't have to write Some(defaultValue) ;)
>     >
>     > 7) (bonus points) we had a "+" operator for T <% Monoid[T] to
>     flatMap
>     > multiple monoids.
>     >
>     > val result: Option[T <% Monoid[T]] = someOption + anotherOption +
>     > yetAnotherOption
>     >
>     > This would cover 99+% of my very-frequently-used Option code, would
>     > make Option very pleasant to use and I wouldn't have to worry
>     about my
>     > PowerOption implicit conversions eating up CPU cycles.
>     >
>     > Power (Option) to the People!!
>     >
>     > alex
>     >
>     >
>
>     --
>     Tony Morris
>     http://tmorris.net/
>
>
>

--
Tony Morris
http://tmorris.net/

Why?

Martin Odersky wrote:
> I believe abstraction can help enormously but can also be overdone.
> And everyone has a different limit where more abstraction hurts rather
> than helps. For instance for me category theory is over the limit but
> for some others it's fine.
>

On Saturday December 26 2009, Tony Morris wrote:
> Martin Odersky wrote:
> > I believe abstraction can help enormously but can also be overdone.
> > ...
> >
> > -- Martin
>
> Why?

Because. (<-- Note maximally abstract answer.)

RRS

Randall Schulz wrote:
>
> Because. (<-- Note maximally abstract answer.)
>

Aww, an angel just got its wings.

I once I had a Fields-medal contender mathematician describe category theory
to me as "abstract theoretical nonsense". I think he was wrong, but never
forget what he said.

--Dave Griffith

Dave Griffith wrote:
>
> Randall Schulz wrote:
>
>> Because. (<-- Note maximally abstract answer.)
>>
>>
>
> Aww, an angel just got its wings.
>
> I once I had a Fields-medal contender mathematician describe category theory
> to me as "abstract theoretical nonsense". I think he was wrong, but never
> forget what he said.
>
>

From wikipedia: "Category theory has several faces known not just to
specialists, but to other mathematicians. A term dating from the 1940s,
"general abstract nonsense", refers to its high level of abstraction,
compared to more classical branches of mathematics."

The phrase in quotes links to its own wikipedia entry which begins:

'In mathematics , *abstract
nonsense*, *general abstract nonsense*, and *general nonsense* are terms
used facetiously by mathematicians
to describe certain kinds
of arguments and methods related to category theory
. Roughly speaking,
category theory is the study of the general form of mathematical
theories, without regard to their content. As a result, a proof
that relies on
category theoretic ideas often seems slightly out of context, sometimes
to the extent that it resembles a comical non sequitur
. Such proofs are dubbed
“abstract nonsense”.

'More generally, “abstract nonsense” may refer to any proof (humorous or
not) that uses primarily category theoretic methods, or even to the
study of category theory itself.'

Note the use of the term "facetiously".

Cheers,

Eric

Eric Schwarzenbach wrote:
> 'In mathematics , *abstract
> nonsense*, *general abstract nonsense*, and *general nonsense* are terms
> used facetiously by mathematicians
> to describe certain kinds
> of arguments and methods related to category theory
> . Roughly speaking,
> category theory is the study of the general form of mathematical
> theories, without regard to their content. As a result, a proof
> that relies on
> category theoretic ideas often seems slightly out of context, sometimes
> to the extent that it resembles a comical non sequitur
> . Such proofs are dubbed
> “abstract nonsense”.
>
Gack. Sorry about the ugliness of the unnecessarily included links. I
forgot the use the maddeningly non-default "paste without formatting" on
that bit.

Tony Morris-4 wrote:
>
> Why?
>

Probably because "everyone has a different limit where more abstraction
hurts rather than helps". If an abstraction involves a concept that you
don't understand the abstraction hurts your understanding of the code.

Different people can learn concepts at different speed. If it takes you a
short time to understand a concept and now can use abstractions based on
that concept than good for you. If you get something quickly it's oftentimes
fun to learn it because you are somehow "rewarded" by this Aha-moment.

Somebody else might take a lot longer to finally grasp a certain concept and
for that person it's perhaps not feasible to invest that much time into
learning the concept. If you try to understand something and just don't get
it at some point you stop to enjoy learning it. And unless you really have
to learn something you don't enjoy you probably wont.