Proposal: Export Data.Word.Word from Prelude

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Export Data.Word.Word from Prelude

Herbert Valerio Riedel
Hello *,

Proposal
--------

I hereby propose to export Haskell2010's Data.Word.Word type from the Prelude


Motivation
----------

Starting with Haskell2010, "Data.Word" exporting the type 'Word', "an
unsigned integral type, with the same size as 'Int'" became part of the
Haskell Report.

'Word' is usually a better choice than 'Int' when non-negative
quantities (such as list lengths, bit or vector indices, or number of
items in a container) need to be represented. Currently however, 'Word'
is at a disadvantage (with respect to 'Int') in terms of public exposure
by being accessible only after an "import Data.Word".

Moreover, since 'Word' is now part of the Haskell Report, libraries
should attempt to avoid name-clashing with 'Word' (and if they do, it
ought to be a conscious decision, which ought to be declared by a
requiring a "import Prelude hiding (Word)"). While one might think
'Word' would be a popular type-name to use in Haskell code, the current
level of name collision is still rather low (as is shown in the next
section), so the cost would still be bearable at this point in my
opinion.


Due diligence (w.r.t. code breakage impact)
-------------------------------------------

Packages depending on `haskell2010` or `haskell98` are not affected, and
neither would be those depending on `base` with a PVP-suggested upper
bound.

However, to get a rough idea how widespread the use of 'Word' as a type
on Hackage currently is, here's a simple check for current uses of
'Word' as a type-name performed with the simple heuristic search

  find  -name '*.*hs*' -exec grep \
     '\(data\|newtype\|type\)[[:space:]]\+Word[ =]' {} +

over the unpacked source trees of the latest versions of the current
6766 packages on Hackage resulted in the following 43 packages being
possibly affected (see specific source-code matches at end of email[1]):

 1   adict-0.4.1
 2   boxes-0.1.3
 3   cjk-0.1.0.1
 4   clash-prelude-0.5.1
 5   combinat-0.2.5.0
 6   concraft-pl-0.7.1
 7   Craft3e-0.1.0.10
 8   crf-chain1-0.2.2
 9   crf-chain1-constrained-0.3.0
 10  crf-chain2-generic-0.3.0
 11  crf-chain2-tiers-0.2.1
 12  delta-h-0.0.3
 13  eros-0.6.0.0
 14  estimators-0.1.4
 15  estreps-0.3.1
 16  FermatsLastMargin-0.1
 17  fsmActions-0.4.4
 18  gf-3.6
 19  happraise-0.1
 20  HAppS-Data-0.9.3
 21  happstack-contrib-0.2.1
 22  hist-pl-fusion-0.5.3
 23  Holumbus-Searchengine-1.2.3
 24  integer-pure-1.0
 25  ixset-typed-0.3
 26  language-bash-0.6.0
 27  language-sh-0.0.3.1
 28  lhc-0.10
 29  MemoTrie-0.6.2
 30  mpppc-0.1.3
 31  nerf-0.5.2
 32  regex-deriv-0.0.4
 33  regex-pderiv-0.1.3
 34  regexpr-symbolic-0.5
 35  remote-0.1.1
 36  soyuz-0.0.0
 37  text-icu-0.6.3.7
 38  text-register-machine-0.4.0
 39  utf8-light-0.4.2
 40  WordNet-1.1.0
 41  WordNet-ghc74-0.1.3
 42  xhaskell-library-0.0.6
 43  york-lava-0.2


Discussion period
-----------------

2 weeks


Footnotes
---------

 [1] More specifically, here's the output of the above mentioned `grep` command:

--8<---------------cut here---------------start------------->8---
adict-0.4.1/src/NLP/Adict/Core.hs:type Word a = V.Vector a
boxes-0.1.3/Text/PrettyPrint/Boxes.hs:data Word = Word { wLen :: Int, getWord  :: String }
cjk-0.1.0.1/CJK/Data/CEDICT.hs:data Word = Word {
clash-prelude-0.5.1/src/CLaSH/Tutorial.hs:type Word = Signed 4
combinat-0.2.5.0/Math/Combinat/FreeGroups.hs:type Word a = [Generator a]
concraft-pl-0.7.1/src/NLP/Concraft/Polish/Morphosyntax.hs:data Word = Word
Craft3e-0.1.0.10/Chapter7.hs:type Word = String
Craft3e-0.1.0.10/Index.hs:type Word = String
crf-chain1-0.2.2/Data/CRF/Chain1/Dataset/External.hs:type Word a = S.Set a
crf-chain1-constrained-0.3.0/src/Data/CRF/Chain1/Constrained/Dataset/External.hs:data Word a b = Word
crf-chain2-generic-0.3.0/Data/CRF/Chain2/Generic/External.hs:data Word a b = Word {
crf-chain2-tiers-0.2.1/src/Data/CRF/Chain2/Tiers/Dataset/External.hs:data Word a b = Word {
delta-h-0.0.3/src/EvalSem.hs:type Word = String
eros-0.6.0.0/src/Text/Eros/Message.hs:type Word         = L.Text
estimators-0.1.4/NLP/Probability/Example/Trigram.hs:newtype Word = Word T.Text
estreps-0.3.1/src/Repeats.lhs:-- type Word = Int
FermatsLastMargin-0.1/FLM/WikiPages.hs:       newtype Word     = Word String
fsmActions-0.4.4/Data/FsmActions.hs:newtype Word sy = Word [sy]
gf-3.6/lib/src/finnish/wordnet/FreqFin.hs:type Word = String
gf-3.6/treebanks/susanne/SusanneFormat.hs:type Word  = String
gf-3.6/treebanks/talbanken/Format.hs:data Word     = W  {id :: Id, word :: String, pos :: Tag}
happraise-0.1/Main.hs:type Word = String
HAppS-Data-0.9.3/src/HAppS/Data/Atom.hs:    newtype Word = Word String
happstack-contrib-0.2.1/src/Happstack/Contrib/Atom.hs:    newtype Word = Word String
hist-pl-fusion-0.5.3/src/NLP/HistPL/Fusion.hs:type Word = T.Text
Holumbus-Searchengine-1.2.3/src/Holumbus/Index/Common/BasicTypes.hs:type Word                       = String
integer-pure-1.0/Data/Integer.hs:type Word    = Int    -- We fake the Word type, to avoid nasty conversions.
ixset-typed-0.3/src/Data/IxSet/Typed.hs:    > newtype Word = Word String
language-bash-0.6.0/src/Language/Bash/Word.hs:type Word = [Span]
language-sh-0.0.3.1/Language/Sh/Syntax.hs:type Word = [Lexeme]
lhc-0.10/lib/base/src/Data/Word.hs:type Word = Word32
lhc-0.10/lib/base/src/GHC/Word.hs:data Word = W# Word# deriving (Eq, Ord)
MemoTrie-0.6.2/src/Data/MemoTrie.hs:--     newtype Word :->: a = WordTrie ([Bool] :->: a)
mpppc-0.1.3/src/Text/PrettyPrint/MPPPC/TwoDim/Combinators/Flow.hs:data Word s t = Printable s t =>
nerf-0.5.2/src/NLP/Nerf/Types.hs:type Word = T.Text
regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/BitCode.hs:type Word = S.ByteString
regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/Posix.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRightD.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/String/LeftToRightD.lhs:> type Word = String
regexpr-symbolic-0.5/RegExpr/RegExprOperations.lhs:> type Word a = [a]
remote-0.1.1/examples/tests/Test-MapReduce.hs:type Word = String
remote-0.1.1/examples/kmeans/KMeans3.hs:type Word = String
soyuz-0.0.0/DCPU16/Instructions.hs:data Word
text-icu-0.6.3.7/Data/Text/ICU/Break.hsc:data Word = Uncategorized       -- ^ A \"word\" that does not fit into another
text-register-machine-0.4.0/Language/TRM/Base.hs:newtype Word = W [Letter] deriving (Eq, Monoid)
utf8-light-0.4.2/src/Codec/Binary/UTF8/Light.hs:data Word = W# Word#
WordNet-1.1.0/NLP/WordNet/Types.hs:type Word = String
WordNet-ghc74-0.1.3/NLP/WordNet/Types.hs:type Word = String
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
york-lava-0.2/modules/Lava/Prelude.hs:type Word n = Vec n Bit
--8<---------------cut here---------------end--------------->8---
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Carter Schonwald
strong +1 from me!


On Sat, Aug 9, 2014 at 7:38 AM, Herbert Valerio Riedel <[hidden email]> wrote:
Hello *,

Proposal
--------

I hereby propose to export Haskell2010's Data.Word.Word type from the Prelude


Motivation
----------

Starting with Haskell2010, "Data.Word" exporting the type 'Word', "an
unsigned integral type, with the same size as 'Int'" became part of the
Haskell Report.

'Word' is usually a better choice than 'Int' when non-negative
quantities (such as list lengths, bit or vector indices, or number of
items in a container) need to be represented. Currently however, 'Word'
is at a disadvantage (with respect to 'Int') in terms of public exposure
by being accessible only after an "import Data.Word".

Moreover, since 'Word' is now part of the Haskell Report, libraries
should attempt to avoid name-clashing with 'Word' (and if they do, it
ought to be a conscious decision, which ought to be declared by a
requiring a "import Prelude hiding (Word)"). While one might think
'Word' would be a popular type-name to use in Haskell code, the current
level of name collision is still rather low (as is shown in the next
section), so the cost would still be bearable at this point in my
opinion.


Due diligence (w.r.t. code breakage impact)
-------------------------------------------

Packages depending on `haskell2010` or `haskell98` are not affected, and
neither would be those depending on `base` with a PVP-suggested upper
bound.

However, to get a rough idea how widespread the use of 'Word' as a type
on Hackage currently is, here's a simple check for current uses of
'Word' as a type-name performed with the simple heuristic search

  find  -name '*.*hs*' -exec grep \
     '\(data\|newtype\|type\)[[:space:]]\+Word[ =]' {} +

over the unpacked source trees of the latest versions of the current
6766 packages on Hackage resulted in the following 43 packages being
possibly affected (see specific source-code matches at end of email[1]):

 1   adict-0.4.1
 2   boxes-0.1.3
 3   cjk-0.1.0.1
 4   clash-prelude-0.5.1
 5   combinat-0.2.5.0
 6   concraft-pl-0.7.1
 7   Craft3e-0.1.0.10
 8   crf-chain1-0.2.2
 9   crf-chain1-constrained-0.3.0
 10  crf-chain2-generic-0.3.0
 11  crf-chain2-tiers-0.2.1
 12  delta-h-0.0.3
 13  eros-0.6.0.0
 14  estimators-0.1.4
 15  estreps-0.3.1
 16  FermatsLastMargin-0.1
 17  fsmActions-0.4.4
 18  gf-3.6
 19  happraise-0.1
 20  HAppS-Data-0.9.3
 21  happstack-contrib-0.2.1
 22  hist-pl-fusion-0.5.3
 23  Holumbus-Searchengine-1.2.3
 24  integer-pure-1.0
 25  ixset-typed-0.3
 26  language-bash-0.6.0
 27  language-sh-0.0.3.1
 28  lhc-0.10
 29  MemoTrie-0.6.2
 30  mpppc-0.1.3
 31  nerf-0.5.2
 32  regex-deriv-0.0.4
 33  regex-pderiv-0.1.3
 34  regexpr-symbolic-0.5
 35  remote-0.1.1
 36  soyuz-0.0.0
 37  text-icu-0.6.3.7
 38  text-register-machine-0.4.0
 39  utf8-light-0.4.2
 40  WordNet-1.1.0
 41  WordNet-ghc74-0.1.3
 42  xhaskell-library-0.0.6
 43  york-lava-0.2


Discussion period
-----------------

2 weeks


Footnotes
---------

 [1] More specifically, here's the output of the above mentioned `grep` command:

--8<---------------cut here---------------start------------->8---
adict-0.4.1/src/NLP/Adict/Core.hs:type Word a = V.Vector a
boxes-0.1.3/Text/PrettyPrint/Boxes.hs:data Word = Word { wLen :: Int, getWord  :: String }
cjk-0.1.0.1/CJK/Data/CEDICT.hs:data Word = Word {
clash-prelude-0.5.1/src/CLaSH/Tutorial.hs:type Word = Signed 4
combinat-0.2.5.0/Math/Combinat/FreeGroups.hs:type Word a = [Generator a]
concraft-pl-0.7.1/src/NLP/Concraft/Polish/Morphosyntax.hs:data Word = Word
Craft3e-0.1.0.10/Chapter7.hs:type Word = String
Craft3e-0.1.0.10/Index.hs:type Word = String
crf-chain1-0.2.2/Data/CRF/Chain1/Dataset/External.hs:type Word a = S.Set a
crf-chain1-constrained-0.3.0/src/Data/CRF/Chain1/Constrained/Dataset/External.hs:data Word a b = Word
crf-chain2-generic-0.3.0/Data/CRF/Chain2/Generic/External.hs:data Word a b = Word {
crf-chain2-tiers-0.2.1/src/Data/CRF/Chain2/Tiers/Dataset/External.hs:data Word a b = Word {
delta-h-0.0.3/src/EvalSem.hs:type Word = String
eros-0.6.0.0/src/Text/Eros/Message.hs:type Word         = L.Text
estimators-0.1.4/NLP/Probability/Example/Trigram.hs:newtype Word = Word T.Text
estreps-0.3.1/src/Repeats.lhs:-- type Word = Int
FermatsLastMargin-0.1/FLM/WikiPages.hs:       newtype Word     = Word String
fsmActions-0.4.4/Data/FsmActions.hs:newtype Word sy = Word [sy]
gf-3.6/lib/src/finnish/wordnet/FreqFin.hs:type Word = String
gf-3.6/treebanks/susanne/SusanneFormat.hs:type Word  = String
gf-3.6/treebanks/talbanken/Format.hs:data Word     = W  {id :: Id, word :: String, pos :: Tag}
happraise-0.1/Main.hs:type Word = String
HAppS-Data-0.9.3/src/HAppS/Data/Atom.hs:    newtype Word = Word String
happstack-contrib-0.2.1/src/Happstack/Contrib/Atom.hs:    newtype Word = Word String
hist-pl-fusion-0.5.3/src/NLP/HistPL/Fusion.hs:type Word = T.Text
Holumbus-Searchengine-1.2.3/src/Holumbus/Index/Common/BasicTypes.hs:type Word                       = String
integer-pure-1.0/Data/Integer.hs:type Word    = Int    -- We fake the Word type, to avoid nasty conversions.
ixset-typed-0.3/src/Data/IxSet/Typed.hs:    > newtype Word = Word String
language-bash-0.6.0/src/Language/Bash/Word.hs:type Word = [Span]
language-sh-0.0.3.1/Language/Sh/Syntax.hs:type Word = [Lexeme]
lhc-0.10/lib/base/src/Data/Word.hs:type Word = Word32
lhc-0.10/lib/base/src/GHC/Word.hs:data Word = W# Word# deriving (Eq, Ord)
MemoTrie-0.6.2/src/Data/MemoTrie.hs:--     newtype Word :->: a = WordTrie ([Bool] :->: a)
mpppc-0.1.3/src/Text/PrettyPrint/MPPPC/TwoDim/Combinators/Flow.hs:data Word s t = Printable s t =>
nerf-0.5.2/src/NLP/Nerf/Types.hs:type Word = T.Text
regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/BitCode.hs:type Word = S.ByteString
regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/Posix.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRightD.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/String/LeftToRightD.lhs:> type Word = String
regexpr-symbolic-0.5/RegExpr/RegExprOperations.lhs:> type Word a = [a]
remote-0.1.1/examples/tests/Test-MapReduce.hs:type Word = String
remote-0.1.1/examples/kmeans/KMeans3.hs:type Word = String
soyuz-0.0.0/DCPU16/Instructions.hs:data Word
text-icu-0.6.3.7/Data/Text/ICU/Break.hsc:data Word = Uncategorized       -- ^ A \"word\" that does not fit into another
text-register-machine-0.4.0/Language/TRM/Base.hs:newtype Word = W [Letter] deriving (Eq, Monoid)
utf8-light-0.4.2/src/Codec/Binary/UTF8/Light.hs:data Word = W# Word#
WordNet-1.1.0/NLP/WordNet/Types.hs:type Word = String
WordNet-ghc74-0.1.3/NLP/WordNet/Types.hs:type Word = String
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
york-lava-0.2/modules/Lava/Prelude.hs:type Word n = Vec n Bit
--8<---------------cut here---------------end--------------->8---
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Johan Tibell-2
+1


On Sat, Aug 9, 2014 at 8:27 PM, Carter Schonwald <[hidden email]> wrote:
strong +1 from me!


On Sat, Aug 9, 2014 at 7:38 AM, Herbert Valerio Riedel <[hidden email]> wrote:
Hello *,

Proposal
--------

I hereby propose to export Haskell2010's Data.Word.Word type from the Prelude


Motivation
----------

Starting with Haskell2010, "Data.Word" exporting the type 'Word', "an
unsigned integral type, with the same size as 'Int'" became part of the
Haskell Report.

'Word' is usually a better choice than 'Int' when non-negative
quantities (such as list lengths, bit or vector indices, or number of
items in a container) need to be represented. Currently however, 'Word'
is at a disadvantage (with respect to 'Int') in terms of public exposure
by being accessible only after an "import Data.Word".

Moreover, since 'Word' is now part of the Haskell Report, libraries
should attempt to avoid name-clashing with 'Word' (and if they do, it
ought to be a conscious decision, which ought to be declared by a
requiring a "import Prelude hiding (Word)"). While one might think
'Word' would be a popular type-name to use in Haskell code, the current
level of name collision is still rather low (as is shown in the next
section), so the cost would still be bearable at this point in my
opinion.


Due diligence (w.r.t. code breakage impact)
-------------------------------------------

Packages depending on `haskell2010` or `haskell98` are not affected, and
neither would be those depending on `base` with a PVP-suggested upper
bound.

However, to get a rough idea how widespread the use of 'Word' as a type
on Hackage currently is, here's a simple check for current uses of
'Word' as a type-name performed with the simple heuristic search

  find  -name '*.*hs*' -exec grep \
     '\(data\|newtype\|type\)[[:space:]]\+Word[ =]' {} +

over the unpacked source trees of the latest versions of the current
6766 packages on Hackage resulted in the following 43 packages being
possibly affected (see specific source-code matches at end of email[1]):

 1   adict-0.4.1
 2   boxes-0.1.3
 3   cjk-0.1.0.1
 4   clash-prelude-0.5.1
 5   combinat-0.2.5.0
 6   concraft-pl-0.7.1
 7   Craft3e-0.1.0.10
 8   crf-chain1-0.2.2
 9   crf-chain1-constrained-0.3.0
 10  crf-chain2-generic-0.3.0
 11  crf-chain2-tiers-0.2.1
 12  delta-h-0.0.3
 13  eros-0.6.0.0
 14  estimators-0.1.4
 15  estreps-0.3.1
 16  FermatsLastMargin-0.1
 17  fsmActions-0.4.4
 18  gf-3.6
 19  happraise-0.1
 20  HAppS-Data-0.9.3
 21  happstack-contrib-0.2.1
 22  hist-pl-fusion-0.5.3
 23  Holumbus-Searchengine-1.2.3
 24  integer-pure-1.0
 25  ixset-typed-0.3
 26  language-bash-0.6.0
 27  language-sh-0.0.3.1
 28  lhc-0.10
 29  MemoTrie-0.6.2
 30  mpppc-0.1.3
 31  nerf-0.5.2
 32  regex-deriv-0.0.4
 33  regex-pderiv-0.1.3
 34  regexpr-symbolic-0.5
 35  remote-0.1.1
 36  soyuz-0.0.0
 37  text-icu-0.6.3.7
 38  text-register-machine-0.4.0
 39  utf8-light-0.4.2
 40  WordNet-1.1.0
 41  WordNet-ghc74-0.1.3
 42  xhaskell-library-0.0.6
 43  york-lava-0.2


Discussion period
-----------------

2 weeks


Footnotes
---------

 [1] More specifically, here's the output of the above mentioned `grep` command:

--8<---------------cut here---------------start------------->8---
adict-0.4.1/src/NLP/Adict/Core.hs:type Word a = V.Vector a
boxes-0.1.3/Text/PrettyPrint/Boxes.hs:data Word = Word { wLen :: Int, getWord  :: String }
cjk-0.1.0.1/CJK/Data/CEDICT.hs:data Word = Word {
clash-prelude-0.5.1/src/CLaSH/Tutorial.hs:type Word = Signed 4
combinat-0.2.5.0/Math/Combinat/FreeGroups.hs:type Word a = [Generator a]
concraft-pl-0.7.1/src/NLP/Concraft/Polish/Morphosyntax.hs:data Word = Word
Craft3e-0.1.0.10/Chapter7.hs:type Word = String
Craft3e-0.1.0.10/Index.hs:type Word = String
crf-chain1-0.2.2/Data/CRF/Chain1/Dataset/External.hs:type Word a = S.Set a
crf-chain1-constrained-0.3.0/src/Data/CRF/Chain1/Constrained/Dataset/External.hs:data Word a b = Word
crf-chain2-generic-0.3.0/Data/CRF/Chain2/Generic/External.hs:data Word a b = Word {
crf-chain2-tiers-0.2.1/src/Data/CRF/Chain2/Tiers/Dataset/External.hs:data Word a b = Word {
delta-h-0.0.3/src/EvalSem.hs:type Word = String
eros-0.6.0.0/src/Text/Eros/Message.hs:type Word         = L.Text
estimators-0.1.4/NLP/Probability/Example/Trigram.hs:newtype Word = Word T.Text
estreps-0.3.1/src/Repeats.lhs:-- type Word = Int
FermatsLastMargin-0.1/FLM/WikiPages.hs:       newtype Word     = Word String
fsmActions-0.4.4/Data/FsmActions.hs:newtype Word sy = Word [sy]
gf-3.6/lib/src/finnish/wordnet/FreqFin.hs:type Word = String
gf-3.6/treebanks/susanne/SusanneFormat.hs:type Word  = String
gf-3.6/treebanks/talbanken/Format.hs:data Word     = W  {id :: Id, word :: String, pos :: Tag}
happraise-0.1/Main.hs:type Word = String
HAppS-Data-0.9.3/src/HAppS/Data/Atom.hs:    newtype Word = Word String
happstack-contrib-0.2.1/src/Happstack/Contrib/Atom.hs:    newtype Word = Word String
hist-pl-fusion-0.5.3/src/NLP/HistPL/Fusion.hs:type Word = T.Text
Holumbus-Searchengine-1.2.3/src/Holumbus/Index/Common/BasicTypes.hs:type Word                       = String
integer-pure-1.0/Data/Integer.hs:type Word    = Int    -- We fake the Word type, to avoid nasty conversions.
ixset-typed-0.3/src/Data/IxSet/Typed.hs:    > newtype Word = Word String
language-bash-0.6.0/src/Language/Bash/Word.hs:type Word = [Span]
language-sh-0.0.3.1/Language/Sh/Syntax.hs:type Word = [Lexeme]
lhc-0.10/lib/base/src/Data/Word.hs:type Word = Word32
lhc-0.10/lib/base/src/GHC/Word.hs:data Word = W# Word# deriving (Eq, Ord)
MemoTrie-0.6.2/src/Data/MemoTrie.hs:--     newtype Word :->: a = WordTrie ([Bool] :->: a)
mpppc-0.1.3/src/Text/PrettyPrint/MPPPC/TwoDim/Combinators/Flow.hs:data Word s t = Printable s t =>
nerf-0.5.2/src/NLP/Nerf/Types.hs:type Word = T.Text
regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/BitCode.hs:type Word = S.ByteString
regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/Posix.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRightD.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
regex-pderiv-0.1.3/Text/Regex/PDeriv/String/LeftToRightD.lhs:> type Word = String
regexpr-symbolic-0.5/RegExpr/RegExprOperations.lhs:> type Word a = [a]
remote-0.1.1/examples/tests/Test-MapReduce.hs:type Word = String
remote-0.1.1/examples/kmeans/KMeans3.hs:type Word = String
soyuz-0.0.0/DCPU16/Instructions.hs:data Word
text-icu-0.6.3.7/Data/Text/ICU/Break.hsc:data Word = Uncategorized       -- ^ A \"word\" that does not fit into another
text-register-machine-0.4.0/Language/TRM/Base.hs:newtype Word = W [Letter] deriving (Eq, Monoid)
utf8-light-0.4.2/src/Codec/Binary/UTF8/Light.hs:data Word = W# Word#
WordNet-1.1.0/NLP/WordNet/Types.hs:type Word = String
WordNet-ghc74-0.1.3/NLP/WordNet/Types.hs:type Word = String
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
york-lava-0.2/modules/Lava/Prelude.hs:type Word n = Vec n Bit
--8<---------------cut here---------------end--------------->8---
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Anthony Cowley
In reply to this post by Herbert Valerio Riedel
While I am +1 on this idea, I think it's worth acknowledging an unfortunate aspect of the name. The name "Word" has good reason, but, without any context, reasonable people will guess it has something to do with Strings. Add to this that other names like "uint" or its more verbose form are perhaps more common among programming languages. When given a numeric suffix, such as Word8 or Word32, some of the ambiguity is shed, but here we would instead see the unadorned name in many places.

I don't have any concrete suggestions for improving this that aren't somewhat groan worthy (eg type UInt = Word), but perhaps someone else might at least offer some comforting words. (Sorry)

Anthony

> On Aug 9, 2014, at 7:38 AM, Herbert Valerio Riedel <[hidden email]> wrote:
>
> Hello *,
>
> Proposal
> --------
>
> I hereby propose to export Haskell2010's Data.Word.Word type from the Prelude
>
>
> Motivation
> ----------
>
> Starting with Haskell2010, "Data.Word" exporting the type 'Word', "an
> unsigned integral type, with the same size as 'Int'" became part of the
> Haskell Report.
>
> 'Word' is usually a better choice than 'Int' when non-negative
> quantities (such as list lengths, bit or vector indices, or number of
> items in a container) need to be represented. Currently however, 'Word'
> is at a disadvantage (with respect to 'Int') in terms of public exposure
> by being accessible only after an "import Data.Word".
>
> Moreover, since 'Word' is now part of the Haskell Report, libraries
> should attempt to avoid name-clashing with 'Word' (and if they do, it
> ought to be a conscious decision, which ought to be declared by a
> requiring a "import Prelude hiding (Word)"). While one might think
> 'Word' would be a popular type-name to use in Haskell code, the current
> level of name collision is still rather low (as is shown in the next
> section), so the cost would still be bearable at this point in my
> opinion.
>
>
> Due diligence (w.r.t. code breakage impact)
> -------------------------------------------
>
> Packages depending on `haskell2010` or `haskell98` are not affected, and
> neither would be those depending on `base` with a PVP-suggested upper
> bound.
>
> However, to get a rough idea how widespread the use of 'Word' as a type
> on Hackage currently is, here's a simple check for current uses of
> 'Word' as a type-name performed with the simple heuristic search
>
>  find  -name '*.*hs*' -exec grep \
>     '\(data\|newtype\|type\)[[:space:]]\+Word[ =]' {} +
>
> over the unpacked source trees of the latest versions of the current
> 6766 packages on Hackage resulted in the following 43 packages being
> possibly affected (see specific source-code matches at end of email[1]):
>
> 1   adict-0.4.1
> 2   boxes-0.1.3
> 3   cjk-0.1.0.1
> 4   clash-prelude-0.5.1
> 5   combinat-0.2.5.0
> 6   concraft-pl-0.7.1
> 7   Craft3e-0.1.0.10
> 8   crf-chain1-0.2.2
> 9   crf-chain1-constrained-0.3.0
> 10  crf-chain2-generic-0.3.0
> 11  crf-chain2-tiers-0.2.1
> 12  delta-h-0.0.3
> 13  eros-0.6.0.0
> 14  estimators-0.1.4
> 15  estreps-0.3.1
> 16  FermatsLastMargin-0.1
> 17  fsmActions-0.4.4
> 18  gf-3.6
> 19  happraise-0.1
> 20  HAppS-Data-0.9.3
> 21  happstack-contrib-0.2.1
> 22  hist-pl-fusion-0.5.3
> 23  Holumbus-Searchengine-1.2.3
> 24  integer-pure-1.0
> 25  ixset-typed-0.3
> 26  language-bash-0.6.0
> 27  language-sh-0.0.3.1
> 28  lhc-0.10
> 29  MemoTrie-0.6.2
> 30  mpppc-0.1.3
> 31  nerf-0.5.2
> 32  regex-deriv-0.0.4
> 33  regex-pderiv-0.1.3
> 34  regexpr-symbolic-0.5
> 35  remote-0.1.1
> 36  soyuz-0.0.0
> 37  text-icu-0.6.3.7
> 38  text-register-machine-0.4.0
> 39  utf8-light-0.4.2
> 40  WordNet-1.1.0
> 41  WordNet-ghc74-0.1.3
> 42  xhaskell-library-0.0.6
> 43  york-lava-0.2
>
>
> Discussion period
> -----------------
>
> 2 weeks
>
>
> Footnotes
> ---------
>
> [1] More specifically, here's the output of the above mentioned `grep` command:
>
> --8<---------------cut here---------------start------------->8---
> adict-0.4.1/src/NLP/Adict/Core.hs:type Word a = V.Vector a
> boxes-0.1.3/Text/PrettyPrint/Boxes.hs:data Word = Word { wLen :: Int, getWord  :: String }
> cjk-0.1.0.1/CJK/Data/CEDICT.hs:data Word = Word {
> clash-prelude-0.5.1/src/CLaSH/Tutorial.hs:type Word = Signed 4
> combinat-0.2.5.0/Math/Combinat/FreeGroups.hs:type Word a = [Generator a]
> concraft-pl-0.7.1/src/NLP/Concraft/Polish/Morphosyntax.hs:data Word = Word
> Craft3e-0.1.0.10/Chapter7.hs:type Word = String
> Craft3e-0.1.0.10/Index.hs:type Word = String
> crf-chain1-0.2.2/Data/CRF/Chain1/Dataset/External.hs:type Word a = S.Set a
> crf-chain1-constrained-0.3.0/src/Data/CRF/Chain1/Constrained/Dataset/External.hs:data Word a b = Word
> crf-chain2-generic-0.3.0/Data/CRF/Chain2/Generic/External.hs:data Word a b = Word {
> crf-chain2-tiers-0.2.1/src/Data/CRF/Chain2/Tiers/Dataset/External.hs:data Word a b = Word {
> delta-h-0.0.3/src/EvalSem.hs:type Word = String
> eros-0.6.0.0/src/Text/Eros/Message.hs:type Word         = L.Text
> estimators-0.1.4/NLP/Probability/Example/Trigram.hs:newtype Word = Word T.Text
> estreps-0.3.1/src/Repeats.lhs:-- type Word = Int
> FermatsLastMargin-0.1/FLM/WikiPages.hs:       newtype Word     = Word String
> fsmActions-0.4.4/Data/FsmActions.hs:newtype Word sy = Word [sy]
> gf-3.6/lib/src/finnish/wordnet/FreqFin.hs:type Word = String
> gf-3.6/treebanks/susanne/SusanneFormat.hs:type Word  = String
> gf-3.6/treebanks/talbanken/Format.hs:data Word     = W  {id :: Id, word :: String, pos :: Tag}
> happraise-0.1/Main.hs:type Word = String
> HAppS-Data-0.9.3/src/HAppS/Data/Atom.hs:    newtype Word = Word String
> happstack-contrib-0.2.1/src/Happstack/Contrib/Atom.hs:    newtype Word = Word String
> hist-pl-fusion-0.5.3/src/NLP/HistPL/Fusion.hs:type Word = T.Text
> Holumbus-Searchengine-1.2.3/src/Holumbus/Index/Common/BasicTypes.hs:type Word                       = String
> integer-pure-1.0/Data/Integer.hs:type Word    = Int    -- We fake the Word type, to avoid nasty conversions.
> ixset-typed-0.3/src/Data/IxSet/Typed.hs:    > newtype Word = Word String
> language-bash-0.6.0/src/Language/Bash/Word.hs:type Word = [Span]
> language-sh-0.0.3.1/Language/Sh/Syntax.hs:type Word = [Lexeme]
> lhc-0.10/lib/base/src/Data/Word.hs:type Word = Word32
> lhc-0.10/lib/base/src/GHC/Word.hs:data Word = W# Word# deriving (Eq, Ord)
> MemoTrie-0.6.2/src/Data/MemoTrie.hs:--     newtype Word :->: a = WordTrie ([Bool] :->: a)
> mpppc-0.1.3/src/Text/PrettyPrint/MPPPC/TwoDim/Combinators/Flow.hs:data Word s t = Printable s t =>
> nerf-0.5.2/src/NLP/Nerf/Types.hs:type Word = T.Text
> regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/BitCode.hs:type Word = S.ByteString
> regex-deriv-0.0.4/Text/Regex/Deriv/ByteString/Posix.lhs:> type Word = S.ByteString
> regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
> regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/LeftToRightD.lhs:> type Word = S.ByteString
> regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
> regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
> regex-pderiv-0.1.3/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
> regex-pderiv-0.1.3/Text/Regex/PDeriv/String/LeftToRightD.lhs:> type Word = String
> regexpr-symbolic-0.5/RegExpr/RegExprOperations.lhs:> type Word a = [a]
> remote-0.1.1/examples/tests/Test-MapReduce.hs:type Word = String
> remote-0.1.1/examples/kmeans/KMeans3.hs:type Word = String
> soyuz-0.0.0/DCPU16/Instructions.hs:data Word
> text-icu-0.6.3.7/Data/Text/ICU/Break.hsc:data Word = Uncategorized       -- ^ A \"word\" that does not fit into another
> text-register-machine-0.4.0/Language/TRM/Base.hs:newtype Word = W [Letter] deriving (Eq, Monoid)
> utf8-light-0.4.2/src/Codec/Binary/UTF8/Light.hs:data Word = W# Word#
> WordNet-1.1.0/NLP/WordNet/Types.hs:type Word = String
> WordNet-ghc74-0.1.3/NLP/WordNet/Types.hs:type Word = String
> xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/LeftToRight.lhs:> type Word = S.ByteString
> xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/Posix.lhs:> type Word = S.ByteString
> xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/RightToLeft.lhs:> type Word = S.ByteString
> xhaskell-library-0.0.6/Text/Regex/PDeriv/ByteString/TwoPasses.lhs:> type Word = S.ByteString
> york-lava-0.2/modules/Lava/Prelude.hs:type Word n = Vec n Bit
> --8<---------------cut here---------------end--------------->8---
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Henning Thielemann-4
Am 09.08.2014 um 21:15 schrieb Anthony Cowley:

> While I am +1 on this idea, I think it's worth acknowledging an unfortunate aspect of the name. The name "Word" has good reason, but, without any context, reasonable people will guess it has something to do with Strings. Add to this that other names like "uint" or its more verbose form are perhaps more common among programming languages. When given a numeric suffix, such as Word8 or Word32, some of the ambiguity is shed, but here we would instead see the unadorned name in many places.

This is my concern, too. I think Word refers to the "machine word", i.e.
data of a size that the processor can optimally cope with. There is no
reason why Word should represent a non-negative number, its just a bit
pattern. Furthermore Word (like Int) has no protection against overflow,
e.g. (-1 :: Word) is accepted without any warnings.


> I don't have any concrete suggestions for improving this that aren't somewhat groan worthy (eg type UInt = Word), but perhaps someone else might at least offer some comforting words. (Sorry)

Modula calls non-negative integers CARDINAL. I like the name. In Haskell
there could be a Cardinal type for arbitrary size non-negative integers
and Card for machine size integers, although the latter one could be
misunderstood as cards used in card games.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Herbert Valerio Riedel
Hello Henning,

On 2014-08-09 at 21:25:50 +0200, Henning Thielemann wrote:

[...]

> Furthermore Word (like Int) has no protection against overflow,
> e.g. (-1 :: Word) is accepted without any warnings.

Like Int*, all Word*-typed literals are checked as well[1]. But for some
reason I haven't investigated (possibly a bug) the check fails for small
negative values unless -XNegativeLiterals is active:


  Prelude> (0xfffffffffffffffff::Data.Word.Word)
  <interactive>:2:2: Warning:
      Literal 295147905179352825855 is out of the GHC.Types.Word range 0..18446744073709551615
  18446744073709551615

  Prelude> (-0xfffffffffffffffff::Data.Word.Word)
  <interactive>:3:3: Warning:
      Literal 295147905179352825855 is out of the GHC.Types.Word range 0..18446744073709551615
  1

  Prelude> (-1::Data.Word.Word)
  18446744073709551615

  Prelude> :set -XNegativeLiterals
  Prelude> (-1::Data.Word.Word)
  <interactive>:6:2: Warning:
      Literal -1 is out of the GHC.Types.Word range 0..18446744073709551615
  18446744073709551615


>> I don't have any concrete suggestions for improving this that aren't
>> somewhat groan worthy (eg type UInt = Word), but perhaps someone
>> else might at least offer some comforting words. (Sorry)
>
> Modula calls non-negative integers CARDINAL. I like the name. In
> Haskell there could be a Cardinal type for arbitrary size non-negative
> integers and Card for machine size integers, although the latter one
> could be misunderstood as cards used in card games.

Fwiw, I did wonder back then why Wirth chose the term 'cardinal' over
e.g.  'natural'. However, the thing is, 'Word' is already part of the
Haskell Report (and before that had been established already via the FFI
addendum), and it's already adopted widely (grep found " Data.Word"
mentioned in 1365 of 6766 packages). So the type-name 'Word' meaning
unsigned fixed-width integral is not going away that soon.

Cheers,
  hvr


 [1]: https://github.com/ghc/ghc/blob/1fc60ea1f1fd89b90c2992d060aecb5b5a65f8c0/compiler/deSugar/MatchLit.lhs#L158-L190
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Henning Thielemann-4
Am 09.08.2014 um 23:12 schrieb Herbert Valerio Riedel:

>> Modula calls non-negative integers CARDINAL. I like the name. In
>> Haskell there could be a Cardinal type for arbitrary size non-negative
>> integers and Card for machine size integers, although the latter one
>> could be misunderstood as cards used in card games.
>
> Fwiw, I did wonder back then why Wirth chose the term 'cardinal' over
> e.g.  'natural'.

"Natural" for arbitrary size non-negative integer and "Nat" for machine
size natural number would be fine to me, too.

 > So the type-name 'Word' meaning
> unsigned fixed-width integral is not going away that soon.

How would you name the arbitrary size natural number type, such that it
is consistent with the Integer/Int scheme?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Niklas Haas
On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <[hidden email]> wrote:
> How would you name the arbitrary size natural number type, such that it
> is consistent with the Integer/Int scheme?

I would honestly go with Natural/Nat.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Edward Kmett-2
I'm personally very strongly +1 on exporting Word as it is from Data.Word from the Prelude sans bike-shedding.

Its absence is quite noticeably weird.

However, I would really prefer to avoid bike-shedding the name of Word.

The name Word from Data.Word is very well understood across the entire community, whereas both Nat and Natural are both names folks have used consistently for unbounded natural numbers in various flavors.

When I see Nat, I do _not_ think bounded machine word, I think induction. 

Adding 1 to a Nat to wrap around and get 0 feels very very wrong to me.

Picking new names just for the sake of picking new names mean that this goes from a no-brainer to something to agonize over. 

It goes from an easy 2 line patch to something that affects every existing user of Data.Word. There is no clean upgrade path across the GHC version where that export happens.

If the proposal becomes to export Word as Nat? I think I'm actually then just as equally strongly -1 against it as I am +1 for it right now.

If and when Herbert's work on working with the strictly positive functions in GMP to make a decent natural number type bear fruit, I'd be happy to have the discussion about exporting that as well, probably as Natural.

But let's be honest, Int/Integer is more or less a happy coincidence. It's nice that they were already in the culture that way, and that folks were indoctrinated by C and other languages to think of Int as a sort of bounded integer. 

I'm not really happy with the prospect of breaking everything just to try to get something syntactically similar that _will_ violate expectations.

There is nothing Natural about a Word.

-Edward




On Sat, Aug 9, 2014 at 7:21 PM, Niklas Haas <[hidden email]> wrote:
On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <[hidden email]> wrote:
> How would you name the arbitrary size natural number type, such that it
> is consistent with the Integer/Int scheme?

I would honestly go with Natural/Nat.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Anthony Cowley

On Aug 9, 2014, at 9:14 PM, Edward Kmett <[hidden email]> wrote:

I'm personally very strongly +1 on exporting Word as it is from Data.Word from the Prelude sans bike-shedding.

Its absence is quite noticeably weird.

However, I would really prefer to avoid bike-shedding the name of Word.

The name Word from Data.Word is very well understood across the entire community, whereas both Nat and Natural are both names folks have used consistently for unbounded natural numbers in various flavors.

Many of the conflicts on hackage cited in the proposal are suggestive of the other obvious meaning of the name Word. That is the community as represented by actual data.

Let's first lay to rest the strawman of renaming Word in Data.Word as nobody suggested it, and I doubt anybody seriously wants it. The only breakage on the table is in packages that define Word themselves.

The reason why the name has to at least be thought about here is that adding it to Prelude means that we are not picking a name for a type, we are effectively preventing any other use of that name.

I remain a +1 on the proposal, but I'm very open to hearing from people who would resent having the name taken out of circulation, and I want future generations to look back and respect the angst we all felt about denying them Wordly pleasures.

Anthony


When I see Nat, I do _not_ think bounded machine word, I think induction. 

Adding 1 to a Nat to wrap around and get 0 feels very very wrong to me.

Picking new names just for the sake of picking new names mean that this goes from a no-brainer to something to agonize over. 

It goes from an easy 2 line patch to something that affects every existing user of Data.Word. There is no clean upgrade path across the GHC version where that export happens.

If the proposal becomes to export Word as Nat? I think I'm actually then just as equally strongly -1 against it as I am +1 for it right now.

If and when Herbert's work on working with the strictly positive functions in GMP to make a decent natural number type bear fruit, I'd be happy to have the discussion about exporting that as well, probably as Natural.

But let's be honest, Int/Integer is more or less a happy coincidence. It's nice that they were already in the culture that way, and that folks were indoctrinated by C and other languages to think of Int as a sort of bounded integer. 

I'm not really happy with the prospect of breaking everything just to try to get something syntactically similar that _will_ violate expectations.

There is nothing Natural about a Word.

-Edward




On Sat, Aug 9, 2014 at 7:21 PM, Niklas Haas <[hidden email]> wrote:
On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <[hidden email]> wrote:
> How would you name the arbitrary size natural number type, such that it
> is consistent with the Integer/Int scheme?

I would honestly go with Natural/Nat.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

David Feuer

I am concerned about the name Word as well. The names Word8 and Word16 come out looking very strange, as well as Word64 on a 32-bit platform. I'd go for renaming them all to UInt, UInt8, UInt16, UInt32, and UInt64, with the current names in Data.Word turned into type synonyms for compatibility (and use by anyone who likes those names).
On Aug 9, 2014 9:36 PM, "Anthony Cowley" <[hidden email]> wrote:
>
>
> On Aug 9, 2014, at 9:14 PM, Edward Kmett <[hidden email]> wrote:
>
>> I'm personally very strongly +1 on exporting Word as it is from Data.Word from the Prelude sans bike-shedding.
>>
>> Its absence is quite noticeably weird.
>>
>> However, I would really prefer to avoid bike-shedding the name of Word.
>>
>> The name Word from Data.Word is very well understood across the entire community, whereas both Nat and Natural are both names folks have used consistently for unbounded natural numbers in various flavors.
>
>
> Many of the conflicts on hackage cited in the proposal are suggestive of the other obvious meaning of the name Word. That is the community as represented by actual data.
>
> Let's first lay to rest the strawman of renaming Word in Data.Word as nobody suggested it, and I doubt anybody seriously wants it. The only breakage on the table is in packages that define Word themselves.
>
> The reason why the name has to at least be thought about here is that adding it to Prelude means that we are not picking a name for a type, we are effectively preventing any other use of that name.
>
> I remain a +1 on the proposal, but I'm very open to hearing from people who would resent having the name taken out of circulation, and I want future generations to look back and respect the angst we all felt about denying them Wordly pleasures.
>
> Anthony
>
>>
>> When I see Nat, I do _not_ think bounded machine word, I think induction. 
>>
>> Adding 1 to a Nat to wrap around and get 0 feels very very wrong to me.
>>
>> Picking new names just for the sake of picking new names mean that this goes from a no-brainer to something to agonize over. 
>>
>> It goes from an easy 2 line patch to something that affects every existing user of Data.Word. There is no clean upgrade path across the GHC version where that export happens.
>>
>> If the proposal becomes to export Word as Nat? I think I'm actually then just as equally strongly -1 against it as I am +1 for it right now.
>>
>> If and when Herbert's work on working with the strictly positive functions in GMP to make a decent natural number type bear fruit, I'd be happy to have the discussion about exporting that as well, probably as Natural.
>>
>> But let's be honest, Int/Integer is more or less a happy coincidence. It's nice that they were already in the culture that way, and that folks were indoctrinated by C and other languages to think of Int as a sort of bounded integer. 
>>
>> I'm not really happy with the prospect of breaking everything just to try to get something syntactically similar that _will_ violate expectations.
>>
>> There is nothing Natural about a Word.
>>
>> -Edward
>>
>>
>>
>>
>> On Sat, Aug 9, 2014 at 7:21 PM, Niklas Haas <[hidden email]> wrote:
>>>
>>> On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <[hidden email]> wrote:
>>> > How would you name the arbitrary size natural number type, such that it
>>> > is consistent with the Integer/Int scheme?
>>>
>>> I would honestly go with Natural/Nat.
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

David Feuer

I am concerned about the name Word as well. The names Word8 and Word16 come out looking very strange, as well as Word64 on a 32-bit platform. I'd go for renaming them all to UInt, UInt8, UInt16, UInt32, and UInt64, with the current names in Data.Word turned into type synonyms for compatibility (and use by anyone who likes those names).
On Aug 9, 2014 9:36 PM, "Anthony Cowley" <[hidden email]> wrote:
>
>
> On Aug 9, 2014, at 9:14 PM, Edward Kmett <[hidden email]> wrote:
>
>> I'm personally very strongly +1 on exporting Word as it is from Data.Word from the Prelude sans bike-shedding.
>>
>> Its absence is quite noticeably weird.
>>
>> However, I would really prefer to avoid bike-shedding the name of Word.
>>
>> The name Word from Data.Word is very well understood across the entire community, whereas both Nat and Natural are both names folks have used consistently for unbounded natural numbers in various flavors.
>
>
> Many of the conflicts on hackage cited in the proposal are suggestive of the other obvious meaning of the name Word. That is the community as represented by actual data.
>
> Let's first lay to rest the strawman of renaming Word in Data.Word as nobody suggested it, and I doubt anybody seriously wants it. The only breakage on the table is in packages that define Word themselves.
>
> The reason why the name has to at least be thought about here is that adding it to Prelude means that we are not picking a name for a type, we are effectively preventing any other use of that name.
>
> I remain a +1 on the proposal, but I'm very open to hearing from people who would resent having the name taken out of circulation, and I want future generations to look back and respect the angst we all felt about denying them Wordly pleasures.
>
> Anthony
>
>>
>> When I see Nat, I do _not_ think bounded machine word, I think induction. 
>>
>> Adding 1 to a Nat to wrap around and get 0 feels very very wrong to me.
>>
>> Picking new names just for the sake of picking new names mean that this goes from a no-brainer to something to agonize over. 
>>
>> It goes from an easy 2 line patch to something that affects every existing user of Data.Word. There is no clean upgrade path across the GHC version where that export happens.
>>
>> If the proposal becomes to export Word as Nat? I think I'm actually then just as equally strongly -1 against it as I am +1 for it right now.
>>
>> If and when Herbert's work on working with the strictly positive functions in GMP to make a decent natural number type bear fruit, I'd be happy to have the discussion about exporting that as well, probably as Natural.
>>
>> But let's be honest, Int/Integer is more or less a happy coincidence. It's nice that they were already in the culture that way, and that folks were indoctrinated by C and other languages to think of Int as a sort of bounded integer. 
>>
>> I'm not really happy with the prospect of breaking everything just to try to get something syntactically similar that _will_ violate expectations.
>>
>> There is nothing Natural about a Word.
>>
>> -Edward
>>
>>
>>
>>
>> On Sat, Aug 9, 2014 at 7:21 PM, Niklas Haas <[hidden email]> wrote:
>>>
>>> On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <[hidden email]> wrote:
>>> > How would you name the arbitrary size natural number type, such that it
>>> > is consistent with the Integer/Int scheme?
>>>
>>> I would honestly go with Natural/Nat.
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Michael Snoyman
In reply to this post by Edward Kmett-2



On Sun, Aug 10, 2014 at 4:14 AM, Edward Kmett <[hidden email]> wrote:
I'm personally very strongly +1 on exporting Word as it is from Data.Word from the Prelude sans bike-shedding.

Its absence is quite noticeably weird.

However, I would really prefer to avoid bike-shedding the name of Word.

The name Word from Data.Word is very well understood across the entire community, whereas both Nat and Natural are both names folks have used consistently for unbounded natural numbers in various flavors.

When I see Nat, I do _not_ think bounded machine word, I think induction. 

Adding 1 to a Nat to wrap around and get 0 feels very very wrong to me.

Picking new names just for the sake of picking new names mean that this goes from a no-brainer to something to agonize over. 

It goes from an easy 2 line patch to something that affects every existing user of Data.Word. There is no clean upgrade path across the GHC version where that export happens.

If the proposal becomes to export Word as Nat? I think I'm actually then just as equally strongly -1 against it as I am +1 for it right now.

If and when Herbert's work on working with the strictly positive functions in GMP to make a decent natural number type bear fruit, I'd be happy to have the discussion about exporting that as well, probably as Natural.

But let's be honest, Int/Integer is more or less a happy coincidence. It's nice that they were already in the culture that way, and that folks were indoctrinated by C and other languages to think of Int as a sort of bounded integer. 

I'm not really happy with the prospect of breaking everything just to try to get something syntactically similar that _will_ violate expectations.

There is nothing Natural about a Word.

-Edward



I agree with Edward completely here. +1 one the original proposal, -1 on any kind of renaming.

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Ivan Lazar Miljenovic
In reply to this post by David Feuer
On 10 August 2014 11:51, David Feuer <[hidden email]> wrote:
> I am concerned about the name Word as well. The names Word8 and Word16 come
> out looking very strange, as well as Word64 on a 32-bit platform. I'd go for
> renaming them all to UInt, UInt8, UInt16, UInt32, and UInt64, with the
> current names in Data.Word turned into type synonyms for compatibility (and
> use by anyone who likes those names).

I'm +1 on the re-exporting (I would be tempted to go the whole hog and
re-export all the Word* types as well).

Regarding David's renaming proposal, wouldn't this cause breakage for
custom instances in existing code, requiring use of
TypeSynonymInstances?

As such, I don't think this would completely solve the problems.

> On Aug 9, 2014 9:36 PM, "Anthony Cowley" <[hidden email]> wrote:
>>
>>
>> On Aug 9, 2014, at 9:14 PM, Edward Kmett <[hidden email]> wrote:
>>
>>> I'm personally very strongly +1 on exporting Word as it is from Data.Word
>>> from the Prelude sans bike-shedding.
>>>
>>> Its absence is quite noticeably weird.
>>>
>>> However, I would really prefer to avoid bike-shedding the name of Word.
>>>
>>> The name Word from Data.Word is very well understood across the entire
>>> community, whereas both Nat and Natural are both names folks have used
>>> consistently for unbounded natural numbers in various flavors.
>>
>>
>> Many of the conflicts on hackage cited in the proposal are suggestive of
>> the other obvious meaning of the name Word. That is the community as
>> represented by actual data.
>>
>> Let's first lay to rest the strawman of renaming Word in Data.Word as
>> nobody suggested it, and I doubt anybody seriously wants it. The only
>> breakage on the table is in packages that define Word themselves.
>>
>> The reason why the name has to at least be thought about here is that
>> adding it to Prelude means that we are not picking a name for a type, we are
>> effectively preventing any other use of that name.
>>
>> I remain a +1 on the proposal, but I'm very open to hearing from people
>> who would resent having the name taken out of circulation, and I want future
>> generations to look back and respect the angst we all felt about denying
>> them Wordly pleasures.
>>
>> Anthony
>>
>>>
>>> When I see Nat, I do _not_ think bounded machine word, I think induction.
>>>
>>> Adding 1 to a Nat to wrap around and get 0 feels very very wrong to me.
>>>
>>> Picking new names just for the sake of picking new names mean that this
>>> goes from a no-brainer to something to agonize over.
>>>
>>> It goes from an easy 2 line patch to something that affects every
>>> existing user of Data.Word. There is no clean upgrade path across the GHC
>>> version where that export happens.
>>>
>>> If the proposal becomes to export Word as Nat? I think I'm actually then
>>> just as equally strongly -1 against it as I am +1 for it right now.
>>>
>>> If and when Herbert's work on working with the strictly positive
>>> functions in GMP to make a decent natural number type bear fruit, I'd be
>>> happy to have the discussion about exporting that as well, probably as
>>> Natural.
>>>
>>> But let's be honest, Int/Integer is more or less a happy coincidence.
>>> It's nice that they were already in the culture that way, and that folks
>>> were indoctrinated by C and other languages to think of Int as a sort of
>>> bounded integer.
>>>
>>> I'm not really happy with the prospect of breaking everything just to try
>>> to get something syntactically similar that _will_ violate expectations.
>>>
>>> There is nothing Natural about a Word.
>>>
>>> -Edward
>>>
>>>
>>>
>>>
>>> On Sat, Aug 9, 2014 at 7:21 PM, Niklas Haas <[hidden email]>
>>> wrote:
>>>>
>>>> On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann
>>>> <[hidden email]> wrote:
>>>> > How would you name the arbitrary size natural number type, such that
>>>> > it
>>>> > is consistent with the Integer/Int scheme?
>>>>
>>>> I would honestly go with Natural/Nat.
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> [hidden email]
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Malcolm Wallace-2

On 10 Aug 2014, at 07:04, Ivan Lazar Miljenovic wrote:

> I'm +1 on the re-exporting (I would be tempted to go the whole hog and
> re-export all the Word* types as well).


I was involved in the discussions when the Word type was originally added to Haskell, primarily for the use of the FFI.  As I recall, people were deeply uncomfortable that there should even be a Word type, with unspecified precision.  The types Word8, Word16, Word32, and Word64 were entirely uncontroversial, because you know what you are dealing with.  The primary use of the Word* types was to represent machine words (bytes, half-words, etc), enabling (for instance) bit-twiddling of individual components of the word.  With an unknown-precision Word value, you can guarantee nothing about whether your bit-operation will work.  I believe the use of unknown-precision Word to represent non-negative integers was the winning justification, but it remains controversial in the same way that Int (rather than Int32, or Integer) does.  Lack of clarity over whether or when a number overflows is a pretty bad downside.  Pragmatically, it may work OK for most people most of the time.  But the Haskel
 l way is to prefer correctness.

Regards,
    Malcolm
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

checked Ints (was: Proposal: Export Data.Word.Word from Prelude)

Herbert Valerio Riedel
Hello Malcolm

On 2014-08-10 at 10:07:42 +0200, Malcolm Wallace wrote:

> [...] I believe the use of unknown-precision Word to represent
> non-negative integers was the winning justification, but it remains
> controversial in the same way that Int (rather than Int32, or Integer)
> does.  Lack of clarity over whether or when a number overflows is a
> pretty bad downside.  Pragmatically, it may work OK for most people
> most of the time.  But the Haskell way is to prefer correctness.

Btw, were there ever any discussions or plans to introduce "checked"
Int/Word types into the Haskell Report? As well as efficient dynamically
(or even statically) checked fromIntegral conversions (c.f. [1])?

I.e. 'Int'/'Word' types (whose bit-width has some degree of freedom as
you point out) whose 'Num' operations would throw appropriate
`ArithException`s if the result over/underflows the type domain
(c.f. [2])


 [1]: I plan to bring this up at some later point as part of an effort
      to provide Haskell with statically accessible range meta-info
      about bounded integral types (something like a promoted `Bounded`
      typeclass), as right now it seems one has to resort to type-level
      hackery such as

        http://hackage.haskell.org/package/int-cast-0.1.1.0/docs/Data-IntCast.html

      to achieve what I have in mind.

 [2]: http://hackage.haskell.org/package/safeint

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: checked Ints (was: Proposal: Export Data.Word.Word from Prelude)

Malcolm Wallace-2

On 10 Aug 2014, at 11:34, Herbert Valerio Riedel wrote:

> Btw, were there ever any discussions or plans to introduce "checked"
> Int/Word types into the Haskell Report?

There were discussions, yes.  I think the concern was that programmers tend to want either (a) correctness or (b) speed.  For the former, there is Integer, for the latter there is Int.  A checked-for-overflow bounded type would give you neither: i.e. slower than Int, but not significantly more correct.  On overflow, your program still goes wrong, but it would manifest as a crash/exception rather than an incorrect value.  

> As well as efficient dynamically
> (or even statically) checked fromIntegral conversions (c.f. [1])?

I think static detection of overflow-correctness would be desirable, yes, leading to promotion of the type from CheckedInt to Int, thus eliminating any runtime checks.  But if you can do that static analysis, you don't actually need another type.

However, I think there is still plenty of scope for a reappraisal of the concept.

Regards,
    Malcolm

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Ben Millwood
In reply to this post by Herbert Valerio Riedel
On Sun, Aug 10, 2014 at 09:07:42AM +0100, Malcolm Wallace wrote:

>
> On 10 Aug 2014, at 07:04, Ivan Lazar Miljenovic wrote:
>
>> I'm +1 on the re-exporting (I would be tempted to go the whole hog and
>> re-export all the Word* types as well).
>
>
> I was involved in the discussions when the Word type was originally
> added to Haskell, primarily for the use of the FFI.  As I recall,
> people were deeply uncomfortable that there should even be a Word
> type, with unspecified precision.  The types Word8, Word16, Word32,
> and Word64 were entirely uncontroversial, because you know what you
> are dealing with.  The primary use of the Word* types was to
> represent machine words (bytes, half-words, etc), enabling (for
> instance) bit-twiddling of individual components of the word.  With
> an unknown-precision Word value, you can guarantee nothing about
> whether your bit-operation will work.  I believe the use of
> unknown-precision Word to represent non-negative integers was the
> winning justification, but it remains controversial in the same way
> that Int (rather than Int32, or Integer) does.  Lack of clarity
> over whether or when a number overflows is a pretty bad downside.  
> Pragmatically, it may work OK for most people most of the time.  
> But the Haskel
> l way is to prefer correctness.

I think I sympathise a great deal with people's discomfort. I feel
like the ubiquity of Int was a mistake: it's basically a performance
optimisation, with reasonably serious correctness issues, and
shouldn't be the first thing every newbie comes across. I moreover
feel like, e.g. `length :: [a] -> Word` (or things of that ilk) would
be even more of a mistake, because type inference will spread that
`Word` everywhere, and `2 - 3 :: Word` is catastrophically wrong.
Although it seems nice to have an output type for non-negative
functions that only has non-negative values, in fact Word happily
supports subtraction, conversion from Integer, even negation (!)
without a hint that anything has gone amiss. So I just don't believe
that it is a type suitable for general "positive integer"
applications.

I feel a little unqualified to comment in the face of people far more
knowledgeable and experienced than I am enthusiastically +1-ing this
proposal, but I'm going to go ahead and -1 it. I think the situations
in which Word is really what you want are few enough that it should
not clutter the universal namespace.

> Regards,
>    Malcolm
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

Evan Laforge
On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood <[hidden email]> wrote:
> `length :: [a] -> Word` (or things of that ilk) would be even more of a
> mistake, because type inference will spread that `Word` everywhere, and `2 -
> 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me.  I have in the past used
Word for things that seemed like they should always be positive, and
pretty quickly reverted back to a signed type.  All you need is a
subtraction anywhere and the chance of underflow is very high.  And,
as Ben said, it's easy for the "always positive" type to wind up in a
domain where subtraction is valid due to type inference.  The
principled thing might be to make that a different type, but in
practice that can be a lot of hassle so it often doesn't happen (do
you use NonEmpty everywhere possible? always have separate types for
absolute and relative measures? sometimes it's not worth the clutter).
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export Data.Word.Word from Prelude

John Lato-2
On Wed, Aug 13, 2014 at 4:05 PM, Evan Laforge <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood <[hidden email]> wrote:
> `length :: [a] -> Word` (or things of that ilk) would be even more of a
> mistake, because type inference will spread that `Word` everywhere, and `2 -
> 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me.  I have in the past used
Word for things that seemed like they should always be positive, and
pretty quickly reverted back to a signed type.  All you need is a
subtraction anywhere and the chance of underflow is very high.  And,
as Ben said, it's easy for the "always positive" type to wind up in a
domain where subtraction is valid due to type inference.  The
principled thing might be to make that a different type, but in
practice that can be a lot of hassle so it often doesn't happen (do
you use NonEmpty everywhere possible? always have separate types for
absolute and relative measures? sometimes it's not worth the clutter).

I agree it would be wrong to have `length` return a Word unconditionally, but I don't think it's a mistake in general to have that option available (i.e. genericLength).  It just means that the programmer is taking on some responsibilities manually instead of leveraging the type system, but sometimes that's the only way to get the desired performance.  Besides, nobody is actually proposing that `length` return a Word, so I don't find this argument relevant to the proposal.

Relatively weak +1 from me (I'm more enthusiastic about exporting the entirely of Intx/Wordx types via the prelude).

John L.



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12