Proposal: Export Data.Word.Word from Prelude

[Ivan Lazar Miljenovic]

On 10 August 2014 11:51, David Feuer <david.feuer at gmail.com> 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" <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
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



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