Features you want future PureScript to *not* have?

[chexxor]

I was thinking about the “mission statement” thing on the PureScript home page. I was motivated by Brian Marick’s concern with the mission statement in his tweet. The PS project’s “elevator pitch” accurately describes the current state of the project, but it doesn’t reflect the values and tastes of the PureScript community. The values and tastes of the project’s community and maintainers pretty well control its future direction.

There are lots of people who learned PureScript and love it – what about it do they love? What about PureScript do they want to ensure isn’t changed? Or, a more interesting question, what parts of other languages do you want PureScript to not adopt?

I’m interested to hear PureScript users’ answers to that latter question:

What parts of other programming languages do you want PureScript to not adopt?

[thomashoneyman]

A reluctance to provide helpful documentation for libraries – not just function documentation, but also “getting started” tutorials, example cases, and so on. I’d love to see this remain just a Haskell thing and see PureScript do better. Rust is a tremendous example of this done well IMO. (I hear the same about Elm, but since I haven’t used the language I can’t say for sure.)

[chexxor]

I’d like PureScript to not allow language extensions, like Haskell has. Should have some system to ensure they don’t end up sitting around forever as opt-in things like in Haskell.

Extensions seem fine for testing things out, but they make it really confusing for newcomers. Why not just bake them into the language proper? And you can’t just ignore them - so many Haskeller’s expect you to know certain extensions and lots of problems that Haskell is uniquely good at describing with types require extensions.

This kinda has an effect of breaking changes to the compiler, of course. I think some Haskell extensions exist as such because it allows users to opt-in to the breaking behavior. If PS didn’t have opt-in breaking changes with any compiler version, then they would be forced to opt-in when upgrading to latest version of the compiler.

[paf31]

I honestly don’t want PureScript to get any new features for at least a year. I think it would be better to spend time on bug fixes, library improvements and documentation (including a language specification).

[marick]

Soul mate! There’s a ton of low-hanging fruit in even core documentation. I hope after 0.12 that pull requests like this one for Data.Map get approved.

[dtwhitney]

I could not agree more. I have been thinking I should keep track of compile errors that are simple to solve but somewhat cryptic when you see them. I’ll start doing that and maybe take a crack at improving them somehow. Is there a discussion on this topic somewhere?

[paf31]

I think there is still a combined compiler issue for error messages which need improving.

[kritzcreek]

@dtwhitney A good start would be filtering the issues for the error-message label:

purescript/purescript

[thomashoneyman]

I’ve made an attempt to walk the walk by putting together more comprehensive documentation for a library of mine:

New documentation for `purescript-halogen-select v1.0`

Inspired by this conversation: I took some time to document Select now that it has a stable release. We already had an overview and module documentation, but I wanted to add some more tutorial-focused content as well as some explanation-focused content around some of the unfamiliar ideas in the library. The documentation site is here: https://citizennet.github.io/purescript-halogen-select/ A thorough, beginner-friendly tutorial on creating a dropdown is here: https://citizennet.github.io/…