Linear types: remove the change to ($)

[monoidal]

This removes one paragraph that has been obsoleted.

The linear types proposal stated that ($) should be made multiplicity polymorphic. When the proposal was being written, GHC had a special typing rule for ($) and this change had to happen on the compiler level. For all other functions, multiplicity polymorphism could be delegated to writers of a linear base library.

With Quick Look impredicativity, ($) no longer has a special typing rule, as described in the QL proposal and implemented in commit 97cff9190d34, GHC/Tc/Gen/Expr.hs.

There is no longer a reason to treat ($) differently. Implementation-wise, there is nothing to do - the deleted text has not been implemented.

[nomeata]

Sounds like a bugfix to me.

Or maybe even a don't fix? I don’t think proposals are meant to be maintained as if they were the documenation, and later changes to a feature are better just documented in the user’s guide, and the proposal stays a faithful record of what was decided/intended at the time of acceptance.

@goldfirere , as the original shepherd, what do you think?

[simonpj]

Or maybe even a don't fix? I don’t think proposals are meant to be maintained as if they were the documenation, and later changes to a feature are better just documented in the user’s guide, and the proposal stays a faithful record of what was decided/intended at the time of acceptance.

Proposals are often much better documentation than what follows, because they give context, motivation, and focus on changes.

So yes, please commit this. Not hard to do!

[nomeata]

Proposals are often much better documentation than what follows, because they give context, motivation, and focus on changes.

But is that a healthy pattern? The proposal is useful when deciding about a change (where things like alternatives are relevant, and motivation, etc). But a user trying to understand a feature should hopefully never have to go to the proposal, and find everything they need to know in the user’s guide. So if the proposal turns out to be better documentation than the documentation, then the documentation is lacking.

Ok, looking closer at this, no need to be pedantic about this change, will treat this as a “bug fix in the proposal”. But in general, let’s not require people (users, developers) who want to understand GHC to read decade old proposals, and instead strive to maintain good, up-to-date, comprehensive documentation in the user’s guide. Pointing to the proposal there is almost as bad as “for details see paper X”.

[goldfirere]

Two very separate points here:

1. Despite losing its custom typing rule, $ is still special as it's a quick look identifier. This means that $ can be used impredicatively regardless of the presence of -XImpredicativeTypes. If we have a multiplicity-polymorphic $ elsewhere, it won't get this special treatment.

2. I think that it's worthwhile updating "live" proposals, where a live proposal is one that is not fully implemented. Linear types #111 is one such proposal -- it's still not done yet, and so keeping the proposal up to date is worthwhile. A long-implemented proposal has less value in staying up to date. I don't think we need to track liveness with any real effort, but it's a good guideline for this sort of thing, I think.