OCaml as my primary language

Post by benreesman » Wed, Aug 13, 2025, 9:09 PM UTC

the__alchemist wrote: post #87

benreesman wrote: post #84

Earlier quoted context omitted.

The RESF is not a conspiracy theory, its a known thing. Especially on HN: https://news.ycombinator.com/item?id=14178950

It's real, and as someone who loves rust, it's embarrassing, and difficult to avoid. The OSS embedded rust users in particular are nuts.

Post by manoDev » Wed, Aug 13, 2025, 9:10 PM UTC

UncleOxidant wrote: post #88

manoDev wrote: post #71

I'm sure there's merit to the language, but the syntax seems absolutely alien to me. Some attempt to look like verbose imperative code, a bunch of semicolons, and for some strange reason, hate of parenthesis. Real life sample: let print_expr exp = (* Local function definitions *) let open_paren prec op_prec = if prec > op_prec then print_string "(" in let close_paren prec op_prec = if prec > op_prec then print_string…

I mean, I guess it depends on your background, but that code looks pretty nice compared to how it would look in a language without pattern matching and ADTs. This is why the MLs excel for things like parsers, interpreters, and compilers. Beauty is in the eye of the beholder, I guess. I suspect that if you gave it a bit of time it would start to really grow on you - that's how it was in my case. At first: "WTF is this…

Post by globuous » Wed, Aug 13, 2025, 9:12 PM UTC

nine_k wrote: post #41

I wish somebody with this amount of experience would compare the benefits / shortcomings of using the ReasonML syntax. (The article mentions it once, in passing.)

Post by jolmg » Wed, Aug 13, 2025, 9:15 PM UTC

ackfoobar wrote: post #90

jasperry wrote: post #74

Question about terminology: Is it common to call higher-order function types "exponential types" as the article does? I know what higher-order functions are, but am having trouble grasping why the types would be called "exponential".

A first-order function type is already exponential. A sum type has as many possible values as the sum of its cases. E.g. `A of bool | B of bool` has 2+2=4 values. Similarly for product types and exponential types. E.g. the type bool -> bool has 2^2=4 values (id, not, const true, const false) if you don't think about side effects.

  f :: Bool -> Maybe Bool

  f False = Nothing
  f False = Just True
  f False = Just False
  f True = Nothing
  f True = Just True
  f True = Just False

  f x = case x of
    True -> Nothing
    False -> Nothing

  f x = case x of
    True -> Nothing
    False -> Just False

  f x = case x of
    True -> Nothing
    False -> Just True

  f x = case x of
    True -> Just False
    False -> Nothing

  f x = case x of
    True -> Just False
    False -> Just False

  f x = case x of
    True -> Just False
    False -> Just True

  f x = case x of
    True -> Just True
    False -> Nothing

  f x = case x of
    True -> Just True
    False -> Just False

  f x = case x of
    True -> Just True
    False -> Just True

Post by nukifw » Wed, Aug 13, 2025, 9:18 PM UTC

ackfoobar wrote: post #31

nukifw wrote: post #13

Earlier quoted context omitted.

In the specific case of OCaml, this is also possible using indexing and GADTs or polymorphic variants. But generally, referencing as its own type serves different purposes. From my point of view, distinguishing between sum branches often tends to result in code that is difficult to reason about and difficult to generalise due to concerns about variance and loss of type equality.

Unless you reach an unsound part of the type system I don't see how. Could you provide an example?

  ```ocaml
  type _ treated_as = 
   | Int : int -> int treated_as
   | Float : float -> float treated_as

  let f (Int x) = x + 1 (* val f : int treated_as -> int *)
  ```

  ```ocaml
  let f = function 
  | `Foo x -> string_of_int (x + 1) 
  | `Bar x -> x ^ "Hello"
  (* val f : [ string` *)

  let g = function
  | `Foo _ -> ()
  | _ -> () 
  (* val g : [> `Foo of 'a ] -> unit *)
  ```