Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think discriminated unions may simply be the wrong tool for parts of this job. Just because you are writing functional code doesn't mean you should throw out everything you know.</p> <p>Discriminated unions are (in some ways, and there is kind of a caveat to this) the inverse of inheritance(derived types), we could call them composed types.</p> <p>In derived type models everything about the parent is guaranteed to be true about the children(LSP), in this composed type model everything about the children is guaranteed to be true about the parent.(i.e. instead of "new dog : animal, new cat : animal, it's new Dog, Cat : CatDog, so you get a new construction of all statements that are true about cats AND dogs. Think of it as the intersection of all statements about both cat and dog.) </p> <p>So the question then becomes, "how do we work with derived types in OCaml?" Well, the "O" in there does stand for object...</p> <p>I would suggest you create an object model with derived types for your shape heiarchy, as you have a top type(shape) and a bottom type(the empty shape,or null). And then you compose your ADT's out of those objects, so you have </p> <p>abstract Shape , Circle : Shape, Rectangle : Shape,</p> <p>Then you have</p> <p>type ShapeProperty = | Foo of Shape | Bar of Rectangle | Blah of Circle;;</p> <p>Anything that knows about a shape property has to be able to handle all three of those cases(reasonable since that's what you have it for), and circle and rectangle are assignment compatible to shape, so you don't have to worry about boxing conventions.</p> <p>For what it's worth, YMMV etc. Haskell (the other major ML dialect running around) doesn't use objects for derived types, it uses what are known as "type classes" which are collections of properties/behaviors that you "derive from" and "guarantee an implementation of" thereby allowing a function to take in a concrete instance of a type class.</p> <p>While much more functional in it's philosophy, trying to figure out what's going on gives me a headache since the conventional abstractions I use for object like constructions no longer apply, and I have to use these constructions that are logically equivalent, but semantically substantially more unusual(although I know a lot of people who use them to great success, so it might just be my own failings).</p> <p>Note on the caveat, since tagged unions are tagged, all you have to do is guarantee a semantic action for all tags. That action could be "failwith 'why are you giving me one of those, I have no idea what to do with it'". The problem as you noticed with this construction is that you lose a lot of the really cool aspects of type safety in doing so. For example, you write a function that takes in an option int, and then if the option is nothing you throw an exception, well, why did you say you knew how to handle an option int?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload