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