This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Introducing a phase rightBefore typer?

3 replies
MLeo Daalder
Joined: 2011-02-13,
User offline. Last seen 42 years 45 weeks ago.

I'm trying to create a compiler plugin that tells me, at compile time,
if an implicit exists.

What it should do is the following, every instance of
Implicit[SomeType] should be replaced with (Implicit[SomeType]{type
exists = Yay or Nay}).

I'd actually like to run the new phase rightAfter typer, however the
following would then not compile:
def test(implicit t: Implicit[String =:= Int]#exists =:= Nay)
This would already produce an error and then my plugin wouldn't not
even have a chance to run.

So the option would then be to run it rightBefore typer and runsAfter
packageobjects, right? Unfortunately the typer phase declares itself
to run rightAfter packageobjects and it will produce the following
error:
scala.tools.nsc.FatalError: phase typer want to run right after
packageobjects, but some phase has declared to run before typer. Re-
run with -Xgenerate-phase-graph to better see the problem.

Aside from that, I think I need the typer information as well. So I
would need a runsDuring. :S

Can anyone suggest a better solution? One of the options would be to
subclass the typer phase, for the obvious reasons I don't think I'd
like to do that.

Also, what could be the reason for the strict runsRightAfter
requirement of typer?
Perhaps I could create a phase that runs before packageobjects
(because before typer isn't possible) and replaces the type
information of Implicit[SomeType] with a symbol with some hooks in it
that would then lookup current type information and change itself
before the typer has a chance to actually read it?

Thank you for your time,

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Introducing a phase rightBefore typer?

Namers, typers, and package objects are intimitely linked. In fact all
three phases happen in an interleaved fashion, using a lot of lazy
evaluation to avoid infinite cycles. That means you need to insert a
plugin either between parser and namer, or else after typer.

Cheers

MLeo Daalder
Joined: 2011-02-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Introducing a phase rightBefore typer?
I've currently inserted my plugin after the namer, however it seems that the typer is already at work before my plugin is called.So I inserted my plugin rightAfter the namer yet the packageobjects wants that spot, if I do runsAfter namer then my plugin gets pushed to after typer, which will create a type error. And rightAfter the parser I'll have to duplicate most logic of the following phases to detect invocations (while I only have idents) to methods/functions that use the Implicit type.


On Sun, Feb 13, 2011 at 15:58, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
Namers, typers, and package objects are intimitely linked. In fact all
three phases happen in an interleaved fashion, using a lot of lazy
evaluation to avoid infinite cycles. That means you need to insert a
plugin either between parser and namer, or else after typer.

Cheers

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Introducing a phase rightBefore typer?

On Sun, Feb 13, 2011 at 9:24 PM, MLeo wrote:
> I've currently inserted my plugin after the namer, however it seems that the
> typer is already at work before my plugin is called.
> So I inserted my plugin rightAfter the namer yet the packageobjects wants
> that spot, if I do runsAfter namer then my plugin gets pushed to after
> typer, which will create a type error. And rightAfter the parser I'll have
> to duplicate most logic of the following phases to detect invocations (while
> I only have idents) to methods/functions that use the Implicit type.
>
Yes, well, it looks like what you want to do is not possible with the
standard plugin architecture.
The transition from parsed trees to trees with full types is really
atomic, you can't squeeze anything in there.
Even if you would let you I would bet the result would be not what you
want. If you need your code to be concurrent with type checking, you'd
need to create a new compiler that overrides analyzer. That's pretty
difficult to do, so if you have other options, I would advise you to
steer away form this.

Cheers

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland