User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Structured Procedural BASIC, why not?

Tue Apr 10, 2018 1:57 pm

Since I am back I have to bring it up.

What form?
What about something like MS-QuickBASIC for the Macintosh, with some of the extensions from MS-BASIC PDS, and an implementation of pointers on top?

I would implement the pointers in the same manner as they are implemented in BBC BASIC V (AKA ARM BASIC). As this would fit well into the existing structure of the language, and only add a single additional level of operator precedence.

WHAT you say?
MS-QuickBASIC 1.0 (a compiler for the Macintosh 680x0 computers) provides builtins for GUI elements, decent graphics commands, and multi-width peek and poke statements (for implementing pointers).

BASIC PDS provides better structured datatypes, and forward declaration.

We are talking structured!
The concept is a structured modern structured procedural BASIC, specifically targeting ARM based systems, firstly the Raspberry Pi. That is to say a BASIC implementation that uses procedures and functions, block oriented conditionals (IF THEN ELSE ENDIF / CASE WHEN), normal looping structures (WHILE WEND / LOOP UNTIL / FOR STEP NEXT), has structured datatypes (TYPE ENDTYPE [think C struct]), add in pointers and we have a complete easy to learn for NOOBS language that obeys the modern rules.

I would posit removing the GOTO and GOSUB keywords wholesale. They are not needed in BASIC, and are the biggest criticism of BASIC by those that do not know any BASIC newer than 1982. BASIC is a structured language, with typed variables, and is still easy to use.

I would also say it would be worth having the GUI statements well known in QuickBASIC, something needed in that language to show off a compiler for the Macintosh, though well implemented by MS in my opinion.
Last edited by DavidS on Tue Apr 10, 2018 5:06 pm, edited 1 time in total.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Structured Procedural BASIC, why not?

Tue Apr 10, 2018 5:04 pm

Ok I know that everyone expected me to mention BASIC in some context.

Though I am serious about the questioning as to how people would view such an implementation as outlined above. A very simple modern structured procedural language, that is simple to learn, has integrated commands for handling windows, widgets, graphics, etc.

The reason for the questioning is the goal of writing a simple compiler (not very good optimization) that will provide the ability to write high level applications that can be compiled as is without requiring a third party toolkit on multiple operating systems. At the same time the compiler should be capable of producing usable low level applications (like OS kernel, or module) so long as high level features are not used until at a level they are implemented.

And let us be realistic, BASIC is very easy to compile, having only 5 levels of Operator precedence, and not allowing for multiple assignments within an expression. Part of the thought is a language simple enough in its rules that it is a little easier to deal with optimization without introducing new bugs (as much as possible).

I am also a little bit tired of optimizing compilers insisting on dead code removal, especially when working low level, where code may appear to be dead to the compiler, though in fact is used by an arcane interaction with the system somewhere else. When you want optimization, you may still have code that is needed getting removed with most modern compilers.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

ejolson
Posts: 1843
Joined: Tue Mar 18, 2014 11:47 am

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 1:21 am

DavidS wrote:
Tue Apr 10, 2018 5:04 pm
Though I am serious about the questioning as to how people would view such an implementation as outlined above.
I would view such a implementation as essentially Free Pascal without the semicolons. While I like Free Pascal quite a lot, I don't consider it very new.

In my opinion, a new programming language should have built-in support for parallel programming. That built in support should be simple, easy to use and forward compatible with Raspberry Pi as well as the coming exascale architectures.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 2:13 am

ejolson wrote:
Wed Apr 11, 2018 1:21 am
DavidS wrote:
Tue Apr 10, 2018 5:04 pm
Though I am serious about the questioning as to how people would view such an implementation as outlined above.
I would view such a implementation as essentially Free Pascal without the semicolons. While I like Free Pascal quite a lot, I don't consider it very new.

In my opinion, a new programming language should have built-in support for parallel programming. That built in support should be simple, easy to use and forward compatible with Raspberry Pi as well as the coming exascale architectures.
No one said new, just modern :) .

Parallel programming is accomplished in procedural languages by the correct use of task management system calls, mutex's, semaphores, etc. No matter what it is going to rely on the programmer to know where critical accesses are and use the correct locks, no way around that. I can not think of a way to simplify that any further by building it into the language, suggestions are welcome.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

jahboater
Posts: 2858
Joined: Wed Feb 04, 2015 6:38 pm

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 6:49 am

DavidS wrote:
Wed Apr 11, 2018 2:13 am
Parallel programming is accomplished in procedural languages by the correct use of task management system calls, mutex's, semaphores, etc. No matter what it is going to rely on the programmer to know where critical accesses are and use the correct locks, no way around that. I can not think of a way to simplify that any further by building it into the language, suggestions are welcome.
Its been built into many languages directly:
Algol68, Ada, Occam, C++ (std::async etc).
No doubt there are more.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 12:23 pm

jahboater wrote:
Wed Apr 11, 2018 6:49 am
DavidS wrote:
Wed Apr 11, 2018 2:13 am
Parallel programming is accomplished in procedural languages by the correct use of task management system calls, mutex's, semaphores, etc. No matter what it is going to rely on the programmer to know where critical accesses are and use the correct locks, no way around that. I can not think of a way to simplify that any further by building it into the language, suggestions are welcome.
Its been built into many languages directly:
Algol68, Ada, Occam, C++ (std::async etc).
No doubt there are more.
I will have to look at Algol68 and Ada, not very familiar with either. I would be interested in an effective way to make things simpler.

Now a language that does well for parallel processing is Spin, though that is designed to run on the 8-core Parallax Propeller P8X32A, and do to the HW setup of only allowing one core (or COG) access to shared memory at a time there are fewer issues with resource contention.

Absolutely will not follow the messed up example of modern C++. And there is some debate how much the library is part of the language in C/C++, there are systems that even the standard C library has little to no meaning on do the the nature of the systems, and yet C is still there (in some cases people even bring over C++).
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

jahboater
Posts: 2858
Joined: Wed Feb 04, 2015 6:38 pm

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 12:37 pm

DavidS wrote:
Wed Apr 11, 2018 12:23 pm
I will have to look at Algol68 and Ada, not very familiar with either. I would be interested in an effective way to make things simpler.
Algol68 had parallel clauses (to go with serial clauses).
Neat syntax, but so long ago!

Even if you don't like the syntax, its worth studying async() and friends in C++17.
Its modern and available now.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 5:08 pm

ejolson wrote:
Wed Apr 11, 2018 1:21 am
I would view such a implementation as essentially Free Pascal without the semicolons. While I like Free Pascal quite a lot, I don't consider it very new.
Pascal is an option I had not considered in some time. There are a lot of similarities between BASIC and Pascal. In many ways Pascal is a nicer language.

It may indeed be time to refresh myself in Pascal. You brought a good point, in that the extra niceties can be implemented in Pascal units a lot easier than implementing them as language built-ins in BASIC.

It would also be a lot easier to write a completely self hosting Pascal compiler than to write the same for BASIC. Both are possible without any big problems, though Pascal definitely simplifies life. At the moment I am not remembering how to implement pointers in Pascal, and I am going to need a refresher in dealing with units. Time to look up some references (and see if Free Pascal is in the Raspbian repos, as a bootstrap compiler).

Thank you very much, for the change in direction for my play. I hope that someone else finds my play of use or fun.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

hippy
Posts: 3617
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 5:17 pm

DavidS wrote:
Wed Apr 11, 2018 12:23 pm
Now a language that does well for parallel processing is Spin, though that is designed to run on the 8-core Parallax Propeller P8X32A, and do to the HW setup of only allowing one core (or COG) access to shared memory at a time there are fewer issues with resource contention.
The Propeller hardware prevents bus contention but doesn't do a lot for resource contention; that still has to be resolved using semaphores and mutexes.

For multi-processing, multi-threading I would just add a simple mechanism to start a subroutine as a separate thread, an asynchronous gosub, which simple terminates when the subroutine ends.

A language which includes good and simple to use GUI screen handling built-in is something I do feel is missing. I like the way VB6 and RealBasic did things, but those are more IDE-plus-Frameworks rather than languages.

I'm not convinced any form of BASIC will attract users these days, though if it offers something other languages don't it might. I have a hankering for something VB6-like for Python but that's perhaps just me.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 5:46 pm

hippy wrote:
Wed Apr 11, 2018 5:17 pm
DavidS wrote:
Wed Apr 11, 2018 12:23 pm
Now a language that does well for parallel processing is Spin, though that is designed to run on the 8-core Parallax Propeller P8X32A, and do to the HW setup of only allowing one core (or COG) access to shared memory at a time there are fewer issues with resource contention.
The Propeller hardware prevents bus contention but doesn't do a lot for resource contention; that still has to be resolved using semaphores and mutexes.

For multi-processing, multi-threading I would just add a simple mechanism to start a subroutine as a separate thread, an asynchronous gosub, which simple terminates when the subroutine ends.

A language which includes good and simple to use GUI screen handling built-in is something I do feel is missing. I like the way VB6 and RealBasic did things, but those are more IDE-plus-Frameworks rather than languages.

I'm not convinced any form of BASIC will attract users these days, though if it offers something other languages don't it might. I have a hankering for something VB6-like for Python but that's perhaps just me.
And therein is my idea. The reasoning for BASIC as a basis is that it has everything needed for the base, and can be fully structured.

The simplicity of implementing and handling windows, widgets, menus, etc that has been demonstrated possible, and is lacking in modern programming language implementations is a large part of what I am looking at.

The problem with just doing an asynchronous subroutine call is that there is still an issue with resource contention (you are basically saying call fork() or pfork() and branch in new thread to subroutine if I understand correctly). There would still need to be a means of providing mutex, and the same level of difficulty for noob programmers that there is in doing the same through the use of system calls.

Also I did say that I would OMIT GOTO and GOSUB completely, so as to get that muddy argument out of the way.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Structured Procedural BASIC, why not?

Wed Apr 11, 2018 9:16 pm

I am definitely going to switch directions to Pascal. After looking at the problem as a whole it makes good sence.

Though I will be including some typecasting to get around the super strong typing of Pascal (though most pascal implementations do the same to solve the same problem). I will also add a C style for loop naming it loop (advantage of BASIC would have been that implementing it as a new keyword would not have looked so odd).

Time for a new thread, to solidify my concept and get some feedback.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

Return to “Other programming languages”

Who is online

Users browsing this forum: No registered users and 9 guests