Text Block / String manipulation with Constant Functions.
Brian Goetz
brian.goetz at oracle.com
Wed Aug 14 12:41:52 UTC 2019
Yes, this is an area we have explored in some depth, see his video for a partial status report on this work:
https://www.youtube.com/watch?v=iSEjlLFCS3E
The summary is that this is indeed practical and desirable, but is a substantial project, and poses substantial disruption to the JLS (and indeed, to the foundations of the language.). So it’s not a small thing, but it’s something we’d like to see.
Sent from my iPad
> On Aug 13, 2019, at 9:21 PM, Aaron Scott-Boddendijk <talden at gmail.com> wrote:
>
> Quite a number of discussions (on and off these lists) about the proposed
> Text Blocks and earlier proposal run into the combinatorial problems of
> supporting all the ways in which the string should be converted from it's
> in-source representation for differing uses.
>
> I wonder if we could take a page from a feature I've found useful in Rust
> ('const functions') and in C++ (constexpr functions).
>
> For Java this would mean annotating methods and providing compiler support
> for those methods that, if the compiler find they act entirely on constant
> inputs, will be guaranteed to have a zero runtime cost by computing the
> result during compilation and only storing the result in the output.
>
> Eg
> | var s = " test ".trim();
>
> If trim() was marked as a 'const function' then the actual String in the
> class-file will be "test".
>
> For String there are quite a few methods that this could be useful for,
> that play well with Text Blocks and other String literals - indent, length,
> replace, strip, trim and valueOf methods spring to mind. Adding appendLine,
> trimLeft, trimRight might prove useful too.
>
> Eg
> | var s = """
> | This
> | is
> | a
> | test
> | """.appendLine().indent(2).replace("\n", "\r\n");
> |
> | s.equals(" This\r\n is\r\n a\r\n test\r\n");
>
> This allows the Text Block to consider only embedded indentation and avoid
> the, I believe usually superfluous, trailing line-separator before the
> terminating """. All of the transformations are guaranteed to be applied by
> the compiler so there's no runtime cost (beyond final storage space in the
> class file which might actually be less).
>
> This encodes API detail into the language-level to a greater degree than
> before since a method may be a constant function in language level N but
> not N-1 (though this just moves the cost to runtime). This might be seen as
> undesirable and potentially surprising.
>
> It's not clear if there are reasonable situations in which the constant
> form might not be desired (eg. such as bloating the clasfile with
> "".indent(1_000).replace(" ", "\n").indent(1_000_000)). Would guaranteeing
> execution at class-load be acceptable instead - sometimes perhaps but
> that's just a different part of runtime.
>
> Obviously we still want Text-blocks (and any eventual 'raw string',
> 'interpolated string' features) to be useful without the verbosity of the
> trailing functions in most cases but adding this would give developers
> control without requiring the grammar to become a swiss-army-knife.
>
> This feature could similarly be applied to other classes (some
> java.lang.Math methods for example, just extending how some constant
> expressions are compile-time evaluated).
>
> --
> Aaron Scott-Boddendijk
More information about the amber-dev
mailing list