Does anybody have an insight on how this workflow interacts with GitHub? I feel like the next step I’d like is sending each of my patches to a different pull request (independent, if possible).
I’m actually writing some tooling to make that possible, but the workflow proposed by stgit feels to close to what I want that I’m wondering if I’m not reimplementing something that exists.
I think what you would do with stgit is work on a master/devel branch + a stack of your patches. When you are ready to do a PR you go “stg publish my-pr-branch; git push github my-pr-branch” to make a branch you can use the github UI to do a pull request with. To update your PR branch after feedback I think you need to republish.
Unfortunately for that workflow, stg publish doesn’t support force pushing directly to a remote branch, which I think would be quite cool. instead i think you need to rerun stg publish + git push.
Ok, I just sent a pull request to stgit that makes the github workflow work better.
With this patch you can do something like stgit publish --overwrite some-pr-branch && git push -f some-pr-branch and it will get your current patches into a github pr. Without my patch it creates a new commit each time you update things.
stgit publish --overwrite some-pr-branch && git push -f some-pr-branch
You will need to manipulate the stack of patches before each publish command to hide patches you don’t with to publish, I am pretty sure something like stg pop dont-want && stg publish will work.
stg pop dont-want && stg publish
This looks extremely interesting, especially considering I’m currently working on an implementation of a variant of nix for working with batch computation. It would be interesting to see what it looks like to define the derivations in Expresso.
The presenter mentioned the possibility of boilerplate being massively reduced due to removing the need for many type definitions, almost everything can be inferred by usage with the compiler screaming at inconsistencies.
Time for some nitpicking! You actually just need a Semigroup, you have no use for munit, and it’s pointless to append the list with munits, since mplus a munit = a by the monoid laws.
mplus a munit
Your comment reminded me of Data.These: since we don’t pad with mempty values, then there a notion of “the zip of two lists will return partial values at some point”.
And that led me to Data.Align, which has the exact function we are looking for:
salign :: (Align f, Semigroup a) => f a -> f a -> f a
(that weird notion was align :: f a -> f b -> f (These a b))
align :: f a -> f b -> f (These a b)
Yeah this is exactly it. Good eye!
It’s funny, because I think I poked the universe in a way that resulted in salign going into Data.Align; A year or so ago, someone mentioned malign in a reddit r/haskell thread, and I pointed out that malign only needed Semigroup and one of the participants in the thread opened an issue requesting a malign alternative with the Semigroup constraint.
Now I feel like a Semigroup evangelist :)