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
> 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