Re: [scala] Re: higher-kinded types

Adriaan,

First of all, thanks for the time and thought you put into this. i'm not happy with your interpretation. i cannot convince myself that refinements might not relax the "A"-ness (apologies for the awful sfunctor of a pun hiding here ;-) of the contained element. More importantly, the bug is a bug regardless of whether my encoding has the semantics i want. The compiler is complaining that type bounds are not met that to my eyes plainly are -- unless you can convince me otherwise. For example, if you can give me the interpretation into the appropriate type calculus of the situation i reported, i will do the calculation myself.

Best wishes,

--greg

On Fri, Jun 26, 2009 at 2:35 AM, Adriaan Moors <adriaan.moors@...> wrote:

Hi,

I think you meant to write

trait MBrace[C[X] <: MBrace[C,X], A] 

instead of

trait MBrace[C[_] <: MBrace[C,A], A]

(see also ticket 2096)

We only used type members in our (OOPSLA) paper to hide some of the higher-kinded types away for backward compatibility.

I would not advocate encoding type constructors using something like your TypeCtor1 trait, as the encoding makes type&kind checking less precise, and you'll lose type inference (type constructor inference should be coming to 2.8.x, btw).

cheers

adriaan

On Thu, Jun 25, 2009 at 8:47 AM, Meredith Gregory <lgreg.meredith@...> wrote:

All,

The following code works without going through the M-P-O construction. It enjoys approximately the same brevity as a Haskell type class.

// smallest expression of monad i can find
trait MBrace[C[_] <: MBrace[C,A],A] {
  def nest( a : A ) : C[A]
  def flatten[T <: C[C[A]]]( bsq : T ) : C[A]
}

// one of the simplest witnesses of monad i can find
class MBraceSeq[A]( a_ : A* ) extends Seq[A] with MBrace[MBraceSeq,A] {
  override def nest( a : A ) = new MBraceSeq[A]( a )
  override def flatten[T <: MBraceSeq[MBraceSeq[A]]]( bsq : T ) : MBraceSeq[A] = {
    (new MBraceSeq[A]( ) /: bsq)( {
      ( acc : MBraceSeq[A], e : MBraceSeq[A] ) => ( acc ++ e ).asInstanceOf[MBraceSeq[A]]
    } )
  }
  override def length = a_.length
  override def elements = a_.elements
  override def apply( n : Int ) = a_.apply( n )
}

Best wishes,

--greg

On Wed, Jun 24, 2009 at 3:49 PM, Meredith Gregory <lgreg.meredith@...> wrote:

All,

Am i correct in concluding that the solution in The Moors-Piessens-Odersky paper only works with collections that have been clever enough to have used type members rather that type parameters? Or, is there a trick to making the vast majority of the collections types that are parametrically typed look as if they have type members? (See example below.)

Best wishes,

--greg

// Paraphrasing the basic Moors-Piessens-Odersky construction
trait TypeCtor1 { type E }
trait Brace[A] extends TypeCtor1 {
  type C <: TypeCtor1
  def nest( a : A ) : C{type E = A}
  def flatten( bsq : C{type E=C{type E=A}} ) : C{type E=A}
}

// Now, how to make a version of BraceList since List is parametrically typed?


--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more information.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com