I should have put that in "Other information":
The simple bug assistant is cool :)

What character do you propose to use for ranges, then?

I'm not sure. The problem is that we're using a C-like notation for caps right
now. In C an array is defined like this:
type array[] = { val1, val2, ... }
That definition has 2 different bracket types, but no < > brackets, so it looks
a bit unnatural.
In this context it's worth thinking about what syntax C-like notations use for
lists and ranges. Ranges are mostly identified via dots in some languages (for
example the GNU extension for switch statements. I'm not sure how nice
"value=(double) 1.234 ... 2.345" looks though. And this notation is missing a
simple identifier for the parser that it's indeed a range and not just
"value=(double) 1.234"

In 0.9, the {} are free because explicit threads are gone. We can use {}. Anyone
wanna patch up 0.9 now?

caps notation != pipeline notation

:)

The API for arrays should also be different from lists to avoid confusion.
I recently committed a wrong "fix" because I didn't get why the same value was
added x times to a list.
Which was of course correct because it was an array, but that was not obvious
from the API used.

There's also lots of special case ifs only executed for (non)fixed lists in the
accessor functions.

Targetting to 0.9.x, one way or another.

I renamed FixedList, I don't want to add extra API so leaving that for others to
fight about.

I think the extra API would make things more clear. Also it would allow type
checking and unambiguous documentation. Adding to bug #319388...

Fixed in CVS