Opened 3 years ago

Closed 2 years ago

## #13652 closed feature request (fixed)

# Add integer division to GHC.TypeLits

Reported by: | vagarenko | Owned by: | |
---|---|---|---|

Priority: | normal | Milestone: | |

Component: | Core Libraries | Version: | 8.0.1 |

Keywords: | Cc: | ||

Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |

Type of failure: | None/Unknown | Test Case: | |

Blocked By: | Blocking: | ||

Related Tickets: | Differential Rev(s): | Phab:D4002 | |

Wiki Page: |

### Description

GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral`

class at type level:

quot rem div mod quotRem divMod

?

### Change History (7)

### comment:1 Changed 3 years ago by

Component: | Compiler → Core Libraries |
---|

### comment:2 follow-up: 3 Changed 2 years ago by

Commit fa8035e3ee83aff5a20fc5e7e2697bac1686d6a6 added type-level versions of `Div`

and `Mod`

to `GHC.TypeNats`

.

The only remaining question—which I will ask to vagarenko—is it important to you to have a `DivMod`

type family in `base`

that uses the value-level `divMod`

under the hood? I ask since one *could* define `DivMod`

in terms of `Div`

and `Mod`

, but perhaps you're wanting something more performant than that.

### comment:3 follow-up: 5 Changed 2 years ago by

Replying to RyanGlScott:

one could define DivMod in terms of Div and Mod

like this:

type DivMod a b = (Div a b, Mod a b)

?

Why would it be less performant than baked in `DivMod`

? Because `a`

and `b`

would be reduced twice?

### comment:4 Changed 2 years ago by

Differential Rev(s): | → D4002 |
---|

### comment:5 Changed 2 years ago by

Differential Rev(s): | D4002 → Phab:D4002 |
---|

Replying to vagarenko:

like this:

type DivMod a b = (Div a b, Mod a b)?

Yes.

Why would it be less performant than baked in

`DivMod`

? Because`a`

and`b`

would be reduced twice?

Indeed. Internally, `div`

and `mod`

(on which the type-level `Div`

and `Mod`

are based) are defined in terms of `divMod`

, so this definition of `DivMod`

would likely compute `divMod`

twice. I can't give you an accurate estimate of how many CPU cycles that would waste, but there is certainly some inefficiency there.

But then again, this is your feature request, so I'll leave the final call up to you. Is the status quo (having just `Div`

and `Mod`

) acceptable for you? Or do you want to see `base`

have the full trifecta of `Div`

, `Mod`

, and `DivMod`

, each of which are based on their respective machine arithmetic operations?

### comment:6 Changed 2 years ago by

Okay, since we don't have `Fst`

and `Snd`

families in `base`

anyway let's skip `DivMod`

.

Thanks for implementing this!

### comment:7 Changed 2 years ago by

Resolution: | → fixed |
---|---|

Status: | new → closed |

**Note:**See TracTickets for help on using tickets.

Libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2017-June/028057.html