On Thu, Aug 27, 2009 at 2:59 AM, Jon Lang<datawea...@gmail.com> wrote: > Michael Zedeler wrote: >> Jon Lang wrote: >>> As for Str, I'm not sure that we should go so far as to say that you >>> _can't_ create RangeIterators over them, so much as to say that the >>> default step algorithm is defined only for single-character strings, >>> and fails if you give it anything else. In particular, the programmer >>> should be allowed to enable Str-based RangeIterators by explicitly >>> supplying his own step algorithm. That is: >>> >>> 'aa' .. 'zz' # Error in list context: default stepper rejects >>> multi-character endpoints >>> 'aa' .. 'zz' :by(&stepper) # custom stepper overrides default concerns >>> >> >> The difference between this and the triple dot-operator is that we provide >> an upper bound (and are forced to use the :by-adverb). Is it worth the >> while? > > It _does_ give you an upper bound, which "..." doesn't do. > >>> This is only a half-formed thought at the moment, so please bear with >>> me: maybe Ranges should extend the triptych that exists with >>> comparison operators. That is, you have "before" and "after", "lt" >>> and "gt", and "<" and ">"; you also have "cmp", "leg", and "<=>". >>> Perhaps ".." should be treated as the numeric operator, and equivalent >>> Str and generic operators should be supplied separately. I'd be >>> inclined to spell the generic Range operator - the one corresponding >>> to "before"/"after"/"cmp" - as "to". I'm not sure how the Str-based >>> one ought to be spelled. >>> >>> With "..", there should be automatic coercion of both endpoints to >>> numbers, just as there is with "<" and ">". With "to", there should >>> be no coercion at all, just like "before" "after", and "cmp". >> >> And just like .. should nummify, the to operator should stringify? >> >> Sounds nice. > > No. Technically, there should be three versions: a generic version > that does no coercion; the version that nummifies; and the version > that stringifies. I can only think of two names to use; so unless > someone else can come up with a viable third name, we have to do > without one of the three. The one that stringifies is the most > expendible, since one can always explicitly stringify when no coercion > is implicitly done, but there's no way _not_ to stringify if it _is_ > implicitly done. And stringified ranges aren't nearly as important to > have as numified ones are. > > -- > Jonathan "Dataweaver" Lang >
-- Jonathan "Dataweaver" Lang
