Re: [Caml-list] [ANN] slacko-0.9.0

[Marek Kubica <marek@xivilization.net>]

Hello Malcolm,

Thanks for looking into my code.

On Sat, 04 Oct 2014 13:36:43 +0000
Malcolm Matalka <mmatalka@gmail.com> wrote:

> I would either change the 'apierror' type to normal variants, or
> spread out the apierror to multiple types.  Can every API function
> really return every one of those errors?  The value of polymorphic
> variants is they are module, and you can share the constructors
> across types.

You're right, there is a common set of errors that most functions return
and then there are some specific errors.

Originally I didn't want to create such a huge type but have every
function have its own polymorphic variants that apply to it, so users
of the API know exactly what errors might be thrown and have to handle
these. The huge type is a direct result of the "validate" function
<https://github.com/Leonidas-from-XIV/slacko/blob/bc6be47cca8d2088d3d7cfb9af0603a350ab0215/src/slacko.ml#L79>
which tests all cases.

I tried specifying a smaller subset of polymorphic variants, but the
compiler always selected the full set. I don't know how to fix this,
because on the one hand side I don't want to have a big monolithic
error type but on the other hand, I don't want to duplicate a subset of
the validate function in every function.

Looking forward for ideas on how to solve this in a more elegant way.

> I would also structure the API calls in terms of the Result.t type in
> Core.  Right now success is part of the error type.

If I understand you correctly, this should do the trick with the
current code:

type result = Success of Yojson.Basic.json | Error of apierror

For future releases I plan to replace the strings in the signatures
with proper types (so, some "string" turn into a "token" types, others
into timestamp types) and to process the resulting JSON into some more
convenient data structures. But for now, I hope to get the error
handling right and then build upon this.

Thanks in advance!

regards,
Marek