Haskell libraries to switch to

[fosskers]

Aura is two years old now, and some libraries have since moved on. Others have better replacements. This is a list of libraries that should be switched to:

1. wreq. Simpler than http-conduit, and uses Lenses.
2. aeson. A lot better than the json package, which is quite out of date by now.
3. aeson-pretty for changing how backup data is stored.
4. text Text is modern and more performant. Also, parsec can work with Text.
5. optparse-applicative Use applicatives for commandline args.
6. semigroups Provides Data.List.NonEmpty. This would be good to have after initial dep checks are done.
7. semigroupoids For Monoidal Functor typeclasses, among others.

I'm up for suggestions.

[blaenk]

text and aeson would be cool. Don't know much about the others.

[nc6]

I would definitely recommend optparse-applicative rather than cmdargs.

[fosskers]

@nc6 I like it. Adding.

[mmhat]

How about an alternative Prelude ?
Something like classy-prelude or basic-prelude.

[aspidites]

Rationale for classy-prelude (which depends on basic-prelude). At a cursory glance it looks like we'd be adding a bunch of dependencies for the sake of convenient imports. I'm sure I'm missing something obvious, @withhat, which is why I'm asking.

[fosskers]

I like classy-prelude. @aspidites There's motivation in easy imports of typeclasses and identically-named prelude functions (map, fold{lr}, etc) from mono-traversable. That package provides a merging of Mono- and Polymorphic structures and allows us to call the same functions on all of them (that is, map == fmap for any Functor, and whatever it needs to be for Monomorphic structures like Text). This is something that Scala does well already. We just call map and that's the end of it.

[aspidites]

That does sound nice, in particular the bit about not having to qualify my use of map, fold, etc.

[bb010g]

I'm thinking more about a custom one that has more ties to semigroupoids.

[fosskers]

Should we roll one? A monotraverable-like that pulls from semigroupoids?

Or should we just alter monotraverable?

[bb010g]

I think an alteration would probably be safest; I'll start on one after I finish configuring NixOS (it's seriously awesome (enough to pull me from Arch :D)). I've noticed quite a few Prelude functions that could be generalized but aren't in classy-prelude (e.g. iterate on Monoid Applicatives).

[fosskers]

Nice, it would be a good thing to have.

[bb010g]

Dyre looks like it could help on the config front.

[fosskers]

Dyre looks good, but would it give us the ability to do recompiles without any haskell dependencies? (that is, in a temporary cabal sandbox).

[aspidites]

One issue I had with dyre when I was playing with it (using yi I think) was
thatca bad config rendered the program unusable. Since its recompiling,
there wasn't a way to just reset to default values.
On Jul 28, 2014 3:36 PM, "Colin Woodbury" notifications@github.com wrote:

Dyre looks good, but would it give us the ability to do recompiles without
any haskell dependencies? (that is, in a temporary cabal sandbox).

—
Reply to this email directly or view it on GitHub
#223 (comment).

[fosskers]

Let's make sure to include a "reset to default" option.

[fosskers]

extensible-transformers?

This seems to be a hot topic.

[bb010g]

The main problem I see (it may not actually be there) is that extensible-transformers still uses the transformers stack internally, and that could hit performance more than, say, effin. I'm not sure though, so don't quote me. :)

[fosskers]

I wish there were a guide for effin.

[fosskers]

Let me take the opportunity to say this:

The Aura Monad is convenient as it gives us "the Monad" to work with through any point in our program. This keeps mental overhead low. However, some problems I've found are:

1. Testing: It's annoying to do one-off tests on functions in the Aura Monad, as you have to boot up the entire Monad stack to do so. This means creating feux-Settings, running it, and unwrapping the results.
2. IO: Some functions need Settings, and possibility ErrorT-like short-circuiting (with >>=), but don't need IO. Yet in the Aura Monad, they can do IO arbitrarily. This isn't as conceptually clean as I'd like it (functions should always strive for as much purity as possible). In hindsight, this probably could've been mitigated with more careful use of Monad Transformers (ie. just using ReaderT for bash parsing, etc).

Whatever we decide, we should keep in mind that Hook writers will appreciate a simple API. They need to be able to see function signatures and understand the constraints they're writing under. The question is, which effects library will give them that?

[aspidites]

"Support for GHC 7.6. This will require very extremely heavy abuse of OverlappingInstances, but it can be done."[1] - That makes me nervous. Haskell Platform featuring 7.8 won't be released until August, and even then, I suspect it will be a while before it becomes standard everywhere. I guess as the first target will be Arch, this isn't a big deal, but I can see this becoming a problem if we decided to support Debian's package manager.

[1] https://github.com/YellPika/effin

[fosskers]

The goal is to take over all of GNU/Linux, so we should do what is most compatible.

[bb010g]

@aspidites I'm pretty sure that's old, as I loaded it just fine in a new GHC.

[aspidites]

out of dat documentation also makes me nervous ;-)

On Tue, Jul 29, 2014 at 9:07 PM, Brayden notifications@github.com wrote:

@aspidites https://github.com/aspidites I'm pretty sure that's old, as
I loaded it just fine in a new GHC.

—
Reply to this email directly or view it on GitHub
#223 (comment).

Regards,
Edwin O Marshall (aspidites)
http://github.com/aspidites https://github.com/aspidites
http://bitbucket.org/aspidites https://bitbucket.org/aspidites
http://www.assembla.com/profile/aspidites?public=true

[aspidites]

Er....date
On Jul 29, 2014 9:25 PM, "Edwin Marshall" emarshall85@gmail.com wrote:

out of dat documentation also makes me nervous ;-)

On Tue, Jul 29, 2014 at 9:07 PM, Brayden notifications@github.com wrote:

@aspidites https://github.com/aspidites I'm pretty sure that's old, as
I loaded it just fine in a new GHC.

—
Reply to this email directly or view it on GitHub
#223 (comment).

Regards,
Edwin O Marshall (aspidites)
http://github.com/aspidites https://github.com/aspidites
http://bitbucket.org/aspidites https://bitbucket.org/aspidites
http://www.assembla.com/profile/aspidites?public=true

[bb010g]

Out of date documentation can be fixed more easily than out of date code. :)

[fosskers]

The README doesn't seem any older than the code itself (checked the Blame on the README.md).

[fosskers]

Is there an easy way to get into effin?

[bb010g]

I'd think just pulling it down and trying some code after reading the paper from Oleg et all.

[fosskers]

I'll give that a whirl then.

[bb010g]

Here's the first version of my labours: https://github.com/bb010g/yapp/
Once set up, you should just be able to do:

{-# LANGUAGE RebindableSyntax, ConstraintKinds #-}
import YAPP

Share and enjoy!

Also, a bit off-topic, but how does the idea of using #aura on Freenode for discussion sound?

[aspidites]

👍 for #aura. @bb010g , any chance you could add why it's more "magical" to the readme along with an example of how to use it?

edit: Glancing at the source file it mostly makes sense. I think examples are still nice. That whole advertising and being friendly to noobs thing...

[bb010g]

@aspidites I'm still working on putting in documentation and fixing some things as I try it out. Examples will be added. The README is a placeholder until I get closer with the main source. I just wanted to get it out sooner than later.

[fosskers]

@bb010g Awesome! That'll be really nice to have. I take it yapp is the only polymorphic prelude based on semigroupoids?

[bb010g]

@fosskers AFAIK.

[fosskers]

You're a pioneer, then.

[aspidites]

A bunch of good tips in these slides

[fosskers]

Thanks for those slides.

[mrak]

optparse-applicative currently doesn't allow short flags to be specified together, a la -Syu 😞

There is an open PR for it, though:
pcapriotti/optparse-applicative#123

[fosskers]

My experimentation with it here would indicate otherwise.

I see what you mean now. My initial reading was "it doesn't allow short flags".

[mrak]

You got me excited there for a moment; I was feverishly looking through your playground to see what I was missing!

[fosskers]

Haha my bad. Well at least the maintainer of the library says he'll be adding it.

[fosskers]

optparse-applicative does allow pacman-style flags now.