I would expect 1:0 to give me an empty sequence
because (a) for all other natural numbers n,
1:n gives me a sequence of n numbers, and (b)
how else am I supposed to get an empty sequence?
Under your interpretation, (x to: y) would never
be empty.
This has absolutely nothing to do with C.
As I commented, every programming language I
know except S uses a default increment of +1
in counted loops, if it allows default increments
at all. Fortran, Algol 68, Pascal, PL/I, the
seq(1) command in Unix, Haskell, the `seq'
function in Erlang, between/3 in Prolog, OCaml,
F#, InterLISP-D, and so it goes.
Fortran is an interesting case, because Fortran 66
left DO label id = lower,upper
unspecified when lower > upper and several compilers
made such loops execute once, to the point where
programmer tended to think the standard required that,
but Fortran 77 nailed it down: NO iterations in that
case.
Here's a typical use of #to:do:
s := 0.
1 to: a size do: [:i |
a at: i put: (s := (a at: i) + s)].
Why would you think it a good idea for this
to crash if the array is empty?
Smalltalk being Smalltalk, nothing stops you adding
through: end do: aBlock
self to: end by: (end < self ifTrue: [-1] ifFalse: [1])
do: aBlock.
to Integer if you really want to.
Oh, there's an ambiguity. Should
5 through 1 mean 5,4,3,2,1 or 1,2,3,4,5?
Both can be argued for.
On Fri, 1 Mar 2019 at 02:03, Tim Mackinnon <tim@testit.works> wrote:
> Hi Richard - but why would you expect 1 to: 0 to give you an empty
> sequence?
>
> If I inspect “0 to: 1” I see:
> 1 -> 0
> 2 -> 1
>
> So I would expect “1 to: 0” to see:
> 1 -> 1
> 2 -> 0.
>
> I asked for a sequence going from 1 down to 0 (in my mind). Knowing about
> all the by: -1 stuff seems very C’ish.
>
> Of course, I get that maybe it will break peoples existing code (and maybe
> that would be why it never gets changed) - but it still feels very strange.
> Or am I missing something?
>
> Tim
>
> On 28 Feb 2019, at 12:38, Richard O'Keefe <rao...@gmail.com> wrote:
>
> Of the couple of hundred programming languages I have
> used, there is precisely one that does what you expect
> (the S programming language, as implemented in R).
> And it is a major pain in the posterior with no upside
> that I can discern.
>
> Suppose I want a sequence of n consecutive integers
> beginning with 1. In Smalltalk, (1 to: n) does the
> job. In R, 1:n *almost* does the job. But what
> happens when n = 0? Smalltalk gives me the right
> answer: an empty sequence. R gives me (1,0). That
> means that *every* *flaming* *time* I write
> for (i in 1:n) {...}
> I have to take special care to ensure that n is not
> 0, sometimes even having to whack in an extra
> if (n > 0) for (i in 1:n) {...}
>
> Trawling through my Smalltalk code, I find that about
> 6.8% of my counted loops are by: -1,
> 0.7% of them are by: a negative number other than -1,
> 2.5% of them are by: a positive number other than 1,
> 90 % are just to:do: with no by:
> Inspecting some of the 90% showed that many of them
> would go catastrophically wrong if 1 to: 0 do:
> performed its body
>
> On Sat, 23 Feb 2019 at 03:58, Tim Mackinnon <tim@testit.works> wrote:
>
>> I've just been caught out with Intervals - why can't you do:
>> 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative
>> interval)?
>>
>> if you want to iterate down a series of numbers do you really have to do:
>> 5 to: 1 by: -1 do: […
>>
>> I always assumed that if x > y the step was automatically -1 (but its
>> not).
>>
>> I asked on Discord - and someone pointed out that if you use variables it
>> could be ambiguous - but is it really? I don’t know if other smalltalks do
>> it this way (I vaguely recall Dolphin going down, but not sure).
>>
>> Either way the Interval comment should mention this - and I’ll correct it
>> when I get the wisdom of the crowd here.
>>
>> Tim
>>
>
>
