injective-function

Non-Injective Closed Type Family

折月煮酒 提交于 2021-01-28 04:31:39
问题 I have this admittedly contrived chunk of code {-# LANGUAGE DataKinds, TypeFamilies #-} data Foo = Foo type family Id (n :: Foo) a where Id 'Foo a = a data Bar (n :: Foo) = Bar class Dispatch (n :: Foo) where consume :: Id n a -> Bar n -> a consume' :: Dispatch n => Id n [Bool] -> Bar n -> [Bool] consume' = consume consume'' :: Dispatch n => Id n [Bool] -> Bar n -> Bool consume'' g x = and (consume' g x) This compiles and works fine. However, if I replace the final consume'' definition with

How do we know all Coq constructors are injective and disjoint?

﹥>﹥吖頭↗ 提交于 2019-12-10 10:28:59
问题 According to this course, all constructors (for inductive types) are injective and disjoint: ...Similar principles apply to all inductively defined types: all constructors are injective, and the values built from distinct constructors are never equal. For lists, the cons constructor is injective and nil is different from every non-empty list. For booleans, true and false are unequal. (And the inversion tactic based on this assumption) I am just wondering how do we know this assumption holds?

How do we know all Coq constructors are injective and disjoint?

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-05 22:16:54
According to this course , all constructors (for inductive types) are injective and disjoint: ...Similar principles apply to all inductively defined types: all constructors are injective, and the values built from distinct constructors are never equal. For lists, the cons constructor is injective and nil is different from every non-empty list. For booleans, true and false are unequal. (And the inversion tactic based on this assumption) I am just wondering how do we know this assumption holds? How do we know that, e.g., we cannot define natural numbers based on 1) a Successor and maybe a

Why can't we define closed data families?

那年仲夏 提交于 2019-12-05 16:20:28
问题 All of the following work: {-# LANGUAGE TypeFamilies #-} type family TF a type instance TF Int = String type instance TF Bool = Char data family DF a data instance DF Int = DFInt String data instance DF Bool = DFBool Char type family CTF a where CTF Int = String CTF Bool = Char CTF a = Double -- Overlap OK! ...but this doesn't (as of GHC-8.2): data family CDF a where CDF Int = CDFInt String CDF Bool = CDFBool Char CDF a = CDFOther Double wtmpf-file24527.hs:16:19: error: parse error on input

Why can't we define closed data families?

99封情书 提交于 2019-12-04 01:17:46
All of the following work: {-# LANGUAGE TypeFamilies #-} type family TF a type instance TF Int = String type instance TF Bool = Char data family DF a data instance DF Int = DFInt String data instance DF Bool = DFBool Char type family CTF a where CTF Int = String CTF Bool = Char CTF a = Double -- Overlap OK! ...but this doesn't (as of GHC-8.2): data family CDF a where CDF Int = CDFInt String CDF Bool = CDFBool Char CDF a = CDFOther Double wtmpf-file24527.hs:16:19: error: parse error on input ‘where’ | 16 | data family CDF a where | ^^^^^ Is it just that nobody has bothered to implement this yet

Injective two-way mappings [duplicate]

早过忘川 提交于 2019-12-03 23:03:30
问题 This question already has answers here : Two way/reverse map (15 answers) Closed last year . I often deal with mappings which are injective. In programming terminology, this can be expressed as a dictionary where all values are unique as well as, of course, all keys. Is there a memory-efficient data structure for injective mappings with all the time-complexity properties you expect from dictionaries? For example: d = {1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'} d.get(2) = 'b' # this works with a

Injective two-way mappings [duplicate]

℡╲_俬逩灬. 提交于 2019-12-01 01:56:04
This question already has an answer here: Two way/reverse map 13 answers I often deal with mappings which are injective . In programming terminology, this can be expressed as a dictionary where all values are unique as well as, of course, all keys. Is there a memory-efficient data structure for injective mappings with all the time-complexity properties you expect from dictionaries? For example: d = {1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'} d.get(2) = 'b' # this works with a normal dictionary d.get('b', reverse=True) = 2 # but this is not possible All the solutions in Two way/reverse map seem to