Specifying invariants on value constructors

Question

Consider the following

data Predicate = Pred Name Arity Arguments

type Name      = String
type Arity     = Int
type Arguments = [Entity]
type Entity    = String

This would allow the creation of

Pred "divides" 2 ["1", "2"]
Pred "between" 3 ["2", "1", "3"]

but also the "illegal"

Pred "divides" 2 ["1"]
Pred "between" 3 ["2", "3"]

"Illegal" because the arity does not match the length of the argument list.

Short of using a function like this

makePred :: Name -> Arity -> Arguments -> Maybe Predicate
makePred n a args | a == length args = Just (Pred n a args)
                  | otherwise = Nothing

and only exporting makePred from the Predicate module, is there a way to enforce the correctness of the value constructor?

Not in the type system. You'd need one of the (even) fancier ones (dependent types? Just guessing here, I'm not really LtU top poster). — , Jan 26 '11 at 22:05
You can probably get something with a hack with "type level naturals", but that's not really a good solution. — Alp Mestanogullari, Jan 26 '11 at 22:39
If I'm not mistaken, Alp Mestanogullari is referring to http://www.haskell.org/haskellwiki/Type_arithmetic . — gspr, Jan 26 '11 at 22:43
"using a function like this" is exactly what most people do. It's called a "smart constructor": http://www.haskell.org/haskellwiki/Smart_constructors — porges, Jan 26 '11 at 23:46

score 6 · Accepted Answer · answered Jan 27 '11 at 08:21

Well, the easy answer is to drop the arity from the smart constructor.

makePred :: Name -> Arguments -> Predicate
makePred name args = Pred name (length args) args

Then if you don't expose the Pred constructor from your module and force your clients to go through makePred, you know that they will always match, and you don't need that unsightly Maybe.

There is no direct way to enforce that invariant. That is, you won't be able to get makePred 2 ["a","b"] to typecheck but makePred 2 ["a","b","c"] not to. You need real dependent types for that.

There are places in the middle to convince haskell to enforce your invariants using advanced features (GADTs + phantom types), but after writing out a whole solution I realized that I didn't really address your question, and that such techniques are not really applicable to this problem in particular. They're usually more trouble than they are worth in general, too. I'd stick with the smart constructor.

I've written an in-depth description of the smart constructor idea. It turns out to be a pretty pleasant middle ground between type verification and runtime verification.

score 0 · Answer 2 · answered Jan 26 '11 at 23:44

It seems to me that, if you want said restrictions to be enforceable, then you should make Predicate a class, and each kind of predicate its own data type that is an instance of Predicate.

This would give you the possibility of having arguments other than String types in your predicates.

Something like this (UNTESTED)

data Entity = Str String | Numeric Int

class Predicate a where
    name :: a -> String
    arity :: a -> Int
    args :: a -> [Entity]
    satisfied :: a -> Bool

data Divides = Divides Int Int
instance Predicate Divides where
    name p = "divides"
    arity p = 2
    args (Divides n x) = [(Numeric n), (Numeric x)]
    satisfied (Divides n x) = x `mod` n == 0

This may or may not solve your issue, but it is certainly a strong option to consider.

This is just coding in circles. The `Predicate` class can be isomorphically represented as a data type `data Predicate = Predicate String Int [Entity] Bool`, the same thing but with less boilerplate, which is basically what the OP already had. See http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ for details. — luqui, Jan 27 '11 at 08:23

Specifying invariants on value constructors

2 Answers2