Add RawSql tuple instances from 13 to 62

[mitchellvitez]

See #1086. This adds up to the max length of a tuple for query results, so people will hopefully never run into result length limits.

If this formatting isn't optimal I can change it up, although I doubt there's going to be any way to format this kind of thing really nicely.

It could also admittedly be much nicer to do this with e.g. Template Haskell and I'd be happy to see this cleaned up using something like that.

• Added @since declarations to the Haddock

After submitting your PR:

• Update the Changelog.md file with a link to your PR
• Bumped the version number if there isn't an (unreleased) on the Changelog
• Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

[mitchellvitez]

Here's the quick-and-dirty Python script I used to generate this, in case it's helpful

since = '-- | @since 2.11.0'
alphabet = list('abcdefghijklmnopqrstuvwxyz')

def cs(i):
    return (alphabet + [f'{c}2' for c in alphabet] + [f'{c}3' for c in alphabet])[:i]

def parens(s):
    return '(' + s + ')'

def raw_sql(i):
    return parens(', '.join([f'RawSql {c}' for c in cs(i)]))

def tuple(i):
    return parens(', '.join(cs(i)))

def compact_tuple(i):
    return parens(','.join(cs(i)))

def pairs(l):
    new = []
    for i in range(0, len(l)-1, 2):
        new.append(f'({l[i]},{l[i+1]})')
    if len(l) % 2:
        new.append(l[-1])
    return new

def paired_tuple(i):
    return parens(','.join(pairs(cs(i))))

for i in range(13, 63):
    print(f"""\
{since}
instance {raw_sql(i)}
      => RawSql {tuple(i)} where
    rawSqlCols e         = rawSqlCols e         . from{i}
    rawSqlColCountReason = rawSqlColCountReason . from{i}
    rawSqlProcessRow     = fmap to{i} . rawSqlProcessRow

{since}
from{i} :: {compact_tuple(i)} -> {paired_tuple(i)}
from{i} {compact_tuple(i)} = {paired_tuple(i)}

{since}
to{i} :: {paired_tuple(i)} -> {compact_tuple(i)}
to{i} {paired_tuple(i)} = {compact_tuple(i)}
""")

[MaxGabriel]

Nice, this looks good to me. I'll leave this up for a couple days to see if anyone has any comments, but I think it's good to merge otherwise

[parsonsmatt]

awesome, thanks so much!

[MaxGabriel]

Update on this is that base doesn't support equality on tuples above size 15, so the test is failing https://www.stackage.org/haddock/lts-15.14/ghc-prim-0.5.3/GHC-Tuple.html#t:-40--44--44--44--44--44--44--44--44--44--44--44--44--44--44--44--41-

We're going to talk to @chessai about seeing if base could support equality up to 62

[parsonsmatt]

we're tuple pioneers

[mitchellvitez]

I've changed the test here to only go up to 15-tuples. I'll try adding Eq/Ord instances to big tuples in base, then later can fix persistent to have up to 62

Not sure whether to leave the current 16-62 sized instances around in this PR. My instinct is it's still good to leave them in, because the type errors about lack of Eq are probably easier to understand than the ones about RawSql instances not existing

[chessai]

So, Eq/Ord instances for larger tuples in base i'm on board with, but it of course shouldn't block this PR at all. base updates happen once every 6 months. i would just remove the tests for larger tuples, or derive Eq instances using StandaloneDeriving. The usage of tuples here "scales", so if a 15-tuple is correct, i would expect a 16-tuple to work as well, and then a 17-tuple, and then an 18-tuple, etc. Though there could be # some persistent-related issue im unaware of.

[MaxGabriel]

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3369