Simon Krajewski

You're using `Dynamic`, so the compiler can't do anything with it and you're at the mercy of the run-time, which may or may not do anything useful with it. Having...

Hmm, that shouldn't be the case because the term starts with `Fo`, which is supposed to rank higher than these letters randomly appearing in other places.

I don't understand how this is supposed to work. If anything uses `--connect` to speak to a different Haxe process via sockets, then anything like `Sys.stdout()` is always going to...

Well, actually, if I'm not hung up on the idea of referencing the actual `stdout` of the client, I suppose we could generalize `com.print` to something that ultimately behaves like...

If we can address the "Another problem", we could further improve the compilation server by not initializing the outside context before running initialization macros. At the moment, we add a...

How about we add a value to the `macro` define so it's `macro = "init" | "build" | "expr"`. Then we can add custom checks like `if (Context.definedValue("macro") != "build")...

Note that the problem isn't the macro context, it's the compilation context.

So there's this code: ```ocaml | Str.Delim a :: Str.Delim b :: tl when a = b -> i := !i + 2; f_string a; loop tl ``` This looks...

Ah, this comes from https://github.com/HaxeFoundation/haxe/commit/68f6e0face85af1983ba4c60032a92c0902dc605 Before, the code wouldn't even go through `interpolate_code` if there were no additional arguments, so the problem was hidden. We can reproduce the issue in...

But that requires declaring it a bug, while it looks very intentional that `{{` becomes `{` and `}}` becomes `}`. The [original implementation](https://github.com/HaxeFoundation/haxe/commit/dec922ca33b6fef694db08726f49bb552f52328e) had that already. Frankly, I think this...