Re: Traversable and foldRight/reduceRight/dropRight/takeRight

I'm going to be very narrow minded for a minute...

What's wrong with Integer.parseInt?  Why do we need a pimped toInt on String?

For those who don't want an exception when they try to parse a String that can't be converted to an integer, Predef or Utils or something could contain:
def atoi(s: String): Int = //  calls Integer.parseInt and returns 0 if an exception is thrown
def atoi(s: String, v: Int): Int = // return v is an exception is thrown

Strings are a really fundamental datatype.  They are parsed into about a trillion different things.  We can't toX for every one of them.  Why treat Int as special?

On Thu, May 14, 2009 at 2:50 PM, Paul Phillips <paulp@improving.org> wrote:

BTW I should mention for those of you who very sensibly don't hang out
on IRC all day talking about scala, the related conversation from
yesterday was about what to do about this ticket:

 http://lampsvn.epfl.ch/trac/scala/ticket/16

I am personally driven into a frenzy of annoyance by having to wrap up
"5".toInt even though my interest almost never goes beyond "did it work
or not?" (Noting for the record that ijuma says he almost always wants
to know why, so I guess that tells you something about our respective
approaches to error handling.)

Now if toInt returned Option[Int] I would be happy to write

 for (i <- "5".toInt) println(i)  or
 val num = "5".toInt getOrElse -42

Instead I end up constantly reimplementing clumsy exception handling.
In fact just looking around the scala stdlib I find:

 // SquareRoot.scala
 def toInt(s: String): Option[Int] =
   try { Some(s.toInt) } catch { case e: NumberFormatException => None }

 // Settings.scala - granted, I think I wrote this one
 def parseInt(x: String): Option[Int] =
   try   { Some(x.toInt) }
   catch { case _: NumberFormatException => None }

And a dozen or instances of

 case _: NumberFormatException =>

which means they threw away the exception to treat the situation as a
painfully verbose Option.

Yet adding toIntOpt/toFloatOpt/toAaaghOpt methods to RichString is a
non-starter for the same reasons I am so against reduceRightOption.

What we have here is a very general issue which must merit a nice
general standard solution which we can put to good work in the mainline
sources and be a shining beacon on the hill for the rest of the world.
On IRC we have the benefit of tony morris who would dazzle you with
slight of monadery and the oracle of kleisli and other wonders of the
ancients, but I'm just a simple country programmer who likes to stay dry
during the hurricanes.

 I have def f(s: String) = s.toInt and it is
   Function1[String,Int]

 Generalizing across the unexceptional Exception, it's actually
   Function1[String,Either[NumberFormatException,Int]]

 Ungeneralizing to the way I almost always want to use it, it's
   Function1[String,Option[Int]]

What I am hungry for is the lightest possible syntax that allows me all
those possibilities depending on what the occasion warrants.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Moral Alien        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
all hip pupils!    |     -- H. L. Mencken

--
http://erikengbrecht.blogspot.com/

On Thu, May 14, 2009 at 7:50 PM, Paul Phillips wrote:
>  I have def f(s: String) = s.toInt and it is
>    Function1[String,Int]
>
>  Generalizing across the unexceptional Exception, it's actually
>    Function1[String,Either[NumberFormatException,Int]]
>
>  Ungeneralizing to the way I almost always want to use it, it's
>    Function1[String,Option[Int]]
>
> What I am hungry for is the lightest possible syntax that allows me all
> those possibilities depending on what the occasion warrants.

At the risk of stating the obvious and wandering off topic, the
following _almost_ works,

def capture[X](implicit m : Manifest[X]) = new {
def apply[T](b : => T) : Either[X, T] = try {
Right(b)
} catch {
case e if m.erasure.isInstance(e) => Left(e.asInstanceOf[X])
}
}

Bending reality for a moment this would enable,

capture[NumberFormatException]("23".toInt)

for your second case and,

capture[NumberFormatException]("23".toInt).right

for the third.

Unfortunately reality doesn't bend so easily and what we actually get is,

scala> capture[NumberFormatException]("23".toInt)
:7: error: type mismatch;
found : Int
required: scala.reflect.Manifest[NumberFormatException]
capture[NumberFormatException]("23".toInt)

because the initial implicit argument list isn't discharged before the
compiler runs into the second.

Is there anything we could do about that for 2.8.0?

Cheers,

Miles