list.split-at should return a tuple

[sorawee]

No description provided.

[blerner]

Maybe yeah, maybe no. Having mnemonically named .prefix and .suffix fields, rather than .{0} and .{1}, is a win for readability, but now that we have tuple bindings, maybe tuples are better. I don't want to change this API signature yet, though.

[sorawee]

I will argue that if we want only either .{0} or .{1}, then we can use take or drop instead. We would only use split-at when we need both. Thus:

{a; b} = lists.split-at(...)
... a ... b ...

instead of:

splited = lists.split-at(...)
... splited.prefix ... splited.suffix ...

seems to be better.

But yes, this is a very low priority issue.

[shriram]

For sure. In fact, a lot of libraries can now exploit tuples, now that they're here. Basically, any place where Common Lisp would have returned multiple values…

[blerner]

I don't think we want to do that, necessarily, actually. Yes of course, if you only need one piece then you should use take or drop accordingly. But keeping in mind that a mantra of our pedagogy has been "give it a name", it seems like an unfortunate step back to then re-anonymize return values and either rely on punctuation-heavy {x; y} = bindings or punctuation-heavy and cryptic .{0} accessors to get the parts of the result. I think splited.prefix and splited.suffix read better, for many cases, than {a; b} = ... -- even just in this example comment, you automatically picked a better name for the split list than you did for the pieces! Returning multiple values is a non-novice feature; I don't think our APIs should all skew that way just because they can (even if, as expert programmers, we'd prefer to use them that way).

And who knows, hypothetically, I could easily see a {field-name => binding, field-name => binding} = binding form to do destructuring assignment of objects, too, which would make the object case as easy to work with as tuples, while still being more self-explanatory and readable...

[jpolitz]

I have a really frustrating moment of friction every time I use partition and split-at where I have to go look up the field names in the docs. If it were a tuple I would get it right every time, and use them more. In fact, when writing 070fdf0, where @blerner suggested that I use partition, I didn't simply because I didn't want to look it up because I was trying to fix it quickly.

Naming is good, and tupling lets the user of a function easily pick their own names – even better! Remembering names is hard, and I think is good to avoid.

Even in the object destructuring case, you have to remember the field names for every multiple-value-returning function, which is cognitive/memory overhead.

[shriram]

So much wisdom in ^^this^^ comment.

[blerner]

There are a lot of devil-in-the-details counterarguments to this, even when I agree with most of it. E.g., width-subtyping means you only need to bind the fields you care about, or intellisense improves the ergonomics of records, or having better/easier-to-use documentation to make finding field names easier. Yes, clearly, picking your own names can be better than remembering the ones we supply. But the additional burdens are (1) learning the tuple syntax (either binding or accessing), (2) choosing multiple good names, (3) remembering that a function returns a tuple that you're supposed to destruct in the first place. It's not an obvious immediate win to me. I expect the eventual pyret-IDE will be a lot more helpful for object-based APIs than tuple-based ones. And I think problems 1 and 2 will be turn-offs for a lot of novices, for whom extra punctuation and syntactic overhead of tuples will be more burdensome than looking up the documentation of a given API to find out its field names.

So my point remains: I don't think we should skew all our APIs to use tuples just because we can.

[sorawee]

By the way, the new take-while (which in my opinion should still be named something else -- brownplt/pyret-docs#22) also returns a tuple :) For the sake of API's consistency, split-at should return a tuple as well, or that take-while should return an object.