Proposal: Lightweight conditional compilation extension

Hi all,

Recently I did some work to make rescript compiler not depending on a patched compiler any more.

The only exception is that we need a light weight conditional compilation mechanism. This is a tiny patch so that you can write code like this:

#if OCAML_VERSION =~ ">4.03.0"
....
#else
#end

I wonder if the community has interest to standardise on it and eventually upstream it.

Why not ppx based solution

The major benefits are:

  • Our patch is tiny and stable, it does not depend on anything, so it does not matter how AST changes, as long as you patch the compiler properly, it is a first class feature in the language, you don’t need worry about how to build the ppxlib or your other ppx dependencies on Windows, it just works.

  • The patch can be backported to ancient ocaml versions, one problem with ppx based conditional compilation is that itself has version problems, the ppx plugin itself works only on a specific ranges of ocaml versions and specific platforms.

What the community can do to rally on such extension?

We can apply such patch to most major versions of ocaml, e.g, (OCaml 4.0~4.12), if we have such extension, it should be easy to write code portable across such versions.

8 Likes

It looks cool to me.
But then, why not having a full-fledged preprocessor as a first-class feature of the language, while we are at it…

Less is more.

I believe this is only the essential feature to write portable code. I don’t mind writing bolierplate code.

Why does it need to be in the compiler ? From what I can tell, this feature should be relatively trivial to implement as a separate line-based text pre-processor.

1 Like

Imagine now I want use a new function in stdlib@4.12

I have two choices:

  • drop support for ocaml versions prior to 4.12
  • add external dependencies, e.g, ppx_optcomp, it is always a pain to add 3rd party dependencies and make it work on windows.

Note for ReScript itself, I can live with specific versions of OCaml compiler, but I think it is a generally a good thing to standarize on it, so we don’t need fight between using the latest utilities and adding external dependencies

I see your point, and I agree, in fact.

It seems to me that your issue is that you want better support for opam on Windows then.

1 Like

In an ideal world, yes.

But life is too short to wait for such good things to happen, so we can get some low hanging fruits first!

I am not sure if I am the only such kind of person: I want my code to have a long life expectancy, so that someday that I don’t have time to contribute or only have one hour a month to do some casual contribution, I want that one hour will be put in improving the code itself instead of make it build. In that case, I don’t want any dependencies in my code.

To conclude: I wish we had a light weight conditional compilation mechanism without third party dependencies and proposed a potential implementation, I will stop here.

1 Like

I think ocaml RFCS is the way to go with proposing OCaml feature additions.

3 Likes

Some people use the c preprocessor on ocaml code. I think this should provide what you need.

I love almost everything about OCaml… but conditional compilation is a minor pain-point I have. I would love to have some more general multistage or “comptime-like” capability… but really, selection of code inclusion on a simple condition would be enough for common needs.

I know I’ve looked through the options available several times over the years, but never anything satisfactory enough that I adopt it. Unfortunately I don’t recall details to have a more concrete argument off-hand.

An RFC needs a lot more thought on it, it’s easier to open a thread and discuss to begin with until you make a formal proposal

1 Like

I think macros would be really nice. I also know people are thinking about a good design for them. Go fast, break things is not ocaml’s motto :stuck_out_tongue:

3 Likes

And I’m glad for that!

This is why I didn’t exactly jump aboard the simple proposal here. I like it for how practical it would be, and “now”… but it’s a bit of a hack (though very common in programming – most editors and tools would readily handle C preprocessor style).

I guess, from my perspective: if 10 years from now, OCaml has no built-in or standard solution to this, then I would have preferred to have bobzhang’s patch – yesterday :). Though from his perspective, this is a solution to problems he has right now, without the luxury of waiting for “something better” (if it should ever exist).

The current options are either ppx, or other preprocessors like camlp4/5, m4, or cppo, right? I thought I wrote up some small document about my most recent comparisons, but now I can’t find it. Maybe my main problem with ppx was too many dependencies (eg. base which I don’t otherwise need or want). And cppo… well, the author seems to even warn against becoming dependent on it. And introducing another preprocessor seems overkill when I just want simple control over code inclusion/exclusion, really.

1 Like

Unrelated to the main thread, but note that Ppxlib versions 0.15.0 and above (released 2020-08-04) do not depend on base. Ppxlib’s current set of dependencies is relatively minimal.

Also, perhaps worth noting that “PPX, the compiler feature” is still independent from “Ppxlib, the toolchain”: it’s still possible to pass the compiler a custom binary to perform the preprocessing action. (I don’t actually recommend this for people using the conventional OCaml tooling – where Ppxlib is the standard – but it seems feasible for those wanting to do simple preprocessing tasks inside other environments.)

With regards to ppx, IIUC I think (?) there are plans to upstream some of the work done in ppxlib to ocaml proper (astlib?) which should hopefully make ppx tenable across OCaml versions.

@jeremiedimino @pitag maybe able to shed some light on it.

Here is the link which details some of the ppx work. Ppx: omp 2.0.0 and next steps

Um, apart from telling the preprocessor what the current ocaml version is (and maybe other config variables), why isn’t cppo already a solution? I’ve used it for this purpose for quite a while (e.g. pa_ppx_migrate/ast.ORIG.ml at master · camlp5/pa_ppx_migrate · GitHub ) and i was cribbing from other code I’ve seen flying around.

ETA: Ah, I see @atavener already asked this.

If it will be considered, please think also about the better syntax for such macroses. Why do we need to stick with decades-old C preprocessor syntax?

I think this is the -pp option of the compiler.

A nicer syntax would be nice, but … remember it has to work independently of the OCaml parser (and to the greatest extent possible, of the OCaml lexer). Otherwise, you can’t use it for the most important use-case: conditional compilation of code based on OCaml version.

1 Like