haskell - Class restriction for type synonyms? -

haskell - Class restriction for type synonyms? -

i want like: (in pseudocode; not compile)

type num => vector2d = (a,a)

or possibly

type num => vector2d = (a,a)

but cannot this.

after reading have feeling accomplish need rankntypes extension or forall keyword, can't wrap mind around this...

can help?

edit: managed, rather "guessing around syntax": solution is, indeed rankntypes:

type vec = forall a. num => (a,a)

this works, rankntypes extension

type vec = num => (a,a)

works equally. what's difference, , how num => constraint, seems quite natural, relate rank n types?

so question still open, i'm looking explanation, rather solution.

type vec = forall a. num => (a, a)

is same thing as

type vec = num => (a, a).

the reason every type variable without corresponding forall implicitly introduced ghc @ topmost type variable scope, example:

const :: -> b -> const :: forall b. -> b -> -- same thing

for part type synonyms syntactic convenience, whenever see vec in type signature, can set parentheses around definition , substitute:

vec -> vec -> integer -- equals: (forall a. num => (a, a)) -> (forall a. num => (a, a)) -> integer

there 1 weird exception, can't blindly substitute in types. if have type synonym this:

type vec = num => (a, a)

then num constraint floats out outermost scope after substitution:

vec = (100, 100) :: vec integer -- vec has type "(integer, integer)"

and multiple constraints on same type variable merge:

addvec :: vec -> vec -> vec addvec (a, b) (c, d) = (a + c, b + d) -- addvec has type "num => (a, a) -> (a, a) -> (a, a)

in above cases class constraint didn't introduce higher-rankedness, because constraints bound variables in outer scope. however, when utilize synonym within info constructors, constraint turns implicit (existential) dictionary:

type foo = num => info bar = bar (foo a) -- equals "data bar = bar (num => a)" -- requires existentialquantifiaction or gadts compile -- , of course, info constructor blocks outwards floating of constraint: type baz = -> (foo a, ()) -- requires impredicativetypes.

so, summarize, behaviour of these kinds of constraints in type synonyms rather wobbly. need rankntypes or rank2types write them out, seems more of implementation artifact else. argue syntax can used introduce quantifiers types, , sort of justifies rankntype requirement, as it's reasonable compiler should observe whether there fresh quantifiers or not, , proceed accordingly (like it's beingness done introduced existentials...).

haskell