define `Sexplib.Sexp.t` in some shared library?

[c-cube]

Hi, for interoperability purposes, it would be interesting to put the type definition of S-expressions in some lightweight library, ideally the stdlib (similar to the result lib) so that several S-expression libraries can be compatible. In general it would be nice if various "alternative" stdlibs/extensions of the stdlib would share more type definitions, but Sexplib is imho a good start.

I know it probably won't happen, but it's worth discussing!

[ghost]

/cc @yminsky, @avsm

We had a discussion about this a while ago. The conclusion then was that having a sexp type without any function to deal with it was useless

[avsm]

Not entirely useless -- convertors to/from Bytes and String from a Sexplib.Sexp.t seem fairly uncontroversial. The high performance ones to Bigarrays and so on could stay in Sexplib.

[c-cube]

@diml well the point is that several independent libraries could work on the type… And ppx generators could generate the type without forcing the use of one of those libraries. (Of course, I complain because I do have a S-expr library, and it currently uses [Atom of string | List of 'a] as 'a since there is no such shared definition :-))

[ghost]

OK, so these are two different requests. @c-cube, I'm not sure that sharing only the type is enough: if two sexp libraries don't agree on the representation of basic types, then in practice they won't work well together

@avsm forcing the dependency on bigarray is bad indeed. Although I thought there were some plan to move bigarrays to the stdlib?

[avsm]

@avsm forcing the dependency on bigarray is bad indeed. Although I thought there were some plan to move bigarrays to the stdlib?

Not for 4.03, so not for a long time...

[c-cube]

@diml I agree on the fact that representations have to be shared. However, it is automatically the case if one uses a ppx (which should only depend on the type representation, right?). I also use S-expressions in a context that is not type-conversion (rather, parsing a subset of a lisp-like format, namely SMTlib), in which case I only care about the type.

Regarding the dep on bigarrays, I kind of recall the (a?) discussion was about moving Unix out of bigarrays, not necessarily bigarrays out of stdlib…

[ghost]

Well, the ppx won't convert the basic types, it will make calls to sexp_of_int, char_of_sexp, ... If two libraries don't do the same thing for these, then converting a sexp produced by another library might not yield the expected result

[c-cube]

I would say it is a problem with the ppx, but this is going nowhere :-).