nukifw

If you are interested, I think I adress this here https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f

In the `show_content` example, using first class modules: `module H : ...`. The type need to be specified and since module composition is hard, it leads to very verbose solution

We try to invest equal time between the OCaml platform (on VSCode) and OCaml-eglot (for Emacs). In fact, I find the VSCode extension to be rich (and generally iso-features with Emacs mode).

However, I (as maintainer of OCaml-eglot) find Emacs easier to extend (the VSCode extension is surprisingly complex when you stray from the beaten path), which seemed perfect for incubating an experimental feature. Furthermore, as mentioned at the end of the article, the feature can also be invoked from a code action, which makes it de facto callable from VSCode once the various PRs have been merged :)

For the first point, you are right. We start by a common (but very useful) feature. Since OCaml allows an infinite level of nesting (and different kind of structure item) it was still a bit of a challenge, mostly for finding the right UX.

For the second point we delay the aeration convention to the formatter (ocamlformat). It can be configure in a different way :)

Thanks for your feedback!

PRs are mentioned at the end of articles. It is possible to `pin` repositories locally on their different branches to experiment with them locally!

Nop, for the moment, we try to not "infer user usages"! But if you extract an expression with variable, there will be, obviously, not be repeated:

    let tau =
      let pi = 3.14 in 
      pi + pi

if we extract `pi + pi` it will lead (if you do not give any concrete name) to the following code:

    let fun_name1 pi = 
       pi + pi

    let tau = 
       let pi = 3.14 in 
       fun_name1 pi

- Extremely dated: we have almost one new release every six month and in recent releases, the language runtime has been changed and user-defined effects have been introduced.

- No HKTs "in your sense" but: ```ocaml module type S = sig type 'a t end `` `type 'a t` is an Higher Kinded type (but in the module Level). - No typeclasses, yes, for the moment but the first step of https://arxiv.org/pdf/1512.01895 is under review: https://github.com/ocaml/ocaml/pull/13275 - no call-site expansion ? https://ocaml.org/manual/5.0/attributes.html look at the attribute `inline`.

Ok! (BTW, thanks for the interaction!)

Yes and my point was, when you want what you present in the first comment, quoting my post, you have tools for that, available in OCaml. But there is cases, when you do not want to treat each branch of your constructors "as a type", when the encoding of visitors is just rough. This is why I think it is nice to have sum type, to complete product type. So i am not sure why we are arguing :)

- You can use GADTs (https://ocaml.org/manual/5.2/gadts-tutorial.html) and indexes to give a concrete type to every constructors:

  ```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 *)
  ```

- You can use the structurale nature of polymorphic variants (https://ocaml.org/manual/5.1/polyvariant.html)

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

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

(Notice the difference between `>` and `<` in the signature?)

And since OCaml has also an object model, you can also encoding sum and sealing using modules (and private type abreviation).

Sorry, I never used ReasonML so I don't see any advantage of using ReasonML except it had the time to die twice in 4 years :)

Usually we speaking only about sum and product (because article usually refers to ADT, so Algebraic Data type). A function is not really Data, so it is not included. But you can use the same tricks (ie: a -> b has arity b^a) to compute the number of potential inhabitant

Package description, but it use its own engine.

And the next milestone of Dune is to become an alternative package manager via Dune package Management, using a store in a "nixish" way.

There is a lot of work on Dune Package Management that will fix some legacy issues related to OPAM, https://dune.readthedocs.io/en/stable/tutorials/dune-package... !! Stay tuned!

Yes, the trick is expanded here: https://libres.uncg.edu/ir/asu/f/Johann_Patricia_2008_Founda... (if you have `Eq a b = Refl : a a eq` you should be able to encode every useful GADTs. But having a compiler support is nice for specifics reason like being able to "try" to detect unreachable cases in match branches for examples.

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.

To be completely honest, I currently only use LLMs to assist me in writing documentation (and translating articles), but I know that other people are looking into it: https://anil.recoil.org/wiki?t=%23projects

Indeed, efforts should be made in terms of DAP (https://microsoft.github.io/debug-adapter-protocol//), extending the following experimentation: https://lambdafoo.com/posts/2024-03-25-ocaml-debugging-with-.... However, I find the assertion about tooling a bit exaggerated, don't you?

Hi! Thank you for your interest (and for potentially reading this).

Yes, F# is a very nice language, however, it seems to me that I am making a somewhat forced comparison between OCaml and F# in the following section: https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f

Yes, as I try to explain in the article (voluntary written in the sense of an archeologic exploration) the main point of frustration is the lack of explanation. Trying to deduce everything was hard, when I was 10 :)

Preface is an opinionated library designed to facilitate the handling of recurring functional programming idioms in OCaml. Many of the design decisions were made in an attempt to calibrate, as best as possible, to the OCaml language. Trying to get the most out of the module language. The name "preface" is a nod to "Prelude".

When learning functional programming, one is often confronted with constructs derived (or not) from category theory. Languages such as Haskell offer very complete libraries to use them, and thus, facilitate their learning. In OCaml, it often happens that these abstractions are buried in the heart of certain libraries/projects (Lwt, Cmdliner, Bonsai, Dune etc.). This is why one of the objectives of Preface is to propose tools for concretising these abstractions, at least as a pedagogical tool using essentially the module-language of OCaml.

He's talking about functor from OCaml and SML which are basically a function in the module level. So a module which take other modules as arguments and produce a new module.

Nice work ! At Dernier Cri, we begon a similar work : https://github.com/derniercri/multilayer-perceptron But we were far less advanced than you!