Are there real advantages to the SomethingIO type synonyms?

[d3adb5]

I noticed in Core.Object there are some type synonyms for IO Commit, IO Tree and IO Blob. Are there any advantages to seeing CommitIO over IO Commit? Personally I think it just adds needless indirection, making the code a little harder to digest.

What do you think?

[lucasoshiro]

@d3adb5 I don't think so... It was only a convenience, because I was trying to prioritize the use of CommitIO, TreeIO and BlobIO over Commit, Tree and Blob, and this somehow was easier for me to read instead of using IO Commit, etc everywhere.

By now I think we can replace them.

[d3adb5]

IMO IO Commit makes more sense to the Haskell trained eyes. Not that I have them, but it's less indirection at the very least. --- no need for anyone to read the type synonym later on to discover that CommitIO is just IO Commit.

[lucasoshiro]

Git itself works with files every time, as it is, basically, a bunch of commands that manipulate the .git directory. I think it is easier to model in C or any other language that doesn't have its IO so decoupled as Haskell.

My idea here in prioritizing the use of IO * instead of >>=ing to functions that manipulate Commit, Tree or Blob is that we can take advantage of the laziness, reading the files of if and when we need them.

[d3adb5]

That makes sense, but I'd much rather see something like IO Commit at the end of the type signature of function (actions) that produce a Commit.

[lucasoshiro]

Hi @d3adb5! I've just replaced it here: #9. Seems to be working, and it's much more elegant