25

In VB both array access and function calls are done with () which makes it difficult to differentiate between those with a quick look. It also makes more nested levels of parentheses like MyArray(GetIndex()) which is much more readable when written as MyArray[GetIndex()]. I don't know about BASIC but it looks like that the same syntax is also used in BASIC

In fact there's no {} and [] in VB either, and other symbols like @, !, #, ~... are also unused, making the syntax very verbose for no reason

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
phuclv
  • 3,592
  • 1
  • 19
  • 30

6 Answers6

45

In the early days, many machines running BASIC had limited character sets. For example, the stock TRS-80 Model I couldn't display the lowercase portion of ASCII, which omitted curly-braces, tilde, and the vertical bar as well. Worse yet, the character codes that usually map to [ \ ] ^ instead mapped to up, down, left, and right arrow characters!

Reaching further back, EBCDIC didn't have a consistent mapping for square brackets, either. There were many different code pages for EBCDIC, each intended for a different region, language, and/or use case. Different code pages could map square brackets to different code points. As a result, a card deck or paper tape from one machine containing those characters might display them as something completely different on another type of machine.

BASIC's syntax, at least in older versions, is well-supported by an uppercase-only display that supports the most common symbols and punctuation.

jeffB
  • 2,826
  • 1
  • 13
  • 20
  • The remark about EBCDIC is not entirely true. EBCDIX did have unique assignments for square brackets, as it offered a complete coverage of ASCII without any remapping. By being an 8 bit code it did offer national characters in parallel, unlike ASCI which used redefined several characters, including the brackets - and that is were some missuse is originated. when transferfing data from an ASCII source, the right ASCII to EBCDIC encoding table had to be used - id not, assignments got screwed the very same way as transfering between SACII variants did. – Raffzahn Apr 29 '21 at 19:39
  • 1
    @Raffzahn I've edited my answer in an attempt to clarify this. Does this help? – jeffB Apr 30 '21 at 19:03
  • No, as the assumption is still not really true. The square brackets were, in all cases known to me, mapped to BA/BB (the same way the curly are at C0/D0. This is true across almost all code pages that were used for data processing. Given, there were special code pages for certain usages, like APL, but so were tables that not even had lower case letters or other cases were not all ASCII symbols were present. Using those exotic applications as argument does not fit the reality of common applications. – Raffzahn Apr 30 '21 at 19:26
  • It might be that the real reason is for using () for arrays was limitations in the Dartmouth character set or hardware, but the TRS-80 is irrelevant. There are many possibilities; maybe Kemeny and Kurtz didn’t think it was productive for a beginner language to force students to worry about types of brackets for each purpose; maybe they copied FORTRAN which many students would need to use eventually; maybe they liked () better; maybe they didn’t even think about it. We might never know without a direct quote from the authors. – Euro Micelli May 01 '21 at 22:02
  • 1
    @Raffzahn I accept that in your experience square brackets were always mapped to BA/BB, but a Google search for EBCDIC square brackets reveals that others have encountered the issue, and that the issue has persisted into the present era. That was the basis for my statement, and I think it's support enough to let the statement stand, even though we of course don't know that this influenced BASIC's syntax. – jeffB May 02 '21 at 00:00
  • 1
    @jeffB Agreed, my experience is mostly tied to the business world. Shoveling data and communicating with remote sub systems :) Now, since you mention EBCDCs influence to BASIC, it might be worth to note that BASIC, to my knowledge, was developed on a GE-200 series, that machine did not use EBCDIC in any way, but it's own 6 bit character set (which in fact did not feature any square brackets). – Raffzahn May 02 '21 at 02:06
28

I don't know about BASIC but it looks like that the same syntax is also used in BASIC

Because Visual BASIC is a BASIC?

Since the very first days of BASIC, arrays are indexed in parentheses and function parameters as well.

When Microsoft added user defined functions to BASIC (*1), they stayed with the existing syntax. A change in either would mean leaving the realm of BASIC - not to mention breaking compatibility with any existing software and any BASIC examples of indexing and/or function calls.

Visual BASIC is a continuation of MS-BASIC 5.x, aka GW-BASIC and QuickBASIC (and QBASIC) and mostly source compatible with them. It was also QuickBASIC that introduced named functions and procedures, as well as made the GOSUB keyword optional.

It's the same natural way any other BASIC developer went when adding named user defined function. From BASIC 09 (1980) and BBC BASIC (1981) all the way to Super BASIC (1984) and GFA BASIC (1986).

In fact there's no {} and [] in VB either, and other symbols like @, !, #, ~... are also unused, making the syntax very verbose for no reason

What you're calling for is a different language. Languages are (mostly) defined by their syntax, as keywords are rather exchangeable. Maybe you're looking for PASCAL? It was quite popular in the early 80s and uses square brackets for array indexing, for exactly that reason (*2).

It's the basic way of BASIC to use parentheses for arrays and function - and symbols like @, !, # and % to qualify variable types.

Some history

Now, going all the way to BASIC's origins, we end with the DTSS running on a GE-200 system. From today's view the GE-200 might be an odd beast, but back in the early days (*3) it's 20 bit words holding 3 6 bit characters weren't unusual. That 6 bit character of course restricted the character set to 64 encodings. In addition, usage of them was highly application specific. For example their COBOL compatible (*4) did support 49 characters including parenthesis, but not square brackets:

enter image description here

On the other hand, their high speed printer did (by default) not provide parenthesis, but square brackets:

enter image description here

(Taken from this scan)

So while it is quite likely that original the usage of parenthesis for index and parameters might have been due the restricted character set of original GE-200 environment, an easy answer can not be given. Though, some information could be gathered by meditating over the original source code.

What is clear is that it was not due some (more or less) standard character set. Especially not ASCII or EBCDIC, as neither of them was already developed and/or available at the time BASIC was defined.

*1 - That is beyond the rudimentary support of FN() of earlier MS BASIC dialects.

*2 - Inherited from ALGOL - the very same way C did :))

*3 - I.e. pre /360 designs.

*4 - Yes, COBOL compatible as at the time, there was still haggling about what features are to be included and ho they are to be handled in source. Mainly about I/O handling, including character set (and Hollerith conversion) .

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • Comments are not for extended discussion; this conversation has been moved to chat. – Chenmunka Apr 30 '21 at 17:54
  • 3
    "Languages are (mostly) defined by their syntax" -- I disagree. Can you transform C to C++, or LISP, or BASIC, or FORTH, by transforming the syntax? Although the syntax is the most visible part of a language, it is the language's semantics that define it. A language specification will often describe the syntax in (for example) a few pages of EBNF, but spend hundreds of pages on the semantics. – Wayne Conrad Apr 30 '21 at 20:04
  • 1
    @WayneConrad Well, beside that semantics without a syntax aren't a language, one can also not do any transformation without. It is the syntax that differentiates languages from each other. ADD A TO B GIVING C adds two numbers in COBOL, while C := A + B does the same in PASCAL and LET C = A + B in BASIC. All three are semantically the same. But they do differ in syntax - and that's exactly why semantics can not tell languages them apart, but syntax does. – Raffzahn May 02 '21 at 02:44
  • Seems odd that the GECOM character set had separate encodings for hyphen and minus, when ASCII merged them. – dan04 May 24 '21 at 21:58
  • @dan04 different emphasis. Then again, this seems more of a mislabeling, as that character is almost universal used as underscore - as a character and literal, as it was used with double striking to underline a print line. quite useful in tabulating. – Raffzahn May 24 '21 at 22:24
  • How would the COBOL form handle cases where the variables have differing precision? By my understanding, one of the reasons COBOL performs computations in that way is to ensure that the precision with which to process every operation is unambiguous. In languages that support computations like d=a+b-c, it would be unclear whether a compiler must allow for the possibility that (a+b) might exceed the range of d in circumstances where (a+b)-c wouldn't. – supercat May 24 '21 at 22:46
16

The Minimal Basic Standard, ECMA-55, 1st Edition, January 1978, contains a very limited character set, only upper case, and very few non-alpha-numeric characters (including parenthesis, but no other brackets); certainly not the full ASCII character set.

This is likely due to compromises in the standards committee between corporate implementers of various existing BASIC versions, many of which were earlier designed for input on keyboards that did not support a full ASCII character set (Apple I, et.al.).

For Tiny BASIC implementations, this also reduces the size of the token recognizer.

hotpaw2
  • 8,183
  • 1
  • 19
  • 46
  • Apple I hardly matters as so few of them were ever made, but the much more common Apple II also did not include []'s on its keyboard, especially ironic as the name in its logo was written as "Apple ][". Apple IIe did finally include them. – Darrel Hoffman Apr 30 '21 at 16:29
  • The Apple II was introduced circa mid-77, likely after the ISO committee work for the Minimal Basic Standard was started. – hotpaw2 Apr 30 '21 at 16:57
  • Neither of them - or any other micro manufacturer - really mattered for the ECMA standard. The drivers were mini computer manufacturers like HP, Wang, Nixdorf or Olivetti. – Raffzahn Apr 30 '21 at 20:28
10

A number of BASICs from the minicomputer era used []'s for array access. The most notable was HP Timeshare BASIC, which I assume inspired the other versions that used the same syntax. In HP, it was optional, and () and [] were synonymous. By convention, () was used for array access while [] was used for array and string slicing. This was by no means universally used, as one can see in books like What To Do After Hitting Return.

Maury Markowitz
  • 19,803
  • 1
  • 47
  • 138
9

BASIC was originally developed on DTSS, which used Model 33 Teletypes for user I/O. The Model 33 didn't have [] characters, so BASIC couldn't use them.

John Doty
  • 2,344
  • 6
  • 12
  • Indeed. See here: http://www.bitsavers.org/pdf/dartmouth/BASIC_Oct64.pdf, pages 14 and 15. – Joe Stevens May 01 '21 at 11:31
  • I think this answer is wrong. Model 33s did have []. I can attest to that, having written Algol 60 code on them. Furthermore DTSS supported Algol 60 and the DTSS documentation uses the correct brackets, noting they are shift-K and shift-M. (Teletypes could be purchased with different typeheads). – dave May 01 '21 at 12:31
  • Originally at least, per this document, they were using model 35 ttys, but that does not change the argument. – dave May 01 '21 at 12:38
  • 1
    @another-dave I believe that 33's and 35's with brackets were exotica. See the image at https://en.wikipedia.org/wiki/Teletype_Model_33#/media/File:TTY33ASR.jpg. No []. – John Doty May 01 '21 at 22:07
  • 3
    @another-dave I helped port DTSS Algol to Multics in 1972. I also used it. I don't think it required [] in those days. The reason is that the most common Multics terminal was an IBM 2741 with a PTTC/EBCD typeball, and that had no []. I think I would remember this as a serious issue if DTSS Algol required []. Perhaps an early implementation used [], but that proved difficult because most terminals and printers didn't have those characters. – John Doty May 01 '21 at 22:16
  • @JohnDoty Exotica or not, we had 30 of 'em. I don't believe I've ever touched an ASR-33 that lacked brackets. – dave May 02 '21 at 02:36
  • I just checked the (paper) manual for the multiaccess system I used in the 1970s, and yup, bracket was bracket on the flexos and ttys, and *( on the impoverished line printer. – dave May 02 '21 at 02:43
  • The pictures I find online for the Teletype ASR-33 show the square brackets as Shift-K and Shift-M. That correlates with my rather dim memories too. – Mark Ransom May 02 '21 at 04:19
  • ICL used a KSR33 with an attached box of lights and switches as the console on most 1900 series machines. A manual I found illustrates the keyboard as having [ and ]. Also, ICL-rebranded teletypes were used as MOP terminals, and I'm pretty certain I remember those as having brackets. (The comment-delimiter in the PLAN assembler was '[') – dave May 02 '21 at 13:17
  • Maybe this is a UK/US difference? – dave May 02 '21 at 13:18
  • @another-dave The "*(" on the line printer is an example of why it was ill-advised to choose characters that common devices couldn't handle. – John Doty May 02 '21 at 15:22
  • I dispute the notion that catering to the worst device on the system is appropriate. But you probably have a modern mindset, where 'of course' all devices have the same character code? But us interactive Algol programmers preferred to have good online representation, and were prepared to tolerate the crappy printer. Much better than being wrong everywhere. – dave May 03 '21 at 01:06
  • @another-dave When the code renders differently on different devices, confusion results. My first experience with FORTRAN required me to use a keypunch with IBM's "commercial" character set, a tedious translation exercise best avoided. There was no keypunch with the correct coding available to me. – John Doty May 03 '21 at 14:35
  • There is no 'translation' needed as Algol programmers. As users of the system, we are aware (because we read the documentation) that not all devices have the same character repertoire. We were not confused. – dave May 03 '21 at 17:21
  • @ another-dave Even as a beginner, you'd mastered all the documentation? BASIC was designed for beginners. – John Doty May 03 '21 at 17:44
  • The Model 33 and Model 35 absolutely did have [ and ] characters. They don't appear on the keycaps because some of the keycaps displayed the Ctrl equivalent (ctrl-G = BELL, ctrl-L = FF) instead of the Shift equivalent (shift-N = ↑, shift-O = ←). But they could be typed on the keyboard, and printed by the typebox/typewheel. In every case, pressing the Shift key inverted the 0x10 bit of the character. This was true for numbers (shift-4 = $), punctuation (shift-; = +), and some letters (shift-K = "["). – AndyB Nov 28 '23 at 19:09
2

What a bunch of whippersnappers!

EBCDIC was part of the IBM S/360 announcement April 7, 1964. Basic first ran May 1, 1964. No connection.

While DTSS was a time sharing system, the GE-225 also ran batch programs. My second or third assembly language was VFAP (Valley Forge Assembly Program) on a 225 at the San Fernando Valley State College. And we submitted jobs on cards.

The card punch most frequently used at the time of Basic's inception was the IBM 026. This was developed in the late 1940s. It was originally designed for use with the IBM 407 accounting machine. So the character set on the original 026 did not even include parentheses. (Parenthetically, if you will pardon the phrase, a later 026 version was developed which included parentheses for that newfangled Fortran programming language.)

026 CE manual: http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/punchedCard/Keypunch/024-026/22-8319-0_24_26_Customer_Engineering_Preliminary_Manual_of_Instruction_1950.pdf

Doug Jones lists a GE card code with both parentheses and square brackets. See: https://homepage.divms.uiowa.edu/~jones/cards/codes.html

I really think that those were developed for the later time sharing machines (e.g. 415, 635). But I never used these in a time sharing environment.

I received an introduction to the differences between 026 BCD and 029 EBCDIC when my first COBOL program, punched on an 026, generated a raft of errors due to the 360-50 expecting 029 EBCDIC. And 029-punched programs never printed correctly on a 407 which many of us sued for proofreading.

So, to answer the original question - Basic did not use square brackets or curly braces because at least some of the hardware they used for input did not have square brackets or curly braces.

In contrast, the DecWriter terminals used at Bell Labs when Unix and C were developed included those characters. So the C language reflected their input devices in much the same way.

Have to cut this off. The museum keepers are coming around to dust the dinosaur bones and I have to pretend to be fossilized.

DisplayName
  • 21
  • 2