Text Block / String manipulation with Constant Functions.

[Aaron Scott-Boddendijk]

I'd read some off the discussion on Constable and ConstantDesc during the
JDK 12 dev cycle though I hadn't seen the presentation (which is a really
good summary, thanks for that).

Looking at some of the frameworks we use, the constant-folding could bring
fairly significant results (looking at how we build query-fragments for
requests to Elasticsearch and numerous examples in parts of the
Spring-framework and just with some of our own builder patterns).

It is a shame that we can't leverage that to get to the cases that would
help with the ergonomics around text-block quickly but I understand that
baking anything like that into the language itself needs to be carefully
considered. I just hope that we don't try to do too much now with the
text-blocks literal that would be better served via constant
folding/propagation later.

Thanks again for the link - the presentation was excellent and as more of
our projects finally break free of Java 8 (the bottleneck now being effort
rather than technical barriers) I will definitely be looking to make use of
this.

Right, now stop reading my prattle and get back to finishing features :)

--
Aaron Scott-Boddendijk

On Thu, Aug 15, 2019 at 12:41 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>
>