Think about namespaces

[treeowl]

@andrewthad suggested changing the naming conventions to use the more common assumption that people will import thing other than types qualified. I think it would probably be too disruptive to do that directly. But sharing (or even copying and pasting) code among the different array implementations would be much easier in that regime. I believe there is quite a lot of code that could be shared. That suggests an alternative approach: layer primitive on top of another package, in the same repository, that uses the other convention. primitive itself would just be a thin shell over the other package.

[andrewthad]

As an alternative, it doesn't necessarily have to be a separate package. It could just be different modules in the primitive package. This would actually be my preference.

[cartazio]

Or vice versa ? What problem are we trying to solve

…

On Mon, Mar 26, 2018 at 2:10 PM Andrew Martin ***@***.***> wrote: As an alternative, it doesn't necessarily have to be a separate package. It could just be different modules in the primitive package. This would actually be my preference. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwh2sWtR2eNOy9hv5KxDv_VlcjY_0ks5tiS8mgaJpZM4S7o-_> .

[treeowl]

@cartazio, there are a decent number of functions (largely in class instances) that are basically the same between Data.Primitive.Array and Data.Primitive.SmallArray, except for the names. I found myself copying definitions, then doing find and replace throughout their bodies. It was annoying. Have you had a chance to look at 109? I'm leaving town tomorrow evening....

[cartazio]

i'll do a review of all the PRs in a day or so, been a bit swampped the past two days with work

…

On Mon, Mar 26, 2018 at 11:46 PM, David Feuer ***@***.***> wrote: @cartazio <https://github.com/cartazio>, there are a decent number of functions (largely in class instances) that are basically the same between Data.Primitive.Array and Data.Primitive.SmallArray, except for the *names*. I found myself copying definitions, then doing find and replace throughout their bodies. It was annoying. Have you had a chance to look at #109 <#109>? I'm leaving town tomorrow evening.... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwj_lhGBkQ0-3Kxy8_zTwiHKsO84qks5tibYIgaJpZM4S7o-_> .

[cartazio]

at least for now: lets not break / change any current naming conventions for Primitive. At least for preexisting modules

Perhaps it makes sense to relax it for newer modules, but that creates a nonuniformity in naming convention for both users and contributors.

i definitely think we have no good reason to wholesale rename all the current modules, this would accomplish nothing and needless break everything down stream with no real improvements.

So our choices are:
a) consistency but a teeny bit of extra verbiage (which allows mostly safe unqualified imports)
b) inconsistency (which also forces newer modules to be imported qualified)

After think about this for the past day or so, i remember'd we reexport everything in Data.Primitive

if we wish to continue to have this module be a good catch all for using all the data structures that Primitive provides, we must continue that slightly verbose convention despite the small cost of verbiage.

nothing precludes a wrapper package that exports stuff with the qualified names, but Primitive will not be that package.