Modularization of the code base

[doyougnu]

I would like to start decoupling the code base. This would mean separate packages for the parser, expander, evaluator. I'm unsure how feasible a lot of that is but just moving code to packages in a cabal.project would be a start.

Why? Well architecturally I really don't like monoliths. This would force us to define good api's between each subsystem and would make maintenance and experimentation easier.

[gelisam]

In any other project, I would worry that the multi-package ghcid experience is not great yet, but on Klister I usually run cabal run klister -- run examples/my-example.kl whenever I edit a .hs or .kl file, and I think that would continue to work just fine if the code is divided into multiple packages. So sure, if that's what you're passionate about, go ahead!

[gelisam]

I'm unsure how feasible a lot of that is

The parser can definitely be separated. The evaluator too, probably, since it isn't split into multiple tasks. But I suspect you will be unhappy with the end result, because the expander+typechecker logic will be much bigger than everything else, you will only have moved out two modules (Parser.hs and Evaluator.hs). I guess the biggest win might be moving out the dependencies of those two files: Syntax, Scope, ScopeSet, Core, PartialCore, SplitCore, Kind, Type, PartialType, SplitType, Value, Env, Unique, Pretty, and ShortShow (which is barely used, we should get rid of it in favor of Pretty).