1+"a" vs "a"+1

On Wed, Aug 3, 2011 at 15:51, eptx wrote:
> Seems like these should return the same type? What's the implication of
> String vs. java.lang.String return type?
>
> scala> :type 1+"a"
> String
>
> scala> :type "a"+1
> java.lang.String
>
> scala> 1+"a"
> res5: String = 1a
>
> scala> "a"+1
> res6: java.lang.String = a1

I wonder why this keeps arising all of a sudden. It's pretty simple, actually.

On scala.Predef, there's a type String = ..., which is used so that
various methods can refer to String without binding themselves to the
underlying implementation (java.lang.String on JVM). So methods that
return String will show up in REPL as returning "String". On the other
hand, Java methods will return java.lang.String, and string literals
will be java.lang.String as well. For example:

scala> "abc" substring 1 // Java method
res12: java.lang.String = bc

scala> "abc" drop 1 // Scala method
res13: String = bc

For the first expression, + is a method defined on Int, see http://www.scala-lang.org/api/current/scala/Int.html

def+ (x: String): String

 

for the second, an Eclipse hover reveals that it is

 

final def + (x$1:Any) => java.lang.String

 

This must be the default + on strings from java. Since Java cannot define operators, I wonder where this is defined – couldn’t figure out…

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of eptx
Sent: August-03-11 2:51 PM
To: scala-user@googlegroups.com
Subject: [scala-user] 1+"a" vs "a"+1

 

Seems like these should return the same type? What's the implication of String vs. java.lang.String return type?

scala> :type 1+"a"
String

scala> :type "a"+1
java.lang.String

scala> 1+"a"
res5: String = 1a

scala> "a"+1
res6: java.lang.String = a1

On Thu, Aug 4, 2011 at 14:10, Razvan Cojocaru wrote:
>
> This must be the default + on strings from java. Since Java cannot define
> operators, I wonder where this is defined – couldn’t figure out…

This is defined in the language itself. Java, as opposed to Scala,
don't mind making
special cases for its library that no user class can reproduce.

It arises regularly because it  violates the expectations of the curious and untainted.

Ideally both would be a type error, and even more ideally, + reserved for commutative operations (abelian semigroup).

On 04/08/2011 7:09 AM, "Daniel Sobral" <dcsobral@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 15:51, eptx <coach3pete@gmail.com> wrote:
>> Seems like these should return the same type? What's the implication of
>> String vs. java.lang.String return type?
>>
>> scala> :type 1+"a"
>> String
>>
>> scala> :type "a"+1
>> java.lang.String
>>
>> scala> 1+"a"
>> res5: String = 1a
>>
>> scala> "a"+1
>> res6: java.lang.String = a1
>
> I wonder why this keeps arising all of a sudden. It's pretty simple, actually.
>
> On scala.Predef, there's a type String = ..., which is used so that
> various methods can refer to String without binding themselves to the
> underlying implementation (java.lang.String on JVM). So methods that
> return String will show up in REPL as returning "String". On the other
> hand, Java methods will return java.lang.String, and string literals
> will be java.lang.String as well. For example:
>
> scala> "abc" substring 1 // Java method
> res12: java.lang.String = bc
>
> scala> "abc" drop 1 // Scala method
> res13: String = bc
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

Still, couldn't figure out where this is defined for the scala compiler. I don't suppose it is hardcoded the way it must be in the Java compiler, so I was looking for the file that defines it :) but could find such a thing - still a mystery for me...

Thanks,
Razvan

On 2011-08-04, at 5:24 PM, Daniel Sobral wrote:

> On Thu, Aug 4, 2011 at 14:10, Razvan Cojocaru wrote:
>>
>> This must be the default + on strings from java. Since Java cannot define
>> operators, I wonder where this is defined – couldn’t figure out…
>
> This is defined in the language itself. Java, as opposed to Scala,
> don't mind making
> special cases for its library that no user class can reproduce.
>

On Thu, Aug 4, 2011 at 19:04, Razvan Cojocaru wrote:
> Still, couldn't figure out where this is defined for the scala compiler. I don't suppose it is hardcoded the way it must be in the Java compiler, so I was looking for the file that defines it :) but could find such a thing - still a mystery for me...

Well, actually, it is -- to make it familiar to Java programmers. This
is one of the decisions that Odersky isn't so sure of nowadays, but,
at this point, there's no way to go back.

BUT, one can add a "+" method to a class in Scala. The specific case
of String is hard-coded because String isn't a Scala class.

>
> Thanks,
> Razvan
>
> On 2011-08-04, at 5:24 PM, Daniel Sobral wrote:
>
>> On Thu, Aug 4, 2011 at 14:10, Razvan Cojocaru wrote:
>>>
>>> This must be the default + on strings from java. Since Java cannot define
>>> operators, I wonder where this is defined – couldn’t figure out…
>>
>> This is defined in the language itself. Java, as opposed to Scala,
>> don't mind making
>> special cases for its library that no user class can reproduce.
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>

So why is it defined as returning java.lang.String and not Predef's alias?

On Thu, Aug 4, 2011 at 5:24 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

On Thu, Aug 4, 2011 at 14:10, Razvan Cojocaru <pub@razie.com> wrote:
>
> This must be the default + on strings from java. Since Java cannot define
> operators, I wonder where this is defined – couldn’t figure out…

This is defined in the language itself. Java, as opposed to Scala,
don't mind making
special cases for its library that no user class can reproduce.

--
Daniel C. Sobral

I travel to the future all the time.

On Thu, Aug 4, 2011 at 2:48 PM, Tony Morris wrote:
> It arises regularly because it  violates the expectations of the curious and
> untainted.
> Ideally both would be a type error, and even more ideally, + reserved for
> commutative operations (abelian semigroup).

+1

(painful memories of when people first overloaded "+" to mean some
arbitrary thing for every bloody possible type in C++ projects.)

I wish that there wasn't a globally-scoped implicit conversion from everything to String. Without this, the '+' on String would be fairly well-behaved. As it is, about once a week I get unexpected results because + has coerced things into being Strings when what I wanted and needed was a compile-time error telling me I'd done something stupid.
Matthew

On 5 August 2011 05:59, Raoul Duke <raould@gmail.com> wrote:

On Thu, Aug 4, 2011 at 2:48 PM, Tony Morris <tmorris@tmorris.net> wrote:
> It arises regularly because it  violates the expectations of the curious and
> untainted.
> Ideally both would be a type error, and even more ideally, + reserved for
> commutative operations (abelian semigroup).

+1

(painful memories of when people first overloaded "+" to mean some
arbitrary thing for every bloody possible type in C++ projects.)

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozertel: (0191) 2566550mob: +447535664143

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you are happy to assume the language subset absent + then scalaz has
the remaining library support that is required plus much more.

On 06/08/11 01:22, Matthew Pocock wrote:
> I wish that there wasn't a globally-scoped implicit conversion from
> everything to String. Without this, the '+' on String would be fairly
> well-behaved. As it is, about once a week I get unexpected results because +
> has coerced things into being Strings when what I wanted and needed was a
> compile-time error telling me I'd done something stupid.
>
> Matthew
>
> On 5 August 2011 05:59, Raoul Duke wrote:
>
>> On Thu, Aug 4, 2011 at 2:48 PM, Tony Morris wrote:
>>> It arises regularly because it violates the expectations of the curious
>> and
>>> untainted.
>>> Ideally both would be a type error, and even more ideally, + reserved for
>>> commutative operations (abelian semigroup).
>>
>> +1
>>
>> (painful memories of when people first overloaded "+" to mean some
>> arbitrary thing for every bloody possible type in C++ projects.)
>>
>
>
>

----------------------------------------------------------------
Nie masz czym pisac? U nas to znajdziesz!
http://linkint.pl/f2a05

On Mon, Nov 7, 2011 at 10:06 AM, Mirco Dotta <mirco.dotta@gmail.com> wrote:

Hi Sandro,

Please, in the future use the scala-ide-user mailing list for Scala IDE (Eclipse)
related questions.

http://groups.google.com/group/scala-ide-user

For the record, this is a known issue and we have a ticket for it:

http://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000636

Luckily, we are working on it now and we should have a fix during the day.
Make sure to follow the ticket so that you get an update as soon as it is fixed.

Mats

Busted

On Tue, Jan 10, 2012 at 10:48 AM, <mats@henricson.se> wrote:

Mats

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang