Algebraic Data Types

Re:Algebraic Data Types by dllthomas on Thursday July 31, 2014 @12:27PM (#8115042)

The way I was envisioning it, there needn't be any down-casting at the language level. Particularly if you want to close the sum type (which you need anyway if you want exhaustiveness checks):

   public static void test(MaybeFoo mf) {
      switch(mf.type) {
         case MaybeFoo.NOTHING:
             /* ... */
             break;
         case MaybeFoo.JUST:
             Foo f = mf.getFoo();

             /* ... */
             break;
      }
   }

Still has exhaustiveness checking and no downcasts. Still can throw if you use the wrong get* under one of those branches, so I'm certainly not saying it's ideal, but I think it legitimately expresses a sum type and can be implemented in most any language with small adjustments.

[ Parent | on HN ]

Re:Algebraic Data Types by theseoafs on Thursday July 31, 2014 @03:07PM (#8116275)

This is sort of a different way of saying the same thing: this is effectively no different from the standard tagged-union approach, with the exact same danger of calling the wrong `get` function and triggering a runtime error that you have in C et al. Don't get me wrong, it's certainly a valid representation of a sum type, but when you hear fans of Haskell and ML talking about how useful sum types are, it's generally because the compiler provides some support to ensure that they're safe and usable.

[ Parent | on HN ]

Re:Algebraic Data Types by dllthomas on Thursday July 31, 2014 @03:28PM (#8116408)

I think we mostly agree.

I would note that when I'm dealing with tagged unions in C, as soon as the operation gets at all complicated (more than maybe 3 lines?) I try to pass it off to another function operating on the internal value which restores safety outside the boilerplate. I agree that support for a true tagged union is ideal, though. (Actually, this might make a good attribute in GCC...)

[ Parent | on HN ]

Re:Algebraic Data Types by bjeanes on Thursday July 31, 2014 @01:29PM (#8115572)

I'd never thought about this before in the context of Java. IIRC, Java can not have type-parameterized enums (i.e. generic enums), so a Maybe<T> isn't possible. I hope I'm wrong — it's been a while since I did much Java.

[ Parent | on HN ]

Re:Algebraic Data Types by dllthomas on Thursday July 31, 2014 @01:51PM (#8115758)

Well, you certainly can by expanding the parameterization manually like I did above. I think you're otherwise correct, though - I don't think Java will presently do it for you.

[ Parent | on HN ]

Re:Algebraic Data Types by tel on Thursday July 31, 2014 @02:17PM (#8115934)

This works fine, it just suffers from boolean blindness.

[ Parent | on HN ]

Re:Algebraic Data Types by dllthomas on Thursday July 31, 2014 @02:35PM (#8116060)

Could you elaborate? I think I understand "boolean blindness" but I'm not sure how it applies here. MaybeFoo.type is deliberately an enum.

(I could totally be missing/misunderstanding something, though...)

[ Parent | on HN ]

Re:Algebraic Data Types by tel on Thursday July 31, 2014 @02:46PM (#8116135)

Checking whether mf.type is NOTHING or JUST is your boolean. It's linked by providence to whether or not getFoo() is a runtime exception. With a true ADT getFoo would not be accessible unless mf.type == JUST, but in this example it's up to the programmer to enforce that providence.

So that's the blindness. The pre/post conditions around how mf.type relates to its surroundings cannot be expressed first-class in the code. You are required to do risky things like call potentially partial code.

[ Parent | on HN ]

Re:Algebraic Data Types by dllthomas on Thursday July 31, 2014 @03:25PM (#8116386)

So it's specifically the separation of the check and the action? I totally agree this is undesirable; I understood "boolean blindness" to be closer to "bare primitive types lack meaning", specialized to Bool.

[ Parent | on HN ]

Re:Algebraic Data Types by tel on Thursday July 31, 2014 @03:56PM (#8116590)

I always think of it as your data types being too unrestricted so as to allow for invalid states. The eliminator for Maybe

    (a -> r) -> r -> Maybe a -> r

means you only access the `a` if it's there and the access/matching are inextricably linked.

So, I think "bare primitive types lack meaning" is basically correct given that you interpret "meaning" as "meaningful uses/actions".

[ Parent | on HN ]

Re:Algebraic Data Types by dllthomas on Thursday July 31, 2014 @04:10PM (#8116683)

Yeah, given the nature of the types involved here, I think the two concepts I was trying to distinguish are not as far apart as I'd thought.

[ Parent | on HN ]