Data Constructors and Readability

I think I’ve put my finger on one reason I’m finding Haskell hard to read. Consider this algebraic data type definition from Real World Haskell:

data Doc = Empty
         | Char Char
         | Text String
         | Line
         | Concat Doc Doc
         | Union Doc Doc
         deriving (Show, Eq)

There’s no distinction between the value constructor and the components of the type. This is especially critical when the constructor and the components have the same name as in the Char constructor above. It also doesn’t help that they have the same naming convention (mixed camel case, initial uppercase letter).

A Java class with multiple factory methods or multiple constructors would be much more verbose, but much more readable. Humans need redundancy, even if it’s logically superfluous.

I suspect a language that retained Haskell’s semantics, but completely replaced the syntax with something more usable, legible, and familiar would have a much greater chance of success.

13 Responses to “Data Constructors and Readability”

  1. John Cowan Says:

    Well, you have to remember that what you call “legible” is what other people call “illegible”.

    Readers, it’s a myth that ERH writes Java. What he actually writes is this:

    <class visibility="public" name="Fibonacci">
      <method visibility="public" modifiers="static"
           returnType="long" name="fib">
        <argument type="int" name="n"/>
        <if>
          <lessThan>
            <variable name="n">
            <integerLiteral value="1">
          </lessThan>
          <return>
            <variable name="n">
          </return>
          <return>
            <add>
              <subtract>
                <variable name="n">
                <integerLiteral value="1">
              </subtract>
              <subtract>
                <variable name="n">
                <integerLiteral value="1">
              </subtract>
            </add>
          </return>
        </if>
      </method>
    </class>
  2. Anonymous Says:

    Can you post the Java equivalent of the Doc data type defined above?

  3. Elliotte Rusty Harold Says:

    Java doesn’t have algebraic data types and pattern matching as such, so there these would probably be subclasses. E.g.

    public abstract class Doc {
    }
    
    public class Empty extends Doc {
    }
    
    public class Text extends Doc {
    
      public Text(String s) {
      }
    
    }
    

    and so forth. This isn’t ideal because this isn’t how you’d solve this problem in Java.

    However if one were to imagine a true Haskell equivalent that used Java-like syntax but Haskell semantics you might see something like this:

    datatype Doc implements Show, Eq {
      
      constructor Char (Char c);
      constructor Text (String s);
      constructor Line();
      constructor Empty();
      constructor Concat(Doc d1, Doc d2);
      constructor Union(Doc d1, Doc d2);
    
    }
    

    That could mean exactly the same thing as the actual Haskell; but I for one would find it much easier to read. Yes, it takes a little longer to type, but ease of reading trumps ease of typing.

    Of course we could play with the exact keywords. Maybe adt or data instead of datatype; maybe new instead of constructor, but you get the idea.

  4. Michael Day Says:

    Try Mercury: like Haskell, but more parentheses :)

    :- type doc
        --->    char(char)
        ;       text(string)
        ;       line
        ;       concat(doc, doc)
        ;       union(doc, doc).
  5. Michael Day Says:

    …and my nicely formatted <pre> has been mangled, sigh.

  6. Elliotte Rusty Harold Says:

    I fixed your comment. I think you have to register to be allowed to use HTML, but I turned off registration a few months ago because no one did, and a security hole had been found in it. Let me turn it back on and see what happens.

  7. elharo Says:

    OK, Let’s see if this works:

    This is some
    preformatted
    text
    so much depends on
    a red Haskell
    furiously thinking
    green thoughts

  8. elharo Says:

    Nope, that didn’t work.

  9. elharo Says:

    OK. The problem isn’t registration. It’s that pre is specifically disallowed (more accurately, not specifically allowed). let me see if I can fix that.

  10. Elliotte Says:

    Let’s see if this works now:

    so much depends on
       a red Haskell
         furiously thinking
            green thoughts
  11. Elliotte Says:

    Aha! It worked. Everyone should be able to use pre here now. I’ll to make the same change on the Cafes.

    Thanks for the nudge.

  12. Elliotte Says:

    I should probably set the stylesheet not to make pre text bold though…

  13. zenlang Says:

    ERH,
    Very interesting post, loved it! I too tried to learn Haskell in the past, and totally understand your post.

Leave a Reply