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