structural type manifests

Hi,
I don't know why we limited the number of parents to 1.
FYI, in virtualized scala, Philipp has extended these manifests: https://github.com/adriaanm/scala-dev/blob/virtualized-mostrecent/src/compiler/scala/tools/nsc/typechecker/Implicits.scala#L1275
Note that with this change, a manifest for a refinement that counts methods amongst its members requires manifests for MethodTypes, which we don't (yet) have(in other words, it'll only work for types with val-members).
cheersadriaan

On Mon, Nov 28, 2011 at 3:15 PM, Christopher Vogt <christopher.vogt@rwth-aachen.de> wrote:

Paul, Adriaan, others,

based on trunk (r26077) I found a way to make LiftCode work for new{...}
(see attached scala test file) by simply removing one line in the
compiler (see attached patch). It also fixes the bug about structural
type manifests.

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

partest passed as well. I am still not completely certain about the
change, as I have no idea what the intention of that line was. SVN
blames the line on Paul. Paul or Adriaan, can you please review the
patch before I commit it?

Thx

Chris

On Mon, Nov 28, 2011 at 6:15 AM, Christopher Vogt
wrote:
> partest passed as well. I am still not completely certain about the
> change, as I have no idea what the intention of that line was. SVN
> blames the line on Paul. Paul or Adriaan, can you please review the
> patch before I commit it?

My blame arises from eliminating a call to .length. The relevant
logic goes all the way back to the introduction of that code, in
r14347.

https://lampsvn.epfl.ch/trac/scala/changeset/14347

So if it doesn't break anything you can see and unbreaks something,
then sounds good to me, though I'm a little doubtful about how much
useful functionality we can be acquiring by commenting out code from
the 14000s.

On Mon, Nov 28, 2011 at 4:20 PM, Adriaan Moors <adriaan.moors@epfl.ch> wrote:

Hi,
I don't know why we limited the number of parents to 1.
FYI, in virtualized scala, Philipp has extended these manifests: https://github.com/adriaanm/scala-dev/blob/virtualized-mostrecent/src/compiler/scala/tools/nsc/typechecker/Implicits.scala#L1275
Note that with this change, a manifest for a refinement that counts methods amongst its members requires manifests for MethodTypes, which we don't (yet) have(in other words, it'll only work for types with val-members).
cheersadriaan

The whole manifest generation will change.  In the future manifests
should be just implicit wrappers on reflect.Types. But to make that work, we need to change reification of types so that manifests are followed. I.e. if I reify type List[T] and T has a manifest `m` then I want to produce the type

  TypeRef(<scala.collection.immutable>, <List>, m.tpe)

In other words, manifests splice reflect types. And to make that work, reification needs to be done at type-checking time (because otherwise no manifests are generated)

And to make that work, the most elegant way would be to do reify as a macro. But we can move it to typechecking time even ebfore we have macros, then there's less work to do afterwards.

So what I would propose: Get rid of phase LiftCode. Expand Code.lift expressions to reified trees in the typechecker (keep the logic in a separate trait of course, Typers.scala is already long enough as it is.

Cheers

 -- Martin

agreed -- sorry, I forgot about that while writing the email, but haven't forgotten I promised to work on this :-)

On Mon, Nov 28, 2011 at 4:37 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Mon, Nov 28, 2011 at 4:20 PM, Adriaan Moors <adriaan.moors@epfl.ch> wrote:

Hi,
I don't know why we limited the number of parents to 1.
FYI, in virtualized scala, Philipp has extended these manifests: https://github.com/adriaanm/scala-dev/blob/virtualized-mostrecent/src/compiler/scala/tools/nsc/typechecker/Implicits.scala#L1275
Note that with this change, a manifest for a refinement that counts methods amongst its members requires manifests for MethodTypes, which we don't (yet) have(in other words, it'll only work for types with val-members).
cheersadriaan

The whole manifest generation will change.  In the future manifests
should be just implicit wrappers on reflect.Types. But to make that work, we need to change reification of types so that manifests are followed. I.e. if I reify type List[T] and T has a manifest `m` then I want to produce the type

  TypeRef(<scala.collection.immutable>, <List>, m.tpe)

In other words, manifests splice reflect types. And to make that work, reification needs to be done at type-checking time (because otherwise no manifests are generated)

And to make that work, the most elegant way would be to do reify as a macro. But we can move it to typechecking time even ebfore we have macros, then there's less work to do afterwards.

So what I would propose: Get rid of phase LiftCode. Expand Code.lift expressions to reified trees in the typechecker (keep the logic in a separate trait of course, Typers.scala is already long enough as it is.

Cheers

 -- Martin