it's a matter of national security

If I get any invites I'll give a heads up.

On Tue, Nov 3, 2009 at 12:16 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

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

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

This principle seems to me incompatible with some of Scala's other principles, namely the unification of primitives and references under a single type hierarchy, and using == to mean equals.

In Java,

  5 == 5L (true)

but

  Integer.valueOf(5).equals(5L) (false)

So what to do with Scala's

  5 == 5L (?)

If it must work just like Java's operations on primitive types, it's true. If it must be able to pass around primitives as parametrized types (hence, box them), and == means .equals, then it's false.

I certainly don't have any good solutions, but I'll try proposing a heretical solution.

In keeping with Scala's other principle that == means Java's .equals and eq means Java's ==, then how about Scala have:

  5 == 5L (false)
  5 eq 5L (true)

This is a total bastardization of all that is consistent and rational, but Java is no better, and if we must copy Java...

--j

On Tue, Nov 3, 2009 at 1:01 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Mon, Nov 2, 2009 at 10:47 PM, Kevin Wright
<kev.lee.wright@googlemail.com> 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

On Tue, Nov 3, 2009 at 6:40 PM, Jorge Ortiz wrote:
> This principle seems to me incompatible with some of Scala's other
> principles, namely the unification of primitives and references under a
> single type hierarchy, and using == to mean equals.
>
> In Java,
>
>   5 == 5L (true)
>
> but
>
>   Integer.valueOf(5).equals(5L) (false)
>
> So what to do with Scala's
>
>   5 == 5L (?)
>
> If it must work just like Java's operations on primitive types, it's true.
> If it must be able to pass around primitives as parametrized types (hence,
> box them), and == means .equals, then it's false.
>
> I certainly don't have any good solutions, but I'll try proposing a
> heretical solution.
>
> In keeping with Scala's other principle that == means Java's .equals and eq
> means Java's ==, then how about Scala have:
>
>   5 == 5L (false)
>   5 eq 5L (true)
>
> This is a total bastardization of all that is consistent and rational, but
> Java is no better, and if we must copy Java...

Please no, don't do it, in the name of all that is good and pure!

How about:
5 == 5L (false)
5 =~= 5L (true)

Note the invented operator there :)

but the *real* problem here is which equality definition is used in
checking for collection membership.
Is there any way we could make this pluggable, maybe even via an
implicit monoid approach?

Then equality gains the same flexibility as comparators

> --j
>
> On Tue, Nov 3, 2009 at 1:01 AM, martin odersky
> wrote:
>>
>> 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
>>
>>  -- Martin
>
>

On Tuesday 03 November 2009 21:40:46 Jorge Ortiz wrote:
> This principle seems to me incompatible with some of Scala's other
> principles, namely the unification of primitives and references under a
> single type hierarchy, and using == to mean equals.
>
> In Java,
>
> 5 == 5L (true)
>
> but
>
> Integer.valueOf(5).equals(5L) (false)
>
> So what to do with Scala's
>
> 5 == 5L (?)

Compile error.

The fallacy is that == is not equals always, it's overloaded for
numeric types. So 5 == 5L is true, just as in Java. But I am going to
shut up now, because we are turning in cycles.

I apologize in advance for intruding upon an internals thread.

On Sun, Nov 1, 2009 at 2:07 PM, martin odersky wrote:
> On Sun, Nov 1, 2009 at 6:13 PM, Paul Phillips wrote:
>> 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).

Is there any convenient means by which all such implicits from Predef
can be unimported wholesale? Automatic coercions between primitive
types are not something I want in my projects, and if they are simply
implicits I can get rid of them but explicitly having to unimport
every such conversion in every file seems masochistically verbose.

Thanks,

Kris

On Tue, Nov 03, 2009 at 11:03:49PM -0600, Kris Nuttycombe wrote:
> Is there any convenient means by which all such implicits from Predef
> can be unimported wholesale? Automatic coercions between primitive
> types are not something I want in my projects, and if they are simply
> implicits I can get rid of them but explicitly having to unimport
> every such conversion in every file seems masochistically verbose.

I'm not sure there's any means at all by which you can do it, let alone
a convenient one. At least I can't seem to do it.

import Predef.{ long2double => _, float2double => _ }

object obj
{
// Have to say Console.println(x) since "error: not found: value println"
// after the above imports.
def m(x: Double) { Console.println(x) }

def main(args: Array[String]): Unit = {
val x: Double = 5L
m(5L)
Console.println(x)
}
}

This compiles and prints 5.0 twice. "Console.println(long2double(5L))"
is a compile error in the same program, so the identifier must be hidden
but the implicit still lurks.

What I was going to say before discovering that none of that worked, is
that even if it did work, you are likely to get conversions. In the
above example calling method m with 5L should fail without the
implicits, but I think "val x: Double = 5L" will succeed with or without
the implicits in Predef, because the typer goes looking for a conversion
and bypasses the implicit mechanism entirely. See

def convertTo(pt: Type): Constant

in Constants.scala.

On 01/11/2009 23:37, martin odersky wrote:
> Right now,
> if you you don't like these conversions , you can always unimport
> them from Predef.

I'm sorry to ask something that seems to be easy to do, but I didn't
google anything relevant on how to do that...

As I really dislike the implicit conversion between numerics, I tried to
unimport them, as said, but didn't succeed. So, my question is: How do
we unimport things that are brought with Predef ? Do have I to recompile
scala-lib without the import ? Or is their a simple switch that I missed
somewhere ?

Thanks in advance for the help,

--
Francois Armand

>>>>> "Francois" == Francois writes:

Francois> As I really dislike the implicit conversion between numerics,
Francois> I tried to unimport them, as said, but didn't succeed. So, my
Francois> question is: How do we unimport things that are brought with
Francois> Predef ?

I'd really like it if there were a way to do this. If Predef must have
these implicits in order to make Java programmers comfortable, then so
be it, but for my own code, I'd prefer to have an easy way to disable
them.

On Wednesday 04 November 2009 21:30:34 Seth Tisue wrote:
> I'd really like it if there were a way to do this. If Predef must have
> these implicits in order to make Java programmers comfortable,

It's funny, but in Java I wasn't comfortable with the conversions also; can
not imagine to be the only :-)

> then so
> be it, but for my own code, I'd prefer to have an easy way to disable
> them.

Yes, but it would be useful at case we have bytes and shorts literals. Both
1.toByte as well as (1 : Byte) are awful. Agree?

Don't know how widespread this is, but I've just received another 30 invites.

Anyone needing an invite, or who has invites to offer the community,
I've created a document here:
http://spreadsheets.google.com/ccc?key=0Aqaj_meGwHUOdGREbFNRRnpMODhZLUw4...

Just add you name and email to the list if you need to be invited

On Tue, Nov 3, 2009 at 11:16 AM, Antonio Cunei wrote:
> 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
>
>