14 May
2020
14 May
'20
6:41 p.m.
o operator overloading
I never could figure out why Stroustrup implemented that "feature"; let's
see, this operator usually means this, except when you use it in that
situation in which case it means something else. Now, try debugging that.
Does your antipathy extend to C++ IO and its heavily overloaded << and >>?
The essence of object-oriented programming is operator overloading. If you
think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
consistent style, then you have to think that integer+integer and
matrix+matrix are even better. To put it more forcefully: the OO style
is revoltingly asymmetric. If you like it why don't you do everyday
arithmetic that way?
I strongly encouraged Bjarne to support operator overloading, used it
to write beautiful code, and do not regret a bit of it. I will agree,
though, that the coercion rules that come along with operator (and
method) overloading are dauntingly complicated. However, for natural uses
(e.g. mixed-mode arithmetic) the rules work intuitively and well.
Mathematics has prospered on operator overloading, and that's why I
wanted it. My only regret is that Bjarne chose to set the vocabulary of
infix operators in stone. Because there's no way to inroduce new ones,
users with poor taste are tempted to recycle the old ones for incongruous
purposes.
C++ offers more features than C and thus more ways to write obscure code.
But when it happens, blame the writer, not the tool.
Doug
8:54 p.m.
New subject: v7 K&R C
On Thu, May 14, 2020 at 2:42 PM Doug McIlroy <doug(a)cs.dartmouth.edu> wrote:
The essence of object-oriented programming is operator
overloading.
Mumble -- I'm not so sure ... Kay coined the term, and I've not directly
taken that away from his writings. But maybe I missed it.
I'm a little reluctant to argue here. I feel a little like I did when I
was arguing with my thesis advisor years ago ;_) I so respect you
opinion and you have demonstrated to me that you are correct on so many
things.
Mathematics has prospered on operator overloading, and that's why I
wanted it.
FWIW: That was Wulf's argument for the BLISS syntax for indirection. It
made more sense mathematically. The problem was that the animals were
already beyond the fields and long lost in the forest, so closing the barn
door later didn't help. Bill later recanted, that while the idea was the
right one, in practice, he was a bad idea.
...
users with poor taste are tempted to recycle the old ones for incongruous
purposes.
Ah, this here is, of course, the crux of the issue. Who shall be
the arbiters of good taste. Doug most of the time, I agree with you and
think you have done a fantastic job of being one of those arbiters. But
like my friend and mentor Wulf, I have to admit the ugly way we did for
years; stands. What you bought, given what we got, seems unbalanced.
There is way too much 'bad' code and I think the overloading multiplies the
bad over the good.
C++ offers more features than C and thus more ways to write obscure code.
It's worse than that. The language definition is constantly peed on by the
masses. Whereas Dennis (and Steve) took a very measured approach as to
when and how to add features to C and while it is admittedly quirky, I find
C code a lot more understandable. To me, the features that were added to C
were ones that experience showed made sense [structs/unions/function
prototypes/void/void*]. But as Larry and I have pointed out, not all of
them did (enums). I don't have the same warm feelings about C++.
My complaint with C++ was (is) it just 'too much'. If Bjorne had added
classes and some of the original simpler things that his original "C with
Classes" paper had and stopped, I think I might be willing to use it
today. But like Larry, I avoid it if at all possible. In practice, its a
tarbaby, and little good has come of it in my world.
I applaud Rob, Ken, Brian and Russ with Go - I think thye hit on a better
medium, certainly for userspace code. And thankfully they have not (so
far) been tempted to 'fix it' (although I have heard rumors that Russ has
things up his sleeve). And for me, the jury is still out on Rust (Dan
Cross I admit got to me to rethink its value a bit, but I have not yet used
it for anything). And Python, which I had hoped would be a reasonable
replacement for Perl, also became a mess when people 'improved' it.
But when it happens, blame the writer, not the tool.
Fair point. I've seen some awesome BLISS code in my day. I bet if I
looked I could find some excellent C++. But in my experience, the signal
to noise ratio is not in favor of either.
Respectfully,
Clem
15 May
15 May
2:44 a.m.
New subject: v7 K&R C
Perhaps for the first time in my career, I am about to disagree with Doug
McIlroy. Sorry, Doug, but I feel the essence of object-oriented computing
is not operator overloading but the representation of behavior. I know you
love using o.o. in OO languages, but that is syntax, not semantics, and OO,
not o.o., is about semantics.
And of course, the purest of the OO languages do represent arithmetic as
methods, but the fit of OO onto C was never going to be smooth.
-rob
On Fri, May 15, 2020 at 4:42 AM Doug McIlroy <doug(a)cs.dartmouth.edu> wrote:
o operator
overloading
I never could figure out why Stroustrup implemented that "feature"; let's
see, this operator usually means this, except when you use it in that
situation in which case it means something else. Now, try debugging
that.
Does your antipathy extend to C++ IO and its heavily overloaded << and >>?
The essence of object-oriented programming is operator overloading. If you
think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
consistent style, then you have to think that integer+integer and
matrix+matrix are even better. To put it more forcefully: the OO style
is revoltingly asymmetric. If you like it why don't you do everyday
arithmetic that way?
I strongly encouraged Bjarne to support operator overloading, used it
to write beautiful code, and do not regret a bit of it. I will agree,
though, that the coercion rules that come along with operator (and
method) overloading are dauntingly complicated. However, for natural uses
(e.g. mixed-mode arithmetic) the rules work intuitively and well.
Mathematics has prospered on operator overloading, and that's why I
wanted it. My only regret is that Bjarne chose to set the vocabulary of
infix operators in stone. Because there's no way to inroduce new ones,
users with poor taste are tempted to recycle the old ones for incongruous
purposes.
C++ offers more features than C and thus more ways to write obscure code.
But when it happens, blame the writer, not the tool.
Doug
3:57 a.m.
New subject: v7 K&R C
In case it helps, here is a definition of OO from Alan Kay:
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things."
-- http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
-r
7:55 a.m.
New subject: v7 K&R C
Being Scottish and in the 70s our world was constrained by UK import restrictions - to
protect our industries. As a boy I cut my teeth on a language called Algol68 that ran on
a ICL 1904 (24 bit word and 6 bit byte, generally a capital letter only system!).
The language was part of my academic course work.
OK it was not a OO language but - in 1968 - it had strict type checking, structures,
user-defined types, enums, void, casts, user-defined operators (overloaded) both infix and
prefix, (all defined on a formal mathematical basis giving syntax and semantics)
Together with “environment enquiries” to find out how big an int was or the precision of
a float.
Users could also define their own operators - think about it as no more that strange names
of a variable or procedure - and also allocate priority to the various operators in that
world (monadics ALWAYS had a priority of 10 and bound tightest). But it went too far.
You could define (note that the concept of += did not exist in the base language in 1968)
a new operator such as “+:=“
op +:= = (ref in a, int b) ref int: a:=a+b; € It took a pointer to an int, and int and
returned the pointer
[Of course you could also define it to be
op +:= = (ref in a, int b) ref int: a:=a-b+7;
]
You could even use Jensen’s device with operators. If you dont know ALgol68 have a speed
read of https://research.vu.nl/ws/portalfiles/portal/74119499/11057
My move to unix and C in the 70s was a huge retro step for me - but I could not develop
systems code in Algol68 - for example the transput library was about 8K before your
blinked. Certainly in C we could code more and faster - no type-checking and we had enuf
experience of compilers to understand what was going on at the machine code level - we
could just drive the I/O registers directly.
Then C++? Like microsoft windows I evaluated, tried it a bit and voted the theory good
but the smell bad. I had a few students who wrote in C++ over a few years, but you know
what, it did not do anything earth shattering and it could be a b*gger to work on a debug
of a 20K line student program! Like some here I think C++ was just on the wrong side of a
line that I dont understand. Similarly, for me, perl is on one side of that line and
python is far over the other side.
My question is:
What is that line? I dont understand it? Effort input vs output? Complexity measure,
debugging complexity in a 3rd party program? [I hated assembler too unless it was my own
(or good) ;-)] But machine code was good, few people would do too much in a complicated
way writing in binary/octal/hex!
On 15 May 2020, at 03:44, Rob Pike
<robpike(a)gmail.com> wrote:
Perhaps for the first time in my career, I am about to disagree with Doug McIlroy. Sorry,
Doug, but I feel the essence of object-oriented computing is not operator overloading but
the representation of behavior. I know you love using o.o. in OO languages, but that is
syntax, not semantics, and OO, not o.o., is about semantics.
And of course, the purest of the OO languages do represent arithmetic as methods, but the
fit of OO onto C was never going to be smooth.
-rob
On Fri, May 15, 2020 at 4:42 AM Doug McIlroy <doug(a)cs.dartmouth.edu
<mailto:doug@cs.dartmouth.edu>> wrote:
o operator overloading
I never could figure out why Stroustrup implemented that "feature"; let's
see, this operator usually means this, except when you use it in that
situation in which case it means something else. Now, try debugging that.
Does your antipathy extend to C++ IO and its heavily overloaded << and >>?
The essence of object-oriented programming is operator overloading. If you
think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
consistent style, then you have to think that integer+integer and
matrix+matrix are even better. To put it more forcefully: the OO style
is revoltingly asymmetric. If you like it why don't you do everyday
arithmetic that way?
I strongly encouraged Bjarne to support operator overloading, used it
to write beautiful code, and do not regret a bit of it. I will agree,
though, that the coercion rules that come along with operator (and
method) overloading are dauntingly complicated. However, for natural uses
(e.g. mixed-mode arithmetic) the rules work intuitively and well.
Mathematics has prospered on operator overloading, and that's why I
wanted it. My only regret is that Bjarne chose to set the vocabulary of
infix operators in stone. Because there's no way to inroduce new ones,
users with poor taste are tempted to recycle the old ones for incongruous
purposes.
C++ offers more features than C and thus more ways to write obscure code.
But when it happens, blame the writer, not the tool.
Doug
3:01 p.m.
New subject: v7 K&R C
On Fri, May 15, 2020 at 08:55:46AM +0100, Dr Iain Maoileoin wrote:
My question is:
What is that line? I dont understand it? Effort input vs output?
Complexity measure, debugging complexity in a 3rd party program?
I think you are asking precisely the right question. There is a line
where one side is good enough and good enough is just that. The other
side is just too much, too much to get tangled up in.
I think Rob and Ken and the rest of the Go team are not lauded enough
for having the restraint to stay on the right side of the line. It's
so easy to be seduced into yet another feature, "it's not that bad,
we can do it." It is far harder to say "Nope, not gonna do that".
The Go team reminds me a bit of the original QNX team. QNX was/is
a message passing microkernel, it's the only microkernel that is
actually micro (in my experience, I hear that L4 is good but haven't
looked). They had a core team of 3 people that were allowed to touch
the actual microkernel. All of which fit into a 4K instruction cache
on x86. Every commit went through the filter of "does this add to
the cache?"
That sort of discipline is really rare. Far more common is "I benchmarked
it and it only slows down by 1%" - that's death by a thousand paper cuts.
3:36 p.m.
New subject: v7 K&R C
On Fri, May 15, 2020 at 08:55:46AM +0100, Dr Iain Maoileoin wrote:
My question is:
What is that line? I dont understand it? Effort input vs output?
Complexity measure, debugging complexity in a 3rd party program?
I think of it less as a line than as a continuum. I am reminded of an input
routine I wrote for a sort several decades ago. Allocate a pointer from one
end of memory, start reading a record into the other end of memory with
something like
while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is now
there */
Very easy to understand, no guesswork about allocating pointers versus
records, and a complete and utter pig. 50% of the processing time of the
entire sort went into loading records. There were 5 or 6 comparisons
being done for every *character* of input (I omitted the bit about
verifying that there was room to store the next character). It might have
made for good reading, but nobody would have used it, because much faster
sorts were already available, and most people *use* code, not *read* it. So
I had to push into uglier territory to get something that worked well
enough to be worth reading.
8:01 p.m.
New subject: v7 K&R C
Unfortunately, if c is char on a machine with unsigned chars, or it’s of type unsigned
char, the EOF will never be detected.
* while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is now there
*/
8:03 p.m.
New subject: v7 K&R C
I think every old Unix hand does
int c; // EOF is typically -1
On Fri, May 15, 2020 at 04:01:23PM -0400, ron(a)ronnatalie.com wrote:
Unfortunately, if c is char on a machine with unsigned
chars, or it???s of type unsigned char, the EOF will never be detected.
* while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is now there
*/
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
8:05 p.m.
New subject: v7 K&R C
Ron,
Hmmm... getchar/getc are defined as returning int in the man page and C is
traditionally defined as an int in this code..
On Fri, May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned
chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
8:18 p.m.
New subject: v7 K&R C
EOF is defined to be -1.
getchar() returns int, but c is a unsigned char, the value of (c = getchar()) will be 255.
This will never compare equal to -1.
Ron,
Hmmm... getchar/getc are defined as returning int in the man page and C is traditionally
defined as an int in this code..
On Fri, May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com <mailto:ron@ronnatalie.com>
> wrote:
Unfortunately, if c is char on a machine with unsigned chars, or it’s of type unsigned
char, the EOF will never be detected.
* while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is now there
*/
8:24 p.m.
New subject: v7 K&R C
I suspect we are saying the same thing. C is defined as an int (as Larry
also showed), not an unsigned char (and frankly if you had done that, most
modern compilers will give you a warning). IIRC you are correct that the
Ritchie compiler would not catch that error.
But, the truth is I know few C (experienced) programmers that would define
c as anything but an int; particularly in the modern era with compiler
warnings as good as they are.
Clem
On Fri, May 15, 2020 at 4:18 PM <ron(a)ronnatalie.com> wrote:
EOF is defined to be -1.
getchar() returns int, but c is a unsigned char, the value of (c =
getchar()) will be 255. This will never compare equal to -1.
Ron,
Hmmm... getchar/getc are defined as returning int in the man page and C is
traditionally defined as an int in this code..
On Fri, May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
16 May
16 May
12:57 a.m.
New subject: v7 K&R C
I always kept local, single characters in ints. This avoided the problem with loading a
character being signed or unsigned. The reason for not specifying is obvious. Today, you
can pick the move-byte-into-word instruction that either sign extends or doesn't. But
when C was defined that wasn't the case. Some machines sign extended when a byte was
loaded into a register and some filled the upper bits with zero. For machines that filled
with zero, a char was unsigned. If you forced the language to do one or the other, it
would be expensive on the opposite kind of machine.
It's one of the things that made C a good choice on a wide variety of machines.
I guess I always "saw" the return value of the getchar() as being in a int sized
register, at first namely R0, so kept the character values returned as ints. The actual
EOF indication from a read is a return value of zero for the number of characters read.
But I'm just making noise because I'm sure everyone knows all this.
Brantley
On May 15, 2020, at 4:18 PM, ron(a)ronnatalie.com
wrote:
EOF is defined to be -1.
getchar() returns int, but c is a unsigned char, the value of (c = getchar()) will be
255. This will never compare equal to -1.
Ron,
Hmmm... getchar/getc are defined as returning int in the man page and C is traditionally
defined as an int in this code..
On Fri, May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
> Unfortunately, if c is char on a machine with unsigned chars, or it’s of type
unsigned char, the EOF will never be detected.
>
>
>
>> • while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
4:14 p.m.
New subject: v7 K&R C
On Fri, May 15, 2020 at 8:58 PM Brantley Coile <brantley(a)coraid.com> wrote:
I think it's worthwhile stating these things explicitly, sometimes.
- Dan C.
> On May 15, 2020, at 4:18 PM, ron(a)ronnatalie.com wrote:
> > > EOF is defined to be -1.
> > getchar() returns int, but c is a unsigned char, the value of (c =
> getchar()) will be 255. This will never compare equal to -1.
> >
> > > Ron,
> > > Hmmm... getchar/getc are defined as
returning int in the man page and C
> is traditionally defined as an int in this code..
> > > On Fri, May 15, 2020 at 4:02 PM
<ron(a)ronnatalie.com> wrote:
> >> Unfortunately, if c is char on a machine with unsigned chars, or it’s
> of type unsigned char, the EOF will never be detected.
> > > > > >
> >>> • while ((c = getchar()) != EOF) if (c == '\n') { /*
entire record
> is now there */
I always kept local, single characters in ints. This
avoided the problem
with loading a character being signed or unsigned. The reason for not
specifying is obvious. Today, you can pick the move-byte-into-word
instruction that either sign extends or doesn't. But when C was defined
that wasn't the case. Some machines sign extended when a byte was loaded
into a register and some filled the upper bits with zero. For machines that
filled with zero, a char was unsigned. If you forced the language to do one
or the other, it would be expensive on the opposite kind of machine.
Not only that, but if one used an exactly `char`-width value to hold, er,
character data as returned from `getchar` et al, then one would necessarily
give up the possibility of handling whatever character value was chosen for
the sentinel marking end-of-input stream. `getchar` et al are defined to
return EOF on end of input; if they didn't return a wider type than `char`,
there would be data that could not be read. On probably every machine I am
ever likely to use again in my lifetime, byte value 255 would be -1 as a
signed char, but it is also a perfect valid value for a byte.
The details of whether char is signed or unsigned aside, use of a wider
type is necessary for correctness and ability to completely represent the
input data.
It's one of the things that made C a good choice on a wide variety of
machines.
I guess I always "saw" the return value of the getchar() as being in a int
sized register, at first namely R0, so kept the character values returned
as ints. The actual EOF indication from a read is a return value of zero
for the number of characters read.
That's certainly true. Had C supported multiple return values or some kind
of option type from the outset, it might have been that `getchar`, read,
etc, returned a pair with some useful value (e.g., for `getchar` the value
of the byte read; for `read` a length) and some indication of an
error/EOF/OK value etc. Notably, both Go and Rust support essentially this:
in Go, `io.Read()` returns a `(int, error)` pair, and the error is `io.EOF`
on end-of-input; in Rust, the `read` method of the `Read` trait returns a
`Result<usize, io::Error>`, though a `Result::Ok(n)`, where `n==0`
indicates EOF.
But I'm just making noise because I'm sure everyone knows all this.
15 May
15 May
8:56 p.m.
New subject: v7 K&R C
On Fri, 15 May 2020, ron(a)ronnatalie.com wrote:
Unfortunately, if c is char on a machine with unsigned
chars, or it’s of
type unsigned char, the EOF will never be detected.
Isn't it nonstandard (although I am aware of some compilers that do it) to
default the type of char to unsigned?
-uso.
16 May
16 May
12:31 a.m.
New subject: v7 K&R C
On 2020-May-15 16:56:42 -0400, Steve Nickolas <usotsuki(a)buric.co> wrote:
Isn't it nonstandard (although I am aware of some
compilers that do it) to
default the type of char to unsigned?
The standard allows "char" to be either signed or unsigned. The ARM ABI
defines char as unsigned.
I recall that Lattice C on the M68K allowed either signed or unsigned char
via a flag. Setting it to "unsigned" generally produced faster code on
my Amiga, though some code assumed signed chars and broke.
--
Peter Jeremy
8:30 a.m.
New subject: v7 K&R C
On Sat, 16 May 2020, Peter Jeremy wrote:
On 2020-May-15 16:56:42 -0400, Steve Nickolas
<usotsuki(a)buric.co> wrote:
Borland did the same.
CC65, I think, defaults to unsigned char, but it's missing some other
features. It is, however, the closest (to my knowledge) that C on the
6502 gets to ANSI starndard.
-uso.
Isn't it nonstandard (although I am aware of
some compilers that do it) to
default the type of char to unsigned?
The standard allows "char" to be either signed or unsigned. The ARM ABI
defines char as unsigned.
I recall that Lattice C on the M68K allowed either signed or unsigned char
via a flag. Setting it to "unsigned" generally produced faster code on
my Amiga, though some code assumed signed chars and broke.
12:43 a.m.
New subject: v7 K&R C
If I had been thick enough to declare c as an unsigned char, it would have
taken a good bit more than 50% of the time, and wouldn't have worked at all.
On Fri, May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned
chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
4:28 p.m.
New subject: v7 K&R C
On Fri, May 15, 2020 at 4:02 PM
<ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is now
there */
The function prototype for getchar() is: int getchar(void);
It returns an int, not a char. In all likelihood this is specifically
*because* EOF is defined as -1. The above code works fine if c is an
int. One always has to be very careful when doing a typecast of a
function return value.
-Paul W.
5:39 p.m.
New subject: v7 K&R C
On Sat, May 16, 2020 at 10:28 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
In the early days of my involvement with FreeBSD, I went through and fixed
about a dozen cases where getopt was being assigned to a char and then
compared with EOF. I'm certain that this is why. Also EOF has to be a value
that's not representable by a character, or your 0xff bytes would disappear.
Warner
On Fri, May
15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
The function prototype for getchar() is: int getchar(void);
It returns an int, not a char. In all likelihood this is specifically
*because* EOF is defined as -1. The above code works fine if c is an
int. One always has to be very careful when doing a typecast of a
function return value.
19 May
19 May
7:45 p.m.
New subject: v7 K&R C
On Sat, May 16, 2020 at 11:39:54AM -0600, Warner Losh wrote:
On Sat, May 16, 2020 at 10:28 AM Paul Winalski
<paul.winalski(a)gmail.com>
wrote:
In the early days of my involvement with FreeBSD, I went through and fixed
about a dozen cases where getopt was being assigned to a char and then
compared with EOF. I'm certain that this is why. Also EOF has to be a value
that's not representable by a character, or your 0xff bytes would disappear.
I think I remember a code review on one of my patches to du(1), I think,
something about adding an option to ignore specific names when
recursing, and I remember either you or BDE chastising me about
while (ch = getopt(...), ch != EOF) :)
G'luck,
Peter
--
Peter Pentchev roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Fri,
May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
Unfortunately, if c is char on a machine with unsigned chars, or it’s of
type unsigned char, the EOF will never be detected.
- while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */
The function prototype for getchar() is: int getchar(void);
It returns an int, not a char. In all likelihood this is specifically
*because* EOF is defined as -1. The above code works fine if c is an
int. One always has to be very careful when doing a typecast of a
function return value.
20 May
20 May
3:52 a.m.
New subject: v7 K&R C
On a vaguely-related note, for some years I've been using the phrase
"algebraic syntax" to characterize languages such as Algol, C/C++,
Fortran, Java(Script), Ruby, etc. Contrary examples might include
Assembler, COBOL, Forth, Lisp, RPG, etc.
However, I can't find this usage in Wikipedia or elsewhere in the
Intertubes. Am I simply confused? Is there a better term to use?
Inquiring gnomes need to mine...
-r
21 May
21 May
3:06 p.m.
New subject: v7 K&R C
On Tue, 19 May 2020, Rich Morin wrote:
On a vaguely-related note, for some years I've
been using the phrase
"algebraic syntax" to characterize languages such as Algol, C/C++,
Fortran, Java(Script), Ruby, etc. Contrary examples might include
Assembler, COBOL, Forth, Lisp, RPG, etc.
My benchmark is "Can it be described in BNF?" LISP, for example, would be
something like:
phrase: "(" phrase ")"
However, I can't find this usage in Wikipedia or
elsewhere in the
Intertubes. Am I simply confused? Is there a better term to use?
Inquiring gnomes need to mine...
You are confused because you are relying upon Wikipedia :-) Well, someone
had to say it, so it may as well be me; as I keep saying, it's only as
accurate as the last idiot who updated it.
-- Dave, a Wikipedia editor
1429
days inactive
1436
days old
23 comments
17 participants
participants (17)
-
Brantley Coile -
Clem Cole -
Dan Cross -
Dave Horsfall -
Doug McIlroy -
Dr Iain Maoileoin -
John P. Linderman -
Larry McVoy -
Paul Winalski -
Peter Jeremy -
Peter Pentchev -
Rich Morin -
Richard Salz -
Rob Pike -
ron＠ronnatalie.com -
Steve Nickolas -
Warner Losh