PROPOSAL: Multiple switch expressions and case ranges

Joseph D. Darcy Joe.Darcy at Sun.COM
Tue Mar 17 14:44:10 PDT 2009


Greetings.

While pattern matching is common in functional languages, my assessment 
is that the effort / reward ratio of this change for Java programs is 
not favorable for inclusion in the platform.

-Joe

Pinku Surana wrote:
> 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.
>
>   




More information about the coin-dev mailing list