Syntax issues with negative literals and infix types

[soronpo]

type ~~[A, B]
type good = 2 ~~ 2
type bad = 2 ~~ -2 //Error:(9, 20) ';' expected but integer literal found.
type work_around = 2 ~~ (-2)

[soronpo]

I hit this issue when I implemented prefix types in SIP33, and I fixed it by placing the PrefixType in CompoundType.

      /** {{{
       *  CompoundType ::= PrefixType
       *                |  AnnotType {with AnnotType} [Refinement]
       *                |  Refinement
       *  }}}
       */
      /** {{{
        *  PrefixType ::= [`-' | `+' | `~' | `!'] SimpleType
        *  }}}
        */

PrefixType can easily handle the special case for a literal type in SimpleType, and fix this issue (similarly to what is done for expressions).
I don't know if it's the best way to fix this. I can add SIP23 to my branch and let you know if its fixed, if you're interested.

[milessabin]

I can add SIP23 to my branch and let you know if its fixed, if you're interested.
That would be very helpful ... thank you :-)

Nb. there are conflicts with 2.13.x which are resolved on my as-yet-not pushed branch.

[soronpo]

@milessabin I took your topic/sip-23-redux and added SIP33. This issue is fixed, and can viewed at
https://github.com/soronpo/scala/tree/sips23%2B33

[soronpo]

Oops. Forgot to push the commit to the branch. Now the branch is updated.

[milessabin]

This issue is fixed by SIP33? That's great ... I think it makes sense to deal with it there ... thanks for that :-)

[soronpo]

The issue is fixed thanks to the prefix type implementation part of the SIP. However, after watching yesterday's SIP meeting, I think that eventually the prefix types will not be accepted and only the infix precedence part will. I think I know now how to modify your SIP23 implementation, to fix this bug. I will provide you with a branch today.

[milessabin]

That'd be great ... thanks again :-)

[soronpo]

Here is the branch https://github.com/soronpo/scala/tree/sips23fix
Notice that this is not just an implementation fix, but a Spec fix (should be fixed in the SIP proposal as well). Also notice that it allows 2 ~~ -2 but not 2 ~~ +2. The latter can be easily supported of course, if you think it should.

[milessabin]

@soronpo I'm not quite sure I understand the relationship between the commit in that branch and SIP-33. Are you saying that it's the part which was rejected by the SIP committee? If that's the case then I think I'd prefer to defer this until after SIP-23 is accepted, which will in any make the case for SIP-33 in it's entirety a lot more compelling.