PROPOSAL: Multiple switch expressions and case ranges (original) (raw)
Pinku Surana suranap at gmail.com
Fri Mar 6 13:44:20 PST 2009
- Previous message: PROPOSAL: Multiple switch expressions and case ranges
- Next message: PROPOSAL: Multiple switch expressions and case ranges
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Updated: Added relevant bug id. Added support for sequences within ranges. More info on how to compile this feature.
Maybe this should be split into two proposals? (1) case ranges and (2) multiple switch expressions.
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 CaseExpression [, CaseExpression] : default : CaseExpression: _ ConstantExpression EnumConstantName [ CaseRanges ] CaseRanges CaseRange CaseRanges , CaseRange CaseRange ConstantExpression EnumConstantName ConstantExpression .. ConstantExpression 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:
The implementation for these two features is similar to that of switch in any optimizing compiler. There are two popular implementations for switch: jump tables (JT) and branching search (BS). This high-level switch statement must be "lowered" to a combination of JT and BS, either implementing them manually and/or using the switch bytecode where appropriate.
First, case ranges are a simple extension because it gives the compiler an easily recognizable dense region of constants. If that range is small enough (ask the JIT guys), then use the switch bytecode so the JIT will generate an efficient JT. If the range is large and the JIT would have done BS anyway, implement the range checks using standard BS techniques. These techniques have been around for over 30 years.
Second, multiple switch expressions are a bit more complicated, but the implementation has existed in pattern matcher compilers for functional languages for over 20 years. In fact, this will be much simpler because it only supports constants. Basically, the compiler builds a decision tree where the case constant/ranges are at the leaves. Then it merges redundant checks and generates BS code and/or uses the switch bytecode to get the JIT to implement a JT.
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 package com.sun.source.tree 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.
4269827 I couldn't find any RFEs for multiple switch expressions.
URL FOR PROTOTYPE (optional):
If there's interest, I can cook up a prototype with Polyglot.
- Previous message: PROPOSAL: Multiple switch expressions and case ranges
- Next message: PROPOSAL: Multiple switch expressions and case ranges
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]