Define the exact scope of purescript-prelude

[rightfold]

I think we should, before 1.0, define exactly when something does and when something does not go into purescript-prelude. Currently it seems very arbitrary.

[hdgarrood]

I suspect it won't be possible to come up with a sensible rule which would allow us to do this, and also I don't think I agree that the lack of one is a problem. Could you expand on what prompted this and why you think it should happen?

[chexxor]

I agree that Prelude needs some level of defined scoping. It needs guidelines to answer question like "Does this module belong in Prelude?"

At the very least, Prelude needs to decide: Who is its the target user? What is the criteria for inclusion of modules?

Some potential definitions of Prelude's scope, as I see it:

"In PureScript, a Prelude is a basis of a community of modules. A community is defined by a shared set of formats and protocols, where a format is a data type and a protocol is a typeclass."

"In PureScript, a Prelude is a set of modules which are used in every PureScript project. It includes the set of data types and typeclasses most PureScript projects will need."

"In PureScript, a Prelude is a set of modules which are useful for getting started on a PureScript project. It includes the data types and typeclasses found to be highly used in open-source PureScript projects."

"In PureScript, a Prelude provides one standard solution to each common problem a PureScript problem will encounter. It includes any module used to solve a problem, like dates, data structures, "

[hdgarrood]

Defining the scope of this library is very different to defining the word "prelude" as used in the context of purescript, for example in sentences like "I am using a custom Prelude". You saying "a Prelude is ..." rather than "the Prelude is ..." makes me think you're thinking about the latter, is that correct?

I don't think we have a problem deciding whether stuff should be added. Some guidelines off the top of my head would be that it should a) not depend on anything outside Prelude, b) be something that we expect lots of projects would find useful, and c) not be too complex. Now b) and c) are of course fuzzy, and I'm sure there are plenty of cases which could be made for moving stuff into or out of Prelude based on these guidelines. But also I think this would be the case for any set of guidelines, and any completely unambiguous and unarguable set of rules would cease to be useful.

[chexxor]

The idea with that phrasing is to communicate that Prelude is a generic concept, one that anybody can implement and it implies philosophical choices - "purescript-prelude" is one prelude, but a user can choose a different prelude on which to base their project. Also, I tried to alleviate the fuzziness in guidelines by specifying the kind of user, and the value that user finds in Prelude - but it's probably not a great solution.

Yeah, I think those guidelines are the current guidelines. But, with those, why not have every PureScript library be in this repo? I imagine most library authors would say their library fits those guidelines. :) I think well-considered guidelines would resolve that, which was my goal.

Perhaps we can answer this question of Prelude's scope by simply describing the problem Prelude is solving, and the constraints in which that problem must be solved.

[hdgarrood]

I think you need to decide whether you're defining the scope of this Prelude or whether you're defining the term "prelude" used more generally, for example as in "a custom prelude"; you can't do both at the same time, they're too different and it will just be confusing. Let's leave the latter aside for the moment as this isn't the right place to discuss it.

I think this Prelude module's main purpose is to provide a standard set of types, typeclasses, functions, etc that everyone knows of and can refer to without having to qualify, and in particular should be used by most PureScript libraries (see Prelude replacements are for application developers), by most documentation / articles / etc (where appropriate), and as a starting point for applications (although at a certain size of application you probably will want to start using a larger one). In addition to the guidelines I mentioned above Prelude should also aim to remain small: this makes it easier to maintain and means we don't need to make breaking changes too often, which makes life easier for people whose projects depend on it. Keeping this Prelude small also means that someone relatively new to PureScript can browse through it and not be too overwhelmed.

Yeah, I think those guidelines are the current guidelines. But, with those, why not have every PureScript library be in this repo? I imagine most library authors would say their library fits those guidelines. :) I think well-considered guidelines would resolve that, which was my goal.

Now I've introduced a new principle which seems to resolve this question, but as I said before, with any set of guidelines, I suspect you'll be able to come up with examples of things that should be moved in or out. So then the choices are to a) amend the guidelines to better reflect the current state of the Prelude or b) to start moving things around so that Prelude better fits the guidelines. I think a) could continue indefinitely, and we're almost certainly not going to do b) because it's a lot of pain for relatively little benefit, so I'm still very much unconvinced that this would be a useful exercise. In particular we're not inundated with library authors asking for their libraries to be incorporated into Prelude, quite the opposite in fact.

[hdgarrood]

I think I'm going to close this, since the discussion seems to have come to an end.

[chexxor]

This should be reopened. The Additive Monoid now lives in prelude, https://github.com/purescript/purescript-prelude/issues/163, and I'd like to have a well-defined project scope to use when arguing for its removal.

Based on the discussion in that issue, it seems like there was very little consideration for whether it should live in Prelude. I don't think Additive should be in Prelude, and I trusted the implicit scope of the Prelude would reject the addition of that kind of thing. I don't blame the person who added it, as that person had no rules to look at when making the judgement.

So, the implicit project scope didn't catch it, so what recourse do we have for campaigning for its removal? It's a bit of a waste of maintainers time to receive a request, "I think Additive is out of scope of the Prelude", because what follows is a unilateral "You're wrong, I'm the maintainer and I say it stays" or else it would be a long argument on its merits for keeping it or dropping it for this one case. It would be leagues better to have a set of guidelines which describe the project scope against which we measure Additive to see if it belongs in this prelude. If there's guidelines, we can make an issue to argue about the guidelines, rather than the one specific instance of Additive.

It's ridiculous to shut down discussion on this. It's a terrible argument that "It's impossible to accurately describe the scope and audience of this prelude, so we shouldn't even try". The same can be said of the PureScript compiler itself -- "It's impossible to write a compiler which allows correctly expressing and checking all aspects of a program, so we shouldn't even try" -- if the compiler is Great but not Perfect there are lots of people will still use it and love it.

[garyb]

It now lives in Prelude because it takes the operations of one prelude class and makes them available in another. What's the advantage of removing it?

To me, the only part of the prelude that makes it interesting is the Prelude module. I'd be fine with having separate libraries for all the parts that make it up and just have the module to re-export. I think the problem with trying to define and argue about what should or shouldn't be in the prelude extends equally to the core libraries in general, since almost everything outside of core pulls in the majority of it anyway. 🤷‍♂️ There's an argument for making it much larger perhaps?

If you want to propose some criteria for why stuff should or shouldn't be in the prelude I can give my thoughts, but this isn't a discussion that interests me much personally, so I won't be making much in the way of considered proposals myself. I'm still not exactly clear on what the problem it's trying to solve is.

[hdgarrood]

It's ridiculous to shut down discussion on this. It's a terrible argument that ...

This is not an appropriate way to conduct this sort of discussion. You haven’t made a sufficiently convincing argument for doing this; that doesn’t mean you get to start calling other people’s viewpoints or actions ‘ridiculous’.

[chexxor]

This is not an appropriate way to conduct this sort of discussion.

Very sorry, I'll be more sensitive. Thanks for maintaining prelude!