Lucas Kramer

My concern is more about how things are logically arranged then about where they physically live. The goal should be to design things such that they don't require documentation to...

I can live with this. I would say that calling this 'the Java approach' seems a bit of a misnomer as Java does seem a bit more structured than this,...

When you mention `reflect` here, are you referring to what is now `core:reflect` or what is now `silver:reflect`? `core:reflect` is a runtime dependency with the `AST` nonterminal, but we don't...

Also, are you envisioning `silver:json`, `silver:reflect`, etc. all being distributed as seperate artifacts in addition to those listed, or would they be under `silver.util`?

But you mentioned above > There must not be any dependencies from runtime or generated code on things outside of the silver.lang artifact. Since what is now a part of...

I guess I still don't understand what you are proposing. Do you mean merging both `core:reflect` and `silver:reflect` into a `silver:lang:reflect` grammar that is distributed as part of the `silver.lang`...

Hmm, I guess I mostly don't have a problem with this. The only question is where does the deserialization code live? This involves some concrete syntax and building a parser....

Also, `hackUnparse` would want to use the `Document` pp variant, since the `String` serialization will fail on anything that isn't `anyAST`.

Although I guess we could move `hackUnparse` to langutil...

I would like to try and actually do this refactoring before the hackathon next week, since these changes would likely entail significant merge conflicts with whatever else is being worked...