RISC OS did that since forever!

I have come across this referenced from the Pi site. Called “Return To BASIC”, it is an “enhanced BASIC” that, well, let’s let the dev speak:

As well as having an interactive environment allowing program entry, debugging, listing and so on in the same way as traditional BASIC has with line numbers, it also takes a more modern approach with a full-screen syntax highlighting editor which allows easier program entry without line-numbers, a unified looping construct, multi-line if/then/else statements, named procedures and functions and many more features to list here.

This guy must have grown up with a ZX Spectrum or something.

Break it down now:

As well as having an interactive environment allowing program entry,

One might argue that ARMBE was an interactive environment (in 1987!), though using a Desktop editor is going to be nicer.

debugging,

Okay, debugging is a bit sucky. You can use Reporter, or PRINT statements (etc) but there is no VB-like break-and-trace.

listing

? How does one edit without a listing?

it also takes a more modern approach with a full-screen syntax highlighting editor

This isn’t really something that the language itself should be offering. On RISC OS, both Zap and StrongEd can provide colourised editing of BASIC code. Additionally, Edit and SrcEdit can help with editing of BASIC, but not syntaxtually coloured.

which allows easier program entry without line-numbers,

Ditto BASIC. The tokenised files need line numbers, but so long as you don’t use GOTO or GOSUB (etc), you can write BASIC without line numbers – certainly, Edit will strip them away if they are only there to place one line after the other.

a unified looping construct,

FOR…NEXT ? REPEAT…UNTIL? WHILE…ENDWHILE? We’ve got ’em all. We had FOR and REPEAT since BASIC 2 in the Beeb!

multi-line if/then/else statements,

…<yawn> Had this since the mid ’80s.

named procedures and functions

Had this since the Beeb.

and many more features to list here.

Same with our BASIC. CASE…ENDCASE for instance? SYS for easy integration with the OS. Etc etc.

We really ought to publicise what we have more!

I get a similar feeling when I keep reading endless articles in magazines that use Python and assume ‘C’ is too arcane for people.

Jim

You went back a long way for that one. ;-)

This guy must have grown up with a ZX Spectrum or something.

Among other things. I was using BetaBASIC on the Spectrum before I came to BBC BASIC in a big way. It had far better control structures, but of course it lacked the speed.

I have met Gordon and you should know that his memories of BBC BASIC were an important influence on RTB. So it is more a case of imitation being the sincerest form of flattery, perhaps. He is one of the movers and shakers of the Pi world.

a unified looping construct,

One of the things RTB has, and BetaBASIC, and I miss in BBC BASIC is a fully flexible loop structure. I have written one for Basalt that does:

 DO [WHILE|UNTIL]
  ...
 LOOP {WHILE|UNTIL]

but it does not yet have exit(break) or continue. These are defined in ANSI BASIC, which is the nearest there is to a standard.

He is one of the movers and shakers of the Pi world.

I wasn’t intending to denigrate him or his achievement – it isn’t just anybody that can put together a BASIC. I was commenting on how so many of the things listed there on the RTB page are things that we have taken for granted for such a long time.

a fully flexible loop structure.

How do you mean? Your example suggests that DO…LOOP can have varying clauses (the placement of the WHILE and UNTIL). Is this correct?
If so, how is this different to choosing between REPEAT…UNTIL and WHILE…ENDWHILE? I prefer the separate forms as it makes it clear that the loop may never be executed (WHILE) and that the loop is always executed at least once (REPEAT).

but it does not yet have exit(break) or continue.

Yes, I thought we had EXIT FOR (etc) but I think I’m mixing that up with VisualBasic. So our logic uses flags instead, like “UNTIL ((blah < meh) AND (NOT endflag))” etc.

and assume ‘C’ is too arcane for people.

If YearOfCode is how they’re teaching CompSci these days, I think it might be better to gloss over a language that allows you free reign to shoot yourself in the foot, and lets you put holes in everybody else’s feet as collateral damage. C has no innate bounds checking, so it is extremely easy to make a fool of yourself in C. Let them upgrade to that once they have some aptitude for it. Or they can just become web developers…

These are defined in ANSI BASIC, which is the nearest there is to a standard.

Actually, there is a standard.

ANSI → X3.113-1987 (full BASIC) or X3.60-1978 (minimal BASIC)
ISO → ISO/IEC 10279:1991
ECMA → ECMA-116 BASIC (WITHDRAWN)

Given the dates of the documents, they might as well be used as toilet paper nowadays. Though, I believe the ANSI and ISO versions are available if you cough up enough coin.

The ECMA version has been withdrawn, so you can get an idea of what it was about (scanned, 70MiB!): http://web.archive.org/web/20111014140105/http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-116,%201st%20edition,%20June%201986.pdf

Some random notes:

• Lines must be numbered, maximum number is 50000.
• Lines cannot be physically longer than 132 characters.
• Spaces can be replaced by line continuation (but the line in total can’t be >132).
• There does not appear to be any differentiation between ints and floats. Speed must suck.
• DATE → very Y2K non-compliant
• OPTION ARITHMETIC – hmmm…
• String lengths are 129 characters max (due to lines being 132 max).

I gave up reading around p42, suffice to say there is a very bastardised attempt at doing something akin to printf() (sect 10.4.3) with the following code:

30 PRINT USING 40: 342, 42.021
40 IMAGE : RATE OF LOSS #### EQUALS ####.## POUNDS

produces  "RATE OF LOSS  342 EQUALS   42.02 POUNDS".

Oh, and it looks like files contain “records” which can be read and written, but much like VisualBasic, what you read and write depends upon what variable type you are using (eg for byte reads you must read into byte variables, anything larger will read multiple bytes). Problem here is that this BASIC has few variable types – a “number” and a “string”.

but it does not yet have exit(break) or continue. These are defined in ANSI BASIC, which is the nearest there is to a standard.

Easy to solve now that we have labels.
OK, I’m gone :)

Your example suggests that DO…LOOP can have varying clauses (the placement of the WHILE and UNTIL). Is this correct?

Yes. You can have WHILE or UNTIL either at the start or the end or neither (needs EXIT), or both if you could think of a need to. You will spot that WHILE/UNTIL are just logical opposites and can be achieved quite easily with a choice of REPEAT/UNTIL and WHILE/ENDWHILE with NOT, but to me, having distinct syntax for essentially the same thing is unnecessary.

it makes it clear that the loop may never be executed (WHILE)

Only because of your familiarity with the syntax, I think. There is nothing in the word WHILE to suggest that this is a loop at all, nor whether it will be executed or not. Although this is just personal taste, it is instructive to look at how loops are constructed in other languages.

On the subject of loops being executed, BBC BASIC always does one pass through a FOR…NEXT loop, even if the control variable is not in the defined range. Do you share my feeling that this is actually a bug? For Basalt I have used the keyword CLOSE to check this condition and skip the loop if appropriate:

FOR i%=start% TO end% STEP step%:CLOSE
 ...
NEXT i%

I thought we had EXIT FOR

No. To achieve this you either construct a multi-line IF or put the loop inside a PROC and use ENDPROC for EXIT. Both are rather clumsy. Basalt has EXIT for FOR/REPEAT/WHILE loops, but I have just not got around to implementing it for DO.

[EXIT] Easy to solve now that we have labels.

This refers to a thread on c.s.a.programming, but it is an illustration of just why GOTO, with labels or not, is dangerous. If you jump out of a loop you still have the loop data on the stack. If you are lucky you will just have a memory leak, but more likely is that you will find your program jumping back to the loop when you least expect or crashing in various unpleasant ways. ;-)

You will spot that WHILE/UNTIL are just logical opposites and can be achieved quite easily with a choice of REPEAT/UNTIL and WHILE/ENDWHILE with NOT

REPEAT/UNTIL is not the same as WHILE/ENDWHILE with NOT. REPEAT/UNTIL always executes the loop once. The odd thing about FOR/NEXT is that the condition is at the beginning of the loop which implies – like WHILE/ENDWHILE – that you can stop the loop occuring but you can’t. Seems odd to me that this works like REPEAT/UNTIL. I find I avoid using FOR/NEXT loops.

For me BASIC’s biggest failing is the lack of a BREAK to terminate a loop early – you have to jump through hoops to work around that.

Sorry, I was not completely clear. I am comparing the standard BASIC loops with DO…LOOP. So, DO WHILE cond..LOOP is WHILE cond...ENDWHILE and DO UNTIL cond...LOOP is WHILE NOT cond...ENDWHILE etc.

But I clearly agree with you about the problem with FOR…NEXT and with the absence of BREAK/EXIT, which I addressed with Basalt. ;-)

re: ‘C’ and Python comment:

Let them upgrade to that once they have some aptitude for it.

That’s fine if the magazines also actually provide them with any articles so they can even decide if they’d want to. As things stand, such questions are widely ignored.

e.g. One magazine a year or few ago said in response to letters that they’d do some articles on ‘C’. The result was one article, then no more.

If you look at the recent IEEE survey ‘C’ remains more used than Python or many other more ‘trendy’ languages. You can debate why, but as things stand the bulk of new ‘coders’ get little awareness of it from magazines. It seems to be left to those who are already well into programming. By which time they may be so used to Python that they avoid “having to learn a new language” whilst they can ‘get by’ with what they know.

I say this as someone who stuck to FORTRAN for a looong time. (And used BBC BASIC for ages before taking to ‘C’.)

So I’m not criticising Python (or BASIC). Just pointing out this blind spot that newcomers may encounter which then slants how they then proceed unwares. As I said, bit like someone re-inventing a BASIC that treats things already in BBC BASIC as ‘new’.

Jim

This refers to a thread on c.s.a.programming, but it is an illustration of just why GOTO, with labels or not, is dangerous. If you jump out of a loop you still have the loop data on the stack. If you are lucky you will just have a memory leak, but more likely is that you will find your program jumping back to the loop when you least expect or crashing in various unpleasant ways. ;-)

That’s why setjmp and longjmp save/retore the stack :)

What? All of it? Including that 256K local array or 100-level deep recursion? And how would this help anyway?

You get the exact same state as when you did read the label.

In C, it’s enough to avoid all broken loop problems (and most of ‘label is in a loop’ problems).

With most compilers, setjmp saves the stack, longjmp restores the stack and modifies the program pointer.

But this is about BBC BASIC, an interpreted language.

You get the exact same state as when you did read the label.

Not quite.
setjmp() will store the non-corruptible registers (v1-v6, sl, fp, lr, sp [and I don’t get why storing sp and lr with STMIA has been deprecated, it was clear and to the point, the replacement code, three lines of it, are somewhat less clear]) and it will store the FP registers F4-F7 if the host has FP.
Calling longjmp() will exit a trap handler if you’re in one, and return the registers to those saved previously. No tidyup is performed, no memory is freed, nothing. The program execution resumes from the setjmp() command, the non-corruptible registers are reset as they were.

In C, it’s enough to avoid all broken loop problems (and most of ‘label is in a loop’ problems).

After trying to figure out some seriously hairy abuse of switch(), while(), setjmp(), longjmp, and break, it dawned on me. This code was implementing a try-throw-catch mechanism.

I felt something inside me die.

If you need setjmp() and longjmp() to resolve broken loops, there is something seriously astray with your algorithm.

With most compilers, setjmp saves the stack, longjmp restores the stack and modifies the program pointer.

Not quite. setjmp() saves the stack pointer. longjmp() restores the stack pointer (and some/all of the other registers too). Depending on use and platform, it can cause memory leaks. It can cause all sorts of fun if you jump from one routine flow structure to another (like the try-throw-catch) or in and out of flow structures which may or may not need/have/require specific stack states.

Personally, I use longjmp() for one thing and one thing only. If an application hits an exception that it cannot handle and there is likely to be unsaved data then jump back to the earlier state, attempt to save user data, then bomb out. I suppose I could continue running, but if something went wrong, it would only go wrong again. Tell the user and let them do something.

Not quite.

That depends of the compiler of course.

If you need setjmp() and longjmp() to resolve broken loops

No, in C we don’t need that. But in Basic yes, too exit loops for example :)

Of course, jumps/gotos are only useful for two things: exceptions or algorithms that did use direct branching (so, here, only for short sections of code).

A lot of no_goto people argue that use of goto make a source code difficult to maintain. True. But not to implement it means also that a lot of existing code cannot be used again. That’s also a problem of maintainability of code here.

Of course, nobody should use it for new algorithms.

Anyway, interpreters and compilers should warn people of the risk of letting a goto going through structures as loop, or if.
More choices but not more problems :)

Else we can also suppress everything that is available in another way, and use only a ‘branch if’ structure for all loops :)
But do we really need less choices?

Now there is clarity.

Of course, jumps/gotos are only useful for two things: exceptions or algorithms that did use direct branching (so, here, only for short sections of code).

Of course, nobody should use it for new algorithms.

too exit loops for example :)

That is three things. [Spanish Inqisition]

Loops: In BBC BASIC it is simple to write code that exits a loop safely and clears the stack appropriately. It might not look elegant, but there is absolutely no need to use a jump and jeopardise your program.

Exceptions: BBC BASIC has simple, but effective, exception handling, which can take care of the stack. This can be enhanced with a little extra code. So no need for jumps there.

Algorithms: If nobody should use jumps for new algorithms then nobody need use them for existing ones. An algorithm is not itself the code that you write. Taking a bleeding chunk of 1960s FORTRAN and transcribing it in BASIC is not very sensible.

Taking a bleeding chunk of 1960s FORTRAN and transcribing it in BASIC is not very sensible.

But to be able to reuse old Basic code is.
Endless debate.

Nota: I absolutely don’t care of Goto, as my code is jumps-free. But I don’t see why we should remove it.

Some people know how to use it the safe way, some other don’t use it at all, and some other are really too new on programming things to understand complex structures. For them, Goto is not a good first step: it’s the only one.

I began to code with gotos, and I’m really not sure I would manage to learn coding without them (the first months). Today, I don’t use them any more. Where is the problem?

I remember when I was making press articles on Basic programming for beginners. It was really a success. Why? Because I used the Python way? No. Because I used very simple programming concepts, as gotos and line numbering, that a lot people can understand. The same people that did not understand Java or Python (but probably do today).

Of course, I would prefer people to start programming with C, Java or ADA, but it’s simply not possible, and sometimes really not required. For a 50 lines graphics demo, gotos are OK. And ABC can compile them in something really optimised.

I remember when I was making press articles on Basic programming for beginners. It was really a success. Why? Because I used the Python way? No. Because I used very simple programming concepts, as gotos and line numbering, that a lot people can understand.

Maybe I’m strange¹ but when I first came across BASIC² I tried to work with bite size chuncks to produce a working programme. With BBC BASIC this involved PROC and FN and a startup bit that called all the PROC and FN. GOTO just seemed like a quick way of getting lost in a knot of indecipherable code³ and was quickly rejected from my world view. Having people advise that GOTO was bad just reinforced the view.

For a 50 lines graphics demo, gotos are OK.

Just doesn’t work for my world view no matter how short – although I suppose something with about 5 – 10 lines might be sort of tolerable.

¹ Most people at work would say there is no maybe in that
² On an ICL1904.
³ GOTO 1000 makes less sense to me than PROC_do_something

Of course, a lot of people don’t need something simple as goto to begin coding. But some does.
So the success of all my different Basic courses made for Dream, then Login:.

I’m not a bad programmer, but it took me years to really understand (not use; understand) OOP.

I think a good Basic programming book should adopt the no-goto way from chapter 1, but should also provide a with-goto solution, for the people that did not understand chapter 1 (a kind of ‘chapter 0, that you should avoid if you can’).

All IHMO, of course.

I think a good Basic programming book should adopt the no-goto way from chapter 1, but should also provide a with-goto solution, for the people that did not understand chapter 1 (a kind of ‘chapter 0, that you should avoid if you can’).

A good book would explain that part B does this, part C does that and part A is the bit that holds the two together – the reception providing direction of problems to the two working departments. If the author can’t explain modularity they should stop writing and go and do something they do know about.

Spending a fair bit of time telling people about something they shouldn’t do as preparation for what they should do is a bit of a waste of time.

That depends of the compiler of course.

You shouldn’t need to save stack contents as a pointer should suffice. RISC OS UnixLib is slightly smarter, it does:

	@ Make sure we free any alloca() memory blocks between the point
	@ of setjmp() and longjmp().

plus a bit of faffing around for pthreads. Otherwise, it rewrites the registers with previously saved versions. [ svn://svn.riscos.info/gccsdk/tags/release_4_1_2_v2/recipe/files/gcc/libunixlib/sys/_jmp.s ]

No, in C we don’t need that. But in Basic yes, too exit loops for example :)

In BASIC you just need a flag variable in your loop, and a teeny-tiny bit more work. I use the same principle in C as I don’t like using break; – it is supposed to break out of the control structure that it is in, but I found it breaking out of a for loop and not the while loop that it was a part of. Maybe it was a compiler bug? This was Norcroft C v4 (IIRC) back in the mid ‘90s. At any rate, as far as I’m concerned, break is used in switch and that’s about it. ;-)

A lot of no_goto people argue that use of goto make a source code difficult to maintain. True.

We agree on that, then. :-)

But not to implement it means also that a lot of existing code cannot be used again. That’s also a problem of maintainability of code here.

Wait – who said about not implementing it? Did I miss a post?

Of course, nobody should use it for new algorithms.

Given that BBC BASIC has had decent control structures and procedural support since the BBC Micro, I would say that nobody should have used it since 1982.
Sadly, a lot of “do cool stuff in BASIC” books of that era had to try to be as compatible as possible with the primary flavours of BASIC which meant that every program was a god-awful mess of GOSUB and GOTO and an entire generation of programmers learned this stuff because they either didn’t realise that the book was written for the lowest common denominator, or their BASIC was the lowest common denominator.
It is for reasons like this why Edsger W.Dijkstra said (and I quote): “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
He, quite clearly, had to grade somebody’s project that was written in BASIC and contained nothing but GO[TO|SUB]. That would make me hate BASIC too…

Anyway, interpreters and compilers should warn people of the risk of letting a goto going through structures as loop, or if.

Assuming, of course, that the compiler/interpreter can figure out what is going on at that level. I don’t think any compiler around warns about weird use of longjmp() – perhaps on the grounds that if you’re using an “advanced” feature (your teach-yourself-C-in-twenty-seconds books probably don’t give much coverage to signal handling) you ought to know what you are doing.
After all, this is the language where indirection is a barrel of laughs, unions can present the same block of data in a gazillion different ways, and it’s quite okay with negative array offsets. Oh, and let’s not talk about the comma. ;-)

But do we really need less choices?

Yes. I’d like a button that says “Software development”. I push it, a program appears, already debugged and packaged. Can I have one of those?

For them, Goto is not a good first step: it’s the only one.

Might I suggest that their efforts might be better spend perfecting origami technique? Or if they yearn for something more intellectual, they can attempt to develop good chess strategy.
Anything that doesn’t involve inflicting shoddy code on others. If their only first step is GOTO, they’re doing it sooooo wrong they might as well not bother.

I began to code with gotos, and I’m really not sure I would manage to learn coding without them (the first months). Today, I don’t use them any more. Where is the problem?

You know why my parent bought me a BBC Micro? I read through the book I mentioned above, when I was like twelve years old, and I knew zip about programming. But even then I hated what I saw. I actually had to photocopy the page and draw lines in different coloured pencils to figure out what the heck was going on. I learned the keywords pretty quickly (it is hard not to in BASIC – PRINT, er, prints stuff, GOTO goes to…) but I couldn’t believe that people were writing software that looked like that rubbish in the book. So then I read the BBC Micro user guide. Entirely. Cover to cover. One rainy weekend when I was alone in the dormitory. PROC and FN! I was enlightened.
So I hassled and hassled and hassled and when asked to justify why I wanted a second hand Beeb that cost more than a new anything-else, I think the quality of my answer sealed the deal. It wasn’t just “the pricey one”, it was one that clearly did something different, even though I think the reason was lost on a somewhat-luddite non-techie mind.

Sorry. I’m with Dijkstra here.

Sometimes GOTO is useful (VB5/6 uses it in error handling constructs), but the eighties pretty much killed it and the minds of everybody who thought that programs are supposed to look like that.

Because I used very simple programming concepts, as gotos and line numbering, that a lot people can understand.

Aaargh!

:-)

You do NOT need to use GOTO to introduce any concept. This is a bizarrely BASIC related question. Read a book on C. You will find lush chapters describing every sort of program flow concept imaginable, with no reference at all to goto. Why? Because an introductory book on C programming that uses goto would be savaged. The goto statement can be useful in C, but it is used in association with all of the other program flow contructs, not instead of them.

Oh, and GOSUB… should never be mentioned. Ever.

For a 50 lines graphics demo, gotos are OK.

For assembler GOTOs are okay (what’s a BNE if not a conditional GOTO?). For anything else, a programmer that learns bad habits in the early stages will find it incredibly hard to shake that off. Unfortunately most languages have a GOTO of some kind, so while it exists, there’s no incentive to do it any other way.

but it took me years to really understand (not use; understand) OOP.

I pretty much ignore OOP. My uncle wrote a book on it. I read about all this constructor friend inheritance overload nonsense and I still don’t really get the point. Whatever he could do in C++, I felt I could do in straight C. It wouldn’t be identical and sometimes it wouldn’t be as nice looking, but that’s because they’re different languages. C lets you do cool things in a single printf that would take lines and lines of BASIC. Why? Because they’re not the same. So you adapt for what you are using and, okay, maybe some people find C++’s OOP to be a good thing. I just didn’t feel that I was sold on the idea. I’ll accept that I think like an assembler programmer so the more abstracted an idea is, the more I want to know “okay, but what code does that actually generate?”.
So I write C. Not C++. My world hasn’t ended, and anyway people have moved on from C++ these days as well. It’s all C-hash-sharp-in-B-flat-minor or whatever this year’s hot paradigm is… I’ll stick to C. It might be old and full of pitfalls and at times self-contradictory, but there is something reassuring in the fact that it has barely moved in a decade and a half, and only that was minor tinkering.

but should also provide a with-goto solution, for the people that did not understand chapter 1

No! If the book needs to provide a with-GOTO version, then the author has failed as a teacher.