Crazy suggestion for dealing with the naming disaster that is ByteString

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

Crazy suggestion for dealing with the naming disaster that is ByteString

Merijn Verstraaten
Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.

But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".

Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.

Cheers,
Merijn

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Crazy suggestion for dealing with the naming disaster that is ByteString

Christopher Allen
I’d love this as I am getting tired of explaining “it’s a string of bytes, not a string-as-in-text.”

> On Jan 28, 2018, at 5:26 AM, Merijn Verstraaten <[hidden email]> wrote:
>
> Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.
>
> But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".
>
> Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.
>
> Cheers,
> Merijn
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Crazy suggestion for dealing with the naming disaster that is ByteString

Lana Black
On 28/01/18 13:51, Christopher Allen wrote:
> I’d love this as I am getting tired of explaining “it’s a string of bytes, not a string-as-in-text.”
>

B-b-but bytestring is a string-as-in-text too among other things.
Otherwise we wouldn't have `instance IsString ByteString' or
Data.ByteString.Char8 module.

I like the idea, but is it worth the hassle? Perhaps, as a start,
someone could make "bytes" as a shim package with `type Bytes =
ByteString' and all related functions re-exported, just to see how it
goes. If the adoption rate turns out to be significant, bytes and
bytestring packages could be swapped.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Crazy suggestion for dealing with the naming disaster that is ByteString

Lana Black
In reply to this post by Merijn Verstraaten
On 28/01/18 11:26, Merijn Verstraaten wrote:
> Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.
>
> But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".
>
> Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.
>

Just to add, there are two problems with this proposal. First, there
already is a package named 'bytes' [1]. Second, renaming the type and
adding a type alias will break all the instances for ByteString in other
packages, because Haskell forbids instance declaration for type aliases
unless TypeSynonymInstances extension is enabled.

[1]: http://hackage.haskell.org/package/bytes

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

Re: Crazy suggestion for dealing with the naming disaster that is ByteString

Aloïs Cochard
In reply to this post by Merijn Verstraaten
Hi,

Why do you think ByteString should be named Bytes?

Maybe I missed it but I don't see any motivation for the rename. I don't see what is wrong with the current name.

Thanks

On 28 Jan 2018 12:27, "Merijn Verstraaten" <[hidden email]> wrote:
Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.

But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".

Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.

Cheers,
Merijn

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries