Idempotency of typechecking

[Eugene Burmako]

Recently I've discovered that typechecking isn't idempotent w.r.t. unapplies, i.e. if you:

1) take a well-typed pattern match that contains extractors

2) typecheck it

3) reset all attrs

4) typecheck it

Then step #4 will crash, because of the <unapply-selector> guy that's generated during step #2.

This is more than just a curious fact, because it's undesirable for reification. When the reifier processes an AST, it dehydrates it by removing the types and leaving only some of the symbols. Subsequent reflective compilation typechecks the reified tree again (actually, it does the typechecking twice) and expects something that has been typechecked once (before the reification) to be successfully typechecked later on. So situations similar to the one described above need to be processed by the reifier in a special way.

Hence the question. What other cases of non-idempotence do you know?

[Eugene Burmako]

After today's meeting, Adriaan mentioned two more cases:
1) This'es for package classes
2) Typed binds

I know about the first one (it's worked around in resetAllAttrs), but
I don't fully get the second one. Adriaan, could you, please, provide
an example?

[Adriaan Moors]

On Tue, Feb 7, 2012 at 7:15 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

After today's meeting, Adriaan mentioned two more cases:
1) This'es for package classes
2) Typed binds

I know about the first one (it's worked around in resetAllAttrs), but
I don't fully get the second one. Adriaan, could you, please, provide
an example?

On second thought, I was probably wrong about Bind. Sorry to have wronged you, Bind.

typedBind enters a new symbol into the scope of the case in which it occurs,

so if you reset the attributes of the rhs of that case, you must make sure to re-typecheck in the right scope

(I think I didn't and blamed it on the supposed lack of idempotency)

[Eugene Burmako]

3) Lazy vals

[Hubert Plociniczak]

On 02/14/2012 10:23 AM, Eugene Burmako wrote:
> 3) Lazy vals

implies nested objects as well, I guess?

[Eugene Burmako]

Yep, when lazy val is local, its name gets appended with $lzy and its
IMPLICIT flag gets reset. More info here: https://issues.scala-lang.org/browse/SI-5276.

On Feb 14, 10:27 am, Hubert Plociniczak <hubert.plocinic...@epfl.ch>
wrote:

[Adriaan Moors]

I just came across this in Duplicators

     *  LabelDefs are not typable from trees alone, unless they have the type ()Unit. Therefore,

     *  their symbols are recreated ad-hoc and their types are fixed inline, instead of letting the

     *  namer/typer handle them, or Idents that refer to them.

[martin odersky]

On Fri, Mar 9, 2012 at 6:08 PM, Adriaan Moors <adriaa...@epfl.ch> wrote:
> I just came across this in Duplicators
>
>      *  LabelDefs are not typable from trees alone, unless they have the
> type ()Unit. Therefore,
>      *  their symbols are recreated ad-hoc and their types are fixed inline,
> instead of letting the
>      *  namer/typer handle them, or Idents that refer to them.
>

Yuck. Anyway to fix this? -- Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Paul Phillips]

On Fri, Mar 9, 2012 at 1:49 PM, martin odersky <martin....@epfl.ch> wrote:
>>      *  LabelDefs are not typable from trees alone, unless they have the
>> type ()Unit. Therefore,
>>      *  their symbols are recreated ad-hoc and their types are fixed inline,
>> instead of letting the
>>      *  namer/typer handle them, or Idents that refer to them.
>>
> Yuck. Anyway to fix this? -- Martin

Why does the type of the LabelDef differ from the type of its rhs?