There's a lot of options when it comes to code style / used packages - let's put some guidelines together to make things easier. I have some ideas in mind, which mostly come from my perspective of trying to learn something along the way and trying to make something useful for others :slightly_smiling_face::
there's great potential to create Haskell compiler that would be readable - GHC has some constraints in place when it comes to performance / backward compatibility / bootstrapping, but we can mostly ignore those. It would be cool to create codebase that people can use as a reference to learn about Haskell's internals, without going too educational at cost of ignoring real-world problems of language implementation.
good documentation would be great. Maybe we could strive for coverage somewhere between GHC and educational material - that is, precise descriptions with good examples in tricky parts, while trying to let code speak for itself when possible. Imagine something similar to "Lions' Commentary on UNIX with Source Code", just as a usable package instead of a book.
we could make use of Haddock as much as possible - I hate it when I'm trying to make sense of GHC/purs and I find function with non-descriptive name, not entirely clear body and no documentation. We could use formatting, ordering of exports, sections and separate text blocks to make modules read like a "story". We could use doctest to get tests from examples for free. Now, that's going to take some work, so we would e.g. do it incrementally instead of slowing down PRs.
when it comes to used packages, we could try to keep the list conservative when possible, but it would be nice to not limit ourselves to some sort of "beginner-friendly" or "common-only" packages - so e.g. recursion-schemes, optics and bound sound like a great fit for a compiler, as long as their use will be clear and they make a visible difference, while e.g. barbies sound like an overkill for me just to remove boilerplate in few transitions between compiler phases.
I've had a bad experience with inference of polymorphic return types of mtl/polysemy style in code with lots of local definitions, plus compilers seem to usually have pretty well defined phases, so I would probably rather use concrete monads for phase-specific code, and only keep polymorphic types for APIs of effects (similar to GHC).
There's a lot of options when it comes to code style / used packages - let's put some guidelines together to make things easier. I have some ideas in mind, which mostly come from my perspective of trying to learn something along the way and trying to make something useful for others :slightly_smiling_face::
there's great potential to create Haskell compiler that would be readable - GHC has some constraints in place when it comes to performance / backward compatibility / bootstrapping, but we can mostly ignore those. It would be cool to create codebase that people can use as a reference to learn about Haskell's internals, without going too educational at cost of ignoring real-world problems of language implementation.
good documentation would be great. Maybe we could strive for coverage somewhere between GHC and educational material - that is, precise descriptions with good examples in tricky parts, while trying to let code speak for itself when possible. Imagine something similar to "Lions' Commentary on UNIX with Source Code", just as a usable package instead of a book.
we could make use of Haddock as much as possible - I hate it when I'm trying to make sense of GHC/
pursand I find function with non-descriptive name, not entirely clear body and no documentation. We could use formatting, ordering of exports, sections and separate text blocks to make modules read like a "story". We could usedoctestto get tests from examples for free. Now, that's going to take some work, so we would e.g. do it incrementally instead of slowing down PRs.when it comes to used packages, we could try to keep the list conservative when possible, but it would be nice to not limit ourselves to some sort of "beginner-friendly" or "common-only" packages - so e.g.
recursion-schemes,opticsandboundsound like a great fit for a compiler, as long as their use will be clear and they make a visible difference, while e.g.barbiessound like an overkill for me just to remove boilerplate in few transitions between compiler phases.I've had a bad experience with inference of polymorphic return types of
mtl/polysemystyle in code with lots of local definitions, plus compilers seem to usually have pretty well defined phases, so I would probably rather use concrete monads for phase-specific code, and only keep polymorphic types for APIs of effects (similar to GHC).