Stanford Scala Class

The first meeting of the Stanford Scala Class (CS 94SI) will be this
Wednesday, April 2 from 4:15pm to 5:45pm at the Gates Computer Science
Building (353 Serra St, Stanford CA), Room B12. Auditors are welcome.

Unfortunately, due to logistical and legal complications, we will be
unable to make videos of the class available online.

For more information, please visit the class website:
http://www.stanford.edu/class/cs94si/

Thank you,

CS 94SI Course Staff
Ben Newman
Jorge Ortiz
Julien Wetterwald

Question regarding Variance and Type Bounds

Re: Question regarding Variance and Type Bounds

Arun Suresh wrote:
>
> any suggestions ?

It compiles for me without any errors.  What version of Scala are you 
using?  Since the error you receive is related to inference you could 
try changing

    case Node(l, e, r) =>
     if (x < e) Node(add(l, x), e, r) else Node(l,  e, add(r, x))

to

    case Node(l, e, r) =>
     if (x < e) Node(add[T](l, x), e, r) else Node(l,  e, add[T](r, x))

Limited type inference (was: Question regarding Variance and Type Bounds)

Arun Suresh schrieb:
> I seem to have hit upon a roadblock.

Your current problem has nothing to do with variance and bounds, you just
overestimated the type inferencer. Change that line:

>     case Nil => Node(Nil, x, Nil)

to
      case Nil => Node(Nil: BSTree[T],x,Nil: BSTree[T])

and your code will compile (to an invariant add method).

The same thing happens if you try to fold with an empty List as init value:

scala> val s = List("Foo", "Bar", "Baz")
s: List[java.lang.String] = List(Foo, Bar, Baz)

scala> (s :\ Nil)(_ :: _)
<console>:6: error: type mismatch;
 found   : List[java.lang.String]
 required: object Nil
       (s :\ Nil)(_ :: _)
                    ^

scala> (s :\ (Nil: List[String]))(_ :: _)
res1: List[String] = List(Foo, Bar, Baz)

IMHO, this is one of the most annoying limitations of the scala type system.

Florian.
--

-- 
But our moral language is fragmented; our contemporaries reject the Kantian
hunch that choosing those things most admirable and plausible as ends in
themselves is the best practice; autonomous sources of the good are everywhere
brown and broken. Thus we have PHP. http://lambda-the-ultimate.org/node/1463

Re: Limited type inference (was: Question regarding Variance and Type Bounds)

On Tue, Apr 1, 2008 at 5:45 AM, Florian Hars <hars <at> bik-gmbh.de> wrote:
>
>  The same thing happens if you try to fold with an empty List as init value:
>
>  scala> val s = List("Foo", "Bar", "Baz")
>  s: List[java.lang.String] = List(Foo, Bar, Baz)
>
>  scala> (s :\ Nil)(_ :: _)
>  <console>:6: error: type mismatch;
>   found   : List[java.lang.String]
>   required: object Nil
>        (s :\ Nil)(_ :: _)
>                     ^
>
>  scala> (s :\ (Nil: List[String]))(_ :: _)
>  res1: List[String] = List(Foo, Bar, Baz)
>
>  IMHO, this is one of the most annoying limitations of the scala type system.

Incidentally, I seem to remember this working in older versions of
Scala, but I don't have one handy to check. I know it doesn't work
now, and I agree it's annoying. Does anybody know/remember whether
this used to work without the type annotation?

Matt

--

-- 
Matt Hellige / matt <at> immute.net
http://matt.immute.net

Re: Limited type inference (was: Question regarding Variance and Type Bounds)

Hi,

On Tuesday 01 April 2008 18:25:56 Matt Hellige wrote:
> Incidentally, I seem to remember this working in older versions of
> Scala, but I don't have one handy to check. I know it doesn't work
> now, and I agree it's annoying. Does anybody know/remember whether
> this used to work without the type annotation?

I think it did. At least I remember Tony Morris had a problem when he tried to 
move from older version to maybe 2.7? And the reason for why the code wasn't 
compiling for the newer was that there was a Nil. Adding type information the 
code worked. He probably can tell in what version it did work.

> Matt

- Henrik

Re: Limited type inference (was: Question regarding Variance and Type Bounds)

Oops, now I remember it was None, not Nil, but the idea is still valid.

- Henrik

On Tuesday 01 April 2008 18:38:36 Henrik Huttunen wrote:
> Hi,
>
> On Tuesday 01 April 2008 18:25:56 Matt Hellige wrote:
> > Incidentally, I seem to remember this working in older versions of
> > Scala, but I don't have one handy to check. I know it doesn't work
> > now, and I agree it's annoying. Does anybody know/remember whether
> > this used to work without the type annotation?
>
> I think it did. At least I remember Tony Morris had a problem when he tried
> to move from older version to maybe 2.7? And the reason for why the code
> wasn't compiling for the newer was that there was a Nil. Adding type
> information the code worked. He probably can tell in what version it did
> work.
>
> > Matt
>
> - Henrik

Re: Limited type inference

Henrik Huttunen wrote:

> I think it did. At least I remember Tony Morris had a problem when he tried to 
> move from older version to maybe 2.7? And the reason for why the code wasn't 
> compiling for the newer was that there was a Nil. Adding type information the 
> code worked. He probably can tell in what version it did work.

I seem to vaguely recall that this is related to the change in how case 
classes are compiled that was introduced in 2.7.0.

Re: Question regarding Variance and Type Bounds

higher kinded types/type functions

I'm exploring some stuff inspired by the Type-level Church encodings
section of Towards Equal Rights for Higher-kinded Types and am
encountering some odd behavior.

Starting with the following definitions in the repl:

case class Equals[A, B >: A <: A]
trait hasT { type t <: hasT }
abstract class TypeHolder[T <: hasT] extends hasT { type t = T }
abstract class TNil extends hasT { type t = Nothing }

I try the following:

scala> Equals[TNil,TypeHolder[TNil]#t]                                          
res4: Equals[TNil,TypeHolder[TNil]#t] = Equals()

scala> Equals[TNil,f[TypeHolder[TNil]]]                                         
res5: Equals[TNil,f[TypeHolder[TNil]]] = Equals()

scala> Equals[TNil,TypeHolder[TypeHolder[TNil]]#t#t]                            
res6: Equals[TNil,TypeHolder[TypeHolder[TNil]]#t#t] = Equals()

scala> Equals[TNil,f[TypeHolder[TypeHolder[TNil]]#t]]                           
res7: Equals[TNil,f[TypeHolder[TypeHolder[TNil]]#t]] = Equals()

So far so good, but then I try switching the application of f and #t:

scala> Equals[TNil,f[TypeHolder[TypeHolder[TNil]]]#t]                           
<console>:10: error: illegal cyclic reference involving type t
       Equals[TNil,f[TypeHolder[TypeHolder[TNil]]]#t]
                                                   ^

As far as I can figure f[TypeHolder[TypeHolder[TNil]]]#t should be
equivalent to TypeHolder[TypeHolder[TNil]]#t#t and
f[TypeHolder[TypeHolder[TNil]]#t]

Even stranger is that after that error,
Equals[TNil,TypeHolder[TypeHolder[TNil]]#t#t] gives an error too where
it worked previously.

scala> Equals[TNil,TypeHolder[TypeHolder[TNil]]#t#t]                            
<console>:9: error: illegal cyclic reference involving type t
       Equals[TNil,TypeHolder[TypeHolder[TNil]]#t#t]
                                                ^

Does anyone have any idea what's going on here?

-- Geoff Reedy