- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Idempotency of typechecking
Tue, 2012-02-07, 19:13
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 it3) 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?
2) typecheck it3) 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?
Tue, 2012-02-07, 20:01
#2
Re: Re: Idempotency of typechecking
On Tue, Feb 7, 2012 at 7:15 PM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:
After today's meeting, Adriaan mentioned two more cases: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)
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?
Tue, 2012-02-14, 10:31
#3
Re: Idempotency of typechecking
3) Lazy vals
On Feb 7, 7:15 pm, Eugene Burmako 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 Feb 7, 7:13 pm, Eugene Burmako wrote:
>
>
>
> > 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 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?
Tue, 2012-02-14, 10:41
#4
Re: Re: Idempotency of typechecking
On 02/14/2012 10:23 AM, Eugene Burmako wrote:
> 3) Lazy vals
implies nested objects as well, I guess?
> On Feb 7, 7:15 pm, Eugene Burmako 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 Feb 7, 7:13 pm, Eugene Burmako wrote:
>>
>>
>>
>>> 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 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?
Tue, 2012-02-14, 11:31
#5
Re: Idempotency of typechecking
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
wrote:
> On 02/14/2012 10:23 AM, Eugene Burmako wrote:
>
> > 3) Lazy vals
>
> implies nested objects as well, I guess?
>
>
>
> > On Feb 7, 7:15 pm, Eugene Burmako 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 Feb 7, 7:13 pm, Eugene Burmako wrote:
>
> >>> 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 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?
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 Feb 7, 7:13 pm, Eugene Burmako wrote:
> 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 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?