While looking at the classes and interfaces I started pondering the SortedAA and LinkedAA structs and I'd like to make some non-backwards compatible changes (in case anyone cares give a holler).

1) change key slicing to exclude the upper endpoint. That way one can write nice slicing expressions like dictionary["a" .. "b"] for all the words that start with "a".

2) rename fromHead and fromTail to begin and end to be closer to C++-style iterators. Slices involving subarrays will be inclusive (as before) so that one can write x[x.begin .. x.end] and have it slice the entire thing. I'll add mixed-type slicing so that x["a" .. x.end] works, too.

3) add from(key) and to(key) to get one-item slices. from(key) is the smallest item greater than or equal to key and to(key) is the largest item less than key. So x["a" .. "b"] is equivalent to x[x.from("a") .. x.to("b")]

4) rename Seq to Sequence, SeqWithKeys to IndexedSequence

5) rip out all the mapSeq, findSeq and catSeq.

On Mon, 2005-05-02 at 17:02 -0400, Ben Hinkle wrote:
> While looking at the classes and interfaces I started pondering the SortedAA and LinkedAA structs and I'd like to make some non-backwards compatible changes (in case anyone cares give a holler).
Since I haven't started using MinTL in my stuff, I don't really care.

> 
> 1) change key slicing to exclude the upper endpoint. That way one can write nice slicing expressions like dictionary["a" .. "b"] for all the words that start with "a".
How would one do something like split a table in two?
Previously (as I understand it) it would have been:
dict["a".."m"]
dict["n".."z"]
But with these changes, "a"'s and "z"'s wouldn't be included.

> 
> 2) rename fromHead and fromTail to begin and end to be closer to C++-style iterators. Slices involving subarrays will be inclusive (as before) so that one can write x[x.begin .. x.end] and have it slice the entire thing. I'll add mixed-type slicing so that x["a" .. x.end] works, too.
> 
> 3) add from(key) and to(key) to get one-item slices. from(key) is the smallest item greater than or equal to key and to(key) is the largest item less than key. So x["a" .. "b"] is equivalent to x[x.from("a") .. x.to("b")]
Could I use this to do the above? How would that look?

> 
> 4) rename Seq to Sequence, SeqWithKeys to IndexedSequence
> 
> 5) rip out all the mapSeq, findSeq and catSeq.
> 
> 

John Demme

>> 1) change key slicing to exclude the upper endpoint. That way one can
>> write
>> nice slicing expressions like dictionary["a" .. "b"] for all the words
>> that
>> start with "a".
> How would one do something like split a table in two?
> Previously (as I understand it) it would have been:
> dict["a".."m"]
> dict["n".."z"]
> But with these changes, "a"'s and "z"'s wouldn't be included.

The expression dict["a".."m"] wouldn't include keys like "mud" but it would
include the key "m". Similarly dict["n".."z"] wouldn't include "zed". So it
would only have split the table if it didn't include multi-letter words.
With the new behavior dict["a".."m"] wouldn't include "m". To split dict in
two one could write
dict[dict.begin() .. "m"]
dict["m" .. dict.end()];

>> 3) add from(key) and to(key) to get one-item slices. from(key) is the
>> smallest item greater than or equal to key and to(key) is the largest
>> item
>> less than key. So x["a" .. "b"] is equivalent to x[x.from("a") ..
>> x.to("b")]
> Could I use this to do the above? How would that look?
Another way of writing the above would be
dict[dict.begin() .. dict.to("m")]
dict[dict.from("m") .. dict.end()];
but that's not the main reason for from/to since it's the same as above. The
use for from/to will be for getting "iterators" that one can manipulate
efficiently.