Adding FP Library of the SMTLIB about dolmen HOT 10 CLOSED

It is for COLIBRI, we have an OCaml to Prolog bridge, so since our previous prolog parser was flaky, using dolmen is more than a bliss.

Thanks for the advices @Gbury!

from dolmen.

I think it's safe to say @Gbury isn't working on it 🙂
Are you writing SMT solvers in OCaml, still, @bobot ?

from dolmen.

I can confirm that I'm not working on it, so if you have the time and motivation, that's great !

For writing the theory, I would give the following advices:

• get inspiration from the other theories written for smtlib
• add together with the theory implementation the reference description of the theory from smtlib (i.e. the fp.smt2 file describing the theory). It helps having it directly next to the implementation and when/if it changes, diffing the new version will help upgrading the theory.
• but most of all, give attention to the error cases, as can be seen in other theories, the code handling the error cases takes quite a lot of place (and time to write), but it is very important, hence why there are quite a lot of helper functions in the base.ml file that you can probably re-use as much as possible (for checking arity, dealing with associative and/or chainable operations, etc...).

The fact that builtins are not exported in Dolmen.Expr is clearly a mistake. As you say, the goal is indeed to match on these builtins as much as possible (rather than testing equality of declared symbols). I'll try and fix it asap, ^^

from dolmen.

Good to hear. Is colibri amenable to be re-written in OCaml, or is it too big a stretch? :p

from dolmen.

Not in OCaml too easy, in Why3 it is better 😉

from dolmen.

@bobot I just pushed bbbe607 which exports and documents the builtins in Dolmen.Expr. Don't hesitate to make any remarks about it, ^^

from dolmen.

Additionally, do you think dolmen should to export the following function (It basically tries and match the type of a term with a bitvector type and if successful extracts the length of the bitvector), or do you think it is simple enough that users can re-implement their variant of it (returning an option, or some other error) ?

from dolmen.

I think it is not necessary, because I think in most use cases one will match on all the possible builtin at the same time.

from dolmen.

The MR #31 should implement the theory.

from dolmen.

I have some small fixes that I will MR in bulk once when COLIBRI+dolmen works fully.

from dolmen.