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

What syntax should we use here? #3

Open
littledan opened this issue Jan 24, 2019 · 5 comments
Open

What syntax should we use here? #3

littledan opened this issue Jan 24, 2019 · 5 comments

Comments

@littledan
Copy link
Owner

The current explainer uses @[expressionLike]. What do you think the syntax should be?

@Jamesernator
Copy link

I personally think @[expressionLike] is okay. Other candidates might be something like identifier!/identifier(args)!, @@identifier/@@identifier(args), or something else entirely.

One way to think about it might be to consider what the language would've looked like if all reserved used such syntax:

@[class] Point {
  constructor(x, y) {
    @[this].x = x
    @[this].y = y
  }
}

@[function] add(a, b) {
  @[return] a + b
}

@[async] @[generator] @[function] foo(sequence) {
  @[for await] (@[const] x @[of] sequence) {
    @[yield] 12
  }
}
class! Point {
  constructor(x, y) {
    this!.x = x
    this!.y = y
  }
}

function! add(a, b) {
  return! a + b
}

async! generator! function! foo(sequence) {
  for! await! (const! x of! sequence) {
    yield! 12
  }
}

Although special syntax does make me wonder of the feasibility of macros with some builtin ones that might not be implementable in userland (e.g. tailcall).

@Morgul
Copy link

Morgul commented Jan 31, 2019

I like @[expressionLike], though would be okay with variations on the theme:

  • @{expressionLike}
  • <@expressionLike>
  • [@expressionLike]
  • !@expressionLike

I don't like any of those better than the proposed.

@pabloalmunia
Copy link

In my very humble opinion @[expressionLike] reminds the destructuring and I prefer other form as !@expresionlike.

@littledan
Copy link
Owner Author

If we go with the static/built-in decorators proposal, we may just be able to use @foo for most of the use cases in this README. I am meaning to update this document, and just haven't gotten around to it yet.

@pabloalmunia
Copy link

Good news. Don't worry, you have a lot of work with a lot of proposals.

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

No branches or pull requests

4 participants