an idea I had

I kind of like the idea....
On Wed, Oct 19, 2011 at 1:47 PM, Paul Phillips <paulp@improving.org> wrote:

I don't think it's a good idea because although it's great when it
does what you want, it's easy to see it would break down under
pressure and there'd be no way to do something like mask one name or
resolve an ambiguity without having to move everything into the body.
Still, when it's handy, it's so handy...

scala> def f(import x: String) = length
f: (x: String)Int

scala> f("bippy")
res0: Int = 5

scala> def f[T](x: T, y: T)(implicit import num: Numeric[T]) = plus(x, y)
f: [T](x: T, y: T)(implicit num: Numeric[T])T

scala> f(5, 10)
res1: Int = 15

It looks handy indeed, but to be honest I also find it more dangerous than useful.
How many imports could you have? What happens if you have a name clash or another type of ambiguity? Even worse what happens if in your example you have 2 String arguments? On which of the 2 you're calling length? If only on the one you're importing you will end up with an ugly asymmetry like in:

scala> def f(import x: String, y: String) = length + y.length

In a word it seems to me a price too high to save just a few characters.
I believe the most important rule to be followed when evolving a language should be: "first, do no harm".

My 2 cents
Mario Fusco
http://twitter.com/#!/mariofusco

On Wed, Oct 19, 2011 at 7:49 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I kind of like the idea....
On Wed, Oct 19, 2011 at 1:47 PM, Paul Phillips <paulp@improving.org> wrote:

I don't think it's a good idea because although it's great when it
does what you want, it's easy to see it would break down under
pressure and there'd be no way to do something like mask one name or
resolve an ambiguity without having to move everything into the body.
Still, when it's handy, it's so handy...

scala> def f(import x: String) = length
f: (x: String)Int

scala> f("bippy")
res0: Int = 5

scala> def f[T](x: T, y: T)(implicit import num: Numeric[T]) = plus(x, y)
f: [T](x: T, y: T)(implicit num: Numeric[T])T

scala> f(5, 10)
res1: Int = 15

On Wed, Oct 19, 2011 at 11:18 AM, Mario Fusco wrote:
> It looks handy indeed, but to be honest I also find it more dangerous than
> useful.
> How many imports could you have? ...

You can derive answers to all your questions directly (if you really
want to know) based on the simple desugaring that it is.

def foo(import x: T, y: U, import z: V) = body

becomes

def foo(x: T, y: U, z: V) = { import x._ ; import z._ ; body }

Whatever happens with the latter, that's what happens.

  def foo(import x: T, y: U, import z: V) = body

becomes

 def foo(x: T, y: U, z: V) = { import x._ ; import z._ ; body }

Sorry, but I don't understand your notation or more probably there's a Scala feature that I ignore.
Are you importing a variable instead of a type? Is that allowed in Scala? 

On Wed, Oct 19, 2011 at 2:32 PM, Mario Fusco wrote:
> Are you importing a variable instead of a type? Is that allowed in Scala?

You can import any stable identifier:

scala> val x = "foo"
x: java.lang.String = foo

scala> import x.length
import x.length

scala> length
res0: Int = 3

scala> var y = "bar"
y: java.lang.String = bar

scala> import y.size
:10: error: stable identifier required, but y found.
import y.size
^

On Oct 19, 2011, at 7:47 PM, Paul Phillips wrote:

> I don't think it's a good idea

I agree. Sorry!

Heiko

On Wed, Oct 19, 2011 at 7:47 PM, Paul Phillips <paulp@improving.org> wrote:

I don't think it's a good idea because although it's great when it
does what you want, it's easy to see it would break down under
pressure and there'd be no way to do something like mask one name or
resolve an ambiguity without having to move everything into the body.
Still, when it's handy, it's so handy...

scala> def f(import x: String) = length
f: (x: String)Int

scala> f("bippy")
res0: Int = 5

scala> def f[T](x: T, y: T)(implicit import num: Numeric[T]) = plus(x, y)
f: [T](x: T, y: T)(implicit num: Numeric[T])T

scala> f(5, 10)
res1: Int = 15

If you go that route, you'd want to afford the same convenience for context bounds.
  def f[T: import Numeric](x: T, y: T) = plus(x, y)
I don't mind the syntax; it would be useful for Scalaz users; but right now I'd prefer stability and bug fixes in the language and surrounding tools over more syntactic sugar.
-jason

On 19/10/2011 20:32, Mario Fusco wrote:
> def foo(import x: T, y: U, import z: V) = body
>
> becomes
>
> def foo(x: T, y: U, z: V) = { import x._ ; import z._ ; body }
>
>
> Sorry, but I don't understand your notation or more probably there's a Scala feature that
> I ignore.
> Are you importing a variable instead of a type? Is that allowed in Scala?

It is like the static import of Java...
But at least, I know understand Paul's idea... :-)

Looks like it can have the advantages... and inconveniences of the 'with' keyword found in
some languages (Visual Basic, Pascal perhaps?). In general, people criticize 'with'
because of 'magic' behavior, ambiguity, possible clashes...
Not a problem for short examples as above, but then again, the gain is small (or null!).
It can be bigger in larger functions, but then we hit the above objections...

In short, a cool, powerful tool, than can be used to make holes in your feet...

Seems very similar to the whole

http://www.scala-lang.org/node/1327

Discussion.

On Oct 20, 2011 8:19 AM, "Heiko Seeberger" <heiko.seeberger@googlemail.com> wrote:

On Oct 19, 2011, at 7:47 PM, Paul Phillips wrote:

> I don't think it's a good idea

I agree. Sorry!

Heiko

> scala> def f(import x: String) = length
> f: (x: String)Int
>
> scala> f("bippy")
> res0: Int = 5

I like the idea of syntactic sugar to import parameters into method scope.

This facility or similar has come up repeatedly [including
drmaciver.com/ImportSIP.html, http://www.scala-lang.org/node/7527,
http://www.scala-lang.org/node/7459]. Suggesting people keep finding
(or imagining) the need for it. I'd rather it was kept in the
"deferred" bucket and reconsidered from time to time, rather than
outright rejecting it.

It seems to offer an alternative means to invoke typeclass methods,
than the "pimp-my-library" style currently used by eg Numeric#Ops and
Scalaz. It would be good to see some specific use cases. The Numeric
use case is seeming less crucial to me personally, since (a) 2.9
improved importing with Numeric.Implicits, (b) more tangible prospects
that implicit conversions will be optimized away in an upcoming
version of Scala [via
https://groups.google.com/forum/#!topic/scala-language/KkgK9TfiPWM].

On Thu, Oct 20, 2011 at 4:47 AM, Paul Phillips wrote:
> I don't think it's a good idea because although it's great when it
> does what you want, it's easy to see it would break down under
> pressure and there'd be no way to do something like mask one name or
> resolve an ambiguity without having to move everything into the body.

That doesn't seem too bad? Given that the parameter import is
syntactic sugar anyway, the worst you have to do is occasionally give
up your sugar (in a localised region of code) to resolve some
ambiguity.

Compare with the syntax for ContextBounds (eg def aMethod[T:Numeric]
{..}). They are in the language now, are very handy, yet break down in
two not uncommon situations, (a) when the implicit param takes
multiple type params, or (b) when there are non-context bound implicit
params present. The implicit import syntax seems no worse on the
breakdown-a-bility scale than context bounds.

-Ben

PS I'd love to see restriction (b) on context bounds lifted. When it
strikes, its a pain in the @ss.

On Fri, Oct 21, 2011 at 6:39 PM, Ben Hutchison wrote:
> (b) when there are non-context bound implicit
> params present. The implicit import syntax seems no worse on the
> breakdown-a-bility scale than context bounds.
>
> -Ben
>
> PS I'd love to see restriction (b) on context bounds lifted. When it
> strikes, its a pain in the @ss.

Already happened.

scala> def f[T: Ordering](x: T)(implicit q: String) = x
f: [T](x: T)(implicit evidence$1: Ordering[T], implicit q: String)T