Drasil: Standardize Drasil File Structure

[Mornix]

Currently Drasil packages have no uniform "path" for inclusion. Some packages do one method, some do another.

Paths:

• drasil-lang: Language.Drasil
• drasil-data: Data.Drasil
• drasil-code: Language.Drasil.{Code,CodeSpec, etc}
• drasil-docLang: Drasil.{DocLang, DocumentLanguage, etc}
• drasil-gen: Language.Drasil
• drasil-printers: Language.Drasil
• drasil-example: Drasil.{GlassBR, SSP, etc}

From this list, we can see that packages split from drasil-lang retain the Language.Drasil prefix,
drasil-data has a pattern which is the same as drasil-lang, and drasil-docLang (and drasil-example although not "used" by anything) has a unique prefix with `Drasil1 at the top level.

It would be nice to standardize of a path structure for consistency, predictability, and before too many sub packages exist.

[JacquesCarette]

So there are at least two things going on here. First, there is a division into "packages" -- these are supposed to be grouping together like things. So we have

• lang: the representation language for two levels (basic information and chunks)
• data: fundamental knowledge that is shareable amongst many pieces of software
• code: code generation
• docLang: document language routines
• gen: generation of all artifacts
• printers: document generation
• example: examples of Drasil use

There is also some places to put modules related to Drasil. It is customary, in Haskell, to define things that are "languages" in Language.X and "data" for X in Data.X. Because Drasil is itself a rich language, it makes some sense to use it as namespace too, and so the examples fit there. GHC, for example, has a top-level GHC package.

That does leave drasil-code, drasil-docLang, drasil-gen and drasil-printers as not having a solid namespace design. So I guess I would be quite open to suggestions (perhaps after perusing Hackage?) of where to place some of these things.

[samm82]

For the sake of completeness, we also have:

• build: build system languages and renderers

EDIT: This issue was very helpful for #1252! Thanks for this nice summary of the packages 👌

[Mornix]

So I've thought about this for a bit and took a very very brief look at Hackage. I noticed Language.ABC as you mentioned. I did also see pretty printers being placed under Text.ABC. So I would say with that bit of information:
drasil-build → Text.Drasil.Build
drasil-code → Text.Drasil.Code
drasil-printers → Text.Drasil.(Printers | just the individual languages like TeX and HTML — Note: to properly do this, we would need to clear up DocType having SRS and Website and move that to a more appropriate package for the SRS component.

https://github.com/JacquesCarette/Drasil/blob/master/code/drasil-printers/Language/Drasil/Output/Formats.hs#L11

drasil-gen → Language.Drasil.Gen
drasil-docLang → Language.Drasil.DocLang
drasil-database → Language.Drasil.Database

drasil-theory → Data.Drasil.Theory (since this seems to be more data oriented)

[JacquesCarette]

I agree with all of these proposed renamings. Doing it should be done quite incrementally though.

From printers, Text.Drasil.Tex (etc) is probably a good way to do it. And indeed, shouldn't be done until 1) the current work on indentation is finished, and 2) DocType is fixed.