Changing the way implicits scope (and associated ideas)

[David MacIver]

This email is more of a brain dump than a concrete proposal. It may be
that this is a terrible idea, but I'd like to hear what other people
think of it and possibly be convinced that it's a terrible idea. :-)
Or it may be that even if it's a good idea no one other than me cares
and/or it's too much work to implement.

The way implicit scoping works currently bothers me. In particular the
way they are shadowed.

I'd like to change the behaviour so that implicits are shadowed by
type and not by name. Take the following example:

object Foo{
  implicit val bar : Bar = stuff;

  def thingy = {
     val bar : Bar = otherstuff;

     implicitly[Bar]; // compiler error because the local bar shadows
the implicit bar
  }
}

(implicitly is a function I often define for demoing these things.
It's def implicitly[T](implicit t : T) = t; So it gives the implicit
value of T currently in scope)

What I'd instead like to happen is

object Foo{
  implicit val bar : Bar = stuff;

  def thingy = {
     val bar : Bar = otherstuff;

     assert (implicitly[Bar] == stuff);
     assert bar == otherstuff
  }
}

So the local variable shadows the identifier but not the implicit.

Here's another example of where the behaviour is contrary to what I'd
like (it bothers me less, but I feel this would help consistency):

object Foo{
  implicit val bar : Bar = stuff;

  def thingy = {
     implicit val squirrel : Bar = otherstuff;

     assert (implicitly[Bar] == otherstuff);  // Instead get compiler
error due to ambiguous implicit value
     assert (bar == stuff)
     assert (squirrel == otherstuff)
  }
}


So what I'd like is that the fact that squirrel is implicitly Bar
shadows the fact that bar is, but does not shadow the identifier for
bar.

Both these behaviours seem wrong to me. They force you to care about
the name of the implicit, which seems counter to their purpose.

Moreover, there are a few cases where this is actively harmful. For
example, I've run into this issue a number of times when trying to use
objects as modules style programming. i.e. I have some class which
describes a module signature, and objects extending it are modules (an
example I've speculated about for this is retargetable SBinary
backends - e.g one using Java serialization, one using the current
approach). But I can't usefully use implicits on this and use multiple
instances of these at once, because if I have two in scope the
implicits of one will shadow the implicits of the other.

Does this make sense? Does it seem useful to you? It just seems like
much saner behaviour to me.

Other things I'd like on top of this (but which are not required for
the basic proposal to make sense):

Have implicitly as a compiler builtin. Possibly reusing the implicit
keyword. So implicit[T] would be an expression evaluating to the
implicit value of T currently in scope. You would additionally be
allowed to do:

 - myObject.implicit[Foo] (equivalent to { import myObject._; implicit[Foo] }
 - import myObject.implicit[Foo] // brings only the fact that Foo is
available implicitly into scope, not the identifier for Foo.

Allow implicits with no identifier. e.g.

implicit val = "jimbob"

(Possibly this might look better as val implicit = "jimbob" ? Not sure)

This would create an implicit but no name for it. The availability of
the implicit would scope as above, but you wouldn't be able to access
it by identifier. This would mainly be useful for weirdo projects like
SBinary and ScalaCheck where you define a large number of implicit
values for different types and it's generally very unlikely that you'd
want to access them by name.

Thoughts? Comments? Random abuse?

[Erik Engbrecht]

Hmmmm...random abuse...

 

How dare you post such drivel to this list!!!

 

Actually my initial reaction is that I'm with you on shadowing, and I agree this is a worthwhile problem to ponder.

 

I'd like compiler warnings when I have to implicitis with the same signature, excluding name, in scope.

 

On 6/9/08, David MacIver <david.maciver@...> wrote:

This email is more of a brain dump than a concrete proposal. It may be
that this is a terrible idea, but I'd like to hear what other people
think of it and possibly be convinced that it's a terrible idea. :-)
Or it may be that even if it's a good idea no one other than me cares
and/or it's too much work to implement.

The way implicit scoping works currently bothers me. In particular the
way they are shadowed.

I'd like to change the behaviour so that implicits are shadowed by
type and not by name. Take the following example:

object Foo{
implicit val bar : Bar = stuff;

def thingy = {
    val bar : Bar = otherstuff;

    implicitly[Bar]; // compiler error because the local bar shadows
the implicit bar
}
}

(implicitly is a function I often define for demoing these things.
It's def implicitly[T](implicit t : T) = t; So it gives the implicit
value of T currently in scope)

What I'd instead like to happen is

object Foo{
implicit val bar : Bar = stuff;

def thingy = {
    val bar : Bar = otherstuff;

    assert (implicitly[Bar] == stuff);
    assert bar == otherstuff
}
}

So the local variable shadows the identifier but not the implicit.

Here's another example of where the behaviour is contrary to what I'd
like (it bothers me less, but I feel this would help consistency):

object Foo{
implicit val bar : Bar = stuff;

def thingy = {
    implicit val squirrel : Bar = otherstuff;

    assert (implicitly[Bar] == otherstuff);  // Instead get compiler
error due to ambiguous implicit value
    assert (bar == stuff)
    assert (squirrel == otherstuff)
}
}


So what I'd like is that the fact that squirrel is implicitly Bar
shadows the fact that bar is, but does not shadow the identifier for
bar.

Both these behaviours seem wrong to me. They force you to care about
the name of the implicit, which seems counter to their purpose.

Moreover, there are a few cases where this is actively harmful. For
example, I've run into this issue a number of times when trying to use
objects as modules style programming. i.e. I have some class which
describes a module signature, and objects extending it are modules (an
example I've speculated about for this is retargetable SBinary
backends - e.g one using Java serialization, one using the current
approach). But I can't usefully use implicits on this and use multiple
instances of these at once, because if I have two in scope the
implicits of one will shadow the implicits of the other.

Does this make sense? Does it seem useful to you? It just seems like
much saner behaviour to me.

Other things I'd like on top of this (but which are not required for
the basic proposal to make sense):

Have implicitly as a compiler builtin. Possibly reusing the implicit
keyword. So implicit[T] would be an expression evaluating to the
implicit value of T currently in scope. You would additionally be
allowed to do:

- myObject.implicit[Foo] (equivalent to { import myObject._; implicit[Foo] }
- import myObject.implicit[Foo] // brings only the fact that Foo is
available implicitly into scope, not the identifier for Foo.

Allow implicits with no identifier. e.g.

implicit val = "jimbob"

(Possibly this might look better as val implicit = "jimbob" ? Not sure)

This would create an implicit but no name for it. The availability of
the implicit would scope as above, but you wouldn't be able to access
it by identifier. This would mainly be useful for weirdo projects like
SBinary and ScalaCheck where you define a large number of implicit
values for different types and it's generally very unlikely that you'd
want to access them by name.

Thoughts? Comments? Random abuse?

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

[David MacIver]

On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
<erik.engbrecht@...> wrote:
> Hmmmm...random abuse...
>
> How dare you post such drivel to this list!!!
>
> Actually my initial reaction is that I'm with you on shadowing, and I agree
> this is a worthwhile problem to ponder.
>
> I'd like compiler warnings when I have to implicitis with the same
> signature, excluding name, in scope.

Hm. Can you clarify which circumstance you'd like a warning for? In
particular, are you saying that the circumstance I said should cause
shadowing of the implicit should actually be a warning?

I'm not convinced a warning for this would be useful either way. It's
already possible to have the same identifier in scope multiple times
and it's largely harmless. It's a compiler error when you try to use
it, not when you try to define it.

[Erik Engbrecht]

Yes, I'd like a warning when one implicit shadows another.  It could be an optional warning.

Actually, now that I think about it, what would be more useful would be if my IDE told me where implicits are being applied and which one is being applied in each location.  Some sort of hover-over or right-click operation.  

On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...> wrote:

On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
<erik.engbrecht@...> wrote:
> Hmmmm...random abuse...
>
> How dare you post such drivel to this list!!!
>
> Actually my initial reaction is that I'm with you on shadowing, and I agree
> this is a worthwhile problem to ponder.
>
> I'd like compiler warnings when I have to implicitis with the same
> signature, excluding name, in scope.

Hm. Can you clarify which circumstance you'd like a warning for? In
particular, are you saying that the circumstance I said should cause
shadowing of the implicit should actually be a warning?

I'm not convinced a warning for this would be useful either way. It's
already possible to have the same identifier in scope multiple times
and it's largely harmless. It's a compiler error when you try to use
it, not when you try to define it.

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

[David MacIver]

Hm. Changing the behaviour and then adding a warning for the new
behaviour seems bizarre to me. I'd rather either not have a warning or
stick with the current behaviour when you have multiple implicits for
the same type.

I don't feel very strongly that the suggested shadowing by type
behaviour is correct. The only part about the proposal I feel at all
strongly about is that implicits *shouldn't* shadow eachother by name.
Making them shadow by type just seems vaguely useful for redefining
implicits locally and is nicely symmetrical with the way shadowing by
name normally works.

On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht
<erik.engbrecht@...> wrote:

> Yes, I'd like a warning when one implicit shadows another.  It could be an
> optional warning.
> Actually, now that I think about it, what would be more useful would be if
> my IDE told me where implicits are being applied and which one is being
> applied in each location.  Some sort of hover-over or right-click operation.
>
>
> On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Hmmmm...random abuse...
>> >
>> > How dare you post such drivel to this list!!!
>> >
>> > Actually my initial reaction is that I'm with you on shadowing, and I
>> > agree
>> > this is a worthwhile problem to ponder.
>> >
>> > I'd like compiler warnings when I have to implicitis with the same
>> > signature, excluding name, in scope.
>>
>> Hm. Can you clarify which circumstance you'd like a warning for? In
>> particular, are you saying that the circumstance I said should cause
>> shadowing of the implicit should actually be a warning?
>>
>> I'm not convinced a warning for this would be useful either way. It's
>> already possible to have the same identifier in scope multiple times
>> and it's largely harmless. It's a compiler error when you try to use
>> it, not when you try to define it.
>
>
>
> --
> http://erikengbrecht.blogspot.com/

[Ricky Clarkson]

I fail to understand why someone would want a warning for something they're doing on purpose.

2008/6/10 David MacIver <david.maciver@...>:

Hm. Changing the behaviour and then adding a warning for the new
behaviour seems bizarre to me. I'd rather either not have a warning or
stick with the current behaviour when you have multiple implicits for
the same type.

I don't feel very strongly that the suggested shadowing by type
behaviour is correct. The only part about the proposal I feel at all
strongly about is that implicits *shouldn't* shadow eachother by name.
Making them shadow by type just seems vaguely useful for redefining
implicits locally and is nicely symmetrical with the way shadowing by
name normally works.

On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht

<erik.engbrecht@...> wrote:
> Yes, I'd like a warning when one implicit shadows another.  It could be an
> optional warning.
> Actually, now that I think about it, what would be more useful would be if
> my IDE told me where implicits are being applied and which one is being
> applied in each location.  Some sort of hover-over or right-click operation.
>
>
> On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Hmmmm...random abuse...
>> >
>> > How dare you post such drivel to this list!!!
>> >
>> > Actually my initial reaction is that I'm with you on shadowing, and I
>> > agree
>> > this is a worthwhile problem to ponder.
>> >
>> > I'd like compiler warnings when I have to implicitis with the same
>> > signature, excluding name, in scope.
>>
>> Hm. Can you clarify which circumstance you'd like a warning for? In
>> particular, are you saying that the circumstance I said should cause
>> shadowing of the implicit should actually be a warning?
>>
>> I'm not convinced a warning for this would be useful either way. It's
>> already possible to have the same identifier in scope multiple times
>> and it's largely harmless. It's a compiler error when you try to use
>> it, not when you try to define it.
>
>
>
> --
> http://erikengbrecht.blogspot.com/

[Viktor Klang]

On Tue, Jun 10, 2008 at 10:40 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

I fail to understand why someone would want a warning for something they're doing on purpose.

I can see it.
"You have been a very very naughty boy..."

 

2008/6/10 David MacIver <david.maciver@...>:

Hm. Changing the behaviour and then adding a warning for the new
behaviour seems bizarre to me. I'd rather either not have a warning or
stick with the current behaviour when you have multiple implicits for
the same type.

I don't feel very strongly that the suggested shadowing by type
behaviour is correct. The only part about the proposal I feel at all
strongly about is that implicits *shouldn't* shadow eachother by name.
Making them shadow by type just seems vaguely useful for redefining
implicits locally and is nicely symmetrical with the way shadowing by
name normally works.

On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht

<erik.engbrecht@...> wrote:
> Yes, I'd like a warning when one implicit shadows another.  It could be an
> optional warning.
> Actually, now that I think about it, what would be more useful would be if
> my IDE told me where implicits are being applied and which one is being
> applied in each location.  Some sort of hover-over or right-click operation.
>
>
> On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Hmmmm...random abuse...
>> >
>> > How dare you post such drivel to this list!!!
>> >
>> > Actually my initial reaction is that I'm with you on shadowing, and I
>> > agree
>> > this is a worthwhile problem to ponder.
>> >
>> > I'd like compiler warnings when I have to implicitis with the same
>> > signature, excluding name, in scope.
>>
>> Hm. Can you clarify which circumstance you'd like a warning for? In
>> particular, are you saying that the circumstance I said should cause
>> shadowing of the implicit should actually be a warning?
>>
>> I'm not convinced a warning for this would be useful either way. It's
>> already possible to have the same identifier in scope multiple times
>> and it's largely harmless. It's a compiler error when you try to use
>> it, not when you try to define it.
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Viktor Klang
Rogue Software Architect

[Ricky Clarkson]

I've never seen the Scala compiler that way personally.

2008/6/10 Viktor Klang <viktor.klang@...>:

On Tue, Jun 10, 2008 at 10:40 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

I fail to understand why someone would want a warning for something they're doing on purpose.

I can see it.
"You have been a very very naughty boy..."

 

2008/6/10 David MacIver <david.maciver@...>:

Hm. Changing the behaviour and then adding a warning for the new
behaviour seems bizarre to me. I'd rather either not have a warning or
stick with the current behaviour when you have multiple implicits for
the same type.

I don't feel very strongly that the suggested shadowing by type
behaviour is correct. The only part about the proposal I feel at all
strongly about is that implicits *shouldn't* shadow eachother by name.
Making them shadow by type just seems vaguely useful for redefining
implicits locally and is nicely symmetrical with the way shadowing by
name normally works.

On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht

<erik.engbrecht@...> wrote:
> Yes, I'd like a warning when one implicit shadows another.  It could be an
> optional warning.
> Actually, now that I think about it, what would be more useful would be if
> my IDE told me where implicits are being applied and which one is being
> applied in each location.  Some sort of hover-over or right-click operation.
>
>
> On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Hmmmm...random abuse...
>> >
>> > How dare you post such drivel to this list!!!
>> >
>> > Actually my initial reaction is that I'm with you on shadowing, and I
>> > agree
>> > this is a worthwhile problem to ponder.
>> >
>> > I'd like compiler warnings when I have to implicitis with the same
>> > signature, excluding name, in scope.
>>
>> Hm. Can you clarify which circumstance you'd like a warning for? In
>> particular, are you saying that the circumstance I said should cause
>> shadowing of the implicit should actually be a warning?
>>
>> I'm not convinced a warning for this would be useful either way. It's
>> already possible to have the same identifier in scope multiple times
>> and it's largely harmless. It's a compiler error when you try to use
>> it, not when you try to define it.
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Viktor Klang
Rogue Software Architect

[David MacIver]

In theory it might not be obvious that you were shadowing.

Also, I've changed my mind. I do feel very strongly that if implicits
don't shadow by name then they do need to shadow by type, as I've
thought of at least one example (my menu DSL) where I rely on being
able to shadow implicits and, generally speaking, having them not able
to shadow is tantamount to putting them in global scope.

On Tue, Jun 10, 2008 at 9:40 AM, Ricky Clarkson
<ricky.clarkson@...> wrote:

> I fail to understand why someone would want a warning for something they're
> doing on purpose.
>
> 2008/6/10 David MacIver <david.maciver@...>:
>>
>> Hm. Changing the behaviour and then adding a warning for the new
>> behaviour seems bizarre to me. I'd rather either not have a warning or
>> stick with the current behaviour when you have multiple implicits for
>> the same type.
>>
>> I don't feel very strongly that the suggested shadowing by type
>> behaviour is correct. The only part about the proposal I feel at all
>> strongly about is that implicits *shouldn't* shadow eachother by name.
>> Making them shadow by type just seems vaguely useful for redefining
>> implicits locally and is nicely symmetrical with the way shadowing by
>> name normally works.
>>
>> On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Yes, I'd like a warning when one implicit shadows another.  It could be
>> > an
>> > optional warning.
>> > Actually, now that I think about it, what would be more useful would be
>> > if
>> > my IDE told me where implicits are being applied and which one is being
>> > applied in each location.  Some sort of hover-over or right-click
>> > operation.
>> >
>> >
>> > On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
>> > wrote:
>> >>
>> >> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> >> <erik.engbrecht@...> wrote:
>> >> > Hmmmm...random abuse...
>> >> >
>> >> > How dare you post such drivel to this list!!!
>> >> >
>> >> > Actually my initial reaction is that I'm with you on shadowing, and I
>> >> > agree
>> >> > this is a worthwhile problem to ponder.
>> >> >
>> >> > I'd like compiler warnings when I have to implicitis with the same
>> >> > signature, excluding name, in scope.
>> >>
>> >> Hm. Can you clarify which circumstance you'd like a warning for? In
>> >> particular, are you saying that the circumstance I said should cause
>> >> shadowing of the implicit should actually be a warning?
>> >>
>> >> I'm not convinced a warning for this would be useful either way. It's
>> >> already possible to have the same identifier in scope multiple times
>> >> and it's largely harmless. It's a compiler error when you try to use
>> >> it, not when you try to define it.
>> >
>> >
>> >
>> > --
>> > http://erikengbrecht.blogspot.com/
>
>

[Viktor Klang]

On Tue, Jun 10, 2008 at 10:45 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

I've never seen the Scala compiler that way personally.

You have to supply the "-Xkinky" option to the compiler.
 

2008/6/10 Viktor Klang <viktor.klang@...>:

On Tue, Jun 10, 2008 at 10:40 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

I fail to understand why someone would want a warning for something they're doing on purpose.

I can see it.
"You have been a very very naughty boy..."

 

2008/6/10 David MacIver <david.maciver@...>:

Hm. Changing the behaviour and then adding a warning for the new
behaviour seems bizarre to me. I'd rather either not have a warning or
stick with the current behaviour when you have multiple implicits for
the same type.

I don't feel very strongly that the suggested shadowing by type
behaviour is correct. The only part about the proposal I feel at all
strongly about is that implicits *shouldn't* shadow eachother by name.
Making them shadow by type just seems vaguely useful for redefining
implicits locally and is nicely symmetrical with the way shadowing by
name normally works.

On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht

<erik.engbrecht@...> wrote:
> Yes, I'd like a warning when one implicit shadows another.  It could be an
> optional warning.
> Actually, now that I think about it, what would be more useful would be if
> my IDE told me where implicits are being applied and which one is being
> applied in each location.  Some sort of hover-over or right-click operation.
>
>
> On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Hmmmm...random abuse...
>> >
>> > How dare you post such drivel to this list!!!
>> >
>> > Actually my initial reaction is that I'm with you on shadowing, and I
>> > agree
>> > this is a worthwhile problem to ponder.
>> >
>> > I'd like compiler warnings when I have to implicitis with the same
>> > signature, excluding name, in scope.
>>
>> Hm. Can you clarify which circumstance you'd like a warning for? In
>> particular, are you saying that the circumstance I said should cause
>> shadowing of the implicit should actually be a warning?
>>
>> I'm not convinced a warning for this would be useful either way. It's
>> already possible to have the same identifier in scope multiple times
>> and it's largely harmless. It's a compiler error when you try to use
>> it, not when you try to define it.
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Viktor Klang
Rogue Software Architect

--
Viktor Klang
Rogue Software Architect

[Erik Engbrecht]

The only way you know what implicits you have in scope is to look at what implicits are defined in all of the modules you've imported.  I know, that sounds simple, but it can represent a significant cognitive load.  Library/framework writers often use implicits to simplify usage, so that the user doesn't need to think about the type that is actually required because the compiler magically knows how to do the conversion in the right way.  Requiring the user to know all the implicits he's importing or inheriting defeats that magic.

 

So it would be nice for the user to know that he is breaking that magic either by importing implicits, inheriting, or defining his own implicits that present a compatibility problem with some other source.

 

On 6/10/08, David MacIver <david.maciver@...> wrote:

In theory it might not be obvious that you were shadowing.

Also, I've changed my mind. I do feel very strongly that if implicits
don't shadow by name then they do need to shadow by type, as I've
thought of at least one example (my menu DSL) where I rely on being
able to shadow implicits and, generally speaking, having them not able
to shadow is tantamount to putting them in global scope.

On Tue, Jun 10, 2008 at 9:40 AM, Ricky Clarkson
<ricky.clarkson@...> wrote:
> I fail to understand why someone would want a warning for something they're
> doing on purpose.
>
> 2008/6/10 David MacIver <david.maciver@...>:
>>
>> Hm. Changing the behaviour and then adding a warning for the new
>> behaviour seems bizarre to me. I'd rather either not have a warning or
>> stick with the current behaviour when you have multiple implicits for
>> the same type.
>>
>> I don't feel very strongly that the suggested shadowing by type
>> behaviour is correct. The only part about the proposal I feel at all
>> strongly about is that implicits *shouldn't* shadow eachother by name.
>> Making them shadow by type just seems vaguely useful for redefining
>> implicits locally and is nicely symmetrical with the way shadowing by
>> name normally works.
>>
>> On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht
>> <erik.engbrecht@...> wrote:
>> > Yes, I'd like a warning when one implicit shadows another.  It could be
>> > an
>> > optional warning.
>> > Actually, now that I think about it, what would be more useful would be
>> > if
>> > my IDE told me where implicits are being applied and which one is being
>> > applied in each location.  Some sort of hover-over or right-click
>> > operation.
>> >
>> >
>> > On Mon, Jun 9, 2008 at 9:10 PM, David MacIver <david.maciver@...>
>> > wrote:
>> >>
>> >> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> >> <erik.engbrecht@...> wrote:
>> >> > Hmmmm...random abuse...
>> >> >
>> >> > How dare you post such drivel to this list!!!
>> >> >
>> >> > Actually my initial reaction is that I'm with you on shadowing, and I
>> >> > agree
>> >> > this is a worthwhile problem to ponder.
>> >> >
>> >> > I'd like compiler warnings when I have to implicitis with the same
>> >> > signature, excluding name, in scope.
>> >>
>> >> Hm. Can you clarify which circumstance you'd like a warning for? In
>> >> particular, are you saying that the circumstance I said should cause
>> >> shadowing of the implicit should actually be a warning?
>> >>
>> >> I'm not convinced a warning for this would be useful either way. It's
>> >> already possible to have the same identifier in scope multiple times
>> >> and it's largely harmless. It's a compiler error when you try to use
>> >> it, not when you try to define it.
>> >
>> >
>> >
>> > --
>> > http://erikengbrecht.blogspot.com/
>
>

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

[David MacIver]

A warning is completely the wrong way to achieve that though.
Shadowing is not wrong - there are many legitimate ways to use it.
It's at most an info level message, and the compiler doesn't really
have a concept of that.

I agree that some sort of tool support for this would be nice though.

On Tue, Jun 10, 2008 at 4:02 PM, Erik Engbrecht
<erik.engbrecht@...> wrote:

> The only way you know what implicits you have in scope is to look at what
> implicits are defined in all of the modules you've imported.  I know, that
> sounds simple, but it can represent a significant cognitive load.
> Library/framework writers often use implicits to simplify usage, so that the
> user doesn't need to think about the type that is actually required because
> the compiler magically knows how to do the conversion in the right way.
> Requiring the user to know all the implicits he's importing or inheriting
> defeats that magic.
>
> So it would be nice for the user to know that he is breaking that magic
> either by importing implicits, inheriting, or defining his own implicits
> that present a compatibility problem with some other source.
>
>
> On 6/10/08, David MacIver <david.maciver@...> wrote:
>>
>> In theory it might not be obvious that you were shadowing.
>>
>> Also, I've changed my mind. I do feel very strongly that if implicits
>> don't shadow by name then they do need to shadow by type, as I've
>> thought of at least one example (my menu DSL) where I rely on being
>> able to shadow implicits and, generally speaking, having them not able
>> to shadow is tantamount to putting them in global scope.
>>
>> On Tue, Jun 10, 2008 at 9:40 AM, Ricky Clarkson
>> <ricky.clarkson@...> wrote:
>> > I fail to understand why someone would want a warning for something
>> > they're
>> > doing on purpose.
>> >
>> > 2008/6/10 David MacIver <david.maciver@...>:
>> >>
>> >> Hm. Changing the behaviour and then adding a warning for the new
>> >> behaviour seems bizarre to me. I'd rather either not have a warning or
>> >> stick with the current behaviour when you have multiple implicits for
>> >> the same type.
>> >>
>> >> I don't feel very strongly that the suggested shadowing by type
>> >> behaviour is correct. The only part about the proposal I feel at all
>> >> strongly about is that implicits *shouldn't* shadow eachother by name.
>> >> Making them shadow by type just seems vaguely useful for redefining
>> >> implicits locally and is nicely symmetrical with the way shadowing by
>> >> name normally works.
>> >>
>> >> On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht
>> >> <erik.engbrecht@...> wrote:
>> >> > Yes, I'd like a warning when one implicit shadows another.  It could
>> >> > be
>> >> > an
>> >> > optional warning.
>> >> > Actually, now that I think about it, what would be more useful would
>> >> > be
>> >> > if
>> >> > my IDE told me where implicits are being applied and which one is
>> >> > being
>> >> > applied in each location.  Some sort of hover-over or right-click
>> >> > operation.
>> >> >
>> >> >
>> >> > On Mon, Jun 9, 2008 at 9:10 PM, David MacIver
>> >> > <david.maciver@...>
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Jun 9, 2008 at 11:50 PM, Erik Engbrecht
>> >> >> <erik.engbrecht@...> wrote:
>> >> >> > Hmmmm...random abuse...
>> >> >> >
>> >> >> > How dare you post such drivel to this list!!!
>> >> >> >
>> >> >> > Actually my initial reaction is that I'm with you on shadowing,
>> >> >> > and I
>> >> >> > agree
>> >> >> > this is a worthwhile problem to ponder.
>> >> >> >
>> >> >> > I'd like compiler warnings when I have to implicitis with the same
>> >> >> > signature, excluding name, in scope.
>> >> >>
>> >> >> Hm. Can you clarify which circumstance you'd like a warning for? In
>> >> >> particular, are you saying that the circumstance I said should cause
>> >> >> shadowing of the implicit should actually be a warning?
>> >> >>
>> >> >> I'm not convinced a warning for this would be useful either way.
>> >> >> It's
>> >> >> already possible to have the same identifier in scope multiple times
>> >> >> and it's largely harmless. It's a compiler error when you try to use
>> >> >> it, not when you try to define it.
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > http://erikengbrecht.blogspot.com/
>> >
>> >
>
>
>
> --
> http://erikengbrecht.blogspot.com/

[Miles Sabin]

On Tue, Jun 10, 2008 at 4:14 AM, Erik Engbrecht
<erik.engbrecht@...> wrote:
> Actually, now that I think about it, what would be more useful would be if
> my IDE told me where implicits are being applied and which one is being
> applied in each location.

That would be nice ... I'll add it to the list.

Cheers,


Miles

[Raphael Jolly]

David MacIver wrote:

> This email is more of a brain dump than a concrete proposal. It may be
> that this is a terrible idea, but I'd like to hear what other people
> think of it and possibly be convinced that it's a terrible idea. :-)
> Or it may be that even if it's a good idea no one other than me cares
> and/or it's too much work to implement.
>
> The way implicit scoping works currently bothers me. In particular the
> way they are shadowed.
>
> I'd like to change the behaviour so that implicits are shadowed by
> type and not by name. Take the following example:
>
> object Foo{
>   implicit val bar : Bar = stuff;
>
>   def thingy = {
>      val bar : Bar = otherstuff;
>
>      implicitly[Bar]; // compiler error because the local bar shadows
> the implicit bar
>   }
> }
>
> (implicitly is a function I often define for demoing these things.
> It's def implicitly[T](implicit t : T) = t; So it gives the implicit
> value of T currently in scope)
>
> What I'd instead like to happen is
>
> object Foo{
>   implicit val bar : Bar = stuff;
>
>   def thingy = {
>      val bar : Bar = otherstuff;
>
>      assert (implicitly[Bar] == stuff);
>      assert bar == otherstuff
>   }
> }
>
> So the local variable shadows the identifier but not the implicit.
>
> Here's another example of where the behaviour is contrary to what I'd
> like (it bothers me less, but I feel this would help consistency):
>
> object Foo{
>   implicit val bar : Bar = stuff;
>
>   def thingy = {
>      implicit val squirrel : Bar = otherstuff;
>
>      assert (implicitly[Bar] == otherstuff);  // Instead get compiler
> error due to ambiguous implicit value
>      assert (bar == stuff)
>      assert (squirrel == otherstuff)
>   }
> }
>
>
> So what I'd like is that the fact that squirrel is implicitly Bar
> shadows the fact that bar is, but does not shadow the identifier for
> bar.
>
> Both these behaviours seem wrong to me. They force you to care about
> the name of the implicit, which seems counter to their purpose.
>
> Moreover, there are a few cases where this is actively harmful. For
> example, I've run into this issue a number of times when trying to use
> objects as modules style programming. i.e. I have some class which
> describes a module signature, and objects extending it are modules (an
> example I've speculated about for this is retargetable SBinary
> backends - e.g one using Java serialization, one using the current
> approach). But I can't usefully use implicits on this and use multiple
> instances of these at once, because if I have two in scope the
> implicits of one will shadow the implicits of the other.
>
> Does this make sense? Does it seem useful to you? It just seems like
> much saner behaviour to me.
>
> Other things I'd like on top of this (but which are not required for
> the basic proposal to make sense):
>
> Have implicitly as a compiler builtin. Possibly reusing the implicit
> keyword. So implicit[T] would be an expression evaluating to the
> implicit value of T currently in scope. You would additionally be
> allowed to do:
>
>  - myObject.implicit[Foo] (equivalent to { import myObject._; implicit[Foo] }
>  - import myObject.implicit[Foo] // brings only the fact that Foo is
> available implicitly into scope, not the identifier for Foo.
>
> Allow implicits with no identifier. e.g.
>
> implicit val = "jimbob"
>
> (Possibly this might look better as val implicit = "jimbob" ? Not sure)
>
> This would create an implicit but no name for it. The availability of
> the implicit would scope as above, but you wouldn't be able to access
> it by identifier. This would mainly be useful for weirdo projects like
> SBinary and ScalaCheck where you define a large number of implicit
> values for different types and it's generally very unlikely that you'd
> want to access them by name.
>
> Thoughts? Comments? Random abuse?

I have exactly the same need. I am trying to introduce so called
"dependent types" in a computer algebra project, see
http://krum.rz.uni-mannheim.de/kredel/jas-ascm2007.pdf , 3.3 Dependent
types, p. 7 for a reference. It is very uneasy to do Java, and hence
interesting to investigate in Scala.

Here is my code:

abstract class Mod[T <: Mod[T]](val mod: Int) {
   class Element(_value: Int) {
     val value = _value%mod
     def +(that: Element) = apply(this.value+that.value)
     override def toString = value.toString
   }
   implicit def apply(value: Int) = new Element(value)
}

class Mod7 extends Mod[Mod7](7)
val Mod7 = new Mod7

import Mod7._

val a = Mod7(4)

a+4 // 1
4+a // 1

This breaks as soon as I introduce another type, like:

class Mod2 extends Mod[Mod2](2)
val Mod2 = new Mod2

import Mod2._

val b = Mod2(1)

b+1 // 0
1+b // 0

a+4 // fails due to Mod2.apply shadowed
4+a // fails due to Mod2.apply shadowed

My question : Is this request being considered for a future release ?

Many thanks !
Raphael

[Raphael Jolly]

Raphael Jolly wrote:

> David MacIver wrote:
>> This email is more of a brain dump than a concrete proposal. It may be
>> that this is a terrible idea, but I'd like to hear what other people
>> think of it and possibly be convinced that it's a terrible idea. :-)
>> Or it may be that even if it's a good idea no one other than me cares
>> and/or it's too much work to implement.
>>
>> The way implicit scoping works currently bothers me. In particular the
>> way they are shadowed.
>>
>> I'd like to change the behaviour so that implicits are shadowed by
>> type and not by name. Take the following example:

[...]

> I have exactly the same need. I am trying to introduce so called
> "dependent types" in a computer algebra project, see
> http://krum.rz.uni-mannheim.de/kredel/jas-ascm2007.pdf , 3.3 Dependent
> types, p. 7 for a reference. It is very uneasy to do Java, and hence
> interesting to investigate in Scala.

My example can be simplified. I believe it will make clearer what I want
to do:

class Mod(val mod: Int) {
   class Element(_value: Int) {
     val value = _value%mod
     def +(that: Element) = apply(this.value+that.value)
     override def toString = value.toString
   }
   implicit def apply(value: Int) = new Element(value)
}

val Mod7 = new Mod(7)
import Mod7._
val a = Mod7(4)

a+4 // 1
4+a // 1

// everything fine up to there. Then define:

val Mod2 = new Mod(2)
import Mod2._
val b = Mod2(1)

b+1 // 0
1+b // 0

a+4 // fails due to Mod7.apply shadowed
4+a // fails due to Mod7.apply shadowed

Raphael

[Martin Odersky]

Hi David,

Interesting thoughts. There are a number of things happening in trunk
that come somewhat close to what you suggest:

Implicit shadowing is still by name, but in case of ambiguity implicits
defined in (companion objects of) subclasses take precedence over
implicits defined in (companion objects of) superclasses. In fact,
that now holds for all overloaded members.

Predef in trunk contains a method `evidence' which has the same
signature and usage as your `implicitly'. Actually, I think I like
`implicitly' better as a name, so I'll probably rename the method.

As to your other suggestions, I think these would significantly
increase the spec footprint, so I don't really see them happening.
Right now, the beauty of implicits is that they are normal members
subject to the same scope resolution rules as all other members. If
you start introducing a class of things with different scope
resolution rules you have dramatically increased the footprint of your
spec!

Cheers

 -- Martin

[Raphael Jolly]

martin odersky wrote:

> Hi David,
>
> Interesting thoughts. There are a number of things happening in trunk
> that come somewhat close to what you suggest:
>
> Implicit shadowing is still by name, but in case of ambiguity implicits
> defined in (companion objects of) subclasses take precedence over
> implicits defined in (companion objects of) superclasses. In fact,
> that now holds for all overloaded members.
>
> Predef in trunk contains a method `evidence' which has the same
> signature and usage as your `implicitly'. Actually, I think I like
> `implicitly' better as a name, so I'll probably rename the method.
>
> As to your other suggestions, I think these would significantly
> increase the spec footprint, so I don't really see them happening.
> Right now, the beauty of implicits is that they are normal members
> subject to the same scope resolution rules as all other members. If
> you start introducing a class of things with different scope
> resolution rules you have dramatically increased the footprint of your
> spec!

Martin, thanks for responding (to David, but still !)

What I could do then is:

class Mod(val mod: Int) {
   class Element(_value: Int) {
     val value = _value%mod
     def +(that: Element) = Element.apply(this.value+that.value)
     override def toString = value.toString
   }
   object Element {
     implicit def apply(value: Int) = new Element(value)
   }
}

val Mod7 = new Mod(7)
val a = Mod7.Element(4)

a+4 // 1
4+a // fails

, but I never understood why the last line fails. This is the same for
scala.BigInt : without importing anything, one has that:

BigInt(1)+1 // works
1+BigInt(1) // fails

One needs to import BigInt._ for the second one to work. This seems to
me to be highly dissymetrical and unfortunate. Without the import, I
would rather have both to work or none at all. Preferably both. Would it
be hard to implement ?

Raphael

[Paul Phillips-3]

On Fri, Sep 18, 2009 at 11:56:37PM +0200, Raphael Jolly wrote:
> BigInt(1)+1 // works
> 1+BigInt(1) // fails
>
> One needs to import BigInt._ for the second one to work. This seems to
> me to be highly dissymetrical and unfortunate. Without the import, I
> would rather have both to work or none at all. Preferably both.

(1: BigInt) + BigInt(1) works without any import.  Without an annotation
that would be inherently ambiguous because of the unpleasantly hacky
any2stringadd, which sticks a "+" method on everything under the sun.

But ignoring that, I don't see why you would expect symmetric behavior
here.  This is OO-land where "x op y" means "x.op(y)", not "op(x, y)",
and so it is natural that x.op(y) and y.op(x) each do their own thing.

--
Paul Phillips      | Every election is a sort of advance auction sale
Stickler           | of stolen goods.
Empiricist         |     -- H. L. Mencken
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

[Raphael Jolly]

Paul Phillips wrote:

> On Fri, Sep 18, 2009 at 11:56:37PM +0200, Raphael Jolly wrote:
>> BigInt(1)+1 // works
>> 1+BigInt(1) // fails
>>
>> One needs to import BigInt._ for the second one to work. This seems to
>> me to be highly dissymetrical and unfortunate. Without the import, I
>> would rather have both to work or none at all. Preferably both.
>
> (1: BigInt) + BigInt(1) works without any import.  Without an annotation
> that would be inherently ambiguous because of the unpleasantly hacky
> any2stringadd, which sticks a "+" method on everything under the sun.
>
> But ignoring that, I don't see why you would expect symmetric behavior
> here.  This is OO-land where "x op y" means "x.op(y)", not "op(x, y)",
> and so it is natural that x.op(y) and y.op(x) each do their own thing.

ok then I need to use imports, and find a workaround to the fact that
implicits are shadowing themselves. What I could do is to use an import
selector:

import Mod7.{apply => mod7}
import Mod2.{apply => mod2}

, but this turns out to remove the implicit nature of the value:

object A { implicit val x = 1 }
import A.x
implicitly[Int] // 1

// restart

object A { implicit val x = 1 }
import A.{x => y}
implicitly[Int] // error: could not find implicit value for parameter e: Int
y // 1
x // error: not found: value x [as expected]

Is that what is expected ?
Raphael

[Raphael Jolly]

Raphael Jolly wrote:

> Paul Phillips wrote:
>> On Fri, Sep 18, 2009 at 11:56:37PM +0200, Raphael Jolly wrote:
>>> BigInt(1)+1 // works
>>> 1+BigInt(1) // fails
>>>
>>> One needs to import BigInt._ for the second one to work. This seems
>>> to me to be highly dissymetrical and unfortunate. Without the import,
>>> I would rather have both to work or none at all. Preferably both.
>>
>> (1: BigInt) + BigInt(1) works without any import.  Without an
>> annotation that would be inherently ambiguous because of the
>> unpleasantly hacky any2stringadd, which sticks a "+" method on
>> everything under the sun.
>>
>> But ignoring that, I don't see why you would expect symmetric behavior
>> here.  This is OO-land where "x op y" means "x.op(y)", not "op(x, y)",
>> and so it is natural that x.op(y) and y.op(x) each do their own thing.
>
> ok then I need to use imports, and find a workaround to the fact that
> implicits are shadowing themselves. What I could do is to use an import
> selector:
>
> import Mod7.{apply => mod7}
> import Mod2.{apply => mod2}
>
> , but this turns out to remove the implicit nature of the value:
>
> object A { implicit val x = 1 }
> import A.x
> implicitly[Int] // 1
>
> // restart
>
> object A { implicit val x = 1 }
> import A.{x => y}
> implicitly[Int] // error: could not find implicit value for parameter e:
> Int
> y // 1
> x // error: not found: value x [as expected]
>
> Is it on purpose ?

I have filled a bug report:

import selector removes implicit nature of value
http://lampsvn.epfl.ch/trac/scala/ticket/2405

Raphael