From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,d95b511473b3a931 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,d95b511473b3a931 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,d95b511473b3a931 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Language Choice and Coding style Date: 1996/07/02 Message-ID: <4ra5hb$do6@goanna.cs.rmit.edu.au> X-Deja-AN: 163223039 references: <4r7cnq$g57@sun.quiknet.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ nntp-posting-user: ok Date: 1996-07-02T00:00:00+00:00 List-Id: rahill@mind.net (Russel A Hill) writes: >Get a life Jon. I type this way because it commnitactes well. Out compiler >Technology isn't suuffieicently advbanced to handle: > > Loop Control Variable = Initial Value Sorry, but this is rubbish. Algol 60 and Algol 68 both allowed this. As an exercise, I once wrote a version of the Prolog read/1 command that allowed embedded blanks in identifiers, and IT WAS DEAD SIMPLE. "Our compiler technology" has been "sufficiently advanced" for more than 30 years. It isn't even a "compiler technology" issue; it's only a "lexical analysis" issue. There is no problem dealing with a mix of identifiers, operator symbols, and punctuation marks. The only problem is when you have keywords that look like identifiers. Algol 68 explored the "stopping" possibilities reasonably thoroughly. One simple method, for example, is "case strop": keywords are in upper case, everything else in lower case. So one might write FOR i FROM LB sensor table TO UB sensor table DO has overflowed OF sensor table [i] := FALSE OD This is not rocket science. Another technique is to use a special prefix character: IMP used '%', Algol 68 used '.': .For i .from .lb sensor table .to .ub sensor table .do Has overflowed .of sensor table [i] := .false; .Od (and with the full stop being in the same shift as the lower case letters, this cannot be said to be hard to type. Indeed, I was surprised to find just how easy it is.) I note comp.lang.c and comp.lang.c++ in the newsgroups line. Let's see what changes to C would be needed to allow embedded blanks in identifiers. Declarations can have lots of words run together, e.g. unsigned long int foo. To handle that, we'll borrow Pascal/Fortran 90 declaration syntax. : will be a variable declaration, and
: will be a function definition. There is one word operator: sizeof. We'll use function call syntax for that, which is already legal anyway. A labelled statement can be told from a declaration by the fact that the keywords that begin a cannot begin a in revised syntax. Here is part of a file comparison program: void print_line(long n, char const *line) { printf("%7ld %s", n, line); if (0 == strchr(line, '\n')) printf("...\n"); } void compare_streams(FILE *f1, FILE *f2) { char line1[LINE_BUFF_SZ]; /* line read from f1 */ char line2[LINE_BUFF_SZ]; /* line read from f2 */ char const *p1; /* set to NULL at end of f1 */ char const *p2; /* set to NULL at end of f2 */ long n; /* current line number */ n = 0; do { n++; /* count attempts to read from f1 */ p1 = fgets(line1, sizeof line1, f1); p2 = fgets(line2, sizeof line2, f2); } while (p1 != NULL && p2 != NULL && strcmp(p1, p2) == 0); if (p1 != NULL && p2 != NULL) { /* neither file has ended yet; the lines must disagree */ printf("files differ\n"); print_line(n, line1); print_line(n, line2); } else if (p1 != NULL) { /* file1 has not ended, but file2 has */ printf("first file longer\n"); print_line(n, line1); } else if (p2 != NULL) { /* file2 has not ended, but file1 has */ printf("second file longer\n"); print_line(n, line2); } /* no output is produced if both files were the same */ } In revised C syntax: print line(n: long, line: char const *): void { printf("%7ld %s", n, line); if (0 == find char in string(line, '\n')) printf("...\n"); } compare_streams(file one, file two: FILE *) void: { line one, line two: char[LINE BUFF SZ]; p one, p two: char const *; n: long; n = 0; do { n++; p one = f get string(line one, sizeof(line one), file one); p two = f get string(line two, sizeof(line two), file two); } while (p one != NULL && p two != NULL && string compare(p one, p two) == 0); if (p one != NULL && p two != NULL) { printf("files differ\n"); print line(n, line one); print line(n, line two); } else if (p one != NULL) { printf("first file longer\n"); print line(n, line one); } else if (p two != NULL) { printf("second file longer\n"); print_line(n, line two); } } Except for declaration syntax, very little changes. What conclusion does this lead to? A blindingly obvious one: it is not our *compiler technology* that forbids embedded blanks in identifiers, it is our *programming language standards*. If we wanted embedded blanks, we could have them. All you have to do is design your language so that ... ... ... ... ... ... cannot occur, and then you don't even need stropping. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.