JEP 186: Collection Literals

[Per Bothner]

On 01/14/2014 03:02 PM, Richard Warburton wrote:
> Is there any real reason to restrict the proposal to implementing any
> specific interface? It seems preferable to able to specify some kind of
> recipe or factory for building an arbitrary concrete type out of a
> collection literal.

For example, one could define:

T v = { e1, ..., en}

as syntactic sugar for:

TB tmp = T.make_builder();
tmp.add(e1); ..; tmp.add(en);
T v = tmp.build();

The type TB is inferred as the return type of make_builder.
It may be the same as T, and TB.build is allowed to return
the argument - perhaps after sealing it as immutable.

[The following goes quite a bit beyond Collection Literals,
and is probably not appropriate for Java, unless we come up
with a very simple and general-purpose syntactic sugar.]

If you're going that route, one might consider literals
for non-collection classes as well.  These often need a
string-based syntax.  For example:

T#{literal[exp]text}

could be syntactic sugar for:

T.valueOf("literal"+(exp)+"text")

Campl p4 has an interesting quotation syntax:
http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html

Kawa has a quite flexible syntax:

&T[prefix-exp1 ... prefix-expn}{literal&[exp]text}he

http://srfi.schemers.org/srfi-108/srfi-108.html

This syntax leads to a neat syntactic sugaring of ProcessBuilder:

&`[out-to: "/tmp/msg"]{echo The directory is: &`{pwd}}

This is equivalent to the shell command:

echo The directory is: `pwd` >/tmp/msg

http://per.bothner.com/blog/2014/Kawa-shell-programming/
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/