Newest at the top
| 2025-01-16 02:14:04 +0100 | <jackdk> | Knowing little about your problem space, and having tremendous respect for Ed's library design sensibilities, I would lean towards following `ad` as a model over `regex-*` since it sounds closer to what you want to do. Note also that the Kmettverse of category-theory-flavoured packages started as a single `category-extras` package that was split when it became too large |
| 2025-01-16 02:12:52 +0100 | <haskellbridge> | <sm> if you unnecessarily proliferate packages and it's not providing real benefit, I promise some day as maintainer you will rue the day |
| 2025-01-16 02:10:53 +0100 | <jackdk> | Especially if the "experimentation phase" means "add and benchmark them all" and that's something that most users will want to do. |
| 2025-01-16 02:10:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-16 02:10:37 +0100 | <haskellbridge> | <sm> but YMMV and you can always split up the package later as jack says |
| 2025-01-16 02:10:24 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-16 02:10:19 +0100 | <haskellbridge> | <sm> especially if they're going to be comparing implementations as you say |
| 2025-01-16 02:10:01 +0100 | <haskellbridge> | <sm> most users will rather pull one simple package than have to think about which variant they need |
| 2025-01-16 02:09:49 +0100 | <jackdk> | sm: +1 |
| 2025-01-16 02:09:35 +0100 | <jackdk> | 70kLoC is about 4× the size of `lens`. I don't understand numeric code well enough to know whether that's a reasonable size for a library or library family. My advice would be to upload a monopackage to a public forge site, hold off on the Hackage release while you get users and see where the convenient cuts are, and split if necessary. |
| 2025-01-16 02:09:16 +0100 | <Guest71> | jackdk: yet, what you say about the regex package is what I imagine my users thinking: I just want the implementation X, don't make me pull Y if I'm not going ot use it |
| 2025-01-16 02:09:04 +0100 | <haskellbridge> | <sm> I think we're advising a cautious less is more approach: yes start with one repo and one package, on github (eg); get a sense of how this will work; if it seems ok, publish that to hackage |
| 2025-01-16 02:08:05 +0100 | <Guest71> | sm: they implementations should be transparently interchangeable so they should have the same dependencies and build under the same stack. |
| 2025-01-16 02:06:34 +0100 | <Guest71> | jackdk: so your are advising to publish a monopackage and split later is users want it? |
| 2025-01-16 02:06:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 02:03:55 +0100 | <jackdk> | IME it is harder to take back over-engineered solutions than it is to add smarts where it's needed. I would start with (for example) a package for calculating "logarithmic expressions" and put them all in there. If you need to split the package later, you can then extract an interface and create several implementations, but the reverse is harder: you can't un-claim a package in the Hackage namespace. |
| 2025-01-16 02:03:38 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Quit: Lost terminal) |
| 2025-01-16 02:03:02 +0100 | <Guest71> | jackdk: From skimming the summary that looks exactly like the kind of project I'm developing |
| 2025-01-16 02:02:53 +0100 | <haskellbridge> | <sm> if the different packages have heterogenous dependencies, such that some of them may be hard to build on certain platforms / with certain GHC versions, that could be a reason to segment. If the deps are the same for all of them, and the only issue is downloading unused code.. that's not a big cost |
| 2025-01-16 02:01:20 +0100 | <jackdk> | OTOH, I consider it a good thing that all the different regex engines in the `regex-*` universe are in different packages, because you usually just pick one (either TDFA or PCRE) and stick with it. I wouldn't use `regex-base` as a guide for how to design an interface usable by multiple implementations, though. My head spins every time I look at it. |
| 2025-01-16 02:00:37 +0100 | <Guest71> | The interface is actually remarkably boring, and by far the least important part. It only exists because I want my users to be able to swap implementations transparently and benchmark the differences for their workloads easily to make a more informed decision. |
| 2025-01-16 02:00:35 +0100 | <haskellbridge> | <sm> +1 |
| 2025-01-16 01:59:41 +0100 | <jackdk> | I'm reminded of https://hackage.haskell.org/package/ad which has a bunch of different automatic differentiation methods in a single library. If the scope of each operation is relatively small, a similar approach may serve you well. It can be annoying to ask your users to go back to their cabal file and re-jig their build just to experiment with another implementation of the same method. |
| 2025-01-16 01:57:33 +0100 | <haskellbridge> | <sm> good idea! validate your repo/package organisation a little before committing to hackage uploads |
| 2025-01-16 01:57:00 +0100 | <Guest71> | As an example: there are many ways to compute a logarithmic expression. So, you have different sub-projects that implement the different ways. Depending on your algorithm or problem as a user of the library, you may prefer one or the other. Maybe you have different use-cases, and you want to use more than one. |
| 2025-01-16 01:57:00 +0100 | <Guest71> | The interface is a collection of numeric operations and the implementations are well... different ways to implement each of them. |
| 2025-01-16 01:55:31 +0100 | <jackdk> | At this point I'm not sure I know what questions to ask. I will point out that you can soft-launch a package by uploading it to a public repo and working from there. Both Cabal and Stack let you pull in code from git repos, and then hopefully you can attract more users and find out what splits they're looking for |
| 2025-01-16 01:55:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-16 01:54:48 +0100 | <ColinRobinson> | 'unit of compilation' is the clear but you generally only see that in specs |
| 2025-01-16 01:52:42 +0100 | <jackdk> | I was planning on getting an idea of the problem you are trying to solve, because my head is in the HTTP API space by default. I don't know much about numeric code and how people expect it to be organised. |
| 2025-01-16 01:52:22 +0100 | <Guest71> | Or rather, just tell me what information you would like about the project. |
| 2025-01-16 01:51:33 +0100 | <Guest71> | jackdk: were you planning to look at the repo? |
| 2025-01-16 01:50:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:50:09 +0100 | JuanDaugherty | ColinRobinson |
| 2025-01-16 01:50:04 +0100 | <Guest71> | JuanDaugherty: sorry, I'm not sure what you meant by that (re: namespaces being just namespaces) |
| 2025-01-16 01:49:11 +0100 | <Guest71> | It's a numeric library |
| 2025-01-16 01:49:06 +0100 | <Guest71> | It basically combines a bunch of numeric interfaces and add some other stuff on top |
| 2025-01-16 01:48:40 +0100 | <Guest71> | I'm currently in the process of trying to publish it, hence this conversation :) |
| 2025-01-16 01:48:15 +0100 | <Guest71> | Oh, sorry, it isn't public as of right now. |
| 2025-01-16 01:47:44 +0100 | <JuanDaugherty> | can a namespace just be a namespace? names r powerful, their rectification is a whole deal |
| 2025-01-16 01:47:38 +0100 | <jackdk> | Ideally a link to a high-level API page. So far I have found a page on cloud-based aged care software and a PDF report from a consultancy about Smart Meters for the Australian Energy Market Commission. Please, help us help you. |
| 2025-01-16 01:47:13 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8310:6e2:3d63:5127) (Ping timeout: 248 seconds) |
| 2025-01-16 01:46:13 +0100 | <Guest71> | Though I imagine you were hoping for something descriptive |
| 2025-01-16 01:45:51 +0100 | <Guest71> | jackdk: it's called Nera |
| 2025-01-16 01:45:08 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-16 01:44:49 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-16 01:43:45 +0100 | <jackdk> | At least its name, I mean. |
| 2025-01-16 01:43:37 +0100 | <jackdk> | I think knowing the specific interface would be extremely helpful, if you can provide it. |
| 2025-01-16 01:43:21 +0100 | <JuanDaugherty> | "module" is more of a construct and often enough contentious, eg. in prolog |
| 2025-01-16 01:42:59 +0100 | <Guest71> | The project originally had a form of Foo.Iface, Foo.Bar.Baz1, Foo.Bar.Baz2, Foo.Bar.Baz3... all the BazN modules implement the Foo.Iface |