Re: Scala Days 2011 is over

Re: Scala Days 2011 is over

On 01/09/2011 01:37, Kris K wrote:
> Any update on when you will have these videos for public viewing? It's
> been more than a 4 weeks 

Working on it. Have faith.
Toni

--

-- 
Antonio Cunei
Scala Team, EPFL

Re: [ANN] Scala+GWT 0.1-M1 released

Congratulations!

Are there plans to get the Jribble parts into Scala as a compiler 
backend, like JVM and MSIL?

Bye,

Simon

Great work!

Thank you very much for your efforts. I did not expect a release this
quickly, given all the potential problems!

However, I'm looking forward for a release where the dev-mode works,
as even in normal GWT, the javascript-compilation is way too slow.
I'll give it a try to see if it works, though 

Really keep up the good work!
Scala + GWT + some AppServer/AppEngine => awesome web development.

It would not matter to me if many language constructs, like detailed
pattern matching, do not work in the first place, and if only very few
scala-library classes are supported. What matters is the idea to use
the main parts of the concise scala syntax (especially closures and
tuples) instead of the clunky java syntax in the gwt!

However, you may need to find a way to eliminate (implicit)
conversions which wrap closures as eventlisteners, if the gwt compiler
does not handle that. 

Re: Great work!

On 02/09/2011 10:05, eric.giese wrote:
> Thank you very much for your efforts. I did not expect a release this
> quickly, given all the potential problems!

Thanks, but I haven't done so much, yet...

As you don't mention which work you compliment, I can take them for me, it is good for the 
ego... 

Although, from context, I can guess it is related to the "[ANN] Scala+GWT 0.1-M1 released" 
thread just below your message (in my e-mail client). I guess your client omitted some 
In-Reply-To or References Mime fields in the header...

(That's just an harmless joke, sorry, I couldn't resist... ^_^')

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Why does sliding have a type parameter?

Re: Why does sliding have a type parameter?

https://issues.scala-lang.org/browse/SI-4778

On Fri, Sep 2, 2011 at 13:40, Cay Horstmann <cay.horstmann <at> gmail.com> wrote:
> Here is the sliding method from IterableLike[A, Repr]:
>
> def sliding[B >: A](size: Int, step: Int): Iterator[Repr]
>
> Why the [B >: A]? What B could be inferred from where?
>
> Thanks,
>
> Cay
>

--

-- 
Daniel C. Sobral

I travel to the future all the time.

Equality of type projection and existential type

scala> class Outer { class Inner }
defined class Outer

Given this definition, I didn't expect that Outer#Inner and o.Inner
forSome { val o: Outer } are equivalent, only that one of them conforms
to the other one.

scala> implicitly[<:<[o.Inner forSome { val o: Outer }, Outer#Inner]]
res3: <:<[o.Inner forSome { val o: Outer },Outer#Inner] = <function1>

As expected. But the other way round, I noticed that:

scala> implicitly[Outer#Inner <:< o.Inner forSome { val o: Outer }]
<console>:9: error: Cannot prove that Outer#Inner <:< Outer#Inner.
              implicitly[Outer#Inner <:< o.Inner forSome { val o: Outer }]

which is quite strange because apparently the compiler simplifies the
existential type to the projection type. Obviously, the compiler also
fails to prove equality:

scala> implicitly[Outer#Inner =:= o.Inner forSome { val o: Outer }]
<console>:9: error: Cannot prove that Outer#Inner =:= Outer#Inner.
              implicitly[Outer#Inner =:= o.Inner forSome { val o: Outer }]

Any advice?

Re: Equality of type projection and existential type

On Sat, Sep 3, 2011 at 10:05 AM, Lars Hupel <hupel <at> in.tum.de> wrote:
> scala> class Outer { class Inner }
> defined class Outer
>
> Given this definition, I didn't expect that Outer#Inner and o.Inner
> forSome { val o: Outer } are equivalent, only that one of them conforms
> to the other one.
>
> scala> implicitly[<:<[o.Inner forSome { val o: Outer }, Outer#Inner]]
> res3: <:<[o.Inner forSome { val o: Outer },Outer#Inner] = <function1>
>
> As expected. But the other way round, I noticed that:
>
> scala> implicitly[Outer#Inner <:< o.Inner forSome { val o: Outer }]
> <console>:9: error: Cannot prove that Outer#Inner <:< Outer#Inner.
>              implicitly[Outer#Inner <:< o.Inner forSome { val o: Outer }]
>
> which is quite strange because apparently the compiler simplifies the
> existential type to the projection type. Obviously, the compiler also
> fails to prove equality:
>
> scala> implicitly[Outer#Inner =:= o.Inner forSome { val o: Outer }]
> <console>:9: error: Cannot prove that Outer#Inner =:= Outer#Inner.
>              implicitly[Outer#Inner =:= o.Inner forSome { val o: Outer }]

Interesting. It _is_ sometimes said that Outer#Inner is equivalent to
o.Inner forSome { val o : Outer }. But that's not what the spec says,
and it's quite clear that that can't be the case: in fact the
equivalence should only work for a _universal_ rather than an
existential quantifier.

Here are a few more examples illustrating that,

scala> implicitly[(o.Inner forSome { val o : Outer }) <:< Outer#Inner]
res24: <:<[o.Inner forSome { val o: Outer },Outer#Inner] = <function1>

scala> val o1 = new Outer
o1: Outer = Outer <at> d551e1

scala> val o2 = new Outer
o2: Outer = Outer <at> 15fc2d5

scala> implicitly[o1.Inner <:< Outer#Inner]
res25: <:<[o1.Inner,Outer#Inner] = <function1>

scala> implicitly[o2.Inner <:< Outer#Inner]
res26: <:<[o2.Inner,Outer#Inner] = <function1>

These are all exactly the results we would expect if Outer#Inner were
defined as the (hypothetical, not current Scala) o.Inner forAll { val
o : Outer }.

Somewhat relatedly, I've come around to the idea that the rendering
for Java raw types as parametrized types with a hidden existential is
back to front: I think they should actually be treated as parametrized
types with a hidden *universal* quantifier, ie. java.util.List should
be interpreted as java.util.List[T] forAll { type T } rather than as
java.util.List[T] forSome { type T } as it currently is.

Cheers,

Miles

--

-- 
Miles Sabin
tel: +44 7813 944 528
gtalk: miles <at> milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Re: Equality of type projection and existential type

On Sat, Sep 3, 2011 at 10:05 AM, Lars Hupel <hupel <at> in.tum.de> wrote:
> scala> class Outer { class Inner }
> defined class Outer
>
> Given this definition, I didn't expect that Outer#Inner and o.Inner
> forSome { val o: Outer } are equivalent, only that one of them conforms
> to the other one.
>
> scala> implicitly[<:<[o.Inner forSome { val o: Outer }, Outer#Inner]]
> res3: <:<[o.Inner forSome { val o: Outer },Outer#Inner] = <function1>
>
> As expected. But the other way round, I noticed that:
>
> scala> implicitly[Outer#Inner <:< o.Inner forSome { val o: Outer }]
> <console>:9: error: Cannot prove that Outer#Inner <:< Outer#Inner.
>              implicitly[Outer#Inner <:< o.Inner forSome { val o: Outer }]
>
> which is quite strange because apparently the compiler simplifies the
> existential type to the projection type. Obviously, the compiler also
> fails to prove equality:
>
> scala> implicitly[Outer#Inner =:= o.Inner forSome { val o: Outer }]
> <console>:9: error: Cannot prove that Outer#Inner =:= Outer#Inner.
>              implicitly[Outer#Inner =:= o.Inner forSome { val o: Outer }]

There's definitely something strange going on here,

scala> class Outer { class Inner }
defined class Outer

scala> val o = new Outer
o: Outer = Outer <at> 7b1b33

scala> val i = new o.Inner
i: o.Inner = Outer$Inner <at> 1a13207

scala> val i1 : Outer#Inner = i
i1: Outer#Inner = Outer$Inner <at> 1a13207

scala> val i2 : x.Inner forSome { val x : Outer } = i
<console>:10: error: type mismatch;
 found   : x.Inner
 required: x.Inner forSome { val x: => Outer }
       val i2 : x.Inner forSome { val x : Outer } = i
           ^
<console>:10: error: type mismatch;
 found   : o.Inner
 required: x.Inner forSome { val x: => Outer }
       val i2 : x.Inner forSome { val x : Outer } = i
                                                    ^

scala> val i3 = (i : x.Inner forSome { val x : Outer })
i3: Outer#Inner = Outer$Inner <at> 1a13207

scala> type OI = x.Inner forSome { val x : Outer }
defined type alias OI

scala> val i4 : OI = i
i3: OI = Outer$Inner <at> 1a13207

scala> val i5 = (i : OI)
i4: Outer#Inner = Outer$Inner <at> 1a13207

I can't see any obvious reason for the difference between i2 and i3
here, and any reason at all for the difference between i2 and i4.

Cheers,

Miles

--

-- 
Miles Sabin
tel: +44 7813 944 528
gtalk: miles <at> milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin