On Sun, May 18, 2014 at 11:55 AM, Nicolas Cellier < [email protected]> wrote:
> > > > 2014-05-18 19:19 GMT+02:00 Eliot Miranda <[email protected]>: > > >> >> >> On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe <[email protected]>wrote: >> >>> >>> On 18 May 2014, at 18:50, Eliot Miranda <[email protected]> wrote: >>> >>> > On May 18, 2014, at 7:59 AM, kilon alios <[email protected]> >>> wrote: >>> > >>> >> yes I know, I was just wondering if that was normal behaviour because >>> it looks quite confusing to me. >>> > >>> > Personally I find it a natural way of expressing an empty interval. >>> to: is syntactic sugar for to:by:, and so the default of 1 for the step >>> (the by: arg) is expected. >>> > >>> > I'm dissatisfied however that I can't write $A to: $Z, or 1 to: >>> Infinity positive (or 1 to: Float inf, ugh). >>> >>> > It should be coupled to some lazy protocol (like Xtreams) otherwise any > selector is going to loop infinitely. > Of course it should. But there are other things. For examp,le, Smalltalk-80 had an InfiniteForm and it always bugged me that InfiniteForm>>extent answered SmallInteger maxVal@SmallInteger maxVal. If one changed that to answer Infinity positive@Infinity positive it was Interval code that broke. So (at least in my image) I fixed the Interval code. Intervals are really useful for modelling things, not just iterating. > >> Since there is Character>>#to: you can actually write $A to: $Z >>> although it returns an Array instead of a String, but that can be solved >>> with >>> >>> ($a to: $z) as: String >>> >>> or >>> >>> String withAll: ($a to: $z) >>> >> >> > Not that it answers a String in Squeak, because this seemed a more natural > recipient than OrderedCollection to me (OrderedCollection it previously > was). > > >> Ugh, that's really bad. So if I want to construct an interval over the >> Unicode characters this hack instantiates a large string. The whole point >> about an Interval is to compute a set of values, not construct a >> collection. If I want to construct a collection I can. >> >> I would add a subclass of Interval, say NonArithmeticInterval, that sent >> successor: step or predecessor: step so that e.g. >> Character>>successor: n >> ^Character value: self asInteger + n >> >> >> > Oh yes, that's coming directly from ASCII era when it did not matter. > ... but then also to:do: and inlined variants will have to be hacked. > Wouldn't the cost be a bit prohibitive? > The inlined versions need only to work with integers. to:by:do: is a different animal to to:by:. Once we have a good adaptive optimizer the answer can be different, but for now... > > Eliot (phone) >>> >> On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda < >>> [email protected]> wrote: >>> >> Hi Kilon, >>> >> >>> >> On May 18, 2014, at 6:32 AM, kilon alios <[email protected]> >>> wrote: >>> >> >>> >> > while I was recording my Interval video tutorial I observed that >>> Interval does not behave as I would expect . Even though (1 to: 100) works >>> as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the >>> interval object but it does not populate it with the numbers. >>> >> > >>> >> >>> >> You have to say >>> >> 1 to: -100 by: -1 >>> >> >>> >> > I would expect it to populate the interval with the numbers or at >>> least fail with an error. This does not look to me like normal behaviour. >>> >> > >>> >> > (-100 to: 1) on the other hand work as expected. >>> >> > >>> >> > Any thoughts on this issue ? >>> >> >>> >> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> > > -- best, Eliot
