add implementation stubs (fixes #285, fixes #298)

[marionebl]

As per

• .ml stubs for exercises #285
• Grade School's use of module parameters for Map is too hard #298

[marionebl]

CI failure appears to be unrelated.

[marionebl]

Addresses #298

[marionebl]

As a side note: I dug into the CI setup a bit and created this version using CircleCI:
https://github.com/marionebl/ocaml/tree/circleci-setup

Maybe this also of interest for another PR?

[sshine]

Closing and opening PR to trigger CI. (I wonder if this is the best way.)

[sshine]

@marionebl: Could you merge master onto this feature branch?

I'm a little confused about the merge conflict; not sure if it's caused by leaving stuff out by intent, or because of breaking changes with base 0.12, or what.

Edit: Also, is this PR intended to be merged? I don't mind that stubs are added for a bunch of exercises at once, since the histories for those files start at nothing.

[marionebl]

@marionebl: Could you merge master onto this feature branch?

I'll get this into a mergable state as soon as the spin offs for #311 land

[marionebl]

One thing I don't like about this is the fact we do not have an automated test for the stub files as I did not find a way to build the tests without executing them.

---

Edit: One way to address this might be adding a new alias to the dune files

(alias
  (name    buildtest)
  (deps    (:x test.exe)))

Executing dune build @buildtest then builds all test without executing them, revealing issues with interfaces and implemenations stubs even before running tests.

[sshine]

@marionebl: My model track is Haskell's, and here we run all tests of all example solutions on every CI run. Come to think of it, this is somewhat wasteful. I don't really know of the particular implications of adding such a build target alias -- my practical experience with OCaml build tools are very limited -- but I like the purpose very much.

If you're interested in becoming a co-maintainer for the OCaml track, you are very welcome.

If you prefer to submit changes as you have been doing so far, you are also very welcome.

[marionebl]

If you're interested in becoming a co-maintainer for the OCaml track, you are very welcome.

I'd be glad to!

If you prefer to submit changes as you have been doing so far, you are also very welcome.

I'd continue submitting PRs even as maintainer so everyone stays on the same page.

[sshine]

@marionebl: Yes, that'd be ideal as long as we're more than one active maintainer, since we get the luxury of fault detection. (I don't think I can supplement your knowledge of CI and OCaml build tools, but four eyes are better than two!)

@iHiD, @kytrinyx:

• Can we make @marionebl co-maintainer of exercism/ocaml?
• And can we disable direct pushes to master? It works like this on exercism/haskell, so that all changes must come through a PR. (I'm not asking for required reviews, but rather just that we force the use of PRs, since they trigger CI.)

[iHiD]

@kytrinyx will sort these for you.

[iHiD]

@marionebl Welcome. Ping me on Slack and I'll add you to the #maintainers channel :)

[kytrinyx]

@marionebl Welcome! Thank you so much for contributing ✨

I've sent the invitation to join the exercism/ocaml team, and have turned on branch protection for the master branch. Let me know if anything is wonky, I always worry that I get things wrong when messing with repo settings.