papers : https://okmij.org/ftp/meta-programming/StagingNG.pdf

https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems.pdf

Problems

1. The directives#if and #defineenable metaprogramming for conditional compilation purposes, like selecting a (whole) data type definition for a given version of a standard (protocol).
2. The directive#include use is twofold: (1) piecing together files containing bits of smart contracts, like data type definitions, (2) embedding Michelson files (.tz) in verbatim strings. These are linked to separate compilation (see #if above). Would adding anincludestatement in CameLIGO replace the use of #include? It seems that (2) cannot be solved using using include (see for example this answer by Tom). Also, for (1), we need a way of using a path that traverses directories, for example: #include "../../bar/foo.ligo”. How would we replace it using include (in particular the ..), given that we aim at supporting Linux, Darwin and Windows?
3. File paths are present in JsLIGO through import * as M from "my/path" but not in CameLIGO where the mapping of module names to/from paths on the file system rely on interactions with the build and package systems. Those file paths are an obstacle to running compilation of JsLIGO files in the browser. #import is used in CameLIGO. It features the same drawbacks as import in JsLIGO (see previous point). Note that #import can also be used in JsLIGO, concurrently to import, which raises some questions.
4. If we add an open & include global scoping statement à la OCaml (or even local: let open M in e), we must consider its impact on aggregation. (NOTE: Gabriel recently closed https://gitlab.com/ligolang/ligo/-/merge_requests/2149) We will have to consider the impact of open & include on get-scope , for example if we open two modules then we need to deal with shadowing:

module A = struct let x = 1 end
module B = struct let x = 42 end

open A
open B

let () = assert (x = 42)

1. If we do separate compilation, how will the interop between syntaxes work? Could we associate a textual representation of the AST, like .cmo are to .ml files? For CameLIGO, if we introduce a build system, we’ll need separate compilation…

Solutions

• Rémi about problem (4) above: Should we port JsLIGO import to CameLIGO and make the build system process the AST to extract the dependencies ? (Should be easy.)
• Could stages/phases help us? There’s Kiselyov’s approach or recent work by Harper? (this discussion for effects in modules)
• About problem (4) above: It seems not that difficult to solve with the recent refactoring in get-scope
• About problem (3) above: We discussed a little bit about how we can do it in such a way that it is intuitive for both people coming from JS/TS, and also people coming from OCaml to work with files & packages.

JsLIGO

• We should not introduce a build system since we can take advantage of the syntax import * as M from “my/path” On the browser, relative paths could resolve URI relative to the current HTTP document. So import * as M from "./bigarray.mligo" would resolve to http://<domain>/bigarray.mligo if the IDE is being served at http://<domain>
• In case of a file within the same project: users can specify that path of the imported file relative to the current file (importer) import * as M from "./token.jsligo"
• In case a user wants to use a package or some specific file from a package, write import * as FA2 from “@ligo/fa” or import * as BA from "@ligo/bigarray/lib.mligo"
• To resolve those paths, we can use our existing find function which we use in the preprocessor,
  1. which first looks for file relative to the current file (if it is a relative path),
  2. if it is a absolute path it tries to find it,
  3. else it tries to resolve it as a package (using ModRes)

CameLIGO