Re: Synopsis 02: Range objects [recap]
On Thu, Aug 27, 2009 at 2:59 AM, Jon Lang 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
Re: Synopsis 02: Range objects [recap]
Jon Lang wrote: 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. Agreed. I should have written that as part of the proposal as well. 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? 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". And just like .. should nummify, the to operator should stringify? Sounds nice. Regards, Michael.
Re: Synopsis 02: Range objects [recap]
Timothy S. Nelson wrote: I think a Complex range only makes sense if you provide 4 endpoints, not 2, but I haven't been following the conversation, so I'll leave it up to the Complex number experts :). (start-angle, start-length) :by(angle-step, length-factor) -- Ruud
Re: Synopsis 02: Range objects [recap]
On Wed, 26 Aug 2009, Michael Zedeler wrote: Thanks to everyone who has posted their thoughts on Ranges. Here are the conclusions I have drawn: Ranges are for checking whether something is within a given interval. RangeIterators are for iterating over elements in a Range with a given step size using :by. We discussed using "Series" or "Sequence" in place of RangeIterator, but Series seems too general and Sequence has already been taken. Up to this point, there are no changes to the spec afaik. Proposed changes: It shouldn't be possible to construct RangeIterators over Str (apart from single length strings) or Complex using the Range operator (..). I haven't been following the conversation, but I've had an idea -- maybe it should be possible to construct a RangeIterator if an ordered set is provided. For example, if the ordered set was '0'.. '9', then the RangeIterator would know that the thing went '0' .. '9', '10' .. '19', '20', etc, whereas if the ordered set was 'a' .. 'z' then it could be something like 'a' .. 'z', 'aa', 'ab' ... 'az', 'ba'... I realise that maybe the first set should've been '1' .. '0' instead, but the general idea is the thing at the moment. I wrote all this, and then saw Jon Lang's idea of providing steppers, which is also good. I think a Complex range only makes sense if you provide 4 endpoints, not 2, but I haven't been following the conversation, so I'll leave it up to the Complex number experts :). HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Synopsis 02: Range objects [recap]
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
Re: Synopsis 02: Range objects [recap]
Thanks to everyone who has posted their thoughts on Ranges. Here are the conclusions I have drawn: Ranges are for checking whether something is within a given interval. RangeIterators are for iterating over elements in a Range with a given step size using :by. We discussed using "Series" or "Sequence" in place of RangeIterator, but Series seems too general and Sequence has already been taken. Up to this point, there are no changes to the spec afaik. Proposed changes: It shouldn't be possible to construct RangeIterators over Str (apart from single length strings) or Complex using the Range operator (..). 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? Regards, Michael Zedeler.
