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

Relax syntax restriction on Pexp_new #6820

Closed
vicuna opened this issue Mar 24, 2015 · 4 comments
Closed

Relax syntax restriction on Pexp_new #6820

vicuna opened this issue Mar 24, 2015 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Mar 24, 2015

Original bug ID: 6820
Reporter: @Drup
Status: closed (set by @alainfrisch on 2015-03-26T09:16:33Z)
Resolution: won't fix
Priority: normal
Severity: minor
Category: typing

Bug description

Currently, only a longident can be placed after the "new" keyword. This kind of restriction has been relaxed for several other piece of syntaxes (+ a check before typechecking). It would be useful to allow expressions there.

Initial motivation can be found here: ocsigen/js_of_ocaml#239 (comment)

(I just realized there is no "OCaml syntax/parser" category in mantis)

@vicuna
Copy link
Author

vicuna commented Mar 25, 2015

Comment author: @alainfrisch

I would find this quite natural if the longident after "new" would indeed be resolved as expression path, but it's not the case. Why would we allow (syntactically) an expression after "new" and not, for instance, a type expression?

As for the initial motivation, what about:

[%js.new] expr

or

[%js.new expr]

?

@vicuna
Copy link
Author

vicuna commented Mar 25, 2015

Comment author: @Drup

I don't see how it could be a type expression. Classes are not types and you can't define them in a signature alone. When a class is defined, a class type of the same name is also defined (and in a different namespace!) but that's a completely different thing. If you define the class type alone, it doesn't give you a class.

[%js.new expr]

Sure, this is what I will do, but I figured I could ask.

@vicuna
Copy link
Author

vicuna commented Mar 25, 2015

Comment author: @Drup

Actually, after re-reading your comment, I see what you meant. You are right, class names are not in the expression namespace, so it doesn't make sense to have a Pexp_ident there.

@vicuna
Copy link
Author

vicuna commented Mar 26, 2015

Comment author: @alainfrisch

Yes, indeed, I did not suggest to allow type expressions, I simply noticed that it wouldn't be less natural than allowing expressions.

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