change signature of concatenate() to take an Iterable

[jvasileff]

Currently, there is an asymmetry in the signatures of expand and concatenate:

shared Element[] concatenate<Element>({Element*}* iterables)

shared Iterable<Element,OuterAbsent|InnerAbsent> expand<Element, OuterAbsent, InnerAbsent>
    (Iterable<Iterable<Element,InnerAbsent>,OuterAbsent> iterables)
    given OuterAbsent satisfies Null
    given InnerAbsent satisfies Null {}

with, IMO, the non-variadic iterables in expand being better, providing the following benefits:

1. In some cases, the production of a nonempty result
2. More convenient syntax for named argument invocations

I believe the second point is an important one, since when programming with apis such as ceylon.ast and ceylon.html, it is far more convenient to always use named argument lists, to avoid confusion between ) and } in the middle of large expressions.

In the examples below, the first is superior:

    printAll {
        expand {
            {"a", "b"},
            {"c", "d"}
        };
    };

    printAll {
        concatenate(
            {"a", "b"},
            {"c", "d"}
        );
    };

    printAll {
        concatenate {
            [
                {"a", "b"},
                {"c", "d"}
            ];
        };
    };

[jvasileff]

In some cases, the production of a nonempty result

Not sure why I keep making that mistake about sequences... nevertheless, this is much better and more consistent:

shared [Element*] concatenate<Element>({{Element*}*} iterables)
    =>  [ for (it in iterables) for (val in it) val ];

[gavinking]

Well I agree, but it would be a breaking change to a function signature that has been there forever. I really added expand() pretty much as a replacement for concatenate(), which is a function I no longer ever use.

[jvasileff]

I too didn't find much use for concatenate(), until I started doing a lot of work with tree-like structures, for which I've found them to be indispensable.

You might say that parameters should just be Iterables, but even when you don't necessarily care about the type, it gets complicated:

void treeLikeTests() {
    void si1({String*} strs = {}, {Integer*} ints = {}) {}
    void si2([String*] strs = [], {Integer*} ints = {}) {}

    si1 { 1, 3, 3, 4 }; // error
    si2 { 1, 3, 3, 4 }; // ok
}

So, I'd generally use si2, and concatenate() to help form the argument for strs in long expressions. expand() is helpful too, but often with .coalesced.sequence().

Using Sequentials is often correct for the trailing parameter too, for immutability and performance.

[gavinking]

I mean concatenate() is fundamentally just expand {}.sequence() so I guess I don't see what the big deal is. I would prefer not to make a breaking change right now.

[jvasileff]

so I guess I don't see what the big deal is

The concern is exactly as I said. It's a PITA to get line endings right in long expressions. Using expand doesn't help at all for this.

I would prefer not to make a breaking change right now

Ok, if that's the answer, I understand.

This isn't a big enough issue on it's own (or even close to it), but I like Apple's approach with Swift for a young language: don't promise source compatibility between releases, but do promise best effort in providing automated fixes in the IDE for project upgrades.

[FroMage]

Is that really for 1.2?

[gavinking]

No.

Sent from my iPhone

On 21 Sep 2015, at 17:05, Stéphane Épardaud notifications@github.com wrote:

Is that really for 1.2?

—
Reply to this email directly or view it on GitHub.