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

Introduce structural constants (literals) into Parsetree/Typedtree #6751

Closed
vicuna opened this issue Jan 13, 2015 · 5 comments
Closed

Introduce structural constants (literals) into Parsetree/Typedtree #6751

vicuna opened this issue Jan 13, 2015 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Jan 13, 2015

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).

@vicuna
Copy link
Author

vicuna commented Jan 13, 2015

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.

@vicuna
Copy link
Author

vicuna commented Feb 19, 2015

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.

@vicuna
Copy link
Author

vicuna commented Dec 2, 2015

Comment author: @alainfrisch

The case for representing structured constant in the Parsetree is really not clear to me. Marking as suspended.

@vicuna vicuna closed this as completed Dec 2, 2015
@vicuna
Copy link
Author

vicuna commented Dec 2, 2015

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.

@vicuna
Copy link
Author

vicuna commented Dec 2, 2015

Comment author: @alainfrisch

generating many parsetree nodes

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant