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

Short-hand version of attributes on structure items and class fields #6586

Closed
vicuna opened this Issue Sep 28, 2014 · 10 comments

Comments

Projects
None yet
1 participant
@vicuna
Copy link
Collaborator

vicuna commented Sep 28, 2014

Original bug ID: 6586
Reporter: @Drup
Status: closed (set by @damiendoligez on 2016-04-12T13:05:04Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.0+beta1 / +rc1
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: ~DO NOT USE (was: OCaml general)
Related to: #6623 #6677
Monitored by: @gasche @hcarty

Bug description

For expressions, the following short-hands are available:
let%foo x = 3 in e
let[@foo bar] x = 3 in e

For structure items, you can do the first, but not the second.

For class fields, "method foo = bar [@@attr payload]" is accepted, but not "method[@attr payload] foo = bar" (You can't put extensions as class fields, so the other issue is not a problem there).

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Sep 29, 2014

Comment author: @lpw25

(You can't put extensions as class fields, so the other issue is not a problem there)

You can put extensions as class fields:

# class c = object
    [%%foo]
  end;;
    Characters 24-27:
      [%%foo]
         ^^^
Uninterpreted extension 'foo'.
@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Sep 29, 2014

Comment author: @Drup

Oh, indeed. I wonder why I miss it. I even saw it in the parsetree ....

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Oct 1, 2014

Comment author: @alainfrisch

I wonder if accepting the short notation for extension on 'let' structure items was such a great idea. It's nice that the syntactic marker (% vs %, @ vs @@) makes it clear whether the extension/attribute is on an expression or a structure item.

For "let[@foo] x = 3", there is a technical problem: item-attributes are attached to individual value_binding, not to the entire let structure item. So in case of "let[@foo] x = 1 and y = 2", there is no natural place to attach the attribute; we could decide it's always on the first value binding, but since the attribute in syntactically attached to the 'let', this would be quite arbitrary.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jan 14, 2015

Comment author: @damiendoligez

Do we have an idea to solve frisch's "technical problem"?
If not, I'll postpone this to 4.03.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jan 15, 2015

Comment author: @Drup

I don't really see the issue. "let[@foo] x = 3 and[@bar] y = 4" is equivalent to "let x = 3 [@@foo] and y = 4 [@@bar]". It is consistent with the current behavior.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jan 15, 2015

Comment author: @alainfrisch

The short-hand notation is currently only recognized just after the initial keyword ("let"), i.e. in the same location where an extension %foo could appear. Clearly, it doesn't make sense to allow "let f = 3 and%foo y = 4", so what you suggest would introduce the only context where the short version is allowed for attributes but not extensions.

Perhaps more importantly, consider:

let[@foo] x = 3 in x

There, @foo is attached to the whole expression (as for any attribute introduced with the short notation after a keyword), not to the "x = 3" binding.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jan 15, 2015

Comment author: @Drup

I agree that the current behavior is not consistent with the way other attributes behaves. Attributes don't behave the same on local let and top-level let.

However, if we don't change the way they behaves, the syntax I gave makes perfect sense.

We could change the behavior of attributes on top-level let so that they behaves the same way than on local let, I personally don't have any opinion on that.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jan 15, 2015

Comment author: @alainfrisch

the syntax I gave makes perfect sense.

Do you refer to:

"let[@foo] x = 3 and[@bar] y = 4" is equivalent to "let x = 3 [@@foo] and y = 4 [@@bar]"

It seems really confusing to have the same form "let[@foo] x" interpreted very differently for top-level bindings and for let-in bindings.

I'd rather stick to the current behavior: (i) item-level attributes always use [@@] and (ii) attributes introduced with the short-form "KEYWORD[@foo] REST_OF_EXPRESSION" are interpreted as "(KEYWORD REST_OF_EXPRESSION)[@foo]".

If you really insist on your proposal, can you try to give some use cases?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jan 18, 2015

Comment author: @Drup

I had one use for methods (annotations on methods for js object literals) but I don't remember for top-level let at the moment.

I think the behavior of attributes on toplevel let is confusing from the beginning and it's even more clear with the additional syntax.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 12, 2016

Comment author: @damiendoligez

This is fixed by #342 and #481.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.