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