Implicits bug (or feature?)

[Tim Azzopardi]

Latest nightly snapshot 2.8

I don't think the code below should compile, if SomeOtherPersonOrderingObjectInadvertentlyImported is commented back in as there is an ambiguous implicit. But it compiles and changes the behaviour of:

people.sortBy(person => person)

to use SomeOtherPersonOrderingObjectInadvertentlyImported rather than the "natural" ordering provided through the Ordered[Person] defined on People.

I think the compiler should say that there is an ambiguous implicit parameter available for

people.sortBy(person => person) .

But it doesn't.





import org.scala_tools.time.Imports._

object TestSortBy {
  case class Person(firstName: String, lastName: String, dateOfBirth: DateTime)
    extends Ordered[Person]
  {
    override def toString() = {
      firstName + ", " + lastName + " " + DateTimeFormat.shortDate().print(dateOfBirth);
    }
    def compare(otherPerson: Person) = {
      lastName.compareTo(otherPerson.lastName)
    }
  }

  // Comment this is and watch the behaviour change. This could be imported accidentally
  // implicit object SomeOtherPersonOrderingObjectInadvertentlyImported
  //   extends Ordering[Person] {
  //   def compare(p1: Person, p2: Person) =
  //    (p1.firstName+p1.lastName).compareTo(p2.firstName+p2.lastName)
  // }

 
  def main(args : Array[String]) : Unit = {
   
    val people =
      Person("Alan", "Kay", new DateTime(1973,12,1,0,0,0,0))::
      Person("James", "Gosling", new DateTime(1991,12,1,0,0,0,0))::
      Person("Anders", "Hejlsberg", new DateTime(1999,12,1,0,0,0,0))::
      Person("Martin", "Odersky", new DateTime(2000,12,1,0,0,0,0))::
      Person("Guido", "Van Rossum", new DateTime(2002,12,1,0,0,0,0))::
      Person("Yukihiro", "Matsumoto", new DateTime(1990,12,1,0,0,0,0))::Nil
   
   
    val peopleOrderedNaturally = people.sortWith((p1,p2) => p1 < p2)
    peopleOrderedNaturally foreach println
    println

    val peopleOrderedNaturallyWithSortBy = people.sortBy(person => person)
    peopleOrderedNaturallyWithSortBy foreach println
    println    

  }

}

[Tim Azzopardi]

Apologies for cross post, I was having trouble with Nabble and thought I was not subscribed o Scala

[Tim Azzopardi]

Apologies for cross post, I was having trouble with Nabble and thought I was not subscribed o Scala

[Tim Azzopardi]

I'm guessing that this a feature due to the scope in which I have put the implict object. If I put the implicit object where it is in the code below, then I am saying I want to override the Person extends Ordered[Person] natural ordering. I assume that is why the compiler does not complain about an ambiguous implicit. (This seems powerful but also terrifying in a very similar way to aop.)

Tim Azzopardi wrote:

Latest nightly snapshot 2.8

I don't think the code below should compile, if SomeOtherPersonOrderingObjectInadvertentlyImported is commented back in as there is an ambiguous implicit. But it compiles and changes the behaviour of:

people.sortBy(person => person)

to use SomeOtherPersonOrderingObjectInadvertentlyImported rather than the "natural" ordering provided through the Ordered[Person] defined on People.

I think the compiler should say that there is an ambiguous implicit parameter available for

people.sortBy(person => person) .

But it doesn't.





import org.scala_tools.time.Imports._

object TestSortBy {
  case class Person(firstName: String, lastName: String, dateOfBirth: DateTime)
    extends Ordered[Person]
  {
    override def toString() = {
      firstName + ", " + lastName + " " + DateTimeFormat.shortDate().print(dateOfBirth);
    }
    def compare(otherPerson: Person) = {
      lastName.compareTo(otherPerson.lastName)
    }
  }

  // Comment this is and watch the behaviour change. This could be imported accidentally
  // implicit object SomeOtherPersonOrderingObjectInadvertentlyImported
  //   extends Ordering[Person] {
  //   def compare(p1: Person, p2: Person) =
  //    (p1.firstName+p1.lastName).compareTo(p2.firstName+p2.lastName)
  // }

 
  def main(args : Array[String]) : Unit = {
   
    val people =
      Person("Alan", "Kay", new DateTime(1973,12,1,0,0,0,0))::
      Person("James", "Gosling", new DateTime(1991,12,1,0,0,0,0))::
      Person("Anders", "Hejlsberg", new DateTime(1999,12,1,0,0,0,0))::
      Person("Martin", "Odersky", new DateTime(2000,12,1,0,0,0,0))::
      Person("Guido", "Van Rossum", new DateTime(2002,12,1,0,0,0,0))::
      Person("Yukihiro", "Matsumoto", new DateTime(1990,12,1,0,0,0,0))::Nil
   
   
    val peopleOrderedNaturally = people.sortWith((p1,p2) => p1 < p2)
    peopleOrderedNaturally foreach println
    println

    val peopleOrderedNaturallyWithSortBy = people.sortBy(person => person)
    peopleOrderedNaturallyWithSortBy foreach println
    println    

  }

}

[Martin Odersky]

On Thu, Nov 5, 2009 at 7:28 PM, Tim Azzopardi <tim@...> wrote:
>
> I'm guessing that this a feature due to the scope in which I have put the
> implict object. If I put the implicit object where it is in the code below,
> then I am saying I want to override the Person extends Ordered[Person]
> natural ordering. I assume that is why the compiler does not complain about
> an ambiguous implicit. (This seems powerful but also terrifying in a very
> similar way to aop.)
>
That almost right, yes. Implicits that are explicitly declared or
imported take precedence over implicits that come with the type. Btw
you can find out what implicits are inserted by running scalac wigth
option -Xprint:typer. This will print out the tree after type
checking.

Cheers

 -- Martin

[Tim Azzopardi]

Thanks for the explanation. I find for potential accidental behavioural
change implications worrying. If I import a (perhaps poorly written) library
that overlaps with a domain from another library say. Maybe I have not experimented with
it enough to understand the practicalities. Would some sort of explicit override
declaration make any sense at or near the point-of-use  or the import without
which an ambiguous implicit error would occur?
Cheers

Martin Odersky wrote:

On Thu, Nov 5, 2009 at 7:28 PM, Tim Azzopardi <[e-mail]> wrote:
>
> I'm guessing that this a feature due to the scope in which I have put the
> implict object. If I put the implicit object where it is in the code below,
> then I am saying I want to override the Person extends Ordered[Person]
> natural ordering. I assume that is why the compiler does not complain about
> an ambiguous implicit. (This seems powerful but also terrifying in a very
> similar way to aop.)
>
That almost right, yes. Implicits that are explicitly declared or
imported take precedence over implicits that come with the type. Btw
you can find out what implicits are inserted by running scalac wigth
option -Xprint:typer. This will print out the tree after type
checking.

Cheers

 -- Martin

[Martin Odersky]

On Thu, Nov 5, 2009 at 10:15 PM, Tim Azzopardi <tim@...> wrote:

>
> Thanks for the explanation. I find for potential accidental behavioural
> change implications worrying. If I import a (perhaps poorly written) library
> that overlaps with a domain from another library say. Maybe I have not
> experimented with
> it enough to understand the practicalities. Would some sort of explicit
> override
> declaration make any sense at or near the point-of-use  or the import
> without
> which an ambiguous implicit error would occur?

Maybe. But I do not know what would be a feasible and clean way to do it.

Cheers

 -- Martin

> Cheers
>
>
> Martin Odersky wrote:
>>
>> On Thu, Nov 5, 2009 at 7:28 PM, Tim Azzopardi <tim@...> wrote:
>>>
>>> I'm guessing that this a feature due to the scope in which I have put the
>>> implict object. If I put the implicit object where it is in the code
>>> below,
>>> then I am saying I want to override the Person extends Ordered[Person]
>>> natural ordering. I assume that is why the compiler does not complain
>>> about
>>> an ambiguous implicit. (This seems powerful but also terrifying in a very
>>> similar way to aop.)
>>>
>> That almost right, yes. Implicits that are explicitly declared or
>> imported take precedence over implicits that come with the type. Btw
>> you can find out what implicits are inserted by running scalac wigth
>> option -Xprint:typer. This will print out the tree after type
>> checking.
>>
>> Cheers
>>
>>  -- Martin
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Implicits-bug-%28or-feature-%29-tp26213631p26222272.html
> Sent from the Scala mailing list archive at Nabble.com.
>
>