PROPOSAL: Binary Literals
Gaseous Fumes
vapor1 at teleport.com
Wed Mar 25 12:35:19 PDT 2009
A couple of quick notes:
1) Ruby already has this. (The underscores in numbers, that is)
2) I considered adding this to the proposal as I was writing it, but decided it was an orthogonal issue and deserved its own proposal, since it has nothing per se to do with binary literals. (As James mentions, it would make sense for all numbers, not just binary ones.)
3) I encourage someone else to write it up as a proposal. If I get done with the other proposals I intend to submit, and still have time, I might do it myself, but if you want to ensure that the proposal gets proposed, I suggest you don't wait for me. One caveat: Consider the impact on Integer.parseInt, Long.decode(), etc. (I suggest the decode methods get changed to accept underscores, but the parseInt ones don't.)
4) An observation to Joe Darcy and the other Sun engineers involved in reviewing proposals: The expected "about five" limit on proposals really encourages people to lump a bunch of semi-related things into one proposal rather than making each their own proposal, even when the latter would be a more logical way of getting individual orthogonal ideas reviewed separately. I think this is a problem.
For instance, the "null safe operators" proposal (all or nothing) vs. splitting each of them out as individual proposals. There have been a number of proposals put forth where I thought "I agree with half of this proposal and wish the other half wasn't in the same proposal."
I hope that the "about" in "about five" is flexible enough to allow a bunch of very minor proposals to expand that limit well past five if they seem good ideas and easy to implement with few repercussions. Five seems like a pretty low number to me, given that it's been MANY years since it was even possible for users to suggest changes to Java (basically, since JDK 5 was in the planning stages, as JDK 6 was announced to be a "no language changes" release), and there has been much evolution in other programming languages during that time. I think that good ideas should make it into Java (and bad ideas shouldn't) subject to the necessary manpower in review and implementation, regardless of the number of proposals used to submit them. Otherwise, Java risks getting left in the dust as other languages become much easier to use, much faster.
Derek
-----Original Message-----
>From: james lowden <jl0235 at yahoo.com>
>Sent: Mar 25, 2009 12:07 PM
>To: coin-dev at openjdk.java.net
>Subject: Re: PROPOSAL: Binary Literals
>
>
>Actually, that's a good idea in general for long numeric constants. 9_000_000_000_000_000L is easier to parse than 9000000000000000L.
>
>
>--- On Wed, 3/25/09, Stephen Colebourne <scolebourne at joda.org> wrote:
>
>> From: Stephen Colebourne <scolebourne at joda.org>
>> Subject: Re: PROPOSAL: Binary Literals
>> To: coin-dev at openjdk.java.net
>> Date: Wednesday, March 25, 2009, 1:50 PM
>> See
>> http://www.jroller.com/scolebourne/entry/changing_java_adding_simpler_primitive
>> for my take on this from long ago.
>>
>> In particular, I'd suggest allowing a character to
>> separate long binary strings:
>>
>> int anInt1 = 0b10100001_01000101_10100001_01000101;
>>
>> much more readable.
>>
>> Stephen
>>
>> 2009/3/25 Derek Foster <vapor1 at teleport.com>:
>> > Hmm. Second try at sending to the list. Let's see
>> if this works. (In the
>> > meantime, I noticed that Bruce Chapman has mentioned
>> something similar in his
>> > another proposal, so I think we are in agreement on
>> this. This proposal
>> > should not be taken as to compete with his similar
>> proposal: I'd quite like
>> > to see type suffixes for bytes, shorts, etc. added to
>> Java, in addition to
>> > binary literals.) Anyway...
>> >
>> >
>> >
>> >
>> > Add binary literals to Java.
>> >
>> > AUTHOR(S): Derek Foster
>> >
>> > OVERVIEW
>> >
>> > In some programming domains, use of binary numbers
>> (typically as bitmasks,
>> > bit-shifts, etc.) is very common. However, Java code,
>> due to its C heritage,
>> > has traditionally forced programmers to represent
>> numbers in only decimal,
>> > octal, or hexadecimal. (In practice, octal is rarely
>> used, and is present
>> > mostly for backwards compatibility with C)
>> >
>> > When the data being dealt with is fundamentally
>> bit-oriented, however, using
>> > hexadecimal to represent ranges of bits requires an
>> extra degree of
>> > translation for the programmer, and this can often
>> become a source of errors.
>> > For instance, if a technical specification lists
>> specific values of interest
>> > in binary (for example, in a compression encoding
>> algorithm or in the
>> > specifications for a network protocol, or for
>> communicating with a bitmapped
>> > hardware device) then a programmer coding to that
>> specification must
>> > translate each such value from its binary
>> representation into hexadecimal.
>> > Checking to see if this translation has been done
>> correctly is accomplished
>> > by back-translating the numbers. In most cases,
>> programmers do these
>> > translations in their heads, and HOPEFULLY get them
>> right. however, errors
>> > can easily creep in, and re-verifying the results is
>> not straightforward
>> > enough to be done frequently.
>> >
>> > Furthermore, in many cases, the binary representations
>> of numbers makes it
>> > much more clear what is actually intended than the
>> hexadecimal one. For
>> > instance, this:
>> >
>> > private static final int BITMASK = 0x1E;
>> >
>> > does not immediately make it clear that the bitmask
>> being declared comprises
>> > a single contiguous range of four bits.
>> >
>> > In many cases, it would be more natural for the
>> programmer to be able to
>> > write the numbers in binary in the source code,
>> eliminating the need for
>> > manual translation to hexadecimal entirely.
>> >
>> >
>> > FEATURE SUMMARY:
>> >
>> > In addition to the existing "1" (decimal),
>> "01" (octal) and "0x1"
>> > (hexadecimal) form of specifying numeric literals, a
>> new form "0b1" (binary)
>> > would be added.
>> >
>> > Note that this is the same syntax as has been used as
>> an extension by the GCC
>> > C/C++ compilers for many years, and also is used in
>> the Ruby language, as
>> > well as in the Python language.
>> >
>> >
>> > MAJOR ADVANTAGE:
>> >
>> > It is no longer necessary for programmers to translate
>> binary numbers to and
>> > from hexadecimal in order to use them in Java
>> programs.
>> >
>> >
>> > MAJOR BENEFIT:
>> >
>> > Code using bitwise operations is more readable and
>> easier to verify against
>> > technical specifications that use binary numbers to
>> specify constants.
>> >
>> > Routines that are bit-oriented are easier to
>> understand when an artifical
>> > translation to hexadecimal is not required in order to
>> fulfill the
>> > constraints of the language.
>> >
>> > MAJOR DISADVANTAGE:
>> >
>> > Someone might incorrectly think that "0b1"
>> represented the same value as
>> > hexadecimal number "0xB1". However, note
>> that this problem has existed for
>> > octal/decimal for many years (confusion between
>> "050" and "50") and does not
>> > seem to be a major issue.
>> >
>> >
>> > ALTERNATIVES:
>> >
>> > Users could continue to write the numbers as decimal,
>> octal, or hexadecimal,
>> > and would continue to have the problems observed in
>> this document.
>> >
>> > Another alternative would be for code to translate at
>> runtime from binary
>> > strings, such as:
>> >
>> > int BITMASK =
>> Integer.parseInt("00001110", 2);
>> >
>> > Besides the obvious extra verbosity, there are several
>> problems with this:
>> >
>> > * Calling a method such as Integer.parseInt at runtime
>> will typically make it
>> > impossible for the compiler to inline the value of
>> this constant, since its
>> > value has been taken from a runtime method call.
>> Inlining is important,
>> > because code that does bitwise parsing is often very
>> low-level code in tight
>> > loops that must execute quickly. (This is particularly
>> the case for mobile
>> > applications and other applications that run on
>> severely resource-constrained
>> > environments, which is one of the cases where binary
>> numbers would be most
>> > valuable, since talking to low-level hardware is one
>> of the primary use cases
>> > for this feature.)
>> >
>> > * Constants such as the above cannot be used as
>> selectors in 'switch'
>> > statements.
>> >
>> > * Any errors in the string to be parsed (for instance,
>> an extra space) will
>> > result in runtime exceptions, rather than compile-time
>> errors as would have
>> > occurred in normal parsing. If such a value is
>> declared 'static', this will
>> > result in some very ugly exceptions at runtime.
>> >
>> >
>> > EXAMPLES:
>> >
>> > // An 8-bit 'byte' literal.
>> > byte aByte = (byte)0b00100001;
>> >
>> > // A 16-bit 'short' literal.
>> > short aShort = (short)0b1010000101000101;
>> >
>> > // Some 32-bit 'int' literals.
>> > int anInt1 = 0b10100001010001011010000101000101;
>> > int anInt2 = 0b101;
>> > int anInt3 = 0B101; // The B can be upper or lower
>> case as per the x in
>> > "0x45".
>> >
>> > // A 64-bit 'long' literal. Note the
>> "L" suffix, as would also be used
>> > // for a long in decimal, hexadecimal, or octal.
>> > long aLong =
>> >
>> 0b01010000101000101101000010100010110100001010001011010000101000101L;
>> >
>> > SIMPLE EXAMPLE:
>> >
>> > class Foo {
>> > public static void main(String[] args) {
>> > System.out.println("The value 10100001 in
>> decimal is " + 0b10100001);
>> > }
>> >
>> >
>> > ADVANCED EXAMPLE:
>> >
>> > // Binary constants could be used in code that needs
>> to be
>> > // easily checkable against a specifications document,
>> such
>> > // as this simulator for a hypothetical 8-bit
>> microprocessor:
>> >
>> > public State decodeInstruction(int instruction, State
>> state) {
>> > if ((instruction & 0b11100000) == 0b00000000) {
>> > final int register = instruction &
>> 0b00001111;
>> > switch (instruction & 0b11110000) {
>> > case 0b00000000: return state.nop();
>> > case 0b00010000: return
>> state.copyAccumTo(register);
>> > case 0b00100000: return
>> state.addToAccum(register);
>> > case 0b00110000: return
>> state.subFromAccum(register);
>> > case 0b01000000: return
>> state.multiplyAccumBy(register);
>> > case 0b01010000: return
>> state.divideAccumBy(register);
>> > case 0b01100000: return
>> state.setAccumFrom(register);
>> > case 0b01110000: return
>> state.returnFromCall();
>> > default: throw new IllegalArgumentException();
>> > }
>> > } else {
>> > final int address = instruction & 0b00011111;
>> > switch (instruction & 0b11100000) {
>> > case 0b00100000: return state.jumpTo(address);
>> > case 0b01000000: return
>> state.jumpIfAccumZeroTo(address);
>> > case 0b01000000: return
>> state.jumpIfAccumNonzeroTo(address);
>> > case 0b01100000: return
>> state.setAccumFromMemory(address);
>> > case 0b10100000: return
>> state.writeAccumToMemory(address);
>> > case 0b11000000: return state.callTo(address);
>> > default: throw new IllegalArgumentException();
>> > }
>> > }
>> > }
>> >
>> > // Binary literals can be used to make a bitmap more
>> readable:
>> >
>> > public static final short[] HAPPY_FACE = {
>> > (short)0b0000011111100000;
>> > (short)0b0000100000010000;
>> > (short)0b0001000000001000;
>> > (short)0b0010000000000100;
>> > (short)0b0100000000000010;
>> > (short)0b1000011001100001;
>> > (short)0b1000011001100001;
>> > (short)0b1000000000000001;
>> > (short)0b1000000000000001;
>> > (short)0b1001000000001001;
>> > (short)0b1000100000010001;
>> > (short)0b0100011111100010;
>> > (short)0b0010000000000100;
>> > (short)0b0001000000001000;
>> > (short)0b0000100000010000;
>> > (short)0b0000011111100000;
>> > }
>> >
>> > // Binary literals can make relationships
>> > // among data more apparent than they would
>> > // be in hex or octal.
>> > //
>> > // For instance, what does the following
>> > // array contain? In hexadecimal, it's hard to
>> tell:
>> > public static final int[] PHASES = {
>> > 0x31, 0x62, 0xC4, 0x89, 0x13, 0x26, 0x4C, 0x98
>> > }
>> >
>> > // In binary, it's obvious that a number is being
>> > // rotated left one bit at a time.
>> > public static final int[] PHASES = {
>> > 0b00110001,
>> > 0b01100010,
>> > 0b11000100,
>> > 0b10001001,
>> > 0b00010011,
>> > 0b00100110,
>> > 0b01001100,
>> > 0b10011000,
>> > }
>> >
>> >
>> > DETAILS
>> >
>> > SPECIFICATION:
>> >
>> > Section 3.10.1 ("Integer Literals") of the
>> JLS3 should be changed to add the
>> > following:
>> >
>> > IntegerLiteral:
>> > DecimalIntegerLiteral
>> > HexIntegerLiteral
>> > OctalIntegerLiteral
>> > BinaryIntegerLiteral // Added
>> >
>> > BinaryIntegerLiteral:
>> > BinaryNumeral IntegerTypeSuffix_opt
>> >
>> > BinaryNumeral:
>> > 0 b BinaryDigits
>> > 0 B BinaryDigits
>> >
>> > BinaryDigits:
>> > BinaryDigit
>> > BinaryDigit BinaryDigits
>> >
>> > BinaryDigit: one of
>> > 0 1
>> >
>> > COMPILATION:
>> >
>> > Binary literals would be compiled to class files in
>> the same fashion as
>> > existing decimal, hexadecimal, and octal literals are.
>> No special support or
>> > changes to the class file format are needed.
>> >
>> > TESTING:
>> >
>> > The feature can be tested in the same way as existing
>> decimal, hexadecimal,
>> > and octal literals are: Create a bunch of constants in
>> source code, including
>> > the maximum and minimum positive and negative values
>> for integer and long
>> > types, and verify them at runtime to have the correct
>> values.
>> >
>> >
>> > LIBRARY SUPPORT:
>> >
>> > The methods Integer.decode(String) and
>> Long.decode(String) should be modified
>> > to parse binary numbers (as specified above) in
>> addition to their existing
>> > support for decimal, hexadecimal, and octal numbers.
>> >
>> >
>> > REFLECTIVE APIS:
>> >
>> > No updates to the reflection APIs are needed.
>> >
>> >
>> > OTHER CHANGES:
>> >
>> > No other changes are needed.
>> >
>> >
>> > MIGRATION:
>> >
>> > Individual decimal, hexadecimal, or octal constants in
>> existing code can be
>> > updated to binary as a programmer desires.
>> >
>> >
>> > COMPATIBILITY
>> >
>> >
>> > BREAKING CHANGES:
>> >
>> > This feature would not break any existing programs,
>> since the suggested
>> > syntax is currently considerd to be a compile-time
>> error.
>> >
>> >
>> > EXISTING PROGRAMS:
>> >
>> > Class file format does not change, so existing
>> programs can use class files
>> > compiled with the new feature without problems.
>> >
>> >
>> > REFERENCES:
>> >
>> > The GCC/G++ compiler, which already supports this
>> syntax (as of version 4.3)
>> > as an extension to standard C/C++.
>> > http://gcc.gnu.org/gcc-4.3/changes.html
>> >
>> > The Ruby language, which supports binary literals:
>> > http://wordaligned.org/articles/binary-literals
>> >
>> > The Python language added binary literals in version
>> 2.6:
>> >
>> http://docs.python.org/dev/whatsnew/2.6.html#pep-3127-integer-literal-support-and-syntax
>> >
>> > EXISTING BUGS:
>> >
>> > "Language support for literal numbers in binary
>> and other bases"
>> >
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025288
>> >
>> > URL FOR PROTOTYPE (optional):
>> >
>> > None.
>> >
>> >
>
>
>
>
More information about the coin-dev
mailing list