|generated/||src and bin will be created here by default. Basically anything you find in here can be deleted.|
|runtime/java/||The Silver runtime, written in Java. Should have decent JavaDocs.|
|support/||Random supporting files. Scripts, syntax highlighting stuff, etc.|
|test/||Tests for silver. Not a particularly good organization below it yet.|
|tutorials/||Tutorials, to be distributed with Silver.|
|grammars/silver/core/||The always-included silver library.|
|grammars/silver/compiler||the Silver compiler implementation|
|grammars/silver/util||silver:util is deprecated, but stuff below it isn’t necessarily, and some of the grammars below it should be considered “standard library”|
|grammars/silver/testing||the testing harness stuff, both the library and the binary.|
|grammars/silver/langutil||standard library stuff, but specific to language processing|
|grammars/silver/compiler/definition/core||the central place to look for silver compiler stuff|
|grammars/silver/compiler/definition/ (env,type,regex,concrete_syntax)||Silver environment, type, regular expression syntax, and the concrete syntax for concrete syntax declarations in Silver. (Don’t confuse this for Silver’s concrete syntax!)|
|grammars/silver/compiler/analysis/||typechecking, flow analysis, etc.|
|grammars/silver/compiler/translation||The translation to Java is here|
|grammars/silver/compiler/host||a “host language” definition for silver.|
|grammars/silver/compiler/extensions||pure extensions to the silver “host language”|
|grammars/silver/compiler/modifications||pieces of the core Silver language that are pretty self-contained, but not true, pure extensions|
|grammars/silver/compiler/composed||Where the main function lies|
Modifications are pieces of the core of the silver language that are relatively self-contained. Let expressions, for example, don’t have a lot of implications in the wider language, or at least, not yet.
The choice of what’s in modifications, and what’s elsewhere at the moment is slightly arbitrary and could use a re-design.
Extensions, in contrast, are actually real, true, pure extensions that follow all the “rules” for what a language extension should be like. Uhh… except the list extension, right now. It’s breaking those rules.
Not much. At the moment, typechecking is basically the only real things in there. And it is kinda nice that the substitution-state threading stuff is hidden away there, but type checking is such a core part of the language now that it makes little sense for it to be separate.
In Silver’s past there have been several different translations, and several parser generators supported. We’re keeping that structure, even though we’re only maintaining Java and Copper.
Basically, it should be designed AS IF you could choose to use other translations and other parser generators, even if none are there. It currently fails to fully live up to that goal, because a few grammars need a little bit of refactoring on that point (e.g. some modifications don’t bother to separate out the java translation, but should.)
At the moment it’s a bit confused. The language has evolved a LOT, and some refactoring is needed.
Roughly, if it’s a really, hugely core part of the language (nonterminals, attributes, production, equations) it goes in core.
If it’s a huge cross-cutting part of the language, but is easily self-contained, it goes as its own thing in definitions. (types, the environment code, the regex grammar)
And modifications are non-cross-cutting, self-contained things that aren’t quite true extensions.
The whole organization could probably use some rethinking.