begriffs / haskell-vim-now

One-line Haskell Vim install
MIT License
988 stars 100 forks source link

Use Haskell instead of bash #249

Closed jship closed 7 years ago

jship commented 7 years ago

@begriffs: Interested in converting usage of bash to Haskell? This commit implements the vast majority of functionality: https://github.com/jship/haskell-vim-now/commit/d608a71ae84cf22c57891b12f0d7432c5e4256a2

My main motivation for doing this was to bring haskell-vim-now to Windows and there are other advantages besides Windows support:

  1. Type safety
  2. Installer speed - helper binaries are installed much quicker via dependency filtering, way easier to do in Haskell than in bash
  3. Access to all packages in Stackage snapshots - this was nice for stache, ansi-terminal, mtl, etc.

This would definitely take additional iterations and community testing to ensure it is feature-complete with the bash scripts. Also have a handful of TODOs that should be resolved for it to be as rock-solid as can be. Maybe the Haskell version could be mentioned as "in beta" in the readme?

I saw an old issue (#131) where @SX91 was interested in this. Since then, Stack 1.4.0 has made Haskell scripting much nicer, and the Turtle lib is great to work with.

hvn_gvim
begriffs commented 7 years ago

Been meaning to comment on this, sorry for the delay. Pretty cool that you got it rewritten like that. I feel kind of like a heretic, but have to admit that I'm not sure the Haskell version looks easier to understand than bash. Maybe if the main logic happened at the start and then functions came later it would orient me better to the code.

jship commented 7 years ago

I agree that using bash is more readable as there's no layer between the script and the shell commands. Turtle does a great job of making scripting nice in Haskell, but there is still a noticeable divide. :)

The code is set up to parallel the existing bash scripts, so I kept most function names the same just with Haskell's casing conventions. The big difference is that it's all in one script instead of split across multiple files. Wrote this very much in a "bang out the code" mentality, so there are places where it could be refactored for readability/cleanliness.

Supporting Windows is what led me to do it in Haskell and am open to any language really.

begriffs commented 7 years ago

Agree that the windows support would be nice. By the way, does the rest of the vim configuration work OK on windows once the installer is done? Have you given it a try?

jship commented 7 years ago

Things work from my testing - ghc-mod, codex, autocomplete, compile check, hlint, git stuff, ctrlp, nerdtree, comment selection, etc. I haven't done an exhaustive test of every config though.

There are some caveats/TODOs I've marked via comments in the script. Would want to resolve those, and might be something the community can help with?

Plugin install is fine, but there is some weirdness around upgrading plugins. vim-plug seems to be able to download new plugin versions and it might still work, but it throws an error on accessing a temp directory.

I'll need to set up my fork to run the install on Travis. Haven't tried the script on non-Windows platforms yet.

jship commented 7 years ago

I might be radio silent on this for a week or so. ZuriHac's next week - woo!

begriffs commented 7 years ago

Hope you're having fun at ZuriHac.

So I've been thinking more about the Haskell installer. Another argument against it is that fewer people will be able to easily contribute fixes. I'm imagining people who want to learn Haskell installing haskell-vim-now and being able to contribute to the Bash script if something goes wrong but having more trouble contributing to a Haskell installer.

On the other hand, there was that recent bug in the installer due to the treatment of booleans which was totally a type error that would never happen in Haskell. Maybe we want to practice what we preach and use Haskell... I think the code should be consciously written in a very approachable style though.

How about opening a pull request with your work in progress so we can discuss in greater detail?

jship commented 7 years ago

Will do, thanks!

EDIT: PR is #253

jship commented 7 years ago

I think the code should be consciously written in a very approachable style though.

Completely agree. I used a MTL-style for this and am fine changing this up if it would make it more approachable. Most functions have MonadIO as a constraint anyways, so we could just as well use IO directly or use plain transformers with no MTL typeclass constraints.

jship commented 7 years ago

Closing this as we want to gradually introduce Haskell and see how it goes along the way. For more on this discussion, see #253.