janestreet / ppx_sexp_conv

Generation of S-expression conversion functions from type definitions
MIT License
88 stars 17 forks source link

allow "-" in variant definition #18

Closed abate closed 4 years ago

abate commented 6 years ago

hello. I want to parse an s-expr that looks like "(public-key (rsa (n 123) (e 123)))" . to do this, I'd like to define a type like type p = Public-key of rsa [@@deriving sexp] and rsa ... ;;

Clearly the problem is that the "-' char is not allowed in a variant definition. Would it be possible to use the same trick used for uppercase/lowercase and convert '_' in '-' while parsing the string

so I would like type p = Public_key of rsa ... that is legal, and the parser will match either ["Public_key", "public_key", "Public-key", "public-key"]

hhugo commented 6 years ago

Another approach would be to do something similar to https://github.com/ocaml-ppx/ppx_deriving_yojson#key and allow to override field names

aalekseyev commented 4 years ago

In my experience at Jane Street people care a lot about enforcement of consistent style, so if anything we'll probably want the spelling to be more canonical rather than less. We don't want to end up with some projects using dashes and others using underscores for no good reason.

Combined with very low interest in this change so far, plainly relaxing the parser seems out of the question.

Now, customizing constructor names for a given type definition can be reasonable. In fact we do it a lot by writing custom t_of_sexp/sexp_of_t functions.

A mechanism @hhugo mentioned to could work, or, if there is more interest in changing the identifier style, [@@deriving sexp ~identifier_style:Kebab_case] could work. (although, then switching to kebab-case would require modifying every type definition)

aalekseyev commented 4 years ago

I'll close this issue because it seems unlikely we'll do any work on it unless there's more interest.