Proposal for BBC BASIC 'FOR lists'

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
Post Reply
User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Fri Nov 08, 2019 10:16 am

The following has appeared at the BBC BASIC forum:
Would something like the following be hard to implement in BBCSDL?

Code: Select all

      FOR I% OF 3, 22, -9
      NEXT
      FOR Day$ OF "Mon", "Fri", "Sun"
      NEXT
Just wondering as it would be so powerful to an already extremely powerful programming language.
My immediate reaction is that it would be a nice extension to the language and quite 'in keeping with' the general BBC BASIC philosophy (and doesn't need any new keywords!). What do you think?

User avatar
dhg2
Posts: 144
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by dhg2 » Fri Nov 08, 2019 10:23 am

Looks nice. It reminds me of 'foreach' from Tcl.
Regards,
- Patrick

User avatar
flaxcottage
Posts: 3753
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by flaxcottage » Fri Nov 08, 2019 10:25 am

I like it, Richard.

BITD Pascal used to have something similar; their example used cheese names I believe. :lol:
- John

Image

Soruk
Posts: 447
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Soruk » Fri Nov 08, 2019 3:46 pm

I like it. Similar to 'for' in the bash shell.

(I wonder how hard that'll be to implement in Matrix Brandy)

markdryan
Posts: 91
Joined: Sun Aug 20, 2017 10:37 pm
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by markdryan » Fri Nov 08, 2019 4:17 pm

I've been thinking about this sort of thing a bit lately, mainly with the goal of eliminating bounds checks on arrays.

Would you also support 1d array and string variables? For example,

Code: Select all

FOR I% OF A%()
NEXT

FOR I% OF A$
NEXT

User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Fri Nov 08, 2019 5:03 pm

markdryan wrote:
Fri Nov 08, 2019 4:17 pm
Would you also support 1d array and string variables?

Code: Select all

FOR I% OF A%()
NEXT
FOR I% OF A$
NEXT
I think my current feeling is that they can be so readily and elegantly implemented with a conventional FOR loop that the benefit wouldn't justify the complication:

Code: Select all

FOR P% = 0 TO DIM(A%(),1)
  I% = A%(P%)
NEXT
FOR P% = 1 TO LEN(A$)
  I% = ASCMID$(A$,P%)
NEXT
In the array case there's also the argument that iterating through the entire array (rather than just a limited range of indices) would be inflexible, especially as BBC BASIC supports only zero-based-index arrays.

julie_m
Posts: 68
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by julie_m » Sat Nov 09, 2019 3:02 pm

This is basically iterating over an anonymous enumerable, to use modern object-oriented parlance.

In a clunky old language that didn't let you apply methods directly to an anonymous constructor, you could always emulate it by initialising a new object and applying an iterator to that. Some would say that is ugly, because there need only ever be one reference to that list in the whole program.

Someone more used to PHP or Perl might expect it to look a bit more like

Code: Select all

10 FOR ("HELLO", "BBC", "FANS") AS WORD$
and then to work with an array in between the brackets:

Code: Select all

10 FOR (A%(10 TO 19)) AS Z%
I guess the important thing is, can the extension be introduced in a way that doesn't break pre-existing code (therefore, no new reserved words) while not being so counter-intuitive as to prevent it being useful?

User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Sat Nov 09, 2019 3:43 pm

julie_m wrote:
Sat Nov 09, 2019 3:02 pm
Someone more used to PHP or Perl might expect it to look a bit more like

Code: Select all

10 FOR ("HELLO", "BBC", "FANS") AS WORD$
To me that feels a less comfortable 'fit' with existing BBC BASIC syntax than what the OP proposed; why should the affected variable come first in the case of the conventional FOR statement but last here? And, as you imply, the introduction of a new keyword (especially a short one like AS) has the potential to break existing programs where it has been used as a variable name.

Anyway, I've received an 'over my dead body' kind of response at the BBC BASIC forum so there are evidently some strongly held views that such an extension should not be contemplated. I must admit that not being a user of one of those languages that support the construct I haven't really missed it myself; I'd be interested to see an example of some code that significantly benefits.

julie_m
Posts: 68
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by julie_m » Sat Nov 09, 2019 7:05 pm

I could be mixing up my BASICs here; if AS isn't a reserved word in any version of post-8-bit BBC BASIC then I agree, it doesn't make good sense to add it for fear of introducing incompatibilities. The actual PHP construct to which I was alluding is

Code: Select all

foreach($hash as $index=>$value) {
    # statements
}
where, inside the loop between the posh brackets, $index is the hash index -- always a scalar value -- and $value is the value, which may be a scalar, array, hash or object, to which it points.

I suppose, when all is said and done, BASIC is one of those clunky, old languages; and that is part of its charm. There is a danger of losing some of that under too many layers of syntactic sugar. (One of the USPs of BASIC always was that there were few constructs to learn before you could start programming in it.)

User avatar
jgharston
Posts: 3722
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by jgharston » Sun Nov 10, 2019 12:53 am

Richard Russell wrote:
Fri Nov 08, 2019 10:16 am

Code: Select all

      FOR I% OF 3, 22, -9
      NEXT
      FOR Day$ OF "Mon", "Fri", "Sun"
      NEXT
My immediate reaction is that it would be a nice extension to the language and quite 'in keeping with' the general BBC BASIC philosophy (and doesn't need any new keywords!). What do you think?
It's the sort of thing I've implemented as

Code: Select all

FOR A%=1 TO 7
Day$=MID$("SunMonTueWedThuFriSat",A%*3-2,3)
...
NEXT
FOR A%=1 TO 3
I%=VALMID$("  3 22 -9",A%*3-2,3)
...
NEXT
I can see how I'd implement it, the FOR control block would have a sort-of "invisible" variable which would be an index/offset into the visible values. In 6502/32K/ARM BASIC it would have the same memory-use issues the string allocator has if you re-use the index variable with different limits, eg:
FOR I% OF 2,4,8,16:NEXT I%
FOR I% OF 1,3,5,7,11,13,17,19,21:NEXT I%

One thing I accidently put in PDP BASIC was IF A$ THEN was interpreted as IF LEN(A$) THEN, which is actually quite useful, but I removed it as it broke the least-surprise paradigm of the IF syntax being IF <numeric_expression>. A typing error with the variable would accidently be valid syntax, whereas the above FOR extension wouldn't suffer from that, you wouldn't accidently type FOR a=something TO as FOR a OF item_list.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
sweh
Posts: 2096
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by sweh » Sun Nov 10, 2019 2:38 am

Richard Russell wrote:
Fri Nov 08, 2019 10:16 am

Code: Select all

      FOR I% OF 3, 22, -9
 
My initial preference would be to use "IN" instead of "OF". Because we're talking about selecting elements IN a set and it matches the math :-) Or maybe "FROM". "IN" shows we iterating amonst the elements a set. "FROM" to show we're selecting elements from a set. In my mind "IN" maintains order, but FROM wouldn't. So I prefer "IN".

"OF" doesn't match any mental model I have and so wouldn't be syntax that makes sense.

Advanced: Allow for optional (...)

So

Code: Select all

  FOR I% IN (3,22,-9)
But maybe this is my Unix shell scripting bias:

Code: Select all

  for a in 10 20 30 40
  do
    echo $a
  done
Rgds
Stephen

User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Sun Nov 10, 2019 4:44 am

sweh wrote:
Sun Nov 10, 2019 2:38 am
My initial preference would be to use "IN" instead of "OF"... Or maybe "FROM".
They suffer from the same objection as 'AS', namely that they involve the introduction of a new keyword and hence risk breaking compatibility with existing programs. Admittedly I have added new keywords myself (EXIT and PRIVATE) but that was many years ago and I felt that the capabilities that they provided were of such high value that the risk was acceptable (and a few programs did indeed break).

But here we are talking about a relatively esoteric extension which confers no extra functionality, as such, but simply provides a more elegant syntax. My opinion is firmly that potentially breaking compatibility with existing programs is too high a price to pay, hence limiting us to existing keywords like OF.

User avatar
BigEd
Posts: 2643
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by BigEd » Sun Nov 10, 2019 8:28 am

(In case anyone else was as confused as I was, OF is part of CASE)

User avatar
1024MAK
Posts: 9283
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by 1024MAK » Sun Nov 10, 2019 9:10 am

BBC BASIC may not use IN as a reserved word, but some other BASICs do where it is a function that returns the (8 bit) value from a 8080/8085/Z80 I/O port address. Although it’s use is not universal as some BASICs use INP instead.

I’m sure I have seen ‘AS’ used (as a reserved word) in a BASIC somewhere, but I may be misremembering. But if it’s not already used in BBC BASIC, that's all that matters.

Mark

User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Sun Nov 10, 2019 10:16 am

1024MAK wrote:
Sun Nov 10, 2019 9:10 am
BBC BASIC may not use IN as a reserved word... I’m sure I have seen ‘AS’ used (as a reserved word) in a BASIC somewhere...
I was of course referring to BBC BASIC (more specifically BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy BASIC which are the only ones to which the proposed language extension is likely to be relevant). AS and IN are valid variable names in those dialects and a program using them as such would break if they were tokenised (not helped by both BB4W and BBCSDL supporting optional lowercase keywords). OF has been a keyword in BBC BASIC for about 35 of its 38 years existence!

julie_m
Posts: 68
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by julie_m » Sun Nov 10, 2019 12:53 pm

There's no need to introduce any new reserved words if you just extend the parser to accept constructs such as:

Code: Select all

FOR J% = 2, 3, 5, 7
    R% = K% MOD J%
    REM ... statements ...
NEXT J%
which would just throw an error in earlier versions. There is no reason why you could not iterate over lists of strings:

Code: Select all

FOR A$ = "Hello", "BBC", "Micro", "Fans"
    PRINT TAB(10, 31); A$'
NEXT A$
and even make the special case where a single string (variable or literal, but not a one-element array) is given to decompose it into its individual characters, so

Code: Select all

FOR A$ = "Hello BBC Micro Fans"
would be treated as equivalent to

Code: Select all

FOR A$ = "H", "e", "l", "l", "o", " ", "B", "B", "C", "M", "i", "c", "r", "o", " ", "F", "a", "n", "s"
The real question is, does it do anything for the language? Does it solve a real problem? (Probably a yes, since there have been various proposals for ways to emulate such functionality.) Is it easier to understand than any of the workarounds that have been used to date? Does the complexity introduced by the additional functionality slow the interpreter down?

User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Sun Nov 10, 2019 3:34 pm

julie_m wrote:
Sun Nov 10, 2019 12:53 pm
There's no need to introduce any new reserved words if you just extend the parser to accept constructs such as:

Code: Select all

FOR J% = 2, 3, 5, 7
To be pedantic BBC BASIC is interpreted and doesn't have a "parser", but I take your point. You'd have to ask the person who originally proposed the syntax what his thinking was.
There is no reason why you could not iterate over lists of strings... and even make the special case where a single string...
"No reason"? I can think of several: it's more work, it's more code, it might have more impact on the performance of the normal FOR...NEXT loop. Perhaps you're not looking at it from the perspective of the poor sod who has to implement it (i.e. probably me)!
The real question is, does it do anything for the language? Does it solve a real problem?
Indeed it is, and as somebody who has never used one of the languages which has this construct I personally don't miss it. I'd still like to see a small example of its use in a 'mocked up' BBC BASIC program that does something useful.

Soruk
Posts: 447
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Soruk » Mon Nov 11, 2019 3:30 pm

Soruk wrote:
Fri Nov 08, 2019 3:46 pm
I like it. Similar to 'for' in the bash shell.

(I wonder how hard that'll be to implement in Matrix Brandy)
Cross-posting my reply in the other forum:
Right now there's a lot going on in the real world that precludes me spending a lot of time on something that might be used a little, if at all, to implement it it Matrix Brandy. On the flip-side, there is only one implementation to worry about (C) so don't have to worry about a second, parallel implementation in assembler or something else!

(And since LIST is a keyword, I'd have thought FOR x% LIST 4, 65, -2 might make more readable sense, unless it's impossible to use the LIST token in a program line; as a command it's limited to immediate mode only and thus likely removed from BBCSDL).

User avatar
Richard Russell
Posts: 931
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by Richard Russell » Mon Nov 11, 2019 3:53 pm

Soruk wrote:
Mon Nov 11, 2019 3:30 pm
unless it's impossible to use the LIST token in a program line; as a command it's limited to immediate mode only and thus likely removed from BBCSDL.
As you surmise, LIST has been removed as a keyword from BBCSDL (and its original 8-bit token of &C9 reallocated to WHEN). From time to time somebody bemoans the loss of commands like DELETE and LIST and RENUMBER from BBCSDL's immediate mode, but if they were ever to be reinstated I don't think I'd bother to tokenise them at all.

User avatar
jgharston
Posts: 3722
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by jgharston » Mon Nov 11, 2019 6:08 pm

And 'OF' semantically matches what it's doing, and matches how you verbalise* the equivalent mathematic action:

for all X of {a, b, f, g, w, cat, trombone}

*well, we did at my school. ;)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
BeebMaster
Posts: 2896
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Proposal for BBC BASIC 'FOR lists'

Post by BeebMaster » Thu Nov 14, 2019 12:14 am

It's a nice idea, and the ability to loop with string variables rather than numeric variables does sound like it would be very handy, but I am still trying to think of an actual programming use for this FOR extension.

It could be used where sequences of data have a recognisable numeric value but irregular string values, like days of the week, months, presidents of the USA, countries in the order they joined the Commonwealth etc, or even the spelling of numbers.

So whereas we might print what day it is using something like:

Code: Select all

DIM Day$(7)
FOR A=1TO7
READ Day$(A)
NEXT
dayofweek=FNgetdayfromRTC
PRINT"Today is ";Day$(dayofweek)

...
DATA Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday

we could perhaps optimise the code significantly by using a FOR list with the days of the week in the list:

Code: Select all

FOR Day$ = Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday
....
But actually I can't even think how that would work in order to finish this example!

Worse than that, and after a few days of genuinely trying to reconcile myself to this new idea, I do think that it breaks our whole conception of how we use FOR...NEXT loops in programming - in my view they are sequential and predictable: we go from the first value to the second value incrementing or decrementing by the value in STEP, if used.

We use a FOR..NEXT loop to repeat the same code a number of times. It might be as straightforward as doing exactly the same thing x times; but much more likely is that we do the same thing x times but making use of the incrementing or decrementing value of x on each pass of the loop. If there is no predictability to the change in value of x between passes then the whole purpose of FOR...NEXT is destroyed.

If we want to repeat the same code using a random set of variables, which a FOR list would allow, I would say we are just as well off calling the code explicitly several times with the "random" variable value each time, or find another way of passing the "random" variable:

A FOR list would let us do:

Code: Select all

FOR IceCreamFlavour$ = Book-End,Pumice Stone,West Germany
PROC SunshineDesserts(IceCreamFlavour$)
NEXT
which could be achieved with:

Code: Select all

PROC SunshineDesserts("Book-End")
PROC SunshineDesserts("Pumice Stone")
PROC SunshineDesserts("West Germany")
or using our READ...DATA friend:

Code: Select all

DIM IceCreamFlavour$(3)
FOR A=1 TO 3
READ IceCreamFlavour$(A)
NEXT
....
DATA Book-End,Pumice Stone,West Germany
....
FOR A=1 TO 3
PROC SunshineDesserts(IceCreamFlavour$(A))
NEXT
To answer the original question, then, I think on reflection that I wouldn't be pushing for this extension to be implemented, as I'm not convinced that it really is within the spirit of BBC BASIC and I don't think it has a proven real-world use.
Image

Post Reply