PROPOSAL: Binary Literals
Mark Thornton
mthornton at optrak.co.uk
Fri Apr 3 02:59:52 PDT 2009
Derek Foster wrote:
>
> I did miss that suggestion, actually. Though now that you've mentioned it:
>
> It's not that I would mind that feature in the compiler ("that feature"
> being compile-time evaluation of common library
> methods which are passed parameters known at compile time). However,
> it doesn't sound terribly easy to implement. Especially when you consider
> the implications of having to do error handling on illegal function
> arguments at compile time, rather than at runtime. In fact, it sounds
> a whole lot more intrusive and a lot more work for the compiler team
> than just being able to parse a simple binary number.
>
They already have to handle the exception resulting from integer
division by zero, so I don't think this makes much difference to compile
time expression evaluation. This is especially true if only methods in
the java namespace were permitted (and these could be restricted to
'easy' methods).
> there is also the fact that some Java platforms simply don't HAVE a Byte
> class. For instance, consider JavaCard:
>
> http://java.sun.com/javacard/
>
> A JavaCard, if you weren't aware, is a literally credit-card-sized computer
>
I was aware it existed but my Java experience hasn't gone any lower than
JavaME. However when expressions are evaluated at compile time the
resulting byte code contains no reference to the source of the
computation -- only the result appears. Thus the fact that Byte isn't
available in the target platform wouldn't matter. For example:
class A {
public static final String STREET="Mead Lane";
}
class B {
public static final String TOWN = "Hertford";
}
class MyApp {
public static final String ADDRESS = A.STREET + "," + B.TOWN;
}
The byte code for MyApp contains
ADDRESS = "Mead Lane, Hertford"
and no reference to classes A, or B. I don't like this behaviour, but it
is what currently happens. I think it was intended to assist with
implementation on restricted environments.
Regards,
Mark Thornton
More information about the coin-dev
mailing list