search

polysemy-research / polysemy-zoo

:monkey::panda_face: Experimental, user-contributed effects and interpreters for polysemy
BSD 3-Clause "New" or "Revised" License
70 stars 20 forks source link

Guidelines for interpretations / contributions with large dependencies #19

Open cah6 opened 5 years ago

cah6 commented 5 years ago

This is somewhat related to https://github.com/isovector/polysemy-zoo/issues/16, but I was actually planning on asking before that issue, too.

My question is: do you have any thoughts / guidelines on a central location for user-contributed effects or interpretations, especially for those interpretations with large dependencies? I doubt you want to define any and all user provided interpretations in this zoo package, since it would probably end up with every Haskell package. But I think it's useful to have one place for people to browse packages, if only just because seeing a ton of examples helps me internalize the concepts and create my own.

For instance, say I interpret KVStore here in terms of the Elasticsearch bloodhound library, in my own repository. Where could people go to check if this was defined before making their own?

The easiest thing is probably just encouraging linking to other repositories in the readme of this repo, though some questions that might be worth thinking about even for this:

  1. should any library be allowed to be linked, or should it be reviewed by you first
  2. should any guidelines be enforced in them, for instance naming the package in some form (like polysemy-* or polysemy-effectName-interpretationName)
  3. Should any specific ordering of the links be stated up front, like grouping it by general effect type, then effect, then interpretations, etc
Avi-D-coder commented 5 years ago

What about keeping multiple packages in this repo. That way they get more eyes on them and are kept up to date.

Effects like @adamConnerSax 's RandomFu would not add dependencies, but would still be visible and tested against.

adamConnerSax commented 5 years ago

Fine by me. Though we should then remove the CanonicalEffect type-family or have some guidelines for when it can be used. Maybe only in this repo?

isovector commented 5 years ago

@Avi-D-coder I'm not opposed to this, but it still has a significant package maintenance burden that I don't particularly want on my plate! If someone else wanted to step up, I'd be more than happy to support them in that!

googleson78 commented 5 years ago

Is it a good idea for stuff like this to go under the polysemy-research group?