Doesn't Hindley-Milner allow us to forego ObjectIO?

[d3adb5]

Haskell's type system is robust enough for types to be inferred in almost every case, and I feel that it makes sense to have loadObjectLegacy :: Object o => Hash -> IO o be the standard way to load an object. The reason for that is that if the output of this action is fed into a function that is expecting, say, a Commit, it's objectParse :: ByteString -> IO Commit that will be called.

However, given the Legacy suffix here, I imagine the functions that use the new data ObjectIO = ObjectIO BlobIO ... type were created out of necessity. What is the practical advantage when loadBlob, loadTree and loadCommit need to be specified? Moreover, would it not be simpler to define the type as follows?

data ObjectIO {
  asBlob   :: IO Blob,  -- implicitly defines: asBlob   :: ObjectIO -> IO Blob
  asTree   :: IO Tree,  -- implicitly defines: asTree   :: ObjectIO -> IO Tree
  asCommit :: IO Commit -- implicitly defines: asCommit :: ObjectIO -> IO Commit
}

Then when someone wants to load a Blob given its Hash, they can call asBlob $ loadObject hash, and any actions that would take a generic object but for whatever reason "specialize" it can directly use these record functions:

hypotheticalAction :: ObjectIO -> SomeOtherType
hypotheticalAction oio | someAssertion = doSomethingToCommits $ asCommit oio
                       | somethingElse = doAnotherSomething $ asTree oio
                       | otherwise = notTooSure $ asBlob oio

Any way we go, the question boils down to: what necessitated ObjectIO on top of the "legacy" loadObject :: Object o => Hash -> IO o?

[lucasoshiro]

Whoa, this decision was made three months ago, I'm trying to remember what I was my motivation. I couldn't find it so far 😁...

Well, I am always revisiting how to model this in Haskell, as it is more challenging than I would do in other languages. Here, my biggest challenge is how to deal with reading objects from the disk, as Git itself is a bunch of commands for manipulating files...

What I would do in an OOP language, for example, Java (sorry), is hide everything under some classes and methods, something like:

abstract class Object {
   private static ObjType getObjType(ByteArray raw) {
       // something that parses the header of the object and return its type
   }
   
   static Object loadObject(Hash hash) {
      ByteArray raw = loadRawObject(hash); // This reads the object file and uncompresses it
      ObjType type = getObjType(type)
      
      switch (type) {
      case CommitType:
          return Commit(raw);
          break;
          
      // same for blob and tree
   }
}

class Commit extends Object {
    String author;
    String message;
    // and so on

    Commit(ByteArray raw) {
        this.author = ...;
        this.message = ...;
    }
}

Of course this is not possible in Haskell, due to the IO...

So, this is the problem: I need to first read the object header to find its type, then parsing it into a internal Blob, Commit or Tree. Maybe we can replace this ObjectIO mess by specifying the types everywhere. I'll try to do that and then I'll see if it works.

[d3adb5]

The way I see it, the loadObjectLegacy :: Object o => Hash -> IO o is flexible enough. This is what would happen if we were to have a function of type Commit -> SomethingElse defined as such:

ourFunction :: Commit -> SomethingElse
ourFunction c = something (foo c) (bar c)

If we were to use it in a do block within IO (assume OverloadedStrings):

main = do
  commit <- loadObjectLegacy "abc123ff"
  return $ ourFunction commit

Reading from top to bottom, to compose the thunk for commit we can do some beta reduction:

main = do
  commit <- loadRawObject "abc123ff" >>= objectParse
  return $ ourFunction commit

But which objectParse? It's a member of the Object typeclass, so we must take its implementation from an instance. To know the instance, we need to know the type. To attain monomorphism, Hindley-Milner will look at ourFunction commit. Some pseudo-Haskell:

ourFunction :: Commit -> SomethingElse
--- therefore
(ourFunction commit) :: SomethingElse
--- and
commit :: Commit

In the scope of main, we must have imported a type class instance for class Object and type Commit, so we have our answer: objectParse comes from such an instance and the right functions are called.

Let's say it didn't matter whether it was a commit or not:

doSomethingToAnObject :: Object o => o -> SomethingElse
doSomethingToAnObject = convertStringToSomethingElse . objectPretty

Now specialization happens the other way around and it's only when we need this SomethingElse that it matters what the type of the original argument was. If we can't infer the type up until we pass it to doSomethingToAnObject, we'll have an ambiguous type variable with no solution. The following example code displays this behavior. Try compiling it:

class Example a where
  fauxFunction :: a -> String
  reconstruct :: String -> IO a

data Example1 = Example1
data Example2 = Example2

instance Example Example1 where
  fauxFunction _ = "Example1"
  reconstruct _ = return Example1

instance Example Example2 where
  fauxFunction _ = "Example2"
  reconstruct _ = return Example2

doSomething :: Example a => a -> String
doSomething = fauxFunction

main :: IO ()
main = do
  example <- reconstruct "Example1"
  print $ doSomething example

This is equivalent to having an interface Iface in Java, a function that returns some Iface, and a function that uses a method from Iface without a default definition. It's just not possible, because in Java this function that returns an Iface needs to know exactly what to return, which must be of concrete type.

I personally don't think this will be a problem moving forward, and would even say we can ditch objectType from the Object type class, delegating that to the very type system.

[lucasoshiro]

Whoa, thanks for the class!
So, I removed the ObjectIO mess in #9, it looks ok. Perhaps I need to test it more.

I personally don't think this will be a problem moving forward, and would even say we can ditch objectType from the Object type class, delegating that to the very type system.

Whoa, indeed. I'll try to do that later.