-> aka tuple & implicits, or, a case for syntax, or, multiple levels of implicits, or ...

Yep, double implicit convertion is not allowed. First, because the number of tests to be performed increases geometrically, which would make the compiler exceedingly slow. Second, if the compiler would have trouble checking all implicits, imagine the poor programmer! As it is, many already do not condone their usage.   I do not know the exact reasons why there isn't a macro system, but an unhygienic one is the macro version of dynamic typing, which doesn't really seem at all in line with the goals of Scala. But, mostly, Scala tries to NOT need such a thing.   I suggest just using the tuple syntax, instead of the -> operator, as in your last example. It's barely longer. Or, if you truly want to use an arrow, just define it:   scala> implicit def toAMap(s: String) = new AnyRef { def ->(i: Int) = (A(s), i) }
toAMap: (s: String)java.lang.Object{def ->(i: Int): (X.A, Int)}   scala> m = Map("s" -> 2)
m: Map[X.A,Int] = Map(A(s) -> 2)   And, of course, it's not a bug. The specification is explicit that implicit definition cannot be chained to make an expression valid.
On Fri, Aug 21, 2009 at 4:48 PM, Martin S. Weber <martin.weber@nist.gov> wrote:

I'd call it a bug, but what do you think about that? (wait, lemme answer that question, you don't think it's a bug.)

scala> object X {
    | case class A(val s: String)
    | implicit def strToA(s: String) : A = A(s)
    | }
defined module X

scala> import X._
import X._

scala> var m :Map[A, Int] = Map()
m: Map[X.A,Int] = Map()

scala> m = Map(1 -> 2)
<console>:9: error: type mismatch;
 found   : (Int, Int)
 required: (X.A, Int)
      m = Map(1 -> 2)
                ^

scala> m = Map(A("s") -> 2)
m: Map[X.A,Int] = Map(A(s) -> 2)

scala> m = Map("s" -> 2)
<console>:9: error: type mismatch;
 found   : (java.lang.String, Int)
 required: (X.A, Int)
      m = Map("s" -> 2)
                  ^

scala> m = Map(("s", 2))
m: Map[X.A,Int] = Map(A(s) -> 2)

As you can see, the variant with -> that is creating a tuple fails to call the implicit conversion. That's, I assume, because -> makes a tuple by an implicit conversion and then we've already called one level of implicit conversions and not are going to call another etc. etc.

This keeps biting me. Can't we have syntax instead? Please? Or real macros?
Or what would you do? Boilerplate code? Sigh. Oh well, thanks for listening.

Regards,
-Martin [atm: grumpy]

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

On Sat, Aug 22, 2009 at 7:00 AM, Daniel Sobral wrote:
> Yep, double implicit convertion is not allowed. First, because the number of
> tests to be performed increases geometrically, which would make the compiler
> exceedingly slow. Second, if the compiler would have trouble checking all
> implicits, imagine the poor programmer! As it is, many already do not
> condone their usage.
>
> I do not know the exact reasons why there isn't a macro system, but an
> unhygienic one is the macro version of dynamic typing, which doesn't really
> seem at all in line with the goals of Scala. But, mostly, Scala tries to NOT
> need such a thing.

The real problem as I see it is that we don't have explicit language
support for extension methods, so we have to twist the implicit
conversions facility into achieving a similar effect. Prohibiting
double-implicits makes perfect sense when they are actually being used
for implicit conversion, but the restriction is cumbersome and
frustrating when we want to combine conversions with extension
methods.

Not that I'm volunteering to specify and implement such a feature, of
course, so unfortunately my complaint isn't as constructive as it
should be. Nevertheless, I think it's important to identify the real
issue (lack of proper extension methods) even if we currently lack the
means to do something about it.

Stuart

I don't really agree with that. I do not think extension methods is a superior alternative to implicit conversions. Or, rather, I think extension methods is a bad idea, which should be discarded in acceptable alternatives exist. IMHO, of course.

On Fri, Aug 21, 2009 at 9:35 PM, Stuart Cook <scook0@gmail.com> wrote:

On Sat, Aug 22, 2009 at 7:00 AM, Daniel Sobral<dcsobral@gmail.com> wrote:
> Yep, double implicit convertion is not allowed. First, because the number of
> tests to be performed increases geometrically, which would make the compiler
> exceedingly slow. Second, if the compiler would have trouble checking all
> implicits, imagine the poor programmer! As it is, many already do not
> condone their usage.
>
> I do not know the exact reasons why there isn't a macro system, but an
> unhygienic one is the macro version of dynamic typing, which doesn't really
> seem at all in line with the goals of Scala. But, mostly, Scala tries to NOT
> need such a thing.

The real problem as I see it is that we don't have explicit language
support for extension methods, so we have to twist the implicit
conversions facility into achieving a similar effect. Prohibiting
double-implicits makes perfect sense when they are actually being used
for implicit conversion, but the restriction is cumbersome and
frustrating when we want to combine conversions with extension
methods.

Not that I'm volunteering to specify and implement such a feature, of
course, so unfortunately my complaint isn't as constructive as it
should be. Nevertheless, I think it's important to identify the real
issue (lack of proper extension methods) even if we currently lack the
means to do something about it.


Stuart

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

On Sat, Aug 22, 2009 at 10:47 AM, Daniel Sobral wrote:
> I don't really agree with that. I do not think extension methods is a
> superior alternative to implicit conversions. Or, rather, I think extension
> methods is a bad idea, which should be discarded in acceptable alternatives
> exist. IMHO, of course.

Perhaps I misunderstand what you mean, but I don't really see how
anything can be described as an “acceptable alternative” to extension
methods. I mean, either you have the ability to make third-party
functions mimic the syntax of built-in methods, or you don't. Are you
saying that's a bad capability to have?

There are of course many different ways to achieve
extension-method-like effects (C#'s extension methods, Scala's
implicit conversions, Ruby's monkey-patching, Objective-C's categories
etc.), with their own respective advantages and disadvantages.
However, I don't really buy the argument that the underlying concept
of extension methods is something to be avoided.

Stuart

Stuart Cook wrote:
> On Sat, Aug 22, 2009 at 7:00 AM, Daniel Sobral wrote:
>
>> Yep, double implicit convertion is not allowed. First, because the number of
>> tests to be performed increases geometrically, which would make the compiler
>> exceedingly slow. Second, if the compiler would have trouble checking all
>> implicits, imagine the poor programmer! As it is, many already do not
>> condone their usage.
>>
>> I do not know the exact reasons why there isn't a macro system, but an
>> unhygienic one is the macro version of dynamic typing, which doesn't really
>> seem at all in line with the goals of Scala. But, mostly, Scala tries to NOT
>> need such a thing.
>>
>
> The real problem as I see it is that we don't have explicit language
> support for extension methods, so we have to twist the implicit
> conversions facility into achieving a similar effect. Prohibiting
> double-implicits makes perfect sense when they are actually being used
> for implicit conversion, but the restriction is cumbersome and
> frustrating when we want to combine conversions with extension
> methods.
>
> Not that I'm volunteering to specify and implement such a feature, of
> course, so unfortunately my complaint isn't as constructive as it
> should be. Nevertheless, I think it's important to identify the real
> issue (lack of proper extension methods) even if we currently lack the
> means to do something about it.
>
>
> Stuart
>
>
Double implicit conversion exists already. It just has a different name

On Fri, 2009-08-21 at 21:47 -0300, Daniel Sobral wrote:
> I don't really agree with that. I do not think extension methods is a
> superior alternative to implicit conversions.

I am not particularly familiar with the c# implementation but, as I
understand, they are superior in some ways. You don't have unnecessary
allocations and you don't have issues with equality.

Ismael

Ismael Juma wrote:
> On Fri, 2009-08-21 at 21:47 -0300, Daniel Sobral wrote:
>> I don't really agree with that. I do not think extension methods is a
>> superior alternative to implicit conversions.
>
> I am not particularly familiar with the c# implementation but, as I
> understand, they are superior in some ways. You don't have unnecessary
> allocations

True, though I'm not sure how big a problem this is with improvement in
Scala and JVM optimizations.

> and you don't have issues with equality.

Equality only becomes a problem when you have implicit conversions. C#
also supports this but it's much less powerful than Scala's solution.

/Jesper Nordenberg

On Sat, 2009-08-22 at 11:03 +0200, Jesper Nordenberg wrote:
> Ismael Juma wrote:
> > I am not particularly familiar with the c# implementation but, as I
> > understand, they are superior in some ways. You don't have unnecessary
> > allocations
>
> True, though I'm not sure how big a problem this is with improvement in
> Scala and JVM optimizations.

It's still a problem because these optimisations are not reliable (both
in terms of when they apply and due to bugs). There is hope though. :)
Escape analysis will be switched on by default in HotSpot 17, so that
will be a big step forward as it will get a lot more testing then. It
would be interesting to do the same with scalac -optimise once it has no
known severe bugs.

Ismael