Michael Zedeler wrote:
> Proposed changes:
> It shouldn't be possible to construct RangeIterators over Str (apart from
> single length strings) or Complex using the Range operator (..).

I'd go one step further with Complex, to say that Range isn't a useful
concept at all so long as "before" and "after" are undefined.

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

> Next open question:
> What about Ranges using different types in each endpoint?
> 1.5 .. 10 :by(0.5)
> (Rat .. Int)
> "0" .. 7
> Should they be coerced - and in that case to what? If we don't coerce them,
> what should be returned?

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

Jonathan "Dataweaver" Lang

Reply via email to