+1 On Sat, Aug 9, 2014 at 8:27 PM, Carter Schonwald

wrote:

strong +1 from me!

On Sat, Aug 9, 2014 at 7:38 AM, Herbert Valerio Riedel 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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.

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?

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 wrote:

On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann < schlepptop@henning-thielemann.de> 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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" wrote:

On Aug 9, 2014, at 9:14 PM, Edward Kmett wrote:

...

I'm personally very strongly +1 on exporting Word as it is from

...

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

Data.Word from the Prelude sans bike-shedding. 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

...

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

induction. 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

wrote:

...

...

On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <

schlepptop@henning-thielemann.de> 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 10 August 2014 11:51, David Feuer 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" wrote:

...

On Aug 9, 2014, at 9:14 PM, Edward Kmett 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 wrote:

...

On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

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

On Sun, Aug 10, 2014 at 4:14 AM, Edward Kmett 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