Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

metaquot feature request: literal quotations #83

Open
gasche opened this issue May 25, 2020 · 2 comments
Open

metaquot feature request: literal quotations #83

gasche opened this issue May 25, 2020 · 2 comments

Comments

@gasche
Copy link
Contributor

gasche commented May 25, 2020

The payload of Pconst_* nodes in the Parsetree is changing on a regular basis: Pconst_int changed, now it is the turn of Pconst_string, etc. Having support for literal quotation would be nice as it would let us write version-robust code to create literals or pattern-match on them, in the simple case where we don't need all the data/knobs of the full datatype. (Typically to parse attribute information encoded in literals.)

( @thierry-martinez and myself were discussing this is ocaml-ppx/ppx_deriving_protobuf#36 (comment) )

I would propose the following interface: [%lit.{integer,int,int32,in64,nativeint,float,char,string} <payload>], available in both expressions and patterns (with a question mark). This is one quotation per constructor in the Ast_helper.Const module (suggestion from @thierry-martinez), and I would propose to use the same payload type as the non-default parameter of the constructor (in particular, string for %lit.integer and int for %lit.int).

@thierry-martinez
Copy link

@gasche Thank you for filling this issue.

(with a colon)

You mean a question mark, I suppose.

thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
@thierry-martinez
Copy link

thierry-martinez commented May 27, 2020

The PR #84 implements (partially) the proposition for OCaml 4.11. I will make PRs for other versions once this one will be reviewed. Note that I didn't think about that but it seems [%lit.{int,int32,int64} ...] can't be implemented for patterns: we can only deconstruct the string in Pconst_integer(s, _), but we can't convert it (for now...) on-the-fly during pattern-matching. On the converse, in OCaml 4.02, where constants are those of Asttypes, we can implement [%lit.{int,int32,int64} ...] but not [%lit.integer ...]. Since it can't be implemented for patterns, I didn't implement them for expressions neither.

thierry-martinez added a commit to thierry-martinez/ppx_tools that referenced this issue May 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants