PROPOSAL: Multiple switch expressions and case ranges (original) (raw)
Pinku Surana suranap at gmail.com
Thu Mar 5 14:16:02 PST 2009
- Previous message: PROPOSAL: fold keyword
- Next message: PROPOSAL: Multiple switch expressions and case ranges
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Has the switch statement in C languages evolved much since the '80s? I'm envious of the case/match expression in functional languages and looking for simple ways to make 'switch' more powerful.
AUTHOR(S): Pinku Surana
OVERVIEW
FEATURE SUMMARY:
Extend the switch statement to support multiple switch expressions and case ranges.
MAJOR ADVANTAGE:
It is syntactic sugar that makes it easier to write/read complex logic. This is one small aspect of the vastly more powerful match or case expression in functional languages.
MAJOR BENEFIT:
Better readability for complex cases, and potentially better performance relative to if statements.
MAJOR DISADVANTAGE:
Requires changes to compiler.
ALTERNATIVES:
It can currently be implemented with if statements.
EXAMPLES
Show us the code!
SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.
switch (c) { case ['a'..'z']: return "lower case" ; case ['A'..'Z']: return "upper case" ; default: return "something else" ; }
ADVANCED EXAMPLE: Show advanced usage(s) of the feature.
switch (suit, value) { case [SPADE..CLUB], [2..10] : return "black low-value card" ; case [HEART..DIAMOND], [2..10] : return "red low-value card" ; case _, [11..14]: return "face card" ; }
DETAILS
SPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming Language as well as any other known impacts.
The lexer will need to support underscore ('_') and ".."
The parser rules for switch statements must be changed.
SwitchStatement: switch (Expression [, Expression]*) SwitchBlock SwitchLabel: case CaseExpressions : default : CaseExpressions: CaseExpression CaseExpressions , CaseExpression CaseExpression: _ ConstantExpression [ ConstantExpression .. ConstantExpression ] EnumConstantName [ EnumConstantName .. EnumConstantName ]
Semantic rules:
- The number of CaseExpressions must equal the number of expressions in the SwitchStatement
- The underscore ('_') means "don't care"
- In [ c1 .. c2], c1 should be less than c2
- The types of the constants/enums must match the type of the expression in the same position
- If the range of constants/enums overlap between case arms, then raise an error.
COMPILATION:
Simple desugaring transformations:
switch (e1, e2) {
case C1, C2: stmt1 ;
case C3, _: stmt2 ;
default: stmt3 ;
}
==>
x = e1 ;
y = e2 ;
switch (x) {
case C1: switch (y) {
case C2: stmt1 ;
case C4: stmt2 ;
default: stmt3 ;
}
break ;
case C3: stmt2 ;
break ;
default: stmt3 ;
} case [V1 .. Vn] : stmts ;
==>
case V1:
case V2:
...
case Vn: stmts ;Both of these could blow up in code size. Therefore, a better implementation of the switch would compile down to gotos to the correct statement block. This is why proper compiler support would be nice.
For case ranges, if the range is too big then turn into an if statement: "if (x >= V1 && x <= V2)".
TESTING: How can the feature be tested?
Normal compiler testing.
LIBRARY SUPPORT: Are any supporting libraries needed for the feature?
None
REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be updated? This list of reflective APIs includes but is not limited to core reflection (java.lang.Class and java.lang.reflect.), javax.lang.model., the doclet API, and JPDA.
The reflection APIs will need to return a list of switch expressions and case constants. Also, new expression nodes must be added for ranges and for the "don't care" underscore.
OTHER CHANGES: Do any other parts of the platform need be updated too? Possibilities include but are not limited to JNI, serialization, and output of the javadoc tool.
Don't think so.
MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature.
I think this would be difficult because the logic would be obscured in if statements.
COMPATIBILITY
BREAKING CHANGES: Are any previously valid programs now invalid? If so, list one.
None.
EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any new overriding occur?
Should be backwards compatible.
REFERENCES
EXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal.
URL FOR PROTOTYPE (optional):
If there's interest, I can cook up a prototype with Polyglot.
- Previous message: PROPOSAL: fold keyword
- Next message: PROPOSAL: Multiple switch expressions and case ranges
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]