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" <acowley at seas.upenn.edu> wrote:
>
>
> On Aug 9, 2014, at 9:14 PM, Edward Kmett <ekmett at gmail.com> 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 <haskell at nand.wakku.to>
wrote:
>>>
>>> On Sat, 09 Aug 2014 23:23:52 +0200, Henning Thielemann <
schlepptop at 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140809/1b9c5aaf/attachment-0001.html>