gmane.comp.lang.scala.internals

Re: [scala] Added lock by default and did a minor amount of cleanup. More to come h... (#610)

Paul Phillips — 2012-05-24T17:16:12

It's a regular nondeterministic failure.

On Wednesday, May 23, 2012, Josh Suereth wrote:

Re: URL for latest nightly tarball?

Miles Sabin — 2012-05-24T16:37:20

Fantastic ... thanks :-)

Cheers,


Miles

Re: URL for latest nightly tarball?

Antonio Cunei — 2012-05-24T14:22:06

It's done. Submitted a pull request.
Toni

On 24/05/2012 15:28, Lukas Rytz wrote:

Re: URL for latest nightly tarball?

Lukas Rytz — 2012-05-24T13:28:35

right, there's a bash script that's supposed to do that
https://github.com/lrytz/jenkins-scripts/blob/master/job/a-scala-nightly-latest

it hasn't been updated to the new naming scheme. toni, can you
have a look? the file names seem to be stable now.

thanks,
lukas

On Thu, May 24, 2012 at 3:24 PM, Miles Sabin <miles-XKJT71GPLR04Q++5jOxPmw< at >public.gmane.org> wrote:

URL for latest nightly tarball?

Miles Sabin — 2012-05-24T13:24:20

Hi folks,

This appears to have completely evaporated. There used to be a symlink
to the latest build here,

  http://www.scala-lang.org/archives/downloads/distrib/files/nightly/distributions/scala-2.10.0.latest.tgz

That disappeared a while back, and I've been using

  https://scala-webapps.epfl.ch/jenkins/job/scala-nightly-main/ws/dists/latest/*zip*/latest.zip

since. But that doesn't appear to have updated since
2.10.0-20120504-065643-e52be82eef.

Can we have the symlink to the latest build on scala-lang.org back?

Cheers,


Miles

Re: Max Overload

Jason Zaugg — 2012-05-24T07:22:52

Of course, you're right: overloading only considers the first parameter list.

-jason

Re: Max Overload

Chris Hodapp — 2012-05-24T07:00:21

I don't think that this helps. It only further disallows you from calling 
the no-type-parameter version by adding even more ambiguity (this time, you 
are actually explicitly adding it).

Furthermore, I don't think that implicits can help. They are considered too 
late:

"""
class A

object O {
  def foo[T: TypeTag](x: Int) = x
  def foo[T: TypeTag, U: TypeTag](x: Int)(implicit a: A) = x
}

O.foo(3) // Error ambiguous
"""

If overloading considerations could be invalidated by implicits this would 
work.

============================


Wow. I just tried testing the method described on the page you linked and 
it worked just like I wanted! I was so excited! Then I remembered that the 
build of Scala I was running on had the patch that I link to above 
applied... sigh.

On Thursday, May 24, 2012 1:34:06 AM UTC-5, Jason Zaugg wrote:

Re: Re: Max Overload

Lukas Rytz — 2012-05-24T06:57:04


+1, compare java's rules
http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2
to scala's, 6.26.3 in

http://www.scala-lang.org/archives/downloads/distrib/files/nightly/pdfs/ScalaReference.pdf

great example of how scala / martin simplifies things.

Re: Max Overload

Jason Zaugg — 2012-05-24T06:34:06

As a workaround, you could accept additional implicit parameters
to witness that the type arguments aren't Nothing.

  https://gist.github.com/977526

-jason

Fwd: [scala] Added lock by default and did a minor amount of cleanup. More to come h... (#610)

Josh Suereth — 2012-05-24T02:11:44

This annotation failure seems unrelated to my change....  Anyone have any
ideas?

---------- Forwarded message ----------
From: scala-jenkins <
reply+i-4724224-e0e573445c7f4f663e147c0c1f52883973e7df1b-29006-EymDizFzQUca5t4wFMVjgA< at >public.gmane.org
Date: Wed, May 23, 2012 at 10:07 PM
Subject: Re: [scala] Added lock by default and did a minor amount of
cleanup. More to come h... (#610)
To: Josh Suereth <Joshua.Suereth-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>


jenkins job pr-scala-testsuite-linux-opt: Failed -
https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/158/

---
Reply to this email directly or view it on GitHub:
https://github.com/scala/scala/pull/610#issuecomment-5889173

Re: Re: Max Overload

Chris Hodapp — 2012-05-23T22:54:53


On Wednesday, May 23, 2012 5:18:26 PM UTC-5, som-snytt wrote:

The interface-based solution seems worse than the different-name-based one. 
In either case, you are using a verbose and non-idiomatic solution when 
standard overloading is the pattern that most people would 
expect. Selfishly, I note that neither solution works for me, specifically. 
 


I fail to see how the behavior that emerges from the change I described 
could possibly surprise anyone more than the previous behavior and I don't 
think that a developer brings the actual "rules" to the forefront of their 
mind whenever they make a method call. Rather, they think about what rules 
are in play when the behavior that they get isn't what they expect (i.e. 
compile-time or run-time errors).
 



You are correct. I have brought this up as a possible issue before. Sorry I 
sent you down this path. It is, in fact, a dark one. It's like the XKCD 
about bad kerning: once you start looking for it, you see it everywhere 
(and, in each instance, you question whether it actually exists).



This is exactly what I'm saying.  I feel like this is (or should be) a 
general doctrine of Scala: if what you wrote works, the compiler shouldn't 
infer that you meant something else. Think about how implicits work, for 
example. They only apply their special rules if what you wrote wouldn't 
compile otherwise. At risk of  stretching things a bit, this is part of the 
basic theory of subtype polymorphism that gives rise to the specificity 
rules in the first place: deviate least from what the user wrote by doing 
the smallest possible upcast.
 


This does not seem like a very viable way to compile a larger codebase. Any 
solution that does not allow fully automated compilation seems to be a 
non-starter.
 


This couldn't hurt. 

There may be a compelling feature need for DynamicProxy (for all I know), 

 I am arguing this on two fronts. However, the reality is that I do need 
this overload resolution behavior in order to complete my SOC project.

Re: Re: Poll on how to name manifest replacements

Som Snytt — 2012-05-23T22:21:18


Just for fun:

Mackie has earned a reputation for bringing high-end technology into

Several visitors requested a one-month *typeable *calendar and so I made

The word above "Classable" is the correct spelling for the word. It is very

Make sure Adriaan won't get tripped up by that.

My twelve-tone ear likes Typic and Classic; but Arrayable is really nice
and the others follow from that.

(Full disclosure: those are Bing results, because Google gives results from
Haskell and this thread.)

Re: Re: Max Overload

Som Snytt — 2012-05-23T22:18:26

On Wed, May 23, 2012 at 10:50 AM, Christopher Vogt <
christopher.vogt-vA1bhqPz9FBZXbeN9DUtxg< at >public.gmane.org> wrote:


This was my intuition, too, when I saw that m(=>A) overloads m(A) but you
can't select it.  (At least let me define a disambiguating m2(=>A) which
can call m(=>A)!  Uncurry already optimizes that application.)  But you can
always stick it in an interface and use it that way.  (That's not
grotesque; all we're asking for is a way to name our selection.)

In the end, one sees the wisdom of simplicity.  As a user, is it more
pleasant to encounter a puzzler once in a blue moon, or to experience a
hiccup of hesitation on an 80% basis because several rules apply?

After you work out the puzzler, you're suffused with a sense of blissful
admiration for the beauty and simplicity of the design.

(Consider a friend of mine who recently spent an hour on a bug in his Java
code due to autoboxing and overloading.  That did not make him love Java
more.)

Chris H.'s example looked familiar, and Google says I replied to it on
scala-user.  So it was Chris who sent me down the dark path of fiddling
with overload resolution!  (Actually, there were a couple of posts and bug
reports that made you go hmm.)

Since then, I see O.R. edge cases everywhere.  Recently, someone asked why
isn't tupling used if that's the only transform that type checks?  There
was a bug report that showed the non-intuitive interaction between subtypes
and varargs in specificity; the example fooled everyone's eyes, like an
optical illusion.  Martin neglected to add that there's the derived-class
rule that contributes to relative weight; that rule contributed to another
not-a-bug report.  So that's three rules: applicable-shape, as-specific-as,
and derived-class.

The underlying theme is: I wrote m[T](a,b,c), and that's what I meant: j
type args and k values.  Why can't the compiler just use that to do the
right thing?

How about "scalac -i -Ydo-right", with -i for -interactive.  Every time it
makes a dubious inference, it asks, "Are you sure you want me to infer...?"

I do agree that a robust -Yoverload-debug would be helpful.  Maybe it would
even say: "You need another set of parens to apply m(A) to a tuple, which
appears to type check."

There may be a compelling feature need for DynamicProxy (for all I know),
but I'm not persuaded by the appeal to general usability.  In other words,
now I understand what Martin is talking about.

Re: Re: Poll on how to name manifest replacements

Josh Suereth — 2012-05-23T21:52:46

Context bounds / type traits pretty much *are* interfaces.
On May 23, 2012 3:25 PM, "Falmarri" <psychicsurgeon-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Max Overload

Chris Hodapp — 2012-05-23T21:31:22

Right. The problem is that if you don't supply any type arguments in your 
call, the compiler infers that you might have meant to supply some. Worse, 
it does not prefer the method that would be called without needing 
inference.

This means that in 
"""
object O {
  def foo(x: Int) = x
  def foo[T](x: Int) = x + 1
}
"""
you are unable to make a call like foo(3).
It weighs foo(3) against foo[Nothing](3). Current overloading rules don't 
cause it to choose foo(3).

If I want to allow DynamicProxy's applyDynamic to accept explicit type 
parameters, I can't have this. I need to write something like:
"""
object DynamicProxy {
  def applyDynamic(name: String)(args: Any*): Any = ...
  def applyDynamic[T1: TypeTag](name: String)(args: Any*): Any = ...
  def applyDynamic[T1: TypeTag, T2: TypeTag](name: String)(args: Any*): Any 
= ...
 ...
}
"""

This isn't just about DynamicProxy, though. I genuinely believe that this 
is a case of the compiler not doing what you expect in a destructive way.

On Wednesday, May 23, 2012 4:19:55 PM UTC-5, Eugene Burmako wrote:

Re: Re: Max Overload

martin odersky — 2012-05-23T21:26:57


 - Martin

Re: Max Overload

Eugene Burmako — 2012-05-23T21:19:55

How do you explicitly state that the method you're calling doesn't
need any type arguments?

On May 23, 11:17 pm, martin odersky <martin.oder...-p8DiymsW2f8< at >public.gmane.org> wrote:

Re: Re: Max Overload

martin odersky — 2012-05-23T21:17:29

On Wed, May 23, 2012 at 7:50 PM, Christopher Vogt <
christopher.vogt-vA1bhqPz9FBZXbeN9DUtxg< at >public.gmane.org> wrote:



But you can call it by giving the type arguments explicitly, right?

 - Martin

Re: Re: Poll on how to name manifest replacements

Luke Vilnis — 2012-05-23T20:03:31

That's the whole problem with giving type classes adjective names.

On Wed, May 23, 2012 at 3:25 PM, Falmarri <psychicsurgeon-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Re: Poll on how to name manifest replacements

Falmarri — 2012-05-23T19:25:49


On Wednesday, May 23, 2012 11:47:36 AM UTC-7, Simon Ochsenreither wrote:

Ok whoops, replied to the author instead of the group =P

This is a great point. I was unquestionably for this scheme until this 
post.

Re: Re: Poll on how to name manifest replacements

Simon Ochsenreither — 2012-05-23T18:51:15



No, you misunderstood. The fact that we have to deal with such problems is 
an implementation detail, just like Arrays.
We shouldn't have to care about it, but we need to.