ugBASIC forum

I would find it useful if ugBASIC was compatible with a more established BASIC dialect so that fewer changes would need to be made for programs to run on other platforms (not available to ugBASIC).

This could also help when deciding what syntax and behaviour to use for new features.

I would suggest using ANSI Full BASIC as implemented in Decimal BASIC for modern machines and IS-BASIC on the Enterprise 64/128. I'm reasonably sure that the ANSI/ISO and ECMA standards for Full BASIC are almost identical.

According to this page, the ISO standard was reviewed in 2008 and remains current.

Hi wysardry!

wysardry wrote: ↑Tue Oct 10, 2023 4:29 pm I would find it useful if ugBASIC was compatible with a more established BASIC dialect so that fewer changes would need to be made for programs to run on other platforms (not available to ugBASIC).

At the time of this writing, ugBASIC is 90%-95% compatible with MICROSOFT BASIC V2. At least, for the main commands related to the BASIC language, such as string management or memory allocation. The graphics and audio extensions are not present in that BASIC, so in those aspects it is not compatible -- although, if you want, you can use the POKE command without problems.

wysardry wrote: ↑Tue Oct 10, 2023 4:29 pm This could also help when deciding what syntax and behaviour to use for new features.

Generally speaking, that's not entirely true. The approach at the time in developing BASIC for a specific platform was to start from the characteristics of that platform. So when deciding the syntax or behavior of certain commands, a lot depended on how the underlying hardware moved. This is exactly one of the points where ugBASIC, with the isomorphic approach, tries to intervene to avoid penalizing one platform rather than another. In fact, the aspects that are common to all BASIC are captured by the general instructions in BASIC. For specific hardware behaviors, instructions are used that "mimic" such behaviors as much as possible, without necessarily introducing a common factor such as abstractions.

In other words: if hardware behaves in a certain way and we want to exploit it, the best thing is to invent commands to manipulate it rather than "leaning" on the standard developed many years ago, which probably didn't want to expose too deep details.

wysardry wrote: ↑Tue Oct 10, 2023 4:29 pm I would suggest using ANSI Full BASIC as implemented in Decimal BASIC for modern machines and IS-BASIC on the Enterprise 64/128.
According to this page, the ISO standard was reviewed in 2008 and remains current.

As far as I know, the ANSI standard never reached the maturity level to truly represent a standard, at least for BASIC. There were few "de facto" BASIC standards in the 1980s, and those standards have influenced subsequent BASICs to some extent. Definitely not the ANSI standard. For example, DECIMAL Basic is based on a 1991 standard, but BASIC was well established more than a decade earlier. I cannot find info about IS-BASIC, but I think it is something similar.

Wasn't Microsoft BASIC V2 used on the Commodore 64? If so, that was horrendous from what I remember of it.

With all the structured features you've included so far, I would have thought you were using QuickBASIC as a guide if any Microsoft product.

There are some Enterprise books available in PDF format, if you're interested. The Programming Guide covers IS-BASIC, but it can be a little long winded in places from what I remember.

The Enterprise 64 was released around 1985, so later than many other 8-bit computers, but it still used a Z80 processor.

Although Decimal BASIC is based on a later version of the standard, I don't think there were many changes from the 1987 or earlier versions. The ANSI standards go back to at least 1978 with Minimal BASIC (Full BASIC added structured programming features later).

wysardry wrote: ↑Sat Oct 14, 2023 9:45 pm Wasn't Microsoft BASIC V2 used on the Commodore 64? If so, that was horrendous from what I remember of it.

Generally speaking, you're right. In the sense that, in terms of commands, it was really poor. However, at the syntax level, it had a number of features that have become "de facto standards". For example, string vectors are such, they are not "vectors of character vectors", or anything like that.

wysardry wrote: ↑Sat Oct 14, 2023 9:45 pm With all the structured features you've included so far, I would have thought you were using QuickBASIC as a guide if any Microsoft product.

Let's make an important distinction.

Syntax-wise, ugBASIC resembles CBM BASIC V2. The reason is simple: I needed a BASIC with which I could participate in the 10 liner. So it needs to be compatible to some extent (for more info, click here).

Keyword-wise, ugBASIC ugBASIC is inspired by many BASIC dedicated to video games. This, for example, explains some idiosyncrasies on some keywords.

wysardry wrote: ↑Sat Oct 14, 2023 9:45 pm There are some Enterprise books available in PDF format, if you're interested.

I will read them, for sure.

wysardry wrote: ↑Sat Oct 14, 2023 9:45 pm The ANSI standards go back to at least 1978 with Minimal BASIC.

Yes, I agree. What I wanted to say anyway is that the ANSI standard is anything but "standard".

Unfortunately, there isn't only one standard for BASIC, as almost every 8-bit computer manufacturer had their own version(s).

ANSI BASIC was originally developed in sync with Dartmouth BASIC (the original BASIC) until version 7 or so, when the original developers decided to go their own way and create True BASIC. True BASIC is now a Windows only, closed source commercial interpreter, so I haven't tried it.

Several BASIC dialects are based on the ANSI standard, such as Decimal BASIC, IS-BASIC on the Enterprise and Bywater BASIC aka bwBASIC. There are probably more that don't mention it.

For example, I recently found out that Vintage BASIC is close to Microsoft's BASIC version 2 as found in the Commodore 64 and is "informed by (but [does] not always stick to) the ANSI Minimal BASIC standard (ANSI X.360-1978)". Sinclair BASIC also started as a subset of ANSI Minimal BASIC.

Exactly, it is precisely because there is this condition of confusion that, at the end of the story, each developer decides what to put or not into the language, syntax and semantics. If we consider ourselves with the mentality of the time, I still believe that it was a good solution to adapt to hardware that was always different but did, more or less, the same thing. It is with today's mentality that all this seems absurd to us, and that we are looking for a "standard". However, it remains that when we talk about a "subset" or ANSI Minimal BASIC, we mean that it is a BASIC dialect. This specification is necessary because there were also manufacturers who invented a specific language to program their computers from scratch, and who had nothing to do with BASIC.

Whenever I see "subset of ANSI BASIC" I assume they mean that some features have not been included, but the ones that are there have the same syntax.

I also assume that a "superset of ANSI BASIC" includes all the features with the same syntax, plus some extras.

I see ANSI BASIC as a guide rather than something that has to be strictly followed with no omissions and no additions. There is a minimal and full version after all, and the full version has some optional modules (such as for graphics).

I dislike variations from this standard, such as in PureBASIC where PRINT is used to print to the screen without starting a new line each time and PRINTN being used for the same thing with a new line at the end. In every BASIC I've used from the 80s, PRINT always added a new line unless you added a semicolon after whatever was being printed.
and would produce the same output, but would print the two words on separate lines.

In PureBASIC the semicolon is used to denote a comment, so the first and second examples would work as expected. The last would print "helloworld" unless you used PRINTN (a little like Write and WriteLn in Pascal).