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
Introduce structural constants (literals) into Parsetree/Typedtree #6751
Comments
Comment author: @alainfrisch For "normal" constants (i.e. not Const_pointer), it would be enough to define an AST for structured constants and a function mapping these terms to existing Parsetree constructors. Generally speaking, we try to keep the Parsetree simple and close enough to source syntax, and there doesn't seem to be a strong argument for supporting two different ways to represent the same constant. |
Comment author: @damiendoligez I see a difficulty here: the parsetree is the output of the parser, so separating structured constants at the parsetree level would imply major work on the grammar, and I'm not even sure it's possible. |
Comment author: @alainfrisch The case for representing structured constant in the Parsetree is really not clear to me. Marking as suspended. |
Comment author: @gasche The report coming from Oleg, I assume that it would simplify his MetaOCaml patches. I suppose that the need for this approach comes from cross-stage persistence of values. (The latter stages being generated by compiling OCaml AST.) That seems a relatively interesting "case" -- MetaOCaml being one of the few out-of-tree forks of OCaml with a steady userbase. |
Comment author: @alainfrisch
Why is this so bad? Is this a performance concern? If we extend the Parsetree with structured constant and ensure that the parser recognize them, it means that all "clients" of the Parsetree need to be prepared to deal e.g. with two possible representation of lists. It really goes against the current direction of making the Parsetree as simple and predictable as possible, with few implicit invariants, and reasonably close to an actual parse tree indeed (i.e. close to the grammar). |
Original bug ID: 6751
Reporter: oleg
Status: resolved (set by @alainfrisch on 2015-12-02T15:43:53Z)
Resolution: suspended
Priority: normal
Severity: feature
Version: 4.02.1
Target version: later
Category: typing
Monitored by: @gasche @hcarty
Bug description
The constants in Pext_constant/Texp_constant nodes are all very
simple and unstructured: strings, integers and floats. Even [] is not
considered a constant, let alone [1;2;3]. When a meta-programming facility
such as a ppx extension or MetaOCaml produces a constant array or
other such literal value, it has to serialize it, generating many
parsetree nodes. For example, to serialize [1.0;pi], we have to
generate three Pexp_construct nodes, and serialize floating-point
values as strings (because this is how FP constants are represented).
Ironically, after the type checking the compiler goes to great pains
to re-create the literal array or list, etc. The Lambda language does
have explicit structural constants; see structured_constant in
bytecomp/lambda.mli. I would like those structural constants to be
exposed in Parsetree as well. Even Const_pointer could be useful: a
ppx extension may generate a large ancient array, to be copied to the
DATA section of the object file (or used in place in the toplevel).
Of course the problem with structural constants is their
typing. Therefore, a structural constant must come with the type:
Const_structural structural_constant
(* or even Obj.repr, although this hurts cross-compilation *)
* core_type
The compiler can later make a cursory check that the content of the
structural_constant agrees with the declared core_type. Generally, we
have just trust the programmer -- as we do anyway when it comes to
serialization and Marshal. But here we can at least do some cursory
check (Marshal trusts blindly).
The text was updated successfully, but these errors were encountered: