Skip to content

Continue ppx obj, provide nested object literal/type support #415

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 3 commits into from
May 25, 2016
Merged

Continue ppx obj, provide nested object literal/type support #415

merged 3 commits into from
May 25, 2016

Conversation

bobzhang
Copy link
Member 

let f : < x : < y : < z : int > > > [@bs.obj]  = {x = { y = { z = 3 }}} [@bs.obj]

@coveralls
Copy link

Coverage Status

Coverage remained the same at 50.656% when pulling 72bf1fa on continue_ppx_obj into 3758f13 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 50.656% when pulling 90ca7b7 on continue_ppx_obj into 3758f13 on master.

@bobzhang bobzhang merged commit a8937cc into master May 25, 2016
@bobzhang bobzhang deleted the continue_ppx_obj branch May 27, 2016 12:41
kevinbarabash pushed a commit to kevinbarabash/rescript-compiler that referenced this pull request Dec 24, 2021
@IwanKaramazow
Tweak grammar of primitive list in externals (rescript-lang#415)
4e7d3c7 
Fixes rescript-lang/syntax#412

Currently the grammar allows for a list of primitives in an external declaration: i.e. `"hi" "hx"` in `external f: (int, int) => int = "hi" "hx"`. This stems from the fact that user primitives with arity greater than 5 should be implemented by two C functions. The first function, to be used in conjunction with the bytecode compiler ocamlc, receives two arguments: a pointer to an array of OCaml values (the values for the arguments), and an integer which is the number of arguments provided. The other function, to be used in conjunction with the native-code compiler ocamlopt, takes its arguments directly. However in the case of compiling to JS, we don't need to deal with this. In order to reduce some complexity, we'll now parse just one primitive.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@bobzhang @coveralls