Leandro Ostera

I've been looking more into the `ocaml-lsp` project and I think it makes most sense to vendor since it already comes with Merlin vendored as well. On top of this,...

I agree that I'd expect this to behave like in OCaml. I also think that I should bring up that ReScript and Reason chose to favor "pipe first" (`->`) instead,...

@ayshiff dope! 🚀 the easiest would be to expose `(|>)` as an external that maps to a `caramel_runtime:pipe/2` function somewhere. But feel free to give it an initial stab by...

Thanks for filing this! Since Caramel is an ML, we do partial application by default. When you called `Io.format x` what you get back is a function `'a list ->...

```erlang -export([hello/1]). -spec hello(list(any())) -> ok. hello(Args) -> io:format(text(), Args). ``` This doesn't quite track because in the Caramel source you still have to call `hello () args`, and that...

```erlang -export([hello/0]). -spec hello() -> fun((list(any())) -> ok). hello() -> fun (Args) -> io:format(text(), Args) end. ``` This would be the Right Thing ™️, but is highly unidiomatic Erlang code.

@nicobao yes, I think they're ignored but they probably should fail with an error (just like `let rec` within a `let`). The automatic uncurrying _can be done_ (as shown by...

Excellent point! Yes, all Caramel code should be valid OCaml code syntactically. Adding a reserved word in Caramel is fine because that word will still be valid OCaml code, it...

When reusing Caramel code on the frontend, if it panics, you could get an exception and handle it in Reason code like you handle anything else. But in a Caramel-only...

> existing OCaml/Reason mostly work with Caramel I see what you mean! Existing code that's throwing exceptions with `raise` will get a compiler warning/error saying that "raise" is unsupported. Existing...