Add exact print proposal

[jappeace]

No description provided.

[ulysses4ever]

@jappeace could you explain what's the relation to the earlier HF proposal?

[Mikolaj]

@jappeace could you explain what's the relation to the earlier HF proposal?

The start of the document says "Note that this is a copy of the TWG proposal: haskellfoundation/tech-proposals#6", but indeed I'm curious how literally this is a copy, in particular, if the experience gained when implementing and discussing lead to some modifications or maybe if this is the baseline over which the modifications are expected to be made.

[ulysses4ever]

There's probably no harm in copying old stuff, but I personally hoped that we can make some profit out of our process and discuss some details that poped up during the past couple months in a new document. If creating a whole new document sounds like too much, a new section in the copy would be fine as well...

[jappeace]

I put the somewhat relevant parts of TWG proposal into the relevant sections of the cabal proposal template.
and filled out some other headings, especially open questions is a fair bit different now.

unlike the original proposal says, the common stanzas have been investigated here:
haskell/cabal#11277

and unlike the original proposal says, comment parsing is now pretty solid with this PR:
haskell/cabal#11252
(my zurich hack prototype did only one or two locations, leana made it work for basically any valid position).

I think these are the only two major implementation issues left from the original TWG proposal:

+ Add support for comma printing.
+ add support for conditional branches.
  See the technical content section for more details on this.

Both of these are investigated by a prototype focussing on "trivia", because FieldGrammar handles both conditionals as well as the comma's.
haskell/cabal#11227 (comment)

[ffaf1]

Hello, we discussed this proposal tonight ad the cabal dev-meeting.

We are generally happy with it, but there are things we would like to get a better idea of.

1. Interested parties. There are a lot of projects using Cabal (the library). It is nice to see “beneficiaries” listed, but the ideal situation would be to investigate who are the major users of Cabal, check who could be affected, collect their feedback before this proposal is accepted. Such thorough changes are bound to cause code breakage! Which leads to

2. Backwards Compatibility / Migration. The section is quite light on details, we need to know more, especially whether there is a simple path to upgrade and whether there are things which could require a more expensive workaround.

3. Impact on maintainers. We are here for the long run, so a sober assessment of how much more work to — e.g. — add to the spec, etc. would be interesting to know.

Thanks for having written this document!

[geekosaur]

I'd like to note that the current POC is a step in the direction of answering some of these questions (I did mention this in the meeting), in particular testing it against clc-stackage should give an idea of both who it affects and what kinds of mitigations and migration strategies will be required.

[Mikolaj]

Right, the POC is a great contribution. Maybe it could serve to update the proposal a bit, especially the parts the maintainers are keen about, as listed by Francesco? This proposal, as opposed to the TWG one, has the benefit of being submitted after some considerable prototyping and some feedback, so it can stand on much less hypothetical foundations than the TWG one. It should now be easier to involve many cabal "stakeholders" in the discussion, soliciting feedback about, e.g., backward compatibility and potential migration policy.

In any case, thank you very much for all this recent work, we are thrilled to see such a professional approach and we hope this can be brought to fruition with minimal friction.

[jappeace]

@ffaf1 Please help me understand what defines a major user, Cabal has around 250 direct depenencies on hackage.
I presume we're not intending to elicit feedback from all of these?

The other points I should be able to address with current information.

[ffaf1]

@jappeace Apologies for the late reply, I am not ignoring you, I am just trying to check which project using Cabal actually e.g. goes through GPD datatype instead of “just” using functions which are opaque with regard to GPD.

It would of course be silly and wrong to ask you to collect feedback from each Cabal dependency.

I recall in the last cabal-dev meet @geekosaur had an example of such a “probably impacted” dependency, but I forgot which one it was.

[geekosaur]

I think I mentioned the custom Setup of gtk2hs and gi-gtk as things which I recall poking at GPD internals. I'm also pretty sure I've seen others, all involving custom Setup.