Repository navigation
Consider splitting up the compiler into multiple packages #3633
Description
Activity
I'd suggest only splitting things up once we've identified specific cases where it would be useful to depend on only those things, so perhaps we could just start with the parser.
This sort of workflow is supported by Stack and used by projects like yesod, see for example https://github.com/yesodweb/yesod so I'd suggest using whatever Stack expects to see (although I haven't yet looked into what that means exactly).
I think the parser and corefn stuff would be super useful to have in their own packages 👍
Reacted by Gabe JohnsonThe thing about corefn is that right now I think we only define corefn -> json conversion and not the other way; for corefn to be useful on its own we'd need the conversion in the other direction right?
The other direction is here https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CoreFn/FromJSON.hs#L109 ?
Lol, ignore me then
@natefaubion thanks for opening the discussion on this!
In spago I sometimes wish we had access to the compiler (mostly for the parser), but we cannot depend on it in the current state as build times would get long.
So it could be nice if e.g. the parser was a separate package (e.g. I already tried to depend on
purescript-cstat some point, see natefaubion/purescript-cst#10), but on the other hand I'm not sure this is a good idea on our side: after allpulphas managed just fine without a compiler dependency for long timeSo far we avoided being blocked by "depending on the compiler", except for purescript/spago#165, where we might have to choose between:
- implementing the functionality in the compiler (problem: adding maybe orthogonal functionality under the "facilitating build tools" label)
- implementing a subset of the PS parser in spago (problems: it might get out of sync with upstream, and other build tools will have to reimplement it if they want the feature)
- depending on the compiler (problem: build times)
Since we are open to splitting off packages, I'll make a small proof of concept of implementing the above feature by depending on the compiler as a library, so I'll get a better idea of which package I'd like (most likely just the parser)
I had a quick look at this (branch) and here's what I'm proposing (if only to stimulate discussion).
We add a
libdirectory in the root of the project to holdpurescript-*packages, and the rest of the repo remains largely the same. Thestack.yamlwould then look like...resolver: lts-13.12 pvp-bounds: upper packages: - '.' - 'lib/purescript-parser' # ...etcIn theory all the packages under
libshould capture some useful piece of the compiler and be published/publishable to hackage (e.g. in the first instance maybe the parser and corefn).The issue is that there are certain "core" modules that would probably need to be shared across these packages (e.g.
Language.PureScript.Errors,Language.PureScript.Names), but how we do that would depend on how granular we want this split to be. I'm assuming we can't list these modules asother-modulesfor several packages when they depend on each other (and that's probably a hack anyway), so we might need apurescript-corepackage, which also feels a bit lame.I'd like to close it and discuss further steps in their own issues, personally.
Reacted by Christoph Hegemann and Fabrizio Ferrai
This was brought up in Slack (primarily by @f-f), and I think it's something we should discuss.