In the recently addedGADT tutorial, I think it's a little confusing how the last example used the tick type variables'inputStream and'callback instead of thetype a b. notation used in the rest of the article. I think I figured out the reason it did so. For one, thetype a b. notation doesn't seem to be supported onexternals, at least when I tried it in the online playground, so it couldn't have been used in the last example.

In the other direction, tick type variables couldn't work in the earlier examples because OCaml (unlike every other language 🙄) will unify the type variable with its later use to make it monomorphic.

However, this doesn't happen in the Streams example because of the module boundary. Adding a module boundary appears to remove the issue from other examples as well (one example).

You might consider changing the doc's examples to include the module boundary and use the tick type variables throughout the doc, given that, in practice, GADTs are likely to be separated by such a module boundary from their uses. In support of this claim, note that the motivating examples in theOCaml docs seem to focus on higher-rank positions (like how theClosure example puts thetype a quantification on theinside, at the parameter itself), suggesting less anticipation of the monomorphization motivation.

If you do think the lack of module boundary is a common realistic scenario, and thus want to keep the examples as they are, you might still want to, in some way, address the discrepancy between the last example and the earlier ones, though you likely don't want to explain all the above esoteric minutiae. I don't personally know what you'd say instead.

Of course, the other alternative is ReScript adding support fortype a b. notation toexternals and then usingtype a b. in the last example. This also depends on whether this is more or less idiomatic than using tick type variables instead.