Inconsistent usage of `==` and `=` equality in docs
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- haskell
- Ambito
- documentation
Direzione di ricerca
Inizia dalla documentazione di Data.Set per powerSet, quindi esamina gli esempi analoghi di cartesianProduct e disjointUnion e la documentazione dei moduli interessati IntSet e Map. Verifica la notazione di ogni equazione rispetto alla distinzione dell'issue tra uguaglianza strutturale e uguaglianza dei valori; il lavoro è completato quando gli esempi incoerenti nella documentazione sono corretti in modo coerente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
While reading the docs for Data.Set, I noticed that in some places == is used and in some = is used. For example, the docs for powerSet:
Calculate the power set of a set: the set of all its subsets.
t `member` powerSet s == t `isSubsetOf` sExample:
powerSet (fromList [1,2,3]) = fromList $ map fromList [[],[1],[1,2],[1,2,3],[1,3],[2],[2,3],[3]]
I guess that = should be used only if we can prove it from the definitions, and only if both sides are "internally" equal. For instance, we can disprove the above example easily:
Prelude Data.Set> putTree = putStrLn . showTree
Prelude Data.Set> putTree $ powerSet (fromList [1,2,3])
fromList [1,3]
+--fromList [1,2]
| +--fromList [1]
| | +--fromList []
| | +--|
| +--fromList [1,2,3]
+--fromList [2,3]
+--fromList [2]
+--fromList [3]
Prelude Data.Set> putTree $ fromList $ Prelude.map fromList [[],[1],[1,2],[1,2,3],[1,3],[2],[2,3],[3]]
fromList [1,2,3]
+--fromList [1]
| +--fromList []
| +--fromList [1,2]
+--fromList [2]
+--fromList [1,3]
+--fromList [2,3]
+--|
+--fromList [3]
The examples for cartesianProduct and disjointUnion can be disproved similarly. From looking around, other modules like IntSet and Map modules also have this issue.
I suppose every nontrivial example/law equation with containers on both sides should use == instead of =.
- Lingua principale
- Haskell
- Stelle
- 355
- Fork
- 194
- Merge medio
- 3g 4h
- PR unite (30g)
- 7
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di haskell/containers
-
unfoldTree is too lazyApertamajor-release strictness Tree
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
haskell/containers#1260 ·
I maintainer di solito rispondono entro 1 giorno
-
IntSet low-hanging-fruit performance
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
haskell/containers#1251 ·
I maintainer di solito rispondono entro 1 giorno
-
maintainability major-release
Difficoltà 3/5 1-2 giorni Idoneità per principianti 70/100
haskell/containers#1250 ·
I maintainer di solito rispondono entro 1 giorno
-
PostOrder: foldl and foldr'Apertaperformance Tree
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
haskell/containers#1247 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 50/100
haskell/containers#1242 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di haskell/containers
Issue simili
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
alunduil/network-arbitrary#180 ·
I maintainer di solito rispondono entro 1 giorno
-
infrastructure
Difficoltà 1/5 1-3 ore Idoneità per principianti 65/100
alunduil/siren-json.hs#232 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
jgm/asciidoc-hs#14 ·
-
brick-3.0Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
commercialhaskell/stackage#8129 · 2 commenti ·