Improve Texp_record constructor representation #516

chambart · 2016-03-18T13:36:30Z

Accessing record information in the typedtree is not very practical, and the information about the type of kept fields (when using the { record with label = exp } construct) is available.

I propose to replace it by:

  | Texp_record of
      record_label_definition array *
      Types.label_description array *
      Types.record_representation *
       expression option

and record_label_definition =
  | Kept of Types.type_expr
  | Overridden of Longident.t loc * expression

This allows to easily access a particular field information (instead of searching for a field with the right field position).

The main motivation for this change is to provide the type information to translcore to propagate it to the lambda. In particular, the PR #336 would make use of it. I had a previous version that needed to do some unification after the type checking, but this version is a lot cleaner.

Notice that even if we lost the order of the fields in the parsetree, this does not affect the evaluation order. I added a test to verify that.

Notice that the evaluation order for record update depend on the number of fields updated:

if there are less than (size - 3) / 2 updated fields then the evaluation order is from the last index to the first
otherwise it is the opposite

Would anyone object if I changed the order to avoid this strangeness ?

chambart · 2016-04-29T15:32:08Z

Merged recent trunk and fix propagation of record update type informations

chambart · 2016-07-07T14:31:33Z

Re-rebased to the current trunk.

Also use the type information to populate makeblock kinds in case of record update and add some test to check that this effectively allow unboxing in case of record update.

This test was failing first due to a bug introduced by #538 . This contain the fix for it.

chambart · 2016-07-07T14:48:02Z

Note also #538 changed the evaluation order of records.
The failure comes from the new evaluation order failing due to this change. If this is considered as irrelevant, I will make every record use the same evaluation order.

chambart · 2016-07-07T14:48:48Z

@garrigue @lpw25 or @alainfrisch would you object to this change ?

alainfrisch · 2016-07-07T15:06:50Z

I think it's a good change, but I did not review the patch itself.

record_label_definition array * Types.label_description array *

Why not (Types.label_description * record_label_definition) array? This makes an invariant explicit (the two arrays have the same length) and simplify the code that work on them.

Moreover, the comment in Typedtree is confusing since it leads to believe that only overridden fields are listed. Perhaps just adding a sentence about the fact that all fields of the record type are listed in the arrays would help.

bluddy · 2016-07-07T15:12:06Z

I would also recommend switching to inline records where there are more than a pair of parameters, for clarity.

chambart · 2016-07-07T15:42:44Z

@alainfrisch, no real reason, it made some change a bit smaller, but this is marginal.

Thanks for the suggestions, I will try this.

chambart · 2016-07-07T16:11:48Z

Rererebased...

And applied @alainfrisch suggestions

chambart · 2016-07-07T16:15:18Z

@bluddy in that case the name of the type of each field is probably sufficient to describe what is its concern, but that should probably go in another pr soon

alainfrisch · 2016-07-11T12:29:51Z

The order I suggested (Types.label_description * record_label_definition) seems more natural (it follows the OCaml syntax).

Regarding (inline or not) record for the arguments: if you think this is a good idea, why not doing it in this PR? Typedtree is processed by external tools (reading .cmt files) so we should indeed aim at user-friendliness and stability (i.e. not change again the definition post 4.04).

It also allows to recover the type of kept fields in a { record with field = expr } expression

…ethod

The expressions defining a record are evaluated from the last field in the type definition to the first one.

alainfrisch · 2016-07-11T14:51:48Z

utils/misc.ml

@@ -181,6 +181,26 @@ module Stdlib = struct
      | None -> default
      | Some a -> f a
  end
+
+  module Array = struct


This helper module is now useless, I think.

alainfrisch · 2016-07-11T15:15:05Z

typing/typedtree.mli

+            If the type is { l1: t1; l2: t2 }, the expression
+            { E0 with t2=P2 } is represented as
+            Texp_record
+              ([| l1, Kept t1; l2 Override P2 |], representation,


This needs to be updated.

alainfrisch · 2016-07-11T15:15:57Z

Good to merge in my opinion (after fixing the doc).

chambart · 2016-07-11T15:27:00Z

@alainfrisch thanks for the review.

…entation Improve Texp_record constructor representation

Remove caml_root API

…ml#516)

* Generalize Table.Regular * Generalize Stats component * Generalize Testimonials * Generalize UserLevelIntroduction * Generalize MediaCarousel * Extract Timeline * Factor out Blog * Add components to storybook * Add Page elements to storybook. * Add a few more examples of Page.Basic * Add examples of PageTitles * Add Page Containers * Implement ContentGrid component. * Extract VerticalHighlightCard * Add examples of ContentGrid. * Add example of VerticalHighlightCard

damiendoligez added this to the 4.04 milestone Mar 31, 2016

chambart force-pushed the improve_texp_record_representation branch from 5914078 to 455a4b5 Compare July 7, 2016 14:28

chambart mentioned this pull request Jul 7, 2016

PR#6217 Improve perf. of functional record update #538

Merged

chambart force-pushed the improve_texp_record_representation branch from 38948fe to 60a8e1d Compare July 7, 2016 16:11

chambart added 12 commits July 11, 2016 16:50

Change Texp_record contents to ease the use

3f00684

It also allows to recover the type of kept fields in a { record with field = expr } expression

Factorisation in the Pexp_record case of Typecore

415f5d8

Emit type error as soon as we know that a label is missing

0cf5f54

Add test of for record evaluation order

640b680

Test cases for record update evaluation order when using the objdup m…

ee49c96

…ethod

Clean translcore record case using the change in Texp_record

338da55

Use the type information to annotate updated record allocation

05d0663

Test the propagation of updated record type information

ef91097

Merge record label descriptions and definition into a single array

6f010f9

Switch declaration and definition order in Tepx_record fields

c2e66f0

Change Texp_record into an inline record

24f947e

Record evaluation order is always the same

b8e9604

The expressions defining a record are evaluated from the last field in the type definition to the first one.

alainfrisch reviewed Jul 11, 2016
View reviewed changes

Update Changes

32cbe38

chambart force-pushed the improve_texp_record_representation branch from 7c28f45 to 32cbe38 Compare July 11, 2016 14:55

Remove unused functions from Misc

7629e30

alainfrisch reviewed Jul 11, 2016
View reviewed changes

Update Texp_record documentation

316756f

chambart merged commit 1ae28b9 into ocaml:trunk Jul 12, 2016

camlspotter pushed a commit to camlspotter/ocaml that referenced this pull request Oct 17, 2017

Merge pull request ocaml#516 from chambart/improve_texp_record_repres…

44f8004

…entation Improve Texp_record constructor representation

bobzhang mentioned this pull request Sep 6, 2018

to-do list for upgrade rescript-lang/rescript#3000

Closed

37 tasks

EduardoRFS pushed a commit to esy-ocaml/ocaml that referenced this pull request May 17, 2021

Merge pull request ocaml#516 from Sudha247/caml_root_4_12

fda9561

Remove caml_root API

mshinwell added a commit to mshinwell/ocaml that referenced this pull request Jun 30, 2021

Flambda-specific copy of Strongly_connected_components (ocaml#516)

a7e049a

stedolan pushed a commit to stedolan/ocaml that referenced this pull request May 24, 2022

Ensure sound closure of local alloc regions in Lambda_to_flambda (oca…

292e0b9

…ml#516)

EmileTrotignon pushed a commit to EmileTrotignon/ocaml that referenced this pull request Jan 12, 2024

Match any character but new lines when searching packages (ocaml#516)

56d6b55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Improve Texp_record constructor representation #516

Improve Texp_record constructor representation #516

Uh oh!

chambart commented Mar 18, 2016

Uh oh!

chambart commented Apr 29, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

alainfrisch commented Jul 7, 2016

Uh oh!

bluddy commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016 •

edited

Loading

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

alainfrisch commented Jul 11, 2016

Uh oh!

alainfrisch Jul 11, 2016

Uh oh!

alainfrisch Jul 11, 2016

Uh oh!

alainfrisch commented Jul 11, 2016

Uh oh!

chambart commented Jul 11, 2016

Uh oh!

Uh oh!

Improve Texp_record constructor representation #516

Improve Texp_record constructor representation #516

Uh oh!

Conversation

chambart commented Mar 18, 2016

Uh oh!

chambart commented Apr 29, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

alainfrisch commented Jul 7, 2016

Uh oh!

bluddy commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

chambart commented Jul 7, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chambart commented Jul 7, 2016

Uh oh!

alainfrisch commented Jul 11, 2016

Uh oh!

alainfrisch Jul 11, 2016

Choose a reason for hiding this comment

Uh oh!

alainfrisch Jul 11, 2016

Choose a reason for hiding this comment

Uh oh!

alainfrisch commented Jul 11, 2016

Uh oh!

chambart commented Jul 11, 2016

Uh oh!

Uh oh!

chambart commented Jul 7, 2016 •

edited

Loading