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

Reserve keywords for Haxe 4.0 #7413

Closed
Simn opened this Issue Sep 10, 2018 · 23 comments

Comments

Projects
None yet
9 participants
@Simn
Copy link
Member

Simn commented Sep 10, 2018

Even if we don't implement them yet, we should reserve them already:

  • overload
  • something like async/await?
  • operator
  • protected

@Simn Simn added this to the Release 4.0 milestone Sep 10, 2018

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Sep 10, 2018

something like async/await?

We don't need these If we want to have only generic coroutine implementation without the need to teach the compiler the semantics of specific coroutine types (like async/await, generators etc).
We need something like suspend (for functions which suspend coroutines) and coroutine (for functions which get transformed into state machines).

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Sep 10, 2018

Also is :)

@nadako

This comment has been minimized.

Copy link
Member

nadako commented Sep 10, 2018

We need something like suspend (for functions which suspend coroutines) and coroutine (for functions which get transformed into state machines).

IIRC in my (kotlin's :)) original proposal, only one keyword is needed, e.g. suspend is both suspending and transformed.

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Sep 13, 2018

Does anyone have feelings about a replacement for @:op?

@nadako

This comment has been minimized.

Copy link
Member

nadako commented Sep 13, 2018

Does anyone have feelings about a replacement for @:op?

Ideally we would have something like function +(a, b), but that means we'd have to generate function names for run-time based on the operator name (and arg types for overloading). I'd be in favor of that anyway, but it requires a lot of design.

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Sep 13, 2018

I'm not worried about name mangling because we have to sort that out for overload anyway.

I'm not sure about unops because you want to distinguish ++a and a++.

@nadako

This comment has been minimized.

Copy link
Member

nadako commented Sep 13, 2018

I'm not sure about unops because you want to distinguish ++a and a++.

Right, don't really want to go the C++ way and have a marker argument... Hmm

@back2dos

This comment has been minimized.

Copy link
Member

back2dos commented Sep 15, 2018

Does anyone have feelings about a replacement for @:op?

Unless you're planning to make it from static function ... I think @:op is just fine. It's short and pretty descriptive.

I think aggressively reserving relatively common keywords would be good in that it'll allow adding their syntax without breaking changes (macros aside). It should be combined with a plan for allowing them in field names to reflect native APIs. My personal favorite would be to allow all keywords to be field names (kind of like it's done with macro).

@Justinfront

This comment has been minimized.

Copy link
Contributor

Justinfront commented Sep 18, 2018

@:op == operation

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Sep 18, 2018

Does anyone have feelings about a replacement for @:op?

In order to give proper syntax for overloaded operators, I think it would require a new keyword operator , then:

function operator(+)( a, b ) {
}
  • unary - vs opneg can be differentiated based on number of arguments
  • there's the problem of unop prefix vs suffix (++a vs a++) but maybe the problem is that we should only define only one operator(++) and have the compiler return the value of a before or after the operation.

There's also the problem of generating a valid function name. the parser could put the operation in @:op like it used to be and set the function name as empty "" , then the compiler would generate the name based on a common name "add" "sub" etc. + eventual numbering/suffixes if several declarations with different types.

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Sep 18, 2018

there's the problem of unop prefix vs suffix (++a vs a++) but maybe the problem is that we should only define only one operator(++) and have the compiler return the value of a before or after the operation.

That limits the possibilities of operator overloading. E.g. prefix and postfix ! carry completely different semantics.

@dpomier

This comment has been minimized.

Copy link

dpomier commented Sep 18, 2018

there's the problem of unop prefix vs suffix (++a vs a++) but maybe the problem is that we should only define only one operator(++) and have the compiler return the value of a before or after the operation.

Maybe the keyword operator could be operation to allow something like this?:

function operation(a+b)( a, b ) {
}
function operation(++a)( a ) {
}
@Simn

This comment has been minimized.

Copy link
Member

Simn commented Sep 18, 2018

I don't really see a problem with allowing an identifier for unops:

  • operator(++a) for prefix
  • operator(a++) for postfix
  • operator(++) for both

Do you think it's strange that it would be allowed for unops but not for binops? I find that fair... and I don't want to allow it for binops because then we have multiple syntaxes that mean the same thing. I also don't want to require it for binops because that seems pointless...

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Sep 18, 2018

Well we would only need an identifier to differentiate ++a from a++ , and I fail to see a compelling case when I want a++ it to do something different than { var tmp = a; ++a; tmp; }

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Sep 18, 2018

@RealyUniqueName ah I forgot about postfix custom operators, maybe then we should follow @Simn proposal, would still not allow them for binops

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Sep 18, 2018

You never know the user's domain specifics :)
I think making this feature as flexible as possible is better than applying synthetic restrictions. Especially taking into account current implementation.
Also, we have @:commutative for the cases when the order is not important.

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Sep 23, 2018

Right, @:commutative... that makes me think we should allow identifiers for binops after all and follow the same rules like we do for unops:

  • operator(a+b) for non-commutative
  • operator(+) for commutative

That aligns quite nicely: If it's just the operator, we get the widest possible interpretation. And by adding identifiers you can restrict it to prefix or postfix for unops, and non-commutative for binops. It's also matches our current approach for @:op because we require the identifiers there and default to non-commutative.

Anyway, I'm gonna reserve operator and overload for now and we'll have to see about the asynchronous thing.

Simn added a commit that referenced this issue Sep 23, 2018

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Sep 23, 2018

It should be combined with a plan for allowing them in field names to reflect native APIs. My personal favorite would be to allow all keywords to be field names (kind of like it's done with macro).

Yes we should discuss this. I certainly don't want to encourage something like this, but I also don't want to make it unnecessarily difficult to match extern APIs.

A problem is that it's easy to support something.public, but public.something is a different case as far as the parser is concerned.

Also, I can already hear @Gama11 cry in the distance if this is to be properly syntax-highlighted.

@frabbit

This comment has been minimized.

Copy link
Member

frabbit commented Sep 23, 2018

I actually like to give operators descriptive names, the generated code is cleaner and you have a name to talk / search about etc. It's fine to have operators but a well named alias is a good thing imho.

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Sep 25, 2018

Might want to reserve protected, just in case.

@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Oct 2, 2018

As for coroutines, I've written some considerations here: nadako/haxe-coroutines#13

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Oct 9, 2018

I'm not sure about protected given we are very unlikely to introduce it (our private is already protected in Java), and we wouldn't want to change the whole definition.

Ok for async/await/operator, although I hate keywords :)

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Dec 5, 2018

Given that the only implementation somebody worked on doesn't use async/await keywords, I'll not reserve them for Haxe 4.

@Simn Simn closed this Dec 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment