I have two immediate thoughts about this.

1. there is already a well-established abstraction for incremental
computation in OCaml, namely in the form of the Jane Street
incremental library (https://github.com/janestreet/incremental). I
think this can capture what you want, and maybe is the path of least
resistance.

2. filesystem watching is a hack anyway, and it will probably never
work properly in any OS-independent way; what you probably want
instead is for compilation to be triggered by e.g. the LSP server when
your editor saves. This is pretty doable based on my LSP prototype.

Kind regards,

Nick

> 1. there is already a well-established abstraction for incremental
> computation in OCaml, namely in the form of the Jane Street
> incremental library (https://github.com/janestreet/incremental). I
> think this can capture what you want, and maybe is the path of least
> resistance.

> 2. filesystem watching is a hack anyway, and it will probably never
> work properly in any OS-independent way; what you probably want
> instead is for compilation to be triggered by e.g. the LSP server when
> your editor saves. This is pretty doable based on my LSP prototype.

Sorry, for some reason I sent a blank mail. The intended text:

Hi Nick, 

thanks for your feedback.

> 1. there is already a well-established abstraction for incremental
> computation in OCaml, namely in the form of the Jane Street
> incremental library (https://github.com/janestreet/incremental). I
> think this can capture what you want, and maybe is the path of least
> resistance.

I do want to experiment with `incremental` and/or `current_incr`, but
first I wanted to get a clearer mental model of where incrementality
actually comes into play. 

+ From skimming the docs of `incremental`, I don't think it's the case
  that we can easily sprinkle some incremental types throughout our code
  and expect good performance. 

  https://github.com/janestreet/incremental/blob/master/doc/index.mdx

  In `Eval.ml`, we have 
  
  ```https://git.sr.ht/~jonsterling/ocaml-forester/tree/main/item/lib/core/Eval.ml#L149
    module Lex_env = Algaeff.Reader.Make (struct type t = Sem.t Env.t end)
    module Dyn_env = Algaeff.Reader.Make (struct type t = Sem.t Env.t end)
    module Heap = Algaeff.State.Make (struct type t = Sem.obj Env.t end)
    ...
  ```
  The documentation for incremental advises against using mutable state: 
  
  > As a result, putting effects in the right hand side of a bind or map
  > to capture historical information is going to be confusing.
  https://github.com/janestreet/incremental/blob/master/doc/part4-pitfalls.mdx
  
  Incrementalising evaluation seems high effort to me, with substantial
  changes to existing code.

+ I also don't think it's strictly necessary to use a library to
  incrementalize forester. For example, I think using we can expect a
  substantial speedup by just being more careful about not
  reparsing/reevaluating/rerendering the entire forest by utilising the
  query mechanisms and graph structure. While this will require some
  amount of code, it isn't as invasive as adapting `Eval.ml`.

> 2. filesystem watching is a hack anyway, and it will probably never
> work properly in any OS-independent way; what you probably want
> instead is for compilation to be triggered by e.g. the LSP server when
> your editor saves. This is pretty doable based on my LSP prototype.

Yeah, I don't think that fs watching will become a part of forester code
anytime soon, but I think we should try to make it so that native fs
watching programs to trigger a rebuild.

Best, Kento