···11-I have a compiler that features multiple compilation phases. For examples sake,
22-consider the following simplified pipeline:
33-44-```ocaml
55-module M = Map.Make(String)
66-77-type state = {
88- phase1: string M.t;
99- phase2: int M.t;
1010- phase3: string M.t;
1111-}
1212-1313-let step1 = M.map String.length
1414-let step2 = M.map Int.to_string
1515-1616-let init source =
1717- {
1818- phase1 = source;
1919- phase2 = M.empty;
2020- phase3 = M.empty
2121- }
2222-2323-let run_phase1
2424- : state -> state
2525- = fun state ->
2626- {
2727- state with
2828- phase2 = step1 state.phase1
2929- }
3030-3131-let run_phase2
3232- : state -> state
3333- = fun state ->
3434- {
3535- state with
3636- phase3 = step2 state.phase2
3737- }
3838-```
3939-4040-*Why do you need a state type? Can't we just compose the functions step1 and
4141-step2?*
4242-4343-The answer is yes, if we only want to consider batch compilation. The
4444-state type arose from the development of a language server that needs access to
4545-all compilation phases. I also want to cleverly update the state upon granular
4646-changes (for example, when a source changes only recompile the stuff that
4747-depends on it, although the example is too simplified to capture that)
4848-4949-This gets to the type of thing I would like to capture.
5050-5151-*Can I use GADTs to prevent phase2 from being run before phase1 completed?*
5252-5353-I am imagining that `state` could be a GADT such that the types of `run_phase*`
5454-reflect that a phase transition is happening. I have had success with GADTs in
5555-the past and it feels to me like this is a potential usecase for them, but I
5656-can't seemt to actually write down what I want.
5757-5858-I realize that I might be trying to be too clever. I could just design an
5959-interface that ensures that everything is being used correctly, but using GADTs
6060-is more slick.
6161-6262-Any pointers, suggestions or alternative approaches are appreciated!
6363-6464-Related:
6565-- https://raphael-proust.gitlab.io/code/gadt-tips-and-tricks.html
+7-1
docs/dune
···11-(documentation)
11+;;; SPDX-FileCopyrightText: 2024 The Forester Project Contributors
22+;;;
33+;;; SPDX-License-Identifier: GPL-3.0-or-later
44+55+(documentation
66+ (package forester)
77+ (mld_files index test developing))
···11-{0 Forester developer docs}
22-33-Forester is a compiled markup language for authoring scientific hypertext. This documentation is intended to give an overview of forester internals for people interested in contributing to the project.
44-55-{1 Questions}
66-77-If you have questions, feel free to write an email to [https://lists.sr.ht/~jonsterling/forester-discuss]. Please employ {{: https://useplaintext.email/#etiquette} plaintext email etiquette}, including line wrapping.
88-99-{1 Getting started}
1010-1111-Forester is implementend in the {{: https://ocaml.org/}OCaml programming language}, so you will need to have the OCaml toolchain installed. You can find instructions {{: https://ocaml.org/install#linux_mac_bsd}here}. Alternatively, you can get access to the toolchain using the {{: https://nixos.org/}Nix package manager}.
1212-1313-{2 Building the project}
1414-1515-[dune build]
1616-1717-{2 Testing}
1818-1919-[dune runtest]
2020-2121-{2 Sending a patch}
2222-2323-Once your changes are ready, follow {{: https://lists.sr.ht/~jonsterling/forester-devel}these instructions} to submit them for review.
2424-2525-{1 Codebase overview}
2626-2727-The code is organized into several libraries:
2828-2929-{!modules:
3030- Forester_core
3131- Forester_compiler
3232- Forester_frontend
3333- Forester_lsp}
3434-3535-{{!test} Test}
+6
lib/compiler/Code.mli
···11+(*
22+ * SPDX-FileCopyrightText: 2024 The Forester Project Contributors
33+ *
44+ * SPDX-License-Identifier: GPL-3.0-or-later
55+ *)
66+17type node =
28 Text of string
39 | Verbatim of string