declaration-site import

This one would need an SID, but how about the ability to specify, on a class, that all members get automatically imported when it's used as a parameter, or in a context bound.
A contrived example, but currently we might do something like this:
  def sum[T : Numeric](pair : Tuple2[T,T]) = {    val context = implicitly[Numeric[T]]    import context._    pair._1 plus pair._2  }
whereas if Numeric was autoimported:
  def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2

Originally, I was thinking to propose typeclass as a keyword, alongside class and object.  Mostly because I imagined this being used only for type classes (imaginative naming, eh?)

Now, I'm thinking it would be just as useful for DSLs.  Imagine something like this in an ARM library:
  def with(r : Resource)(block : Resource => Unit) = {     r.open()    block(r)    r.close()  }
If Resource was auto-imported, then we could write:
  with(file) {    lines foreach { println }   }
instead of:
  with(file) { f =>    f.lines foreach { println }  }

Once a type (or type constructor) has been marked as autoimportable, this quality would also be inherited by subclasses. I've convinced myself that the idea has a lot of potential, but don't have any definite opinions on the best notation to use.

What does everyone think?

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I have two minds about this...
One is that I have a very strong dislike for wildcard imports, and this seems worse.  It's an implicit wildcard import.
The other is that almost every time I pick up a Scala library, I receive a bunch of compile errors because I do:
import library.foo.{ TheClassIWant, TheOtherClassIWant }
...and as a result don't have all magical implicits that make the library work nicely.
So basically providing a way to let library designers specify the implicits that are needed to make the library work properly, and have the compiler magically import them so people like me don't end up digging through documentation and source code figuring out exactly what to import, or feel dirty because they get lazy and add in a wildcard import.
In other words, my other mind says the proposal doesn't go far enough.
On Fri, Sep 3, 2010 at 6:31 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

This one would need an SID, but how about the ability to specify, on a class, that all members get automatically imported when it's used as a parameter, or in a context bound.
A contrived example, but currently we might do something like this:
  def sum[T : Numeric](pair : Tuple2[T,T]) = {    val context = implicitly[Numeric[T]]    import context._    pair._1 plus pair._2  }
whereas if Numeric was autoimported:
  def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2

Originally, I was thinking to propose typeclass as a keyword, alongside class and object.  Mostly because I imagined this being used only for type classes (imaginative naming, eh?)

Now, I'm thinking it would be just as useful for DSLs.  Imagine something like this in an ARM library:
  def with(r : Resource)(block : Resource => Unit) = {     r.open()    block(r)    r.close()  }
If Resource was auto-imported, then we could write:
  with(file) {    lines foreach { println }   }
instead of:
  with(file) { f =>    f.lines foreach { println }  }

Once a type (or type constructor) has been marked as autoimportable, this quality would also be inherited by subclasses. I've convinced myself that the idea has a lot of potential, but don't have any definite opinions on the best notation to use.

What does everyone think?

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

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

What about clashes between the imported members of various context bounds?

scala> trait Functor[F[_]] { def fmap[A, B](as: F[A], f: A => B): F[B] }
defined trait Functor

scala> def foo[M[_]: Functor, N[_]: Functor] {}
foo: [M[_],N[_]](implicit evidence$1: Functor[M],implicit evidence$2:
Functor[N])Unit

scala> def foo[M[_], N[_]](implicit mf: Functor[M], nf: Functor[M]) {
| import mf._
| import nf._
| }

Someone recently suggested a syntactic change for an opt-in version of this.

def foo[M[_]: import Functor, N[_]: Functor] {}

-jason

On Sat, Sep 4, 2010 at 2:57 AM, Kevin Wright wrote:
> I think that a lot of what you're after can be achieved with companion
> singletons and package objects.
> What I'm proposing is something far more controlled.
> I want to pull wildcard imports into a strongly delimited scope for two very
> specific (yet common) use cases.
> No doubt others will come along and find other uses for such an idea
> though...
>
> On 4 September 2010 01:19, Erik Engbrecht wrote:
>>
>> I have two minds about this...
>> One is that I have a very strong dislike for wildcard imports, and this
>> seems worse.  It's an implicit wildcard import.
>> The other is that almost every time I pick up a Scala library, I receive a
>> bunch of compile errors because I do:
>> import library.foo.{ TheClassIWant, TheOtherClassIWant }
>> ...and as a result don't have all magical implicits that make the library
>> work nicely.
>> So basically providing a way to let library designers specify the
>> implicits that are needed to make the library work properly, and have the
>> compiler magically import them so people like me don't end up digging
>> through documentation and source code figuring out exactly what to import,
>> or feel dirty because they get lazy and add in a wildcard import.
>> In other words, my other mind says the proposal doesn't go far enough.
>> On Fri, Sep 3, 2010 at 6:31 PM, Kevin Wright
>> wrote:
>>>
>>> This one would need an SID, but how about the ability to specify, on a
>>> class, that all members get automatically imported when it's used as a
>>> parameter, or in a context bound.
>>> A contrived example, but currently we might do something like this:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = {
>>>     val context = implicitly[Numeric[T]]
>>>     import context._
>>>     pair._1 plus pair._2
>>>   }
>>> whereas if Numeric was autoimported:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2
>>>
>>> Originally, I was thinking to propose typeclass as a keyword, alongside
>>> class and object.  Mostly because I imagined this being used only for type
>>> classes
>>> (imaginative naming, eh?)
>>>
>>> Now, I'm thinking it would be just as useful for DSLs.  Imagine something
>>> like this in an ARM library:
>>>   def with(r : Resource)(block : Resource => Unit) = {
>>>     r.open()
>>>     block(r)
>>>     r.close()
>>>   }
>>> If Resource was auto-imported, then we could write:
>>>   with(file) {
>>>     lines foreach { println }
>>>   }
>>> instead of:
>>>   with(file) { f =>
>>>     f.lines foreach { println }
>>>   }
>>>
>>> Once a type (or type constructor) has been marked as autoimportable, this
>>> quality would also be inherited by subclasses.
>>> I've convinced myself that the idea has a lot of potential, but don't
>>> have any definite opinions on the best notation to use.
>>>
>>> What does everyone think?
>>>
>>> --
>>> Kevin Wright
>>>
>>> mail / gtalk / msn : kev.lee.wright@gmail.com
>>> pulse / skype: kev.lee.wright
>>> twitter: @thecoda
>>>
>>
>>
>>
>> --
>> http://erikengbrecht.blogspot.com/
>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
>

What about clashes between the imported members of various context bounds?

scala> trait Functor[F[_]] { def fmap[A, B](as: F[A], f: A => B): F[B] }
defined trait Functor

scala> def foo[M[_]: Functor, N[_]: Functor] {}
foo: [M[_],N[_]](implicit evidence$1: Functor[M],implicit evidence$2:
Functor[N])Unit

scala> def foo[M[_], N[_]](implicit mf: Functor[M], nf: Functor[M]) {
|   import mf._
|   import nf._
| }

Someone recently suggested a syntactic change for an opt-in version of this.

 def foo[M[_]: import Functor, N[_]: Functor] {}

-jason

On Sat, Sep 4, 2010 at 2:57 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
> I think that a lot of what you're after can be achieved with companion
> singletons and package objects.
> What I'm proposing is something far more controlled.
> I want to pull wildcard imports into a strongly delimited scope for two very
> specific (yet common) use cases.
> No doubt others will come along and find other uses for such an idea
> though...
>
> On 4 September 2010 01:19, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:
>>
>> I have two minds about this...
>> One is that I have a very strong dislike for wildcard imports, and this
>> seems worse.  It's an implicit wildcard import.
>> The other is that almost every time I pick up a Scala library, I receive a
>> bunch of compile errors because I do:
>> import library.foo.{ TheClassIWant, TheOtherClassIWant }
>> ...and as a result don't have all magical implicits that make the library
>> work nicely.
>> So basically providing a way to let library designers specify the
>> implicits that are needed to make the library work properly, and have the
>> compiler magically import them so people like me don't end up digging
>> through documentation and source code figuring out exactly what to import,
>> or feel dirty because they get lazy and add in a wildcard import.
>> In other words, my other mind says the proposal doesn't go far enough.
>> On Fri, Sep 3, 2010 at 6:31 PM, Kevin Wright <kev.lee.wright@gmail.com>
>> wrote:
>>>
>>> This one would need an SID, but how about the ability to specify, on a
>>> class, that all members get automatically imported when it's used as a
>>> parameter, or in a context bound.
>>> A contrived example, but currently we might do something like this:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = {
>>>     val context = implicitly[Numeric[T]]
>>>     import context._
>>>     pair._1 plus pair._2
>>>   }
>>> whereas if Numeric was autoimported:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2
>>>
>>> Originally, I was thinking to propose typeclass as a keyword, alongside
>>> class and object.  Mostly because I imagined this being used only for type
>>> classes
>>> (imaginative naming, eh?)
>>>
>>> Now, I'm thinking it would be just as useful for DSLs.  Imagine something
>>> like this in an ARM library:
>>>   def with(r : Resource)(block : Resource => Unit) = {
>>>     r.open()
>>>     block(r)
>>>     r.close()
>>>   }
>>> If Resource was auto-imported, then we could write:
>>>   with(file) {
>>>     lines foreach { println }
>>>   }
>>> instead of:
>>>   with(file) { f =>
>>>     f.lines foreach { println }
>>>   }
>>>
>>> Once a type (or type constructor) has been marked as autoimportable, this
>>> quality would also be inherited by subclasses.
>>> I've convinced myself that the idea has a lot of potential, but don't
>>> have any definite opinions on the best notation to use.
>>>
>>> What does everyone think?
>>>
>>> --
>>> Kevin Wright
>>>
>>> mail / gtalk / msn : kev.lee.wright@gmail.com
>>> pulse / skype: kev.lee.wright
>>> twitter: @thecoda
>>>
>>
>>
>>
>> --
>> http://erikengbrecht.blogspot.com/
>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
>

This one would need an SID, but how about the ability to specify, on a class, that all members get automatically imported when it's used as a parameter, or in a context bound.
A contrived example, but currently we might do something like this:
  def sum[T : Numeric](pair : Tuple2[T,T]) = {    val context = implicitly[Numeric[T]]    import context._    pair._1 plus pair._2  }
whereas if Numeric was autoimported:
  def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2

Originally, I was thinking to propose typeclass as a keyword, alongside class and object.  Mostly because I imagined this being used only for type classes (imaginative naming, eh?)

Now, I'm thinking it would be just as useful for DSLs.  Imagine something like this in an ARM library:
  def with(r : Resource)(block : Resource => Unit) = {     r.open()    block(r)    r.close()  }
If Resource was auto-imported, then we could write:
  with(file) {    lines foreach { println }   }
instead of:
  with(file) { f =>    f.lines foreach { println }  }

Once a type (or type constructor) has been marked as autoimportable, this quality would also be inherited by subclasses. I've convinced myself that the idea has a lot of potential, but don't have any definite opinions on the best notation to use.

What does everyone think?

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Good point :)
I like the syntax.It's low on boilerplate (can't imagine too many such imports in a declaration) It can be used on both parameters and context bounds it doesn't require the introduction of any new keywords
I don't even imagine it would be too hard to implement!


For the DSL use-case, I think something like this would do the trick:
  def with(r : Resource)(block : import Resource => Unit) =


On 4 September 2010 09:39, Jason Zaugg <jzaugg@gmail.com> wrote:

What about clashes between the imported members of various context bounds?

scala> trait Functor[F[_]] { def fmap[A, B](as: F[A], f: A => B): F[B] }
defined trait Functor

scala> def foo[M[_]: Functor, N[_]: Functor] {}
foo: [M[_],N[_]](implicit evidence$1: Functor[M],implicit evidence$2:
Functor[N])Unit

scala> def foo[M[_], N[_]](implicit mf: Functor[M], nf: Functor[M]) {
|   import mf._
|   import nf._
| }

Someone recently suggested a syntactic change for an opt-in version of this.

 def foo[M[_]: import Functor, N[_]: Functor] {}

-jason

On Sat, Sep 4, 2010 at 2:57 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
> I think that a lot of what you're after can be achieved with companion
> singletons and package objects.
> What I'm proposing is something far more controlled.
> I want to pull wildcard imports into a strongly delimited scope for two very
> specific (yet common) use cases.
> No doubt others will come along and find other uses for such an idea
> though...
>
> On 4 September 2010 01:19, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:
>>
>> I have two minds about this...
>> One is that I have a very strong dislike for wildcard imports, and this
>> seems worse.  It's an implicit wildcard import.
>> The other is that almost every time I pick up a Scala library, I receive a
>> bunch of compile errors because I do:
>> import library.foo.{ TheClassIWant, TheOtherClassIWant }
>> ...and as a result don't have all magical implicits that make the library
>> work nicely.
>> So basically providing a way to let library designers specify the
>> implicits that are needed to make the library work properly, and have the
>> compiler magically import them so people like me don't end up digging
>> through documentation and source code figuring out exactly what to import,
>> or feel dirty because they get lazy and add in a wildcard import.
>> In other words, my other mind says the proposal doesn't go far enough.
>> On Fri, Sep 3, 2010 at 6:31 PM, Kevin Wright <kev.lee.wright@gmail.com>
>> wrote:
>>>
>>> This one would need an SID, but how about the ability to specify, on a
>>> class, that all members get automatically imported when it's used as a
>>> parameter, or in a context bound.
>>> A contrived example, but currently we might do something like this:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = {
>>>     val context = implicitly[Numeric[T]]
>>>     import context._
>>>     pair._1 plus pair._2
>>>   }
>>> whereas if Numeric was autoimported:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2
>>>
>>> Originally, I was thinking to propose typeclass as a keyword, alongside
>>> class and object.  Mostly because I imagined this being used only for type
>>> classes
>>> (imaginative naming, eh?)
>>>
>>> Now, I'm thinking it would be just as useful for DSLs.  Imagine something
>>> like this in an ARM library:
>>>   def with(r : Resource)(block : Resource => Unit) = {
>>>     r.open()
>>>     block(r)
>>>     r.close()
>>>   }
>>> If Resource was auto-imported, then we could write:
>>>   with(file) {
>>>     lines foreach { println }
>>>   }
>>> instead of:
>>>   with(file) { f =>
>>>     f.lines foreach { println }
>>>   }
>>>
>>> Once a type (or type constructor) has been marked as autoimportable, this
>>> quality would also be inherited by subclasses.
>>> I've convinced myself that the idea has a lot of potential, but don't
>>> have any definite opinions on the best notation to use.
>>>
>>> What does everyone think?
>>>
>>> --
>>> Kevin Wright
>>>
>>> mail / gtalk / msn : kev.lee.wright@gmail.com
>>> pulse / skype: kev.lee.wright
>>> twitter: @thecoda
>>>
>>
>>
>>
>> --
>> http://erikengbrecht.blogspot.com/
>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I'd make it (implicit import block: Resource => Unit), implicit being optional. But that's too kludgy, imho. I think this needs to be better thought-out.

On Sat, Sep 4, 2010 at 06:46, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Good point :)
I like the syntax.It's low on boilerplate (can't imagine too many such imports in a declaration) It can be used on both parameters and context bounds it doesn't require the introduction of any new keywords
I don't even imagine it would be too hard to implement!


For the DSL use-case, I think something like this would do the trick:
  def with(r : Resource)(block : import Resource => Unit) =


On 4 September 2010 09:39, Jason Zaugg <jzaugg@gmail.com> wrote:

What about clashes between the imported members of various context bounds?

scala> trait Functor[F[_]] { def fmap[A, B](as: F[A], f: A => B): F[B] }
defined trait Functor

scala> def foo[M[_]: Functor, N[_]: Functor] {}
foo: [M[_],N[_]](implicit evidence$1: Functor[M],implicit evidence$2:
Functor[N])Unit

scala> def foo[M[_], N[_]](implicit mf: Functor[M], nf: Functor[M]) {
|   import mf._
|   import nf._
| }

Someone recently suggested a syntactic change for an opt-in version of this.

 def foo[M[_]: import Functor, N[_]: Functor] {}

-jason

On Sat, Sep 4, 2010 at 2:57 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
> I think that a lot of what you're after can be achieved with companion
> singletons and package objects.
> What I'm proposing is something far more controlled.
> I want to pull wildcard imports into a strongly delimited scope for two very
> specific (yet common) use cases.
> No doubt others will come along and find other uses for such an idea
> though...
>
> On 4 September 2010 01:19, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:
>>
>> I have two minds about this...
>> One is that I have a very strong dislike for wildcard imports, and this
>> seems worse.  It's an implicit wildcard import.
>> The other is that almost every time I pick up a Scala library, I receive a
>> bunch of compile errors because I do:
>> import library.foo.{ TheClassIWant, TheOtherClassIWant }
>> ...and as a result don't have all magical implicits that make the library
>> work nicely.
>> So basically providing a way to let library designers specify the
>> implicits that are needed to make the library work properly, and have the
>> compiler magically import them so people like me don't end up digging
>> through documentation and source code figuring out exactly what to import,
>> or feel dirty because they get lazy and add in a wildcard import.
>> In other words, my other mind says the proposal doesn't go far enough.
>> On Fri, Sep 3, 2010 at 6:31 PM, Kevin Wright <kev.lee.wright@gmail.com>
>> wrote:
>>>
>>> This one would need an SID, but how about the ability to specify, on a
>>> class, that all members get automatically imported when it's used as a
>>> parameter, or in a context bound.
>>> A contrived example, but currently we might do something like this:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = {
>>>     val context = implicitly[Numeric[T]]
>>>     import context._
>>>     pair._1 plus pair._2
>>>   }
>>> whereas if Numeric was autoimported:
>>>   def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2
>>>
>>> Originally, I was thinking to propose typeclass as a keyword, alongside
>>> class and object.  Mostly because I imagined this being used only for type
>>> classes
>>> (imaginative naming, eh?)
>>>
>>> Now, I'm thinking it would be just as useful for DSLs.  Imagine something
>>> like this in an ARM library:
>>>   def with(r : Resource)(block : Resource => Unit) = {
>>>     r.open()
>>>     block(r)
>>>     r.close()
>>>   }
>>> If Resource was auto-imported, then we could write:
>>>   with(file) {
>>>     lines foreach { println }
>>>   }
>>> instead of:
>>>   with(file) { f =>
>>>     f.lines foreach { println }
>>>   }
>>>
>>> Once a type (or type constructor) has been marked as autoimportable, this
>>> quality would also be inherited by subclasses.
>>> I've convinced myself that the idea has a lot of potential, but don't
>>> have any definite opinions on the best notation to use.
>>>
>>> What does everyone think?
>>>
>>> --
>>> Kevin Wright
>>>
>>> mail / gtalk / msn : kev.lee.wright@gmail.com
>>> pulse / skype: kev.lee.wright
>>> twitter: @thecoda
>>>
>>
>>
>>
>> --
>> http://erikengbrecht.blogspot.com/
>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Daniel C. Sobral

I travel to the future all the time.

This one would need an SID, but how about the ability to specify, on a class, that all members get automatically imported when it's used as a parameter, or in a context bound.

• It's tremendously hard to implement an export mechanism (this was mostly pre-PaulP and Paul may have a different take on the difficulty)
• Explicit import is considered a win, not a lose, when it comes to readable code, especially in light of implicits
• Getting the scoping right is non-trivial from both the code perspective and from the user perspective (oh no, not another Scala complexity. ;-) )

A contrived example, but currently we might do something like this:
  def sum[T : Numeric](pair : Tuple2[T,T]) = {    val context = implicitly[Numeric[T]]    import context._    pair._1 plus pair._2  }
whereas if Numeric was autoimported:
  def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2

Originally, I was thinking to propose typeclass as a keyword, alongside class and object.  Mostly because I imagined this being used only for type classes (imaginative naming, eh?)

Now, I'm thinking it would be just as useful for DSLs.  Imagine something like this in an ARM library:
  def with(r : Resource)(block : Resource => Unit) = {     r.open()    block(r)    r.close()  }
If Resource was auto-imported, then we could write:
  with(file) {    lines foreach { println }   }
instead of:
  with(file) { f =>    f.lines foreach { println }  }

Once a type (or type constructor) has been marked as autoimportable, this quality would also be inherited by subclasses. I've convinced myself that the idea has a lot of potential, but don't have any definite opinions on the best notation to use.

What does everyone think?

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Fri, Sep 3, 2010 at 3:31 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

This one would need an SID, but how about the ability to specify, on a class, that all members get automatically imported when it's used as a parameter, or in a context bound.

There have been a number of discussions over time about variations on "export"... from the ability to import something simple (e.g., net.liftweb.UsualSuspects which pulls in the 15 or so common Lift imports) to what you're proposing.

David MacIver even went so far as to write up a SIP (Scala Improvement Proposal) which I reviewed and rejected because his use cases had northing to do with the "export" use case... although in subsequent discussions, he pointed out that his SIP covered the "export" case as well.

The main objections to the idea over time have been:

• It's tremendously hard to implement an export mechanism (this was mostly pre-PaulP and Paul may have a different take on the difficulty)
• Explicit import is considered a win, not a lose, when it comes to readable code, especially in light of implicits
• Getting the scoping right is non-trivial from both the code perspective and from the user perspective (oh no, not another Scala complexity. ;-) )

With the above being said, I'd love the idea of some sort of "export" mechanism, especially, if it comes along with the use of method to lend implicits to parameters (especially function body parameters).
 

A contrived example, but currently we might do something like this:
  def sum[T : Numeric](pair : Tuple2[T,T]) = {    val context = implicitly[Numeric[T]]    import context._    pair._1 plus pair._2  }
whereas if Numeric was autoimported:
  def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2

Originally, I was thinking to propose typeclass as a keyword, alongside class and object.  Mostly because I imagined this being used only for type classes (imaginative naming, eh?)

Now, I'm thinking it would be just as useful for DSLs.  Imagine something like this in an ARM library:
  def with(r : Resource)(block : Resource => Unit) = {     r.open()    block(r)    r.close()  }
If Resource was auto-imported, then we could write:
  with(file) {    lines foreach { println }   }
instead of:
  with(file) { f =>    f.lines foreach { println }  }

Once a type (or type constructor) has been marked as autoimportable, this quality would also be inherited by subclasses. I've convinced myself that the idea has a lot of potential, but don't have any definite opinions on the best notation to use.

What does everyone think?

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

On Fri, Sep 3, 2010 at 3:31 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

This one would need an SID, but how about the ability to specify, on a class, that all members get automatically imported when it's used as a parameter, or in a context bound.

There have been a number of discussions over time about variations on "export"... from the ability to import something simple (e.g., net.liftweb.UsualSuspects which pulls in the 15 or so common Lift imports) to what you're proposing.

David MacIver even went so far as to write up a SIP (Scala Improvement Proposal) which I reviewed and rejected because his use cases had northing to do with the "export" use case... although in subsequent discussions, he pointed out that his SIP covered the "export" case as well.

The main objections to the idea over time have been:

• It's tremendously hard to implement an export mechanism (this was mostly pre-PaulP and Paul may have a different take on the difficulty)
• Explicit import is considered a win, not a lose, when it comes to readable code, especially in light of implicits
• Getting the scoping right is non-trivial from both the code perspective and from the user perspective (oh no, not another Scala complexity. ;-) )

With the above being said, I'd love the idea of some sort of "export" mechanism, especially, if it comes along with the use of method to lend implicits to parameters (especially function body parameters).
 

A contrived example, but currently we might do something like this:
  def sum[T : Numeric](pair : Tuple2[T,T]) = {    val context = implicitly[Numeric[T]]    import context._    pair._1 plus pair._2  }
whereas if Numeric was autoimported:
  def sum[T : Numeric](pair : Tuple2[T,T]) = pair._1 plus pair._2

Originally, I was thinking to propose typeclass as a keyword, alongside class and object.  Mostly because I imagined this being used only for type classes (imaginative naming, eh?)

Now, I'm thinking it would be just as useful for DSLs.  Imagine something like this in an ARM library:
  def with(r : Resource)(block : Resource => Unit) = {     r.open()    block(r)    r.close()  }
If Resource was auto-imported, then we could write:
  with(file) {    lines foreach { println }   }
instead of:
  with(file) { f =>    f.lines foreach { println }  }

Once a type (or type constructor) has been marked as autoimportable, this quality would also be inherited by subclasses. I've convinced myself that the idea has a lot of potential, but don't have any definite opinions on the best notation to use.

What does everyone think?

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

+1 to the variant below.

It would be another step towards making Scala type classes (such as
Numeric) as user-friendly as Haskell's. (Along with support for mixing
context-bounds and regular implicit params together on the same
method)

-Ben

On Sat, Sep 4, 2010 at 6:39 PM, Jason Zaugg wrote:
> Someone recently suggested a syntactic change for an opt-in version of this.
>
>  def foo[M[_]: import Functor, N[_]: Functor] {}
>

Actually... (one sleep later) Im having some doubts and going to
qualify my support for this proposal:

What are the use cases? What problem is it solving that cannot already
be solved?

Even if you import the methods of an implicit parameter, what have you
gained? For Numeric, you've got plus(x, y), times(x, y), and of course
that implicit conversion mkNumericOps() that brings the OO-style
numeric operators onto your target object.

So, generally, you seem to still need an implicit conversion to make
Numeric work OO-style. I suspect its the same for most type-classes.
In which case, whats insufficient about the pattern used in Scalaz,
which combines pimped-types and implicit type-classes successfully
already?

Eg http://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/I...

The only reason that doesn't work for Numeric is an unfortunate
"accident", whereby the + operator was unconditionally claimed for
Strings early on, and cannot be easily undone. Otherwise, we'd have a
convenient syntax for Numeric ops today, without any syntax
extensions. See this thread for details and a workaround:

http://scala-programming-language.1934581.n4.nabble.com/scala-Numerics-a...

In short: I feel we need more/wider use cases to motivate this...

-Ben

On Tue, Sep 7, 2010 at 12:19 AM, Ben Hutchison wrote:
> +1 to the variant below.
>
> It would be another step towards making Scala type classes (such as
> Numeric) as user-friendly as Haskell's. (Along with support for mixing
> context-bounds and regular implicit params together on the same
> method)
>
> -Ben
>
> On Sat, Sep 4, 2010 at 6:39 PM, Jason Zaugg wrote:
>> Someone recently suggested a syntactic change for an opt-in version of this.
>>
>>  def foo[M[_]: import Functor, N[_]: Functor] {}
>>
>

Actually... (one sleep later) Im having some  doubts and going to
qualify my support for this proposal:

What are the use cases? What problem is it solving that cannot already
be solved?

Even if you import the methods of an implicit parameter, what have you
gained? For Numeric, you've got plus(x, y), times(x, y), and of course
that implicit conversion mkNumericOps() that brings the OO-style
numeric operators onto your target object.

So, generally, you seem to still need an implicit conversion to make
Numeric work OO-style. I suspect its the same for most type-classes.
In which case, whats insufficient about the pattern used in Scalaz,
which combines pimped-types and implicit type-classes successfully
already?

Eg http://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/Identity.scala

The only reason that doesn't work for Numeric is an unfortunate
"accident", whereby the + operator was unconditionally claimed for
Strings early on, and cannot be easily undone. Otherwise, we'd have a
convenient syntax for Numeric ops today, without any syntax
extensions. See this thread for details and a workaround:

http://scala-programming-language.1934581.n4.nabble.com/scala-Numerics-and-implicits-td2003363.html

In short: I feel we need more/wider use cases to motivate this...

-Ben

On Tue, Sep 7, 2010 at 12:19 AM, Ben Hutchison <brhutchison@gmail.com> wrote:
> +1 to the variant below.
>
> It would be another step towards making Scala type classes (such as
> Numeric) as user-friendly as Haskell's. (Along with support for mixing
> context-bounds and regular implicit params together on the same
> method)
>
> -Ben
>
> On Sat, Sep 4, 2010 at 6:39 PM, Jason Zaugg <jzaugg@gmail.com> wrote:
>> Someone recently suggested a syntactic change for an opt-in version of this.
>>
>>  def foo[M[_]: import Functor, N[_]: Functor] {}
>>
>

On Tue, Sep 7, 2010 at 9:33 AM, Kevin Wright wrote:
> The problem it's solving is with DSLs, and being able to push definitions
> into the scope of a by-name parameter.
> It'll help type classes, and is probably a nice-to-have feature there, but
> DSLs are definitely my main motivation on this one

Ok, point taken, it does make more sense to me in a DSL context than
for type classes.

While the resource mgt example you gave is a good starting point, it
would be nice to see some more DSL use cases to evaluate an import (or
export) proposal against...?

-Ben