Coin Considerations

[Reinier Zwitserloot]

Of all those items, list comprehensions and list literals rank -far-  
higher on my 'general utility' meter than any of the other ones, but  
almost all of them seem doable with a minimum of JLS munging.

list comprehensions, /IF/ they produce a complete list and not a  
lazily evaluating iterable, is just syntax sugar. If they do apply  
lazy evaluation, it inherits most of the problems closure proposals  
try to deal with. Serious doubts about suitability for Project Coin in  
the latter case. Suggestion: [] makes complete lists, there's always  
the opportunity to introduce a slightly alternative syntax in the  
future when/if closures show up in java8 and those issues have already  
been solved - then an iterable based list comprehension is just syntax  
sugared into something involving closures for the generator and filter  
expressions.

List literals are equally complicated; the complication lies in  
correctly parsing a new construct, such as 'stuff in between array  
brackets that does not appear after an expression (because that would  
be array index lookup)' - presuming for a moment that list  
comprehensions use [] as well.

array style access for lists, maps, and strings: I believe Joe D'Arcy  
posted it as a suggestion at the announcement of coin-dev. Support  
from the community has been tepid at best, but in combination with  
comprehensions and slices, I'd be in favour. Much more difficult for  
maps (right now brackets-after-expression wants an integer inside the  
brackets. You'd be changing this for maps to be a K instead). Proposal  
without bracket access for maps would still sound good to me. I don't  
use list.get(X) very often, though...

negative array indices should count backwards: Utterly impossible for  
arrays. Would break backwards compatibility (foo[-1] should produce an  
ArrayIOOBException, people will be relying on that). The notion that  
many things in java return -1 to indicate 'not found' (such as  
String.indexOf) makes this idea a bit more complicated than it might  
seem at first glance, and the idea you could only apply it to Lists,  
not arrays, would be an unfortunate inconsistency. I say: skip this one.

slices: What type of list should roll out? A generic immutable  
List<T>, regardless of what you sliced on? If so, trivial syntax  
sugar: Add a library that produces a sliced list given as input a list  
and 2 numbers, then rewrite all slices to a call to this library. Also  
offers a sneaky way to get the last item in a list without -1 syntax:  
list[-1:0][0]. Alternative outputs: A bound view (which just remembers  
start index and size, and continues to call .get(X+offset) into the  
original list), which would mean removing an item in the original list  
removes it from the sliced list. Such a bound view could support being  
mutable, but that would introduce even more weirdness: Removing an  
item from the original does not shrink the bound view, but removing it  
via the bound vie DOES shrink the bound view. Meh. I strongly suggest  
making slicelists immutable copies to avoid this mess.

autoboxing arrays to lists and vice versa: Because they share part of  
their inheritance tree (specifically: java.lang.Object), that would  
get very confusing, very fast. There's also the issue of covariance:  
Can you autobox an ArrayList<T>[] to a List<List<T>>? Again, type  
issues. I doubt this one is worth it.


  --Reinier Zwitserloot



On Mar 16, 2009, at 11:37, Vilya Harvey wrote:

> 2009/3/14 Reinier Zwitserloot <reinier at zwitserloot.com>
> So what proposals are still fermenting in the minds of coin
> contributors? Inspired by the recent discussion between Joe D'Arcy and
> Mark Mahieu that people are possibly thinking someone else will be
> proposing it.
>
> I had a few things in mind, mostly to do with lists, some of which  
> people have already mentioned:
> list comprehensions.
> either list literals or autoboxing/unboxing conversions between  
> arrays and lists (I haven't really thought this one through yet; I  
> suspect there would be a lot of issues in deciding when to apply the  
> boxing).
> array style access for lists, maps and strings.
> negative array indexes should count from the back of the array (e.g.  
> a[-1] == a[a.length - 1]).
> slice syntax a la python for arrays, lists and strings.
> I'll happily write any of these up, if anyone thinks there'd be  
> enough interest.
>
> Vil.