it's a matter of national security

Hi Paul.

This is indeed bad, but I believe the culprit lies elsewhere. It's not
reasonable to widen an if-then-else
with one Int branch and one Long branch to an Any. Generally, we need
to be more careful when computing the lub/glb between numeric types.
This should be special-cased to yield the larger of the two types. I
am also each time annoyed I type

List(0, 0, 0.5) can get a List[Any] instead of a List[Double].

Cheers

On Sat, Oct 31, 2009 at 11:03:44PM +0100, martin odersky wrote:
> This is indeed bad, but I believe the culprit lies elsewhere.

Ah, well that comes toward my point: that in the face of these semantics
what was once "elsewhere" is now an integral component of equality
whether we like it or not. Anything which influences type inference can
also influence whether two entities will be considered equal.

> It's not reasonable to widen an if-then-else with one Int branch and
> one Long branch to an Any.

AnyVal, but yes, exactly. I'm very glad to hear you feel that way, I
was afraid that inferring AnyVal was going to be a requirement given the
inheritance hierarchy. So far in my life I have wanted AnyVal to be
the inferred type, let me count them up here, exactly never.

Any is a tiny bit more useful, but only a tiny bit. Here is an
observation: I never want Any or AnyVal to be inferred. If I want to
use those types I will say so explicitly. The rest of the time if that
is what is inferred, it means I made a mistake.

If at all possible I would like to get that numeric inference change in
place before I check in any equality change, lest we end up chasing
mysteries needlessly. I can take a stab at it if you want. If we had
that then maybe we wouldn't need the other component of what I will
propose (but I still think we should) which is: no automatic coercions
between primitives whatsoever.

val x: Byte = 5 // type error
def f(x: Long) { } ; f(5) // type error
someLong | someInt // type error

It's not hard to anticipate resistance to this and I can make the case
for it at length when I have more than a couple minutes, but let me
observe that I already brought trunk into line with these semantics and
not only was it less work than I'd anticipated, the resulting code was
clearly better. I think now it would be a good idea even if we had no
equality issues anywhere.

(I did introduce byte and short literals, e.g. 5b and 10s, to compensate
for those types not being inferred from int literals.)

I moved these lines out of Predef into their own object, so they can
still be imported on a case-by-case basis.

implicit def byte2short(x: Byte): Short = x.toShort
implicit def byte2int(x: Byte): Int = x.toInt
implicit def byte2long(x: Byte): Long = x.toLong
implicit def byte2float(x: Byte): Float = x.toFloat
implicit def byte2double(x: Byte): Double = x.toDouble

implicit def short2int(x: Short): Int = x.toInt
implicit def short2long(x: Short): Long = x.toLong
implicit def short2float(x: Short): Float = x.toFloat
implicit def short2double(x: Short): Double = x.toDouble

implicit def char2int(x: Char): Int = x.toInt
implicit def char2long(x: Char): Long = x.toLong
implicit def char2float(x: Char): Float = x.toFloat
implicit def char2double(x: Char): Double = x.toDouble

implicit def int2long(x: Int): Long = x.toLong
implicit def int2float(x: Int): Float = x.toFloat
implicit def int2double(x: Int): Double = x.toDouble

implicit def long2float(x: Long): Float = x.toFloat
implicit def long2double(x: Long): Double = x.toDouble

implicit def float2double(x: Float): Double = x.toDouble

I hope we can leave the door open to this even if you're not immediately
enamored of the idea, because based on this:

> To me there are two non-negotiables.:
>
> 1) We cannot mess with the equals/hashCode contract.
> 2) == in Scala must yield true wherever == in Java yields true.

...by themselves these two statements are irreconcilable unless for a
given A and B, the truth value of A == B varies depending on the static
types of A and B. That means the ONLY place I can achieve some measure
of consistency and limit the ugly surprises is by requiring everything
which might influence the static type of numerics to be explicit,
wherever possible.

It doesn't solve every single issue, but given 1) and 2) above it's as
close as I can imagine us getting.

Hi Paul,

On Sun, 2009-11-01 at 09:13 -0800, Paul Phillips wrote:
> On Sat, Oct 31, 2009 at 11:03:44PM +0100, martin odersky wrote:
> > It's not reasonable to widen an if-then-else with one Int branch and
> > one Long branch to an Any.
>
> AnyVal, but yes, exactly. I'm very glad to hear you feel that way

Me too.

> I will propose (but I still think we should) which is: no automatic coercions
> between primitives whatsoever.
>
> val x: Byte = 5 // type error
> def f(x: Long) { } ; f(5) // type error
> someLong | someInt // type error

I am also in favour of this.

> (I did introduce byte and short literals, e.g. 5b and 10s, to compensate
> for those types not being inferred from int literals.)

I think this is useful independent of everything else.

> I moved these lines out of Predef into their own object, so they can
> still be imported on a case-by-case basis.
>
> implicit def byte2short(x: Byte): Short = x.toShort
> implicit def byte2int(x: Byte): Int = x.toInt
> implicit def byte2long(x: Byte): Long = x.toLong
> implicit def byte2float(x: Byte): Float = x.toFloat
> implicit def byte2double(x: Byte): Double = x.toDouble
>
> implicit def short2int(x: Short): Int = x.toInt
> implicit def short2long(x: Short): Long = x.toLong
> implicit def short2float(x: Short): Float = x.toFloat
> implicit def short2double(x: Short): Double = x.toDouble
>
> implicit def char2int(x: Char): Int = x.toInt
> implicit def char2long(x: Char): Long = x.toLong
> implicit def char2float(x: Char): Float = x.toFloat
> implicit def char2double(x: Char): Double = x.toDouble
>
> implicit def int2long(x: Int): Long = x.toLong
> implicit def int2float(x: Int): Float = x.toFloat
> implicit def int2double(x: Int): Double = x.toDouble
>
> implicit def long2float(x: Long): Float = x.toFloat
> implicit def long2double(x: Long): Double = x.toDouble
>
> implicit def float2double(x: Float): Double = x.toDouble

Sounds like a good compromise so that people can still get the automatic
conversions if they prefer.

Best,
Ismael

Paul Phillips a écrit :
> no automatic coercions
> between primitives whatsoever.
>
> val x: Byte = 5 // type error
> def f(x: Long) { } ; f(5) // type error
> someLong | someInt // type error

Oh yes PLEASE ! Assignment to a different type must NOT typecheck
without implicit - and primitives are not different here.
This solution has my vote (well, even several if I'm allowed).

All~

I have to agree, the number of bugs that finding auto-promotion of
primitives has caused dwarfs the savings of being able to type '0'
instead of '0.0'.

Matt

On Sun, Nov 1, 2009 at 2:36 PM, Francois Armand wrote:
> Paul Phillips a écrit :
>>
>> no automatic coercions between primitives whatsoever.
>>
>>  val x: Byte = 5           // type error
>>  def f(x: Long) { } ; f(5) // type error
>>  someLong | someInt        // type error
>
>
> Oh yes PLEASE ! Assignment to a different type must NOT typecheck without
> implicit - and primitives are not different here.
> This solution has my vote (well, even several if I'm allowed).
>
> --
> Francois Armand
> http://fanf42.blogspot.com
>

+1

If an ANY explicit type conversion is wanted, then the user should
explicitly import that behaviour.
Primitives are no different here.

Another +1 for byte/short suffixes, these have long been absent from
both scala and java.

On Sun, Nov 1, 2009 at 6:50 PM, Matt Fowles wrote:
> All~
>
> I have to agree, the number of bugs that finding auto-promotion of
> primitives has caused dwarfs the savings of being able to type '0'
> instead of '0.0'.
>
> Matt
>
> On Sun, Nov 1, 2009 at 2:36 PM, Francois Armand wrote:
>> Paul Phillips a écrit :
>>>
>>> no automatic coercions between primitives whatsoever.
>>>
>>>  val x: Byte = 5           // type error
>>>  def f(x: Long) { } ; f(5) // type error
>>>  someLong | someInt        // type error
>>
>>
>> Oh yes PLEASE ! Assignment to a different type must NOT typecheck without
>> implicit - and primitives are not different here.
>> This solution has my vote (well, even several if I'm allowed).
>>
>> --
>> Francois Armand
>> http://fanf42.blogspot.com
>>
>

Hi Paul,

Your mail surprised me quite a bit and troubled me to no small degree.

On Sun, Nov 1, 2009 at 6:13 PM, Paul Phillips wrote:
> On Sat, Oct 31, 2009 at 11:03:44PM +0100, martin odersky wrote:
>> This is indeed bad, but I believe the culprit lies elsewhere.
>
> Ah, well that comes toward my point: that in the face of these semantics
> what was once "elsewhere" is now an integral component of equality
> whether we like it or not.  Anything which influences type inference can
> also influence whether two entities will be considered equal.
>
>> It's not reasonable to widen an if-then-else with one Int branch and
>> one Long branch to an Any.
>
> AnyVal, but yes, exactly.  I'm very glad to hear you feel that way, I
> was afraid that inferring AnyVal was going to be a requirement given the
> inheritance hierarchy.  So far in my life I have wanted AnyVal to be
> the inferred type, let me count them up here, exactly never.
>
> Any is a tiny bit more useful, but only a tiny bit.  Here is an
> observation: I never want Any or AnyVal to be inferred.  If I want to
> use those types I will say so explicitly.  The rest of the time if that
> is what is inferred, it means I made a mistake.
>
> If at all possible I would like to get that numeric inference change in
> place before I check in any equality change, lest we end up chasing
> mysteries needlessly.  I can take a stab at it if you want.

Agreed to that. I'd like to take a look at the spec first, to see how
we can accommodate this.

> If we had
> that then maybe we wouldn't need the other component of what I will
> propose (but I still think we should) which is: no automatic coercions
> between primitives whatsoever.
>
>  val x: Byte = 5           // type error
>  def f(x: Long) { } ; f(5) // type error
>  someLong | someInt        // type error
>
I can't imagine that will fly. If we did that everybody would
immediately add the required implicits (because that's all they are,
right now).

> It's not hard to anticipate resistance to this and I can make the case
> for it at length when I have more than a couple minutes, but let me
> observe that I already brought trunk into line with these semantics and
> not only was it less work than I'd anticipated, the resulting code was
> clearly better.  I think now it would be a good idea even if we had no
> equality issues anywhere.
>
I don't believe trunk is in any way representative for this. There is
almost no mixed computation in trunk. You'd have to look at numeric
codes or bit-fiddling codes instead to see where it matters.

> (I did introduce byte and short literals, e.g. 5b and 10s, to compensate
> for those types not being inferred from int literals.)

Wait, where is that speced? I'd be totally against adding this to the
language. If you need 1 to be a byte, write (1: Byte). No more special
cases for literals, please! Instead, I would really value if we could
find an extensible syntax for literals. Study what's in Fortress, they
have made some progress in this direction.

> I moved these lines out of Predef into their own object, so they can
> still be imported on a case-by-case basis.
>
>  implicit def byte2short(x: Byte): Short = x.toShort
>  implicit def byte2int(x: Byte): Int = x.toInt
>  implicit def byte2long(x: Byte): Long = x.toLong
>  implicit def byte2float(x: Byte): Float = x.toFloat
>  implicit def byte2double(x: Byte): Double = x.toDouble
>
>  implicit def short2int(x: Short): Int = x.toInt
>  implicit def short2long(x: Short): Long = x.toLong
>  implicit def short2float(x: Short): Float = x.toFloat
>  implicit def short2double(x: Short): Double = x.toDouble
>
>  implicit def char2int(x: Char): Int = x.toInt
>  implicit def char2long(x: Char): Long = x.toLong
>  implicit def char2float(x: Char): Float = x.toFloat
>  implicit def char2double(x: Char): Double = x.toDouble
>
>  implicit def int2long(x: Int): Long = x.toLong
>  implicit def int2float(x: Int): Float = x.toFloat
>  implicit def int2double(x: Int): Double = x.toDouble
>
>  implicit def long2float(x: Long): Float = x.toFloat
>  implicit def long2double(x: Long): Double = x.toDouble
>
>  implicit def float2double(x: Float): Double = x.toDouble
>
> I hope we can leave the door open to this even if you're not immediately
> enamored of the idea, because based on this:
>
>> To me there are two non-negotiables.:
>>
>> 1) We cannot mess with the equals/hashCode contract.
>> 2) == in Scala must yield true wherever == in Java yields true.
>
> ...by themselves these two statements are irreconcilable unless for a
> given A and B, the truth value of A == B varies depending on the static
> types of A and B.

That's indeed a consequence, which is also true for almost every other
language on the planet.

> That means the ONLY place I can achieve some measure
> of consistency and limit the ugly surprises is by requiring everything
> which might influence the static type of numerics to be explicit,
> wherever possible.
>
> It doesn't solve every single issue, but given 1) and 2) above it's as
> close as I can imagine us getting.

I do not think we are getting anywhere. If we want to do these big
changes we have to discuss them beforehand. I hope you did not add
these things to trunk?

I am going to put a foot down now and say that equality and implicits
between numeric types will remain as in the spec, barring a formal SIP
process, which will take time. I realize that some people do not like
it, but given that we only have a couple of days to 2.8 I have to make
a decision, and that's what it is.

Please tell me whether you want to implement it or I should do it.

Generally I get this feeling that coherence between the compiler and
the language spec is sacrificed for experiments and undiscussed
commits to the compiler and I am troubled by that. Let me state what
for me are non-negotiables:

Any change to the spec is discussed and agreed to by me before it is
implemented in trunk.
The spec includes what's in Predef.

I value you a lot as a committer (that's even an understatement) but I
am charged to keep Scala consistent in many different dimensions, and
this procedure is the only way I can do that.

I hope you understand and agree to that model.

Cheers

Hi Martin,

On Sun, 2009-11-01 at 21:07 +0100, martin odersky wrote:
> Any change to the spec is discussed and agreed to by me before it is
> implemented in trunk.

Paul will surely clarify this when he has a chance, but I see all
commits that go to trunk and I don't think any of the things he proposed
here are in trunk. When Paul says, "I implemented X", I believe he means
that he did it in a personal branch locally or in GitHub.

Best,
Ismael

On Sun, Nov 1, 2009 at 6:07 PM, martin odersky <martin.odersky@epfl.ch> wrote:

Hi Paul,

> If we had
> that then maybe we wouldn't need the other component of what I will
> propose (but I still think we should) which is: no automatic coercions
> between primitives whatsoever.
>
>  val x: Byte = 5           // type error
>  def f(x: Long) { } ; f(5) // type error
>  someLong | someInt        // type error
>
I can't imagine that will fly. If we did that everybody would
immediately add the required implicits (because that's all they are,
right now).

I'm inclined to believe otherwise, and the replies to Paul's e-mail reinforce my conviction.
Using the same literal syntax for all numerals cause all sorts of problem. Working with bytes, for which no literals exists, is a tremendous pain.  I might add the implicits between Int and Double to my code but, likely, I wouldn't.
When using mixed arithmetic it is even more important than ever to be sure they don't mix unintentionally.
On an _unrelated subject_, as for the byte and short literals, I much like them, as would anyone who has worked a lot with network protocols. In fact, I like the coin changes as well. So, let me just register my opinion heavily in their favor as a Scala programmer.
Of course, as a programmer I'd be very upset if any such changes were not spec'ed as well, but since this is scala-internals, I expect things to be fully worked out before hitting the trunk.
--
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 Sun, 2009-11-01 at 18:36 -0200, Daniel Sobral wrote:
>
>
> On Sun, Nov 1, 2009 at 6:07 PM, martin odersky
> wrote:
> Hi Paul,
>
> > If we had
> > that then maybe we wouldn't need the other component of what
> I will
> > propose (but I still think we should) which is: no automatic
> coercions
> > between primitives whatsoever.
> >
> > val x: Byte = 5 // type error
> > def f(x: Long) { } ; f(5) // type error
> > someLong | someInt // type error
> >
>
> I can't imagine that will fly. If we did that everybody would
> immediately add the required implicits (because that's all
> they are,
> right now).
>
>
> I'm inclined to believe otherwise, and the replies to Paul's e-mail
> reinforce my conviction.

Indeed and another statement from Martin in the same email supports
this:

"I don't believe trunk is in any way representative for this. There is
almost no mixed computation in trunk. You'd have to look at numeric
codes or bit-fiddling codes instead to see where it matters."

As I understand it, that says that this is only applicable in some
scenarios (i.e. not everybody would do it). In those scenarios, they are
free to import the implicit conversions (I still think it's a bad idea
though).

> Using the same literal syntax for all numerals cause all sorts of
> problem. Working with bytes, for which no literals exists, is a
> tremendous pain.
>
> I might add the implicits between Int and Double to my code but,
> likely, I wouldn't.
>
> When using mixed arithmetic it is even more important than ever to be
> sure they don't mix unintentionally.
>
> On an _unrelated subject_, as for the byte and short literals, I much
> like them, as would anyone who has worked a lot with network
> protocols. In fact, I like the coin changes as well. So, let me just
> register my opinion heavily in their favor as a Scala programmer.

Indeed.

Having said that, I understand Martin's reluctance as there is pressure
to get 2.8.0 out there and last-minute changes can be problematic. At
the same time, it's also worth considering if these changes would be
possible in the future, given backwards compatibility guarantees that
may be given once 2.8.0 is out.

Ismael

I have about 2 seconds while changing planes, but in all cases when
referencing implementation it's on my machine, and I only mention it at
all to illustrate that I know it's viable. I'm generally not explicit
about whether I checked something in because I kind of figured you can
see the actual commits.

On Nov 1, 2009, at 3:07 PM, martin odersky wrote:
> Wait, where is that speced? I'd be totally against adding this to the
> language.

I take it the experiments with code review bogged down and stopped
being followed. If you guys try it again, I can recommend the
Rietveld tool. You can upload the code and then view it and review it
in a web browser.

I won't lie. It's still a bit of a hassle, and it does slow progress
down somewhat. However, it does mean at least two people are aware of
every change. Also, I find that I write code a little differently if
I know it's going to be reviewed before I can commit it. I reread it
myself, I remove stray bits from the patch, I'm more likely to write a
test....

Lex

On Nov 1, 2009, at 1:50 PM, Matt Fowles wrote:
> I have to agree, the number of bugs that finding auto-promotion of
> primitives has caused dwarfs the savings of being able to type '0'
> instead of '0.0'.

Literals don't necessarily have to be lumped in with arbitrary
expressions. Auto-conversion of literals looks extremely safe and
convenient.

For general expressions, the main question I wonder about is whether
we end up with so many conversions in code that they become useless.
If common cases end up needing explicit conversion, then code would
end up littered with conversions. This is bad enough by itself, but
it's worse when you realize that programmers stop considering each
conversion and start adding them automatically to shut the compiler up.

What the "common" cases are, I don't know. I think the Java rules
have found a good balance, but I don't have any solid evidence. I'm
happy, and the folks I've talked to are happy, and that's not true in
other languages i've used that required a larger number of explicit
conversions.

Lex

On Sun, Nov 1, 2009 at 1:53 PM, Lex Spoon <lex@lexspoon.org> wrote:

On Nov 1, 2009, at 3:07 PM, martin odersky wrote:

Wait, where is that speced? I'd be totally against adding this to the
language.

I take it the experiments with code review bogged down and stopped being followed.  If you guys try it again, I can recommend the Rietveld tool.  You can upload the code and then view it and review it in a web browser.

I won't lie.  It's still a bit of a hassle, and it does slow progress down somewhat.  However, it does mean at least two people are aware of every change.  Also, I find that I write code a little differently if I know it's going to be reviewed before I can commit it.  I reread it myself, I remove stray bits from the patch, I'm more likely to write a test....

We've been doing Review Board with Lift for the last 6 weeks.  Yes, it slows things down a little.  On the other hand, the quality of the code (and the amount of documentation I've written) has increased substantially.
 

Lex

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

On Sun, Nov 1, 2009 at 10:09 PM, Paul Phillips wrote:
> I have about 2 seconds while changing planes, but in all cases when
> referencing implementation it's on my machine, and I only mention it at
> all to illustrate that I know it's viable.  I'm generally not explicit
> about whether I checked something in because I kind of figured you can
> see the actual commits.
>
Yes, I can, but only at work. From my home machine I never got a good
setup where I can monitor commits easily. Anyway, thanks for
clarifying this! I take what you did as a basis for discussion, and we
can certainly discuss. I was only worried that things make it into
trunk without that discussion.

Cheers

On Sun, Nov 1, 2009 at 9:36 PM, Daniel Sobral wrote:
>
>
> On Sun, Nov 1, 2009 at 6:07 PM, martin odersky
> wrote:
>>
>> Hi Paul,
>>
>> > If we had
>> > that then maybe we wouldn't need the other component of what I will
>> > propose (but I still think we should) which is: no automatic coercions
>> > between primitives whatsoever.
>> >
>> >  val x: Byte = 5           // type error
>> >  def f(x: Long) { } ; f(5) // type error
>> >  someLong | someInt        // type error
>> >
>> I can't imagine that will fly. If we did that everybody would
>> immediately add the required implicits (because that's all they are,
>> right now).
>>
> I'm inclined to believe otherwise, and the replies to Paul's e-mail
> reinforce my conviction.

I have learned from many years experience that one should be very
careful with evaluating e-mail responses. There have been many issues
where followed what was seemingly public opinon, only to raise a storm
from all the people who were happy with the previous status quo and
were unhappy with the changes after they were made.

> Using the same literal syntax for all numerals cause all sorts of problem.
> Working with bytes, for which no literals exists, is a tremendous pain.
>
No, it's not: 1: Byte is all you need to say. What could be clearer?
Why invent cryptic one letter suffixes?

> I might add the implicits between Int and Double to my code but, likely, I
> wouldn't.
> When using mixed arithmetic it is even more important than ever to be sure
> they don't mix unintentionally.

But the fact is, they are spec'ed, and implemented, and used. They
won't go away without a major community driven effort, backed by a
formal SIP. And I sincerely doubt such a SIP would fly. Scala is
beyond the age where we can change such things on a whim. Right now,
if you you don't like these conversions , you can always unimport
them from Predef.

Cheers

I fully agree that code review is good. The problem is finding
reviewers. Everybody wants me to review their code and I am the person
least likely to find the time to do it. That's the fundamental problem
we need to address. So, how can we find a way to match reviewers with
contributors?

Cheers

On Sunday 01 November 2009 20:13:22 Paul Phillips wrote:
...
> (I did introduce byte and short literals, e.g. 5b and 10s, to compensate
> for those types not being inferred from int literals.)

Would be very appreciated!

I have met real situations lacking numeric literals clearness. And, of course
there are ones uncovered yet, but - by good luck only - working at available
tests.

Andrew

On Sun, Nov 1, 2009 at 2:42 PM, martin odersky <martin.odersky@epfl.ch> wrote:

I fully agree that code review is good. The problem is finding
reviewers.

It's up to the submitter to get reviewers.  For the most part, it works because everyone is relying on everyone else, so it's hard to say "No" because people are going to say "no" back to you.
 

Everybody wants me to review their code and I am the person
least likely to find the time to do it.

I have a personal policy that I rarely review code unless there's a compelling reason to review it.  There are also changes that I ask particular people to review because they have experiese in the given area.

For the most part after about a week of everyone looking at their thumbs waiting for people to review their code, they start reviewing and you get a good cycle.

Thanks,

David
 

That's the fundamental problem
we need to address. So, how can we find a way to match reviewers with
contributors?

Cheers

On Sun, Nov 1, 2009 at 8:37 PM, martin odersky <martin.odersky@epfl.ch> wrote:

> Using the same literal syntax for all numerals cause all sorts of problem. > Working with bytes, for which no literals exists, is a tremendous pain.
>
No, it's not: 1: Byte is all you need to say. What could be clearer?
Why invent cryptic one letter suffixes?

It is very clear indeed, Martin, if not at all intuitive -- as in, I wouldn't think of writing it this way.
However, it becomes a problem when you have hundreds or even thousands of lines of code with expressions involving four, eight byte (or short) literals. It gets rather inconvenient.
Alas, that was with C many years ago. In the past two years I had to write no more than five lines involving byte manipulation, with as many byte literals. I spent an inordinate amount of time trying to get the code to work, precisely because I couldn't figure out how to write a byte literal.
As for cryptic one letter suffixes, we are all pretty used to adding an "L" for Long. A "B" suffix might look unfamiliar for all of 15 seconds. An "S" suffix might get a longer look, but, then again, shorts are even rarer than bytes. On the other hand, I can't recall a single language where a byte literal is written as "1 : Byte".
And, even more cryptic than that is the fact that "0010" is 8, and, yet, because of a very old tradition, so it is.
So, my own point of view, as someone who did a lot of work with bytes and shorts and some rather arbitrarily-sized and inconvenient bit lengths, is that a "B" suffix will please anyone who does need to work with bytes a lot, that a ": Byte" suffix will displease them, and that the kind of code that will use such things is so niche that "cryptic" is rather irrelevant at any rate. But it's still more likely to get used than octal notation.
That's just my 2 cents. I'm not going to throw any fits one way or parties the other, but I think it is important to present a viewpoint that might not be familiar to people working with other kinds of software.  

> I might add the implicits between Int and Double to my code but, likely, I
> wouldn't.
> When using mixed arithmetic it is even more important than ever to be sure
> they don't mix unintentionally.

But the fact is, they are spec'ed, and implemented, and used. They
won't go away without a major community driven effort, backed by a
formal SIP. And I sincerely doubt such a SIP would fly. Scala is
beyond the age where we can change such things on a whim. Right now,
if you  you don't like these conversions , you can always unimport
them from Predef.

I'm not pressing for change here, just stating my opinion on the matter. How can one ever make informed decisions without information?

--
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 Mon, Nov 2, 2009 at 4:51 AM, Daniel Sobral wrote:
> On Sun, Nov 1, 2009 at 8:37 PM, martin odersky
> wrote:
>>
>> > Using the same literal syntax for all numerals cause all sorts of
>> > problem.
>> > Working with bytes, for which no literals exists, is a tremendous pain.
>> >
>> No, it's not: 1: Byte is all you need to say. What could be clearer?
>> Why invent cryptic one letter suffixes?
>
> It is very clear indeed, Martin, if not at all intuitive -- as in, I
> wouldn't think of writing it this way.
> However, it becomes a problem when you have hundreds or even thousands of
> lines of code with expressions involving four, eight byte (or short)
> literals. It gets rather inconvenient.
> Alas, that was with C many years ago. In the past two years I had to write
> no more than five lines involving byte manipulation, with as many byte
> literals. I spent an inordinate amount of time trying to get the code to
> work, precisely because I couldn't figure out how to write a byte literal.
> As for cryptic one letter suffixes, we are all pretty used to adding an "L"
> for Long. A "B" suffix might look unfamiliar for all of 15 seconds. An "S"
> suffix might get a longer look, but, then again, shorts are even rarer than
> bytes. On the other hand, I can't recall a single language where a byte
> literal is written as "1 : Byte".
> And, even more cryptic than that is the fact that "0010" is 8, and, yet,
> because of a very old tradition, so it is.
> So, my own point of view, as someone who did a lot of work with bytes and
> shorts and some rather arbitrarily-sized and inconvenient bit lengths, is
> that a "B" suffix will please anyone who does need to work with bytes a lot,
> that a ": Byte" suffix will displease them, and that the kind of code that
> will use such things is so niche that "cryptic" is rather irrelevant at any
> rate. But it's still more likely to get used than octal notation.
> That's just my 2 cents. I'm not going to throw any fits one way or parties
> the other, but I think it is important to present a viewpoint that might not
> be familiar to people working with other kinds of software.
>
>>
>> > I might add the implicits between Int and Double to my code but, likely,
>> > I
>> > wouldn't.
>> > When using mixed arithmetic it is even more important than ever to be
>> > sure
>> > they don't mix unintentionally.
>>
>> But the fact is, they are spec'ed, and implemented, and used. They
>> won't go away without a major community driven effort, backed by a
>> formal SIP. And I sincerely doubt such a SIP would fly. Scala is
>> beyond the age where we can change such things on a whim. Right now,
>> if you  you don't like these conversions , you can always unimport
>> them from Predef.
>>
> I'm not pressing for change here, just stating my opinion on the matter. How
> can one ever make informed decisions without information?
>
Hi Daniel,

Thanks for your opinions. Yes, of course I'm interested in knowing
them, and also the ones of the others. The point was, there's a
decision not to do anything like that for 2.8. Rather than simply
shutting off the debate with that message I wanted to give my reasons
for the decision. That does not mean I do not encourage debate.

Cheers

Hi David,

I like your suggestions. I''ll discuss them with the people at EPFL at
the next Scala meeting tomorrow. Paul, Miles, and other external
contributors, what are your opinions on code review?

Cheers

On Mon, Nov 2, 2009 at 9:18 AM, martin odersky wrote:
> I like your suggestions. I''ll discuss them with the people at EPFL at
> the next Scala meeting tomorrow. Paul, Miles, and other external
> contributors, what are your opinions on code review?

It's a Good Thing, obviously. I agree with you that the main issue is
the availability of reviewer cycles.

I'm less convinced by review board type software however. I review all
IDE patches that come my way and I find it quite straightforward to do
that without (although I suppose Eclipse's facility to preview patches
as side by side diffs covers quite a lot of the EPFL review board's
functionality).

I "review" compiler and library changes for impact on the IDE when I
see the SVN commit messages, and then again when I update (again,
Eclipse is helpful here). I find that the immediacy of likely impact
of an incoming change tends to focus the attention more than a more
distant and polite review request does.

Cheers,

Miles

I am a huge fan of Code Reviews.  The first project that made me do them regularily literally changed the way I develop software. 
I like ReviewBoard(and  Rietveld) better than simply emailing patches because I like the history and openness that is maintained when using ReviewBoard (or alternative).  Email is too private for my taste and ReviewBoard has the benefit of being able to annotate lines which makes reviews very nice.  The big minus for me is not being able to do realtime discussions easily.  I would like to experiment with Wave at some point to see if it could be used for this sort of task.
Jesse
On Mon, Nov 2, 2009 at 10:48 AM, Miles Sabin <miles@milessabin.com> wrote:

On Mon, Nov 2, 2009 at 9:18 AM, martin odersky <martin.odersky@epfl.ch> wrote:
> I like your suggestions. I''ll discuss them with the people at EPFL at
> the next Scala meeting tomorrow. Paul, Miles, and other external
> contributors, what are your opinions on code review?

It's a Good Thing, obviously. I agree with you that the main issue is
the availability of reviewer cycles.

I'm less convinced by review board type software however. I review all
IDE patches that come my way and I find it quite straightforward to do
that without (although I suppose Eclipse's facility to preview patches
as side by side diffs covers quite a lot of the EPFL review board's
functionality).

I "review" compiler and library changes for impact on the IDE when I
see the SVN commit messages, and then again when I update (again,
Eclipse is helpful here). I find that the immediacy of likely impact
of an incoming change tends to focus the attention more than a more
distant and polite review request does.

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Hi Martin,

On Sun, 2009-11-01 at 23:42 +0100, martin odersky wrote:
> I fully agree that code review is good. The problem is finding
> reviewers. Everybody wants me to review their code and I am the person
> least likely to find the time to do it. That's the fundamental problem
> we need to address. So, how can we find a way to match reviewers with
> contributors?

In other projects where reviewer cycles are hard to find, I use a system
where:

(1) I commit trivial fixes directly (review after commit, if necessary).

(2) If I am confident about a change, but it may have a small impact
(e.g. a new API method) or someone else knows the area better than me, I
ask for review and give a (generous) date on when I plan to commit. If
no-one says anything, I go ahead and commit. This gives reviewers the
opportunity to express concerns without causing too much of a slowdown.
They can also just say "I'm not too comfortable with the change, but I
won't have time to review it properly by the date given" to remove the
time deadline.

(3) For more complex changes, at least one person should review the
code.

It obviously helps to have many reviewers and I think the standard
library is an area where this is achievable as one gets familiar with it
during normal usage (unlike the compiler).

Of course, this only works if people actually have the time to do
reviews. If changes in (3) take ages to be reviewed and the ones in (2)
end up getting in after the time expires with no comments, then it seems
pointless.

Best,
Ismael

On Mon, Nov 2, 2009 at 11:52 AM, Ismael Juma wrote:
> Hi Martin,
>
> On Sun, 2009-11-01 at 23:42 +0100, martin odersky wrote:
>> I fully agree that code review is good. The problem is finding
>> reviewers. Everybody wants me to review their code and I am the person
>> least likely to find the time to do it. That's the fundamental problem
>> we need to address. So, how can we find a way to match reviewers with
>> contributors?
>
> In other projects where reviewer cycles are hard to find, I use a system
> where:
>
> (1) I commit trivial fixes directly (review after commit, if necessary).
>
> (2) If I am confident about a change, but it may have a small impact
> (e.g. a new API method) or someone else knows the area better than me, I
> ask for review and give a (generous) date on when I plan to commit. If
> no-one says anything, I go ahead and commit. This gives reviewers the
> opportunity to express concerns without causing too much of a slowdown.
> They can also just say "I'm not too comfortable with the change, but I
> won't have time to review it properly by the date given" to remove the
> time deadline.
>
> (3) For more complex changes, at least one person should review the
> code.
>
> It obviously helps to have many reviewers and I think the standard
> library is an area where this is achievable as one gets familiar with it
> during normal usage (unlike the compiler).
>
> Of course, this only works if people actually have the time to do
> reviews. If changes in (3) take ages to be reviewed and the ones in (2)
> end up getting in after the time expires with no comments, then it seems
> pointless.

Thanks for sharing this. Lex, since you brought this up, can you
explain a little more how the code review process should work in your
opinion?

Cheers

as a minor contributor, I'd like to add a +.05 (or whatever vote I get
based on contributions)

Sent from my iPhone

On Nov 2, 2009, at 4:18 AM, martin odersky
wrote:

> Hi David,
>
> I like your suggestions. I''ll discuss them with the people at EPFL at
> the next Scala meeting tomorrow. Paul, Miles, and other external
> contributors, what are your opinions on code review?
>
> Cheers
>

On Sun, Nov 01, 2009 at 09:07:08PM +0100, martin odersky wrote:
> I am going to put a foot down now and say that equality and implicits
> between numeric types will remain as in the spec, barring a formal SIP
> process, which will take time. I realize that some people do not like
> it, but given that we only have a couple of days to 2.8 I have to make
> a decision, and that's what it is.
>
> Please tell me whether you want to implement it or I should do it.

I'm not sure how much of that is a consequence of you picturing me going
through trunk like a whirling dervish and how much is a consequence of
technical factors. I invested a lot of time and sanity in finding a way
to preserve what I consider necessary semantics in the face of
constraints which seemed close to impossible to satisfy. Having
possibly done so, I don't want to implement an inadequate solution.

I can satisfy the non-negotiables but if you don't agree that

(List(1L, 2L) contains 1) != (Set(1L, 2L) contains 1)

is a problem, then no matter what compromises I dream up they'll seem
like bad tradeoffs from your perspective. That imposes an additional
satisfiability requirement which excludes all my solutions.

So the upshot is that I think you need to do it. Not that there is much
to do to switch to the simple version. Some things which may remain to
consider:

scala> class Bob { override def equals(other: Any) = other match { case _: Int => true } }
defined class Bob

scala> 1 == (new Bob)
:6: warning: comparing values of types Int and Bob using `==' will always yield false
1 == (new Bob)
^
res0: Boolean = true

If BoxesRunTime goes away completely that's going to become false in
that direction. If anyone came to count on that iffy feature they're
going to be receiving a dose of falsity.

And I'm fairly certain the answer to f2 in this set is a bug:

def f1[T,U](x: T, y: U) = x == y
def f2 = f1[Int, Long] _
def f3(x: Int, y: Long) = x == y
def f4 = f3 _

Under -future-eqeq f2(5, 5L) is false and f4(5, 5L) is true although
they have identical types of (Int, Long) => Boolean. f2 should be true.
I don't know how many other bugs related to unboxing might be lurking
out there, as until now failing to unbox didn't change the result. And
this ticket might be worth figuring out as it ties into similar areas:

http://lampsvn.epfl.ch/trac/scala/ticket/2400
"java primitive char ends up negative"

On Mon, Nov 02, 2009 at 10:18:16AM +0100, martin odersky wrote:
> I like your suggestions. I''ll discuss them with the people at EPFL at
> the next Scala meeting tomorrow. Paul, Miles, and other external
> contributors, what are your opinions on code review?

It sounds fine in theory and I fear it in practice. As a reviewer I
expect I would be unpopular; as a reviewee I would expect to have a lot
of trouble finding enough reviewers; on the whole I would expect to lose
even more code than I do now, and I already lose far more code than I
commit. (By "lose" I mean it falls out of sync with trunk far enough
that I abandon the branch rather than nurse it along.) And to be
entirely frank, most of the code I lose is of higher quality than the
code it was intended to modify or replace, so losing more feels like the
wrong direction to go.

I would love to get feedback on my code for some reason other than my
having accidentally broken something, but realistically I don't expect
code review to deliver much of that, and I surely can expect it to
deliver new barriers between me and trunk -- and once in place those
barriers require no human to maintain them.

I'm not voting against it, just laying out my anxieties.

> It sounds fine in theory and I fear it in practice. As a reviewer I
> expect I would be unpopular; as a reviewee I would expect to have a lot
> of trouble finding enough reviewers; on the whole I would expect to lose
> even more code than I do now, and I already lose far more code than I
> commit.

Post-commit code review seems the best fit for this and many situations.

I would suggest adding fields to Trac to indicate that (1) a code review is needed, and (2) the code has been committed to svn.  I think it would also be beneficial to make the components defined in Trac more granular.  That way someone can setup a query (and I think an RSS feed) of the tickets have committed code that needs review for a particular component.

Then if no one reviews it, no one reviews it.

Of course, this assumes that all commits that needs review have an associated Trac ticket.

On Mon, Nov 2, 2009 at 11:13 AM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Nov 02, 2009 at 10:18:16AM +0100, martin odersky wrote:
> I like your suggestions. I''ll discuss them with the people at EPFL at
> the next Scala meeting tomorrow. Paul, Miles, and other external
> contributors, what are your opinions on code review?

It sounds fine in theory and I fear it in practice.  As a reviewer I
expect I would be unpopular; as a reviewee I would expect to have a lot
of trouble finding enough reviewers; on the whole I would expect to lose
even more code than I do now, and I already lose far more code than I
commit. (By "lose" I mean it falls out of sync with trunk far enough
that I abandon the branch rather than nurse it along.) And to be
entirely frank, most of the code I lose is of higher quality than the
code it was intended to modify or replace, so losing more feels like the
wrong direction to go.

I would love to get feedback on my code for some reason other than my
having accidentally broken something, but realistically I don't expect
code review to deliver much of that, and I surely can expect it to
deliver new barriers between me and trunk -- and once in place those
barriers require no human to maintain them.

I'm not voting against it, just laying out my anxieties.

--
Paul Phillips      | It's better to have gloved and tossed than never to
Stickler           | have played baseball.
Empiricist         |
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

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

Ricky Clarkson wrote:
>> It sounds fine in theory and I fear it in practice. As a reviewer I
>> expect I would be unpopular; as a reviewee I would expect to have a lot
>> of trouble finding enough reviewers; on the whole I would expect to lose
>> even more code than I do now, and I already lose far more code than I
>> commit.
>
> Post-commit code review seems the best fit for this and many situations.

On the svn dev team we use post-commit reviews with the mailing list
extensively. If Scala uses this route, then a new scala-commits mailing list is
created and a svn post-commit script is set up to call mailer.py to email
scala-commits. Scala-commits is set up with a Reply-To header pointing to
scala-internals so that all replys to commits and the discussion occurs in
public and allow anybody to jump in an offer advice. All Scala committers would
have to subscribe to scala-commits.

This method would allow Martin to easily see commits from anywhere, is light
enough to allow fast commits for Paul, but allows a method for people to easily
review and comment upon the code. It'll also promote better code quality
because it is going to a list that people will look at. My code is of better
quality when I know it'll get reviewed.

Even if Scala team doesn't go this route but use pre-commit reviews, setting up
a scala-commits mailing list would be useful for the community, for those of us
who prefer email to RSS Trac feeds for commits.

Regards,
Blair

On Monday November 2 2009, Blair Zajac wrote:
> Ricky Clarkson wrote:
> >> ...
> >
> > Post-commit code review seems the best fit for this and many
> > situations.
>
> On the svn dev team we use post-commit reviews with the mailing list
> extensively. If Scala uses this route, then a new scala-commits
> mailing list is created and a svn post-commit script is set up to
> call mailer.py to email scala-commits. Scala-commits is set up with
> a Reply-To header pointing to scala-internals so that all replys to
> commits and the discussion occurs in public and allow anybody to jump
> in an offer advice. All Scala committers would have to subscribe to
> scala-commits.

This is my naive and nearly knee-jerk idea for everything related to
group communication of late: What about Google Wave?

> ...
>
> Regards,
> Blair

Randall Schulz

On Mon, Nov 2, 2009 at 7:41 PM, Randall R Schulz wrote:
> On Monday November 2 2009, Blair Zajac wrote:
>> Ricky Clarkson wrote:
>> >> ...
>> >
>> > Post-commit code review seems the best fit for this and many
>> > situations.
>>
>> On the svn dev team we use post-commit reviews with the mailing list
>> extensively.  If Scala uses this route, then a new scala-commits
>> mailing list is created and a svn post-commit script is set up to
>> call mailer.py to email scala-commits.  Scala-commits is set up with
>> a Reply-To header pointing to scala-internals so that all replys to
>> commits and the discussion occurs in public and allow anybody to jump
>> in an offer advice.  All Scala committers would have to subscribe to
>> scala-commits.
>
> This is my naive and nearly knee-jerk idea for everything related to
> group communication of late: What about Google Wave?
>
Well, we'd need an invitation for the whole developer team, and that
does not seem to be easy to get.

Cheers

On Monday November 2 2009, martin odersky wrote:
> On Mon, Nov 2, 2009 at 7:41 PM, Randall R Schulz wrote:
> > ...
> >
> > This is my naive and nearly knee-jerk idea for everything related
> > to group communication of late: What about Google Wave?
>
> Well, we'd need an invitation for the whole developer team, and that
> does not seem to be easy to get.

No, not so far. The only question is how long it's going to stay in
limited release.

On the other hand, Google might well be willing to give a set of Wave
accounts for something as significant as an important new language's
development team, especially one they can readily see benefitting their
own operations.

> Cheers
>

I don't think Wave would be the perfect solution, but I have 12 invites left if the Scala team wants to explore this option.

--j

On Mon, Nov 2, 2009 at 10:43 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Mon, Nov 2, 2009 at 7:41 PM, Randall R Schulz <rschulz@sonic.net> wrote:
> On Monday November 2 2009, Blair Zajac wrote:
>> Ricky Clarkson wrote:
>> >> ...
>> >
>> > Post-commit code review seems the best fit for this and many
>> > situations.
>>
>> On the svn dev team we use post-commit reviews with the mailing list
>> extensively.  If Scala uses this route, then a new scala-commits
>> mailing list is created and a svn post-commit script is set up to
>> call mailer.py to email scala-commits.  Scala-commits is set up with
>> a Reply-To header pointing to scala-internals so that all replys to
>> commits and the discussion occurs in public and allow anybody to jump
>> in an offer advice.  All Scala committers would have to subscribe to
>> scala-commits.
>
> This is my naive and nearly knee-jerk idea for everything related to
> group communication of late: What about Google Wave?
>
Well, we'd need an invitation for the whole developer team, and that
does not seem to be easy to get.

Cheers

I have a similar number.

2009/11/2 Jorge Ortiz :
> I don't think Wave would be the perfect solution, but I have 12 invites left
> if the Scala team wants to explore this option.
>
> --j
>
> On Mon, Nov 2, 2009 at 10:43 AM, martin odersky
> wrote:
>>
>> On Mon, Nov 2, 2009 at 7:41 PM, Randall R Schulz
>> wrote:
>> > On Monday November 2 2009, Blair Zajac wrote:
>> >> Ricky Clarkson wrote:
>> >> >> ...
>> >> >
>> >> > Post-commit code review seems the best fit for this and many
>> >> > situations.
>> >>
>> >> On the svn dev team we use post-commit reviews with the mailing list
>> >> extensively.  If Scala uses this route, then a new scala-commits
>> >> mailing list is created and a svn post-commit script is set up to
>> >> call mailer.py to email scala-commits.  Scala-commits is set up with
>> >> a Reply-To header pointing to scala-internals so that all replys to
>> >> commits and the discussion occurs in public and allow anybody to jump
>> >> in an offer advice.  All Scala committers would have to subscribe to
>> >> scala-commits.
>> >
>> > This is my naive and nearly knee-jerk idea for everything related to
>> > group communication of late: What about Google Wave?
>> >
>> Well, we'd need an invitation for the whole developer team, and that
>> does not seem to be easy to get.
>>
>> Cheers
>>
>>  -- Martin
>> >
>> >> ...
>> >>
>> >> Regards,
>> >> Blair
>> >
>> >
>> > Randall Schulz
>> >
>> >
>
>

All~

Unless google wave has a useful way of displaying diffs, then I don't
see it as being particularly useful to this case...

Matt

On Mon, Nov 2, 2009 at 3:01 PM, Ricky Clarkson wrote:
> I have a similar number.
>
> 2009/11/2 Jorge Ortiz :
>> I don't think Wave would be the perfect solution, but I have 12 invites left
>> if the Scala team wants to explore this option.
>>
>> --j
>>
>> On Mon, Nov 2, 2009 at 10:43 AM, martin odersky
>> wrote:
>>>
>>> On Mon, Nov 2, 2009 at 7:41 PM, Randall R Schulz
>>> wrote:
>>> > On Monday November 2 2009, Blair Zajac wrote:
>>> >> Ricky Clarkson wrote:
>>> >> >> ...
>>> >> >
>>> >> > Post-commit code review seems the best fit for this and many
>>> >> > situations.
>>> >>
>>> >> On the svn dev team we use post-commit reviews with the mailing list
>>> >> extensively.  If Scala uses this route, then a new scala-commits
>>> >> mailing list is created and a svn post-commit script is set up to
>>> >> call mailer.py to email scala-commits.  Scala-commits is set up with
>>> >> a Reply-To header pointing to scala-internals so that all replys to
>>> >> commits and the discussion occurs in public and allow anybody to jump
>>> >> in an offer advice.  All Scala committers would have to subscribe to
>>> >> scala-commits.
>>> >
>>> > This is my naive and nearly knee-jerk idea for everything related to
>>> > group communication of late: What about Google Wave?
>>> >
>>> Well, we'd need an invitation for the whole developer team, and that
>>> does not seem to be easy to get.
>>>
>>> Cheers
>>>
>>>  -- Martin
>>> >
>>> >> ...
>>> >>
>>> >> Regards,
>>> >> Blair
>>> >
>>> >
>>> > Randall Schulz
>>> >
>>> >
>>
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@gmail.com
> Google Wave: ricky.clarkson@googlewave.com
>

On Mon, Nov 2, 2009 at 8:55 PM, Jorge Ortiz wrote:
> I don't think Wave would be the perfect solution, but I have 12 invites left
> if the Scala team wants to explore this option.
>
I'd like to try it, but probably first for the scala meetings. Thanks
to Miles, Jorge and Randall for their willingness to giuve away
invites. Toni, can you send an about equal number of addresses of the
Scala team to everyone? That should be about 4 invites for everyone.

Thanks

On Monday November 2 2009, martin odersky wrote:
> On Mon, Nov 2, 2009 at 8:55 PM, Jorge Ortiz wrote:
> > I don't think Wave would be the perfect solution, but I have 12
> > invites left if the Scala team wants to explore this option.
>
> I'd like to try it, but probably first for the scala meetings. Thanks
> to Miles, Jorge and Randall for their willingness to giuve away
> invites. Toni, can you send an about equal number of addresses of the
> Scala team to everyone? That should be about 4 invites for everyone.

Just to be fair, only Jorge and Ricky offered Wave invitations. I have
none to offer, just the one that I got some other kind soul to nominate
me for.

> Thanks
>

>>>>> "martin" == martin odersky writes:

> ...by themselves these two statements are irreconcilable unless for a
> given A and B, the truth value of A == B varies depending on the
> static types of A and B.

Martin> That's indeed a consequence, which is also true for almost
Martin> every other language on the planet.

Well, almost every other statically typed language. Obviously,
dynamically typed languages don't have this problem at all! And Scala
doesn't only compete against other statically typed languages.

Just an observation...

Sorry, I meant Ricky Clarkson. -- Martin

On Mon, Nov 2, 2009 at 10:11 PM, Randall R Schulz wrote:
> On Monday November 2 2009, martin odersky wrote:
>> On Mon, Nov 2, 2009 at 8:55 PM, Jorge Ortiz wrote:
>> > I don't think Wave would be the perfect solution, but I have 12
>> > invites left if the Scala team wants to explore this option.
>>
>> I'd like to try it, but probably first for the scala meetings. Thanks
>> to Miles, Jorge and Randall for their willingness to giuve away
>> invites. Toni, can you send an about equal number of addresses of the
>> Scala team to everyone? That should be about 4 invites for everyone.
>
> Just to be fair, only Jorge and Ricky offered Wave invitations. I have
> none to offer, just the one that I got some other kind soul to nominate
> me for.
>
>
>> Thanks
>>
>>  -- Martin
>
>
> Randall Schulz
>
>

Sure, I'll make a list immediately.
Toni

martin odersky wrote:
> On Mon, Nov 2, 2009 at 8:55 PM, Jorge Ortiz wrote:
>> I don't think Wave would be the perfect solution, but I have 12 invites left
>> if the Scala team wants to explore this option.
>>
> I'd like to try it, but probably first for the scala meetings. Thanks
> to Miles, Jorge and Randall for their willingness to giuve away
> invites. Toni, can you send an about equal number of addresses of the
> Scala team to everyone? That should be about 4 invites for everyone.
>
> Thanks
>

Maybe this isn't just a static/dynamic problem at all, I can reproduce
this problem using pure algebra
All I need is two values that are equal, except when they're not

To compare an integer and a float, how about this notation:
1 = 1.0
absolutely nobody's going to disagree with that

But... that's not the whole picture, this way captures the unique
characteristics of floats and ints far better
1 ± 0.5 = 1 ± 0.0000000000000005
So, Is that true?

More to the point, does this imply that it's correct to implicitly
convert an int to a float?
Or is such behaviour just another demonstration of entropy?
Where we seem to be gaining precision from nowhere, but really we're
losing out far more in overall program accuracy.

On Mon, Nov 2, 2009 at 9:19 PM, Seth Tisue wrote:
>>>>>> "martin" == martin odersky writes:
>
>  > ...by themselves these two statements are irreconcilable unless for a
>  > given A and B, the truth value of A == B varies depending on the
>  > static types of A and B.
>
>  Martin> That's indeed a consequence, which is also true for almost
> Martin> every other language on the planet.
>
> Well, almost every other statically typed language.  Obviously,
> dynamically typed languages don't have this problem at all!  And Scala
> doesn't only compete against other statically typed languages.
>
> Just an observation...
>
> --
> Seth Tisue @ Northwestern University / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>

On Nov 2, 2009, at 6:14 AM, martin odersky wrote:
> Thanks for sharing this. Lex, since you brought this up, can you
> explain a little more how the code review process should work in your
> opinion?

Well, that's the hard part! I can describe how it works in my
experience, for what it's worth. Every group has to feel out
something that works for them.

Figuring out who will do a review is important. Otherwise, you can
drop good work, like Paul asks about. For any task that is planned,
go ahead and figure out the reviewer up front. "Joe, you do it, and
Elaine, can you review it?" For unsolicited work, the submitter just
has to pick someone and ask. I notice that many people are ending up
with regular review buddies to handle their normal patches. That
would sound especially important to think about for remote contributors.

Like many the groups of others on this thread, our manager doesn't
review very much, any more than he codes very much.

For very small changes, our team has "desk reviews" where someone
looks up from their desk and goes "yeah, that one-liner looks good to
me". The same thing over instance message programs also works fine.

There is a lot of disagreement on how strict reviews should be. In my
opinion the lighter end of the spectrum works better. Some people try
to really grill each other at review time so as to perfect the code,
but the things that I like about code review are more incidental, and
only require that there is any review at all:

1. The submitter tends to clean up their code more, because it's on
display.

2. Pure accidents have a good chance of being caught.

3. The two people often share tips and tricks about the tools, APIs,
and idioms.

Regarding tools, we have found emailing patches to be okay, and Review
Board and Reitveld both to be better. We haven't tried Wave, but as
much as I like Wave for other uses I expect that it won't compete well
until someone writes a diffing tool for it.

Finally, I haven't found after-commit review to be effective.
Apparently the svn group has, so it must depend on the people
involved. In our group, I find that the submitter will take arbitrary
amounts of time responding to review comments, and thus the code in
the repository is unaffected by the review. Making the review happen
first is a way to help everyone stay honest.

Lex

There are probably a number of people, like me, who haven't contributed code yet, but would be happy to get involved as reviewers. In particular, it would be a great way to learn the internals better. 
Of course, it might be easier to start with libraries and work up to hairy compiler bits...
dean

On Mon, Nov 2, 2009 at 10:13 AM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Nov 02, 2009 at 10:18:16AM +0100, martin odersky wrote:
> I like your suggestions. I''ll discuss them with the people at EPFL at
> the next Scala meeting tomorrow. Paul, Miles, and other external
> contributors, what are your opinions on code review?

It sounds fine in theory and I fear it in practice.  As a reviewer I
expect I would be unpopular; as a reviewee I would expect to have a lot
of trouble finding enough reviewers; on the whole I would expect to lose
even more code than I do now, and I already lose far more code than I
commit. (By "lose" I mean it falls out of sync with trunk far enough
that I abandon the branch rather than nurse it along.) And to be
entirely frank, most of the code I lose is of higher quality than the
code it was intended to modify or replace, so losing more feels like the
wrong direction to go.

I would love to get feedback on my code for some reason other than my
having accidentally broken something, but realistically I don't expect
code review to deliver much of that, and I surely can expect it to
deliver new barriers between me and trunk -- and once in place those
barriers require no human to maintain them.

I'm not voting against it, just laying out my anxieties.

--
Paul Phillips      | It's better to have gloved and tossed than never to
Stickler           | have played baseball.
Empiricist         |
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

--
Dean Wampler
coauthor of "Programming Scala" (O'Reilly)
-  http://programmingscala.com

twitter: @deanwampler, @chicagoscala
Chicago-Area Scala Enthusiasts (CASE):
-  http://groups.google.com/group/chicagoscala
-  http://www.meetup.com/chicagoscala/ (Meetings)
http://www.linkedin.com/in/deanwampler
http://www.polyglotprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

I can take up a few as well, if needed. I have 8 left.

On Mon, Nov 2, 2009 at 7:11 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday November 2 2009, martin odersky wrote:
> On Mon, Nov 2, 2009 at 8:55 PM, Jorge Ortiz wrote:
> > I don't think Wave would be the perfect solution, but I have 12
> > invites left if the Scala team wants to explore this option.
>
> I'd like to try it, but probably first for the scala meetings. Thanks
> to Miles, Jorge and Randall for their willingness to giuve away
> invites. Toni, can you send an about equal number of addresses of the
> Scala team to everyone? That should be about 4 invites for everyone.

Just to be fair, only Jorge and Ricky offered Wave invitations. I have
none to offer, just the one that I got some other kind soul to nominate
me for.


> Thanks
>
>  -- Martin


Randall Schulz

--
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.

I am both willing to do some reviews and offer up some wave invites as well.  I have 20 but I think I should save some for my colleges here at work :)  So say 10 from me.

Jesse
On Tue, Nov 3, 2009 at 1:13 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

I can take up a few as well, if needed. I have 8 left.

On Mon, Nov 2, 2009 at 7:11 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday November 2 2009, martin odersky wrote:
> On Mon, Nov 2, 2009 at 8:55 PM, Jorge Ortiz wrote:
> > I don't think Wave would be the perfect solution, but I have 12
> > invites left if the Scala team wants to explore this option.
>
> I'd like to try it, but probably first for the scala meetings. Thanks
> to Miles, Jorge and Randall for their willingness to giuve away
> invites. Toni, can you send an about equal number of addresses of the
> Scala team to everyone? That should be about 4 invites for everyone.

Just to be fair, only Jorge and Ricky offered Wave invitations. I have
none to offer, just the one that I got some other kind soul to nominate
me for.


> Thanks
>
>  -- Martin


Randall Schulz

--
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 Mon, Nov 2, 2009 at 10:47 PM, Kevin Wright
wrote:
> Maybe this isn't just a static/dynamic problem at all, I can reproduce
> this problem using pure algebra
> All I need is two values that are equal, except when they're not
>
> To compare an integer and a float, how about this notation:
> 1 = 1.0
> absolutely nobody's going to disagree with that
>
>
> But... that's not the whole picture, this way captures the unique
> characteristics of floats and ints far better
> 1 ± 0.5  =  1 ± 0.0000000000000005
> So, Is that true?
>
One of the prinicpal characteristics of Scala is that it takes over
operations on primitive types wholesale from Java. Yes, one can debate
whether some of this makes sense (for instance, I also think that % is
badly defined in Java), but that's the principle, and we are going to
stick to it.

Cheers

Jesse Eichar wrote:
> I am both willing to do some reviews and offer up some wave invites as well.
> I have 20 but I think I should save some for my colleges here at work :)
> So say 10 from me.
>

Thanks, I am now gathering information from the group. With all the offers
we received, it will probably be just 2 invites needed from each one :)

I'll contact all those interested later today, thanks for your offers everyone!
Toni