Lineups and ranges

[KimBruce]

I have some concerns about our notations for lineups and ranges:

[1,2,3] is a lineup with three consecutive integers (with type Iterable[[Number]]) (1..3) is a range with three consecutive integers (with type Sequence[[Number]]) [1..3] is a lineup with a single element that is a range of 3 consecutive integers with type Iterable[[Sequence[[Number]] ]]).

The last is likely to be highly confusing to students.

Did we ever talk about possibly using the notation [i..n] for a lineup with elements from i to n?

A different, but related issue:

Is there any reason a lineup shouldn't have type Sequence? I think we all just look at it as an immutable list.

Bottom line, is the collections class too complex for novices just learning Grace. I don't mind having types with finer gradations as long as I'm not forced to talk about them. I.e., in an intro course, I'd like to be able to talk about Sequences and Lists (immutable vs mutable), but not mention anything else. But if a student looks at the documentation then they also have to figure out Iterable because of lineups. If lineups are Sequences then that is one less thing to worry about.

[kjx]

Did we ever talk about possibly using the notation [i..n] for a lineup with elements from i to n?

Nope - and it's hard to see how that would work with 1..n being a request of ..n to 1. It may be easiest to attack this syntactically, not using a ".." operator but writing, I dunno "range(1,n)" or 1.upTo(n) or something instead. At least [ range(1,n) ] is a bit easier to follow.

But the fundamental difference between [1..3] and (1..3) is an inescapable "feature" of the lineup design. Again, writing seq (1..3) would make things more explicit: seq(range(1,3)) even more so. But this leads us away from lineups (even though with overriding on arity with can do without them - #94).

Is there any reason a lineup shouldn't have type Sequence? I think we all just look at it as an immutable list.

"Lineups" will end up having the most general immutable sequence type. We should just give in an adopt that now.

I'd like to be able to talk about Sequences and Lists (immutable vs mutable)

which means Lineups have to be sequences (or vice versa) or else you have to talk about three entities (Lineups, Sequences, and Lists) which would annoy William of Ockham.

[apblack]

We can make [ ] mean sequence if you want. The basic different between a collection and a sequence is that the collection isn't indexable, whereas the sequence is. This is motivated by lazy collections, where indexing is O(n) rather than O(1). But since literals with [ and ] are eager by construction, I don't see that we loose anything by making them sequences.

As for .., it's just an operator. If you don't like it, you don't have to use it. Until numbers are pluggable, it's hard to take it out, but one could make a dialect that flagged .. as illegal.

[kjx]

I'd rather get rid of "[ ]" all together - certainly get rid of its pervasive use for creating collections.

Collection & Sequence is an important distinction, although I'm not sure those are ultimately the best terms. Java now uses "stream" for lazy use-once collections, which I quite like. The motivation is laziness and parallelism. Streams may have a definite size, or an unknown size (for laziness or filtering etc); these sizes are used to control parallelism.

the catch with ".." is it's kind of special cased. "." and "..." are reserved syntax, but ".." is just a normal operator. Dropping "..." would reduce the special case.

[kjx]

decided to leave things as they are pending potential removal of [ ] notation