How to create a new *package* in a Scala Compiler Plugin?

[This kind of thing would be better on scala-internals.]

On Sat, Oct 29, 2011 at 5:27 AM, monster wrote:
> In my quest to generate new code in a Scala compiler plugin, I have
> now created working classes. The next logical step is to put those
> classes in a new, non-existing package. In Java, a package is
> basically a directory name, but in Scala a package seems much more
> complicated.

I'm not sure there would be packages in scala were it not for java
(and the jvm.) They're basically a degenerate case of modules with
some arbitrary limitations. So if it's complicated it's only due to
round peg and square holedness.

> and than later create a Tree for the package with PackageDef. But
> PackageDef doesn't take the symbol as parameter, as one would expect,

Packages aren't like anything else. They're not first class ("package
foo is not a value") etc.

> val newPkg = parentPackage.newPackage(NoPosition, newTermName(name))
> newPkg.moduleClass.setInfo(new PackageClassInfoType(new Scope,
>    newPkg.moduleClass))
> newPkg.setInfo(newPkg.moduleClass.tpe)
> parentPackage.info.decls.enter(newPkg)
> // ...
> val newPkgTree = PackageDef(Ident(newPkg.name), List(ClassDef(...)))

You shouldn't have to get this low level. What do you plan to do with
the PackageDef tree? Offhand I can't see what you can accomplish with
it. You're already in there programatically, the tree will just get
in your way.

But if you do want one, the symbol could be created and set up for you
like this:

scala> val t = PackageDef(Select(Ident("scala"), "bippy"), Nil)
t: $r.intp.global.PackageDef =
package scala.bippy {

}

scala> typer.namer.enterSym(t)
res0: $r.intp.global.analyzer.Context = Context(package
@EmptyTree unit=NoCompilationUnit scope=378315997)

scala> t.symbol
res1: $r.intp.global.Symbol = package bippy

scala> t.symbol.ownerChain
res2: List[$r.intp.global.Symbol] = List(package bippy, package scala,
package )

scala> definitions.getModule("scala.bippy")
res3: $r.intp.global.Symbol = package bippy

On Oct 29, 5:09 pm, Paul Phillips wrote:
> [This kind of thing would be better on scala-internals.]

The description of "scala-internals" mailing lists clearly says:

"only post new threads if you commit to the Scala code base"

So I don't think I should be posting there.

> some arbitrary limitations. So if it's complicated it's only due to
> round peg and square holedness.

I didn't mean complicated in a negative sense, I meant that packages
exist only implicitly in Java, while in Scala the exist explicitly as
objects, so they are "bigger" than Java packages.

> You shouldn't have to get this low level.  What do you plan to do with
> the PackageDef tree? Offhand I can't see what you can accomplish with
> it.  You're already in there programatically, the tree will just get
> in your way.

Honestly, I just don't know what I'm meant to do. And I didn't find an
example, so I'm just experimenting, but things keep getting more
complicated without showing any signs of success. To put it simply, I
have a trait in package X, and I generate a Class, and I want it in
package X.Y (the simple case) That is all I'm trying to do, but
despite creating a Package Y symbol, and making it child of package X,
and making the generated Class a child of Package Y, the generated
Class is still in Package X (according to the output of "[[syntax
trees at end of generatewrappers]]/") when compiled, and the I get an
Exception. But one thing I found strange is that I was expecting each
package to be visited once, but it seems it is visited once per child,
or maybe once per source file.

I think the only correct point to add new code to a package is when it
is being visited, but a package that doesn't exist doesn't get
visited. And even if the target package existed, I still don't know
how I would go about it. If the target package gets visited before the
annotated trait that causes generation, then it is too late to create
a new child for that package when I hit the trait, and if the trait
gets visited first, where and how do I "store" the generated class
until the target package gets visited. It does seem possible to visit
the same package several times, but if the new package is not even a
child of the current package, how would I put the new (pre-existing or
not) package in the "global queues of things to visit"?