Adding constraints to deriving declarations

Question

I have this datatype

newtype Dimension a b = MkDimension b

Whenever it is properly formatted (e.g. satisfies the format constraint), I want to derive a set of classes. I do not want a Dimension which does not satisfy the format constraint to be created.

This also means that if I do this:

newtype Dimension a b = MkDimension b 
    deriving newtype Num

fromIntegral is still capable of producing dimensions which are improperly formatted. What should I do? I want to also derive applicative, monoid, and others which would all give the opportunity to create invalid dimension values.

Details: To ensure that ordering doesn't matter when adding dimensions, I attempted to ensure that a Dimension would never have anything to the 0, and would be fully sorted (e.g. (MkDimension 2 :: Dimension '[ '("Meter",0)] Int) + (MkDimension 4 :: Dimension '[] Int)) would be bad, as they are the same dimension, but we would get a type-error. More realistically, the types could be in the wrong order, also causing an error. (MkDimension 2 :: Dimension '[ '("Meter",1),'("Foot",1)] Int) + (MkDimension 4 :: Dimension '[ '("Foot",1),'("Meter",1)] Int). To stop both of those, I want to make it so that fromIntegral is only allowed on properly formatted dimensions.

type family Has0 a where 
    Has0 '[] = 'False
    Has0 '(_,0) ': _ = 'True
    Has0 _ ': b = Has0 b

type Format a = (a ~ Sort a, Has0 a ~ 'False)

The definition of sort is too long to fit in here.

Say a bit more about what Dimension represents. It's hard to answer right now. Generally, I would recommend to avoid the temptation to derive All tEh kLaSseS for your custom data types, and in particular not Num. People do that all to often, and it subverts the whole point of having a strong type system that makes it easy to get just the right results, instead of weird unexpected behaviour. — leftaroundabout
– leftaroundabout, Commented Sep 8 at 19:21
You haven't told us anything about what "the format constraint" means. But in general I doubt that deriving is going to be sufficient for you; you will almost certainly have to do those derivations manually. — Louis Wasserman
– Louis Wasserman, Commented Sep 8 at 19:42
I added the definition of format and explained what I wanted it to do. — Ashok Kimmel
– Ashok Kimmel, Commented Sep 8 at 19:50
Ok, so this type should definitely not have Num instance - it would be completely the wrong interface. Instead, you should implement VectorSpace plus a custom multiplication, that takes care so e.g. the product of two lengths is an area (different type). — leftaroundabout
– leftaroundabout, Commented Sep 8 at 20:31

Daniel Wagner · Accepted Answer · 2025-09-08 21:20:33Z

2

The answer to the question as asked is to use standalone deriving.

{-# Language StandaloneDeriving #-}
deriving instance Format a => Num (Dimension a b)

However, I agree with the comments that this probably isn't wise; especially the type of (*) is probably not sensible in that instance.

answered Sep 8 at 21:20

Daniel Wagner

156k10 gold badges231 silver badges393 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Ashok Kimmel Sep 9 at 0:52

What should I use then? Num is a mess, but I want addition and subtraction using the common operators without needing special prelude imports.

leftaroundabout Sep 9 at 9:46

As I commented earlier, VectorSpace is the appropriate abstraction for this kind of thing. It's a lightweight dependency, no reason not to use it. If you find the a ^+^ b syntax ugly, you can always import Prelude hiding ((+), (-)) and locally define infixl 6 +; (+)=(^+^).

Ashok Kimmel Sep 9 at 12:39

Are there any common type family-based multiplication functions in use?

Collectives™ on Stack Overflow

Adding constraints to deriving declarations

1 Answer 1

3 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Your Answer

Sign up or log in

Post as a guest

Related