OCaml as my primary language

PS rereading this I think "hope you're a Haskeller" might be read as an insult. That's not my intention, here's why I mention Haskell.

1. It's THE other language with a type system based on HM.

2. Variant constructors as functions. OCaml does not do that, Haskell does (slightly more elegant). This hints sunnydiskincali is more familiar with Haskell than OCaml.

3. I was confused by `type shape = S.shape`. How does `RemovePoint(Shape).shape` has the `Point` case removed then? I tried that on a REPL ^1 and it didn't even compile. Again, syntax errors hinting at Haskell experiences.

Well now I've written so much I may as well do a point-by-point refutation: ^2

> you create the ability to side-step exhaustiveness

Big claim, sounds scary to someone not familiar with sum types. But Java/Kotlin both enforce exhaustiveness. You could have provided an example in your second response, instead you dump a bunch of code that does not compile.

> Sure you can, that's just subtyping.

Then you followed up with an example that is not subtyping, but an unrelated type of a new set of new values.

> This is doing things quick and dirty. For this trivial example it's fine

This is not fine. I undersold the verbosity of your "quick and dirty" solution saying "7 lines". To actually work with those two types, the pair of conversion functions `Shape.shape -> Bound.shape option` and `Bound.shape -> Shape.shape` is needed.

> They're not similar at all.

~100 words in the paragraph, gestures to formalization, yet never explained how sum types implemented as sealed inheritance cannot be "enforcing valid program-states at a type-level". Thus my comment "a lot of words to say very little".

> You're still creating a type

I see you removed "unrelated" in an edit. The statement is now accurate but pointless. Of course I need to create a type, how else can I use the type system to say "this function won't return a point"?

> disingenuous to imply the quotation means that the type-system in Java ... was lifted from ML.

It would be more than disingenuous, colossally stupid even, if I did imply that. The wrongness would be on the level of claiming "English and Japanese are in the same language family".

Your cognate/false friend analogy is much smaller in scope, just like Java taking sum types (implementing them as sealed inheritance) from ML.

1: https://ocsigen.org/js_of_ocaml/toplevel/

2: https://xkcd.com/386/

I'm very embarrassed to say this. Those code examples weren't non-compiling OCaml, but valid SML. Once I remembered the existence of the language (in my defence it was never mentioned in the thread), I managed to compile the code, and confirm my suspicion:

`val point: Bound.shape = Shape.Point` type-checks, because `type shape = S.shape`. To drive the point home, so does

    val DoesNotReturnPoint : Shape.shape -> Bound.shape = fn x => x

So the module example does not show "this function won't return a point" as one would have hoped.

I certainly can’t say whether this is idiomatic as I was working it all out myself. But I’d basically write a type for each operation (as I’d read elsewhere). And honestly this was a bit of a drag too. I really wanted some reflection to make generating this code more ergonomic. From memory I’d have types like these

Author id: int, name: string, book_id: int

NewAuthor name: string, book_id: int

ViewAuthor name: string, book_title: string

Author represents the data in the db, NewAuthor allows for an insert operation, and ViewAuthor is for showing the data to a user.

You could argue for combing Author and NewAuthor and making id optional but I wanted to enforce at the type level that I was working with stored data without needing to check id everywhere.