Re: typer and tree mutation

Yeah, but sometimes Types contain crucial information that we cannot express without them.
For example, how would you express a type that is annotated with a locally defined annotation? We have AnnotationInfo#args of type List[Tree], AnnotationInfo#atp of type Type and AnnotationInfo#original of type Tree. I'm not sure how to use this trinity to compose an equivalent tree that won't fail subsequent reflective compilation.
On 15 February 2012 18:09, martin odersky <martin.odersky@epfl.ch> wrote:

On Wed, Feb 15, 2012 at 6:02 PM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:
> On the onset of reification Martin tried that, and it didn't work. /cc'ing
> Martin to learn about the details.
>
>
> On 15 February 2012 17:57, Paul Phillips <paulp@improving.org> wrote:
>>
>>
>>
>> On Wed, Feb 15, 2012 at 8:54 AM, Eugene Burmako <eugene.burmako@epfl.ch>
>> wrote:
>>>
>>> Speaking of robustness of the reifier, I passionately hate the fact
>>> that we cannot reify Types.
>>>
>>> Any ideas about dealing with this are very welcome.
>>
>>
>> We'd have to start with, why can't we reify types?
>
It produces an awful avalanche of reification code. In the end this
buys us nothing because backend transformers will transform the trees,
so they need a type checker anyway to typecheck the transformed trees.
Much better to reify typeless trees and use the type checker in the
backend to reconstitute the types. Fail fast philosophy. If
something's critical make sure it is used all the time.

Cheers

On Wed, Feb 15, 2012 at 6:22 PM, Eugene Burmako wrote:
> Yeah, but sometimes Types contain crucial information that we cannot express
> without them.
>
> For example, how would you express a type that is annotated with a locally
> defined annotation? We have AnnotationInfo#args of type List[Tree],
> AnnotationInfo#atp of type Type and AnnotationInfo#original of type Tree.
> I'm not sure how to use this trinity to compose an equivalent tree that
> won't fail subsequent reflective compilation.
>

First, the problem is probably smallish enough that we can just
declare it unsupported. Second, I do not think the way annotations are
typed should influence any strategy for the larger design. That way is
pretty arbitrary, and can presumably be changed.

Cheers

Yeah, sure, but this is a part of a bigger picture. For example, classOf[locally declared type] cannot be reified due to the same reason. Maybe, future will reveal more important scenarios, or one of the refactorings in the typer will break some part of reification. If we could make the reifier more robust in advance, that'd be wonderful.
On 15 February 2012 18:48, martin odersky <martin.odersky@epfl.ch> wrote:

On Wed, Feb 15, 2012 at 6:22 PM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:
> Yeah, but sometimes Types contain crucial information that we cannot express
> without them.
>
> For example, how would you express a type that is annotated with a locally
> defined annotation? We have AnnotationInfo#args of type List[Tree],
> AnnotationInfo#atp of type Type and AnnotationInfo#original of type Tree.
> I'm not sure how to use this trinity to compose an equivalent tree that
> won't fail subsequent reflective compilation.
>

First, the problem is probably smallish enough that we can just
declare it unsupported. Second, I do not think the way annotations are
typed should influence any strategy for the larger design. That way is
pretty arbitrary, and can presumably be changed.

Cheers

On Wed, Feb 15, 2012 at 9:56 AM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:

Yeah, sure, but this is a part of a bigger picture. For example, classOf[locally declared type] cannot be reified due to the same reason.

That reminds me...
  /** Apparently we smuggle a Type around as a Literal(Constant(tp))    *  and the implementation of Constant#tpe is such that x.tpe becomes   *  ClassType(value.asInstanceOf[Type]), i.e. java.lang.Class[Type].   *  Can't find any docs on how/why it's done this way. See ticket    *  SI-490 for some interesting comments from lauri alanko suggesting   *  that the type given by classOf[T] is too strong and should be   *  weakened so as not to suggest that classOf[List[String]] is any    *  different from classOf[List[Int]].   *   *  !!! See deconstMap in Erasure for one bug this encoding has induced:   *  I would be very surprised if there aren't more.    */  def mkClassOf(tp: Type): Tree =    Literal(Constant(tp)) setType ConstantType(Constant(tp))
The deconstMap reference is in regards to this ticket:

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