*Re: [TUHS] v7 K&R C
2020-04-25 2:51 ` Rob Pike
2020-04-25 2:54 ` Rob Pike@ 2020-04-25 3:37 ` Dave Horsfall
2020-04-27 13:19 ` Tony Finch2 siblings, 0 replies; 55+ messages in thread
From: Dave Horsfall @ 2020-04-25 3:37 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
On Sat, 25 Apr 2020, Rob Pike wrote:
> The ability to call a function pointer fp with the syntax fp() rather
> than (*fp)() came rather late, I think at Bjarne's suggestion or
> example. Pretty sure it was not in v7 C, as you observe.
I have never seen that syntax used (and I've been tooling around with Unix
for decades). The variable "fp" in an argument list is a pointer to the
function, not the function itself, so dereference it.
I wouldn't put it past Stroustrup to have it in C++ though, as it pretty
much has everything else in it.
> Convenient though the shorthand may be, it always bothered me as
> inconsistent and misleading. (I am pretty sure I used it sometimes
> regardless.)
Indeed... My principle is to write code as though the next person to
maintain it is a psychopathic axe-murderer who knows where you live (or
perhaps even yourself, a year later)...
-- Dave
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-04-25 2:51 ` Rob Pike
2020-04-25 2:54 ` Rob Pike
2020-04-25 3:37 ` Dave Horsfall@ 2020-04-27 13:19 ` Tony Finch2 siblings, 0 replies; 55+ messages in thread
From: Tony Finch @ 2020-04-27 13:19 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Rob Pike <robpike@gmail.com> wrote:
> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.
I've seen some interesting discussion about Dave Horsfall's favourite
retro-C definition of abort():
int abort 4;
...
abort();
https://minnie.tuhs.org/pipermail/tuhs/2020-March/020680.html
In particular a lot of people didn't know that function pointers could not
be called like abort() so they didn't realise that 4 was the machine code
contents of the function, not the address of the function. (Extra
confusing since branching to address 4 was also a plausible way to crash
the program...)
But that made me wonder what 7th-and-earlier C would do if you tried to
call a local variable. I guess that would lead to the compiler saying
error("Call of non-function");
Tony.
--
f.anthony.n.finch <dot@dotat.at> http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes: Northeasterly 4 to 6, occasionally 7 at
first in north Fair Isle. Moderate or rough. Showers. Good, occasionally
moderate.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-04-25 2:54 ` Rob Pike
2020-04-25 3:04 ` Larry McVoy@ 2020-05-11 0:28 ` scj
2020-05-11 0:32 ` Rob Pike
` (2 more replies)1 sibling, 3 replies; 55+ messages in thread
From: scj @ 2020-05-11 0:28 UTC (permalink / raw)
To: Rob Pike; +Cc: The Eunuchs Hysterical Society, ak
[-- Attachment #1: Type: text/plain, Size: 2760 bytes --]
Following up on Rob's comment, I always took the point of view that
Dennis owned the C description, and what he said goes. Not that I
didn't make suggestions that he accepted. One of the better ones
(actually in B) was ^ for exclusive OR. One of the worse ones was the
syntax for casts. We looked at about 5 different ideas and hated all of
them. And most of them couldn't be easily compiled with Yacc. So I
took the grammar for declarations, removed the variable name, and voila,
it expressed everything we wanted in the way of semantics, had a simple
rule of construction, and we badly needed the functionality for the
Interdata port. I quickly came to hate it, though -- the casts we were
using looked like a teletype threw up in the middle of the code.
With respect to enums, there is a feature I've wanted for years: a typed
typedef. Saying typetdef int foo would make foo an integer, but if you
passed an ordinary int to something declared as foo it would be an
error. Even if it was an integer constant unless cast.
The amount of mechanism required to get that behavior from both C and
C++ is horrible, so far as I know, although C++ has accreted so much
stuff maybe it's there now...
Steve
---
On 2020-04-24 19:54, Rob Pike wrote:
> Another debate at the time was caused by a disagreement between pcc and cc regarding enums: are they a type or just a way to declare constant? I remember getting annoyed by pcc not letting me declare a constant with an enum and use it as an int. I protested to scj and dmr and after some to-ing and fro-ing Steve changed pcc to treat them as constants.
>
> Not sure it was the right decision, but C desperately wanted a non-macro way to define a constant. I'd probably argue the same way today. The real lesson is how propinquity affects progress.
>
> -rbo
>
> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
> The ability to call a function pointer fp with the syntax fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty sure it was not in v7 C, as you observe.
>
> Convenient though the shorthand may be, it always bothered me as inconsistent and misleading. (I am pretty sure I used it sometimes regardless.)
>
> -rob
>
> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com> wrote:
>
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com> wrote:
>
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com> wrote:
> This doesn't like the function pointer.
>
> $ cc -c choparg.c
> choparg.c:11: Call of non-function
>
> Perhaps:
>
> (*fcn)(arg);
We have a winner!
Also, Kartik, dunno where it is on the net, but if you install a v7
system, /usr/src/cmd/c
Adam
[-- Attachment #2: Type: text/html, Size: 5167 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 0:28 ` scj@ 2020-05-11 0:32 ` Rob Pike
2020-05-11 0:57 ` Larry McVoy
2020-05-11 2:08 ` Lawrence Stewart
2020-05-11 11:36 ` Michael Kjörling2 siblings, 1 reply; 55+ messages in thread
From: Rob Pike @ 2020-05-11 0:32 UTC (permalink / raw)
To: Steve Johnson; +Cc: The Eunuchs Hysterical Society, ak
[-- Attachment #1: Type: text/plain, Size: 3180 bytes --]
Interesting that Go had only what you call "typed typdefs" until we needed
to add "untyped typedefs" so we could provide aliasing for forwarding
declarations. And that necessity made me unhappy. But the short version: Go
went the other way with what "typedef" means.
-rob
On Mon, May 11, 2020 at 10:28 AM <scj@yaccman.com> wrote:
> Following up on Rob's comment, I always took the point of view that Dennis
> owned the C description, and what he said goes. Not that I didn't make
> suggestions that he accepted. One of the better ones (actually in B) was ^
> for exclusive OR. One of the worse ones was the syntax for casts. We
> looked at about 5 different ideas and hated all of them. And most of them
> couldn't be easily compiled with Yacc. So I took the grammar for
> declarations, removed the variable name, and voila, it expressed everything
> we wanted in the way of semantics, had a simple rule of construction, and
> we badly needed the functionality for the Interdata port. I quickly came
> to hate it, though -- the casts we were using looked like a teletype threw
> up in the middle of the code.
>
> With respect to enums, there is a feature I've wanted for years: a typed
> typedef. Saying typetdef int foo would make foo an integer, but if you
> passed an ordinary int to something declared as foo it would be an error.
> Even if it was an integer constant unless cast.
>
> The amount of mechanism required to get that behavior from both C and C++
> is horrible, so far as I know, although C++ has accreted so much stuff
> maybe it's there now...
>
> Steve
> ---
>
>
>
> On 2020-04-24 19:54, Rob Pike wrote:
>
> Another debate at the time was caused by a disagreement between pcc and cc
> regarding enums: are they a type or just a way to declare constant? I
> remember getting annoyed by pcc not letting me declare a constant with an
> enum and use it as an int. I protested to scj and dmr and after some to-ing
> and fro-ing Steve changed pcc to treat them as constants.
>
> Not sure it was the right decision, but C desperately wanted a non-macro
> way to define a constant. I'd probably argue the same way today. The real
> lesson is how propinquity affects progress.
>
> -rbo
>
>
> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
>
> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.
>
> Convenient though the shorthand may be, it always bothered me as
> inconsistent and misleading. (I am pretty sure I used it sometimes
> regardless.)
>
> -rob
>
>
> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
> wrote:
>
>
>
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com>
> wrote:
>
>
>
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com> wrote:
>
> This doesn't like the function pointer.
>
>
> $ cc -c choparg.c
> choparg.c:11: Call of non-function
>
>
> Perhaps:
>
> (*fcn)(arg);
>
>
> We have a winner!
>
> Also, Kartik, dunno where it is on the net, but if you install a v7
> system, /usr/src/cmd/c
>
> Adam
>
>
[-- Attachment #2: Type: text/html, Size: 5575 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 0:32 ` Rob Pike@ 2020-05-11 0:57 ` Larry McVoy
2020-05-11 17:32 ` Greg A. Woods0 siblings, 1 reply; 55+ messages in thread
From: Larry McVoy @ 2020-05-11 0:57 UTC (permalink / raw)
To: Rob Pike; +Cc: The Eunuchs Hysterical Society, ak
My mail is screwed up, I see Rob's reply to Steve but didn't see Steve's
original.
> On Mon, May 11, 2020 at 10:28 AM <scj@yaccman.com> wrote:
> > With respect to enums, there is a feature I've wanted for years: a typed
> > typedef. Saying typetdef int foo would make foo an integer, but if you
> > passed an ordinary int to something declared as foo it would be an error.
> > Even if it was an integer constant unless cast.
Steve, I couldn't agree more, you are 100% right, this is how it should
work. I wanted to like enums because I naively thought they'd have these
semantics but then learned they really aren't any different than a well
managed list of #defines.
IMHO, without your semantics, enums are pretty useless, #define is good
enough and more clear.
--lm
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 0:28 ` scj
2020-05-11 0:32 ` Rob Pike@ 2020-05-11 2:08 ` Lawrence Stewart
2020-05-11 11:36 ` Michael Kjörling2 siblings, 0 replies; 55+ messages in thread
From: Lawrence Stewart @ 2020-05-11 2:08 UTC (permalink / raw)
To: Steve Johnson; +Cc: The Eunuchs Hysterical Society, ak
[-- Attachment #1: Type: text/plain, Size: 3802 bytes --]
If I remember correctly, enums in Mesa (the PARC Pascal like system language) had typed enums.
The 1979 version of the language manual at http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf <http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf>
says so anyway.
-L
PS The niftiest use of #define I know about was at the short lived supercomputer company SiCortex around 2005. Wilson Snyder (verilator fame) wrote a thing that extracted all the constants and register definitions from the CPU chip spec and output them as #define equivalents in 5 different languages.
PPS Thank you for ‘^'
> On 2020, May 10, at 8:28 PM, scj@yaccman.com wrote:
>
> Following up on Rob's comment, I always took the point of view that Dennis owned the C description, and what he said goes. Not that I didn't make suggestions that he accepted. One of the better ones (actually in B) was ^ for exclusive OR. One of the worse ones was the syntax for casts. We looked at about 5 different ideas and hated all of them. And most of them couldn't be easily compiled with Yacc. So I took the grammar for declarations, removed the variable name, and voila, it expressed everything we wanted in the way of semantics, had a simple rule of construction, and we badly needed the functionality for the Interdata port. I quickly came to hate it, though -- the casts we were using looked like a teletype threw up in the middle of the code.
>
> With respect to enums, there is a feature I've wanted for years: a typed typedef. Saying typetdef int foo would make foo an integer, but if you passed an ordinary int to something declared as foo it would be an error. Even if it was an integer constant unless cast.
>
> The amount of mechanism required to get that behavior from both C and C++ is horrible, so far as I know, although C++ has accreted so much stuff maybe it's there now...
>
> Steve
>
> ---
>
>
>
> On 2020-04-24 19:54, Rob Pike wrote:
>
>> Another debate at the time was caused by a disagreement between pcc and cc regarding enums: are they a type or just a way to declare constant? I remember getting annoyed by pcc not letting me declare a constant with an enum and use it as an int. I protested to scj and dmr and after some to-ing and fro-ing Steve changed pcc to treat them as constants.
>>
>> Not sure it was the right decision, but C desperately wanted a non-macro way to define a constant. I'd probably argue the same way today. The real lesson is how propinquity affects progress.
>>
>> -rbo
>>
>>
>> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com <mailto:robpike@gmail.com>> wrote:
>> The ability to call a function pointer fp with the syntax fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty sure it was not in v7 C, as you observe.
>>
>> Convenient though the shorthand may be, it always bothered me as inconsistent and misleading. (I am pretty sure I used it sometimes regardless.)
>>
>> -rob
>>
>>
>> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com <mailto:athornton@gmail.com>> wrote:
>>
>>
>>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com <mailto:charles.unix.pro@gmail.com>> wrote:
>>>
>>>
>>>
>>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com <mailto:athornton@gmail.com>> wrote:
>>> This doesn't like the function pointer.
>>>
>>> $ cc -c choparg.c
>>> choparg.c:11: Call of non-function
>>>
>>> Perhaps:
>>>
>>> (*fcn)(arg);
>>>
>>
>> We have a winner!
>>
>> Also, Kartik, dunno where it is on the net, but if you install a v7 system, /usr/src/cmd/c
>>
>> Adam
[-- Attachment #2: Type: text/html, Size: 7007 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 0:57 ` Larry McVoy@ 2020-05-11 17:32 ` Greg A. Woods
2020-05-11 18:25 ` Paul Winalski0 siblings, 1 reply; 55+ messages in thread
From: Greg A. Woods @ 2020-05-11 17:32 UTC (permalink / raw)
To: The Unix Heritage Society mailing list
[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]
At Sun, 10 May 2020 17:57:46 -0700, Larry McVoy <lm@mcvoy.com> wrote:
Subject: Re: [TUHS] v7 K&R C
>
> > On Mon, May 11, 2020 at 10:28 AM <scj@yaccman.com> wrote:
> > > With respect to enums, there is a feature I've wanted for years: a typed
> > > typedef. Saying typetdef int foo would make foo an integer, but if you
> > > passed an ordinary int to something declared as foo it would be an error.
> > > Even if it was an integer constant unless cast.
>
> Steve, I couldn't agree more, you are 100% right, this is how it should
> work. I wanted to like enums because I naively thought they'd have these
> semantics but then learned they really aren't any different than a well
> managed list of #defines.
Absolutely agreed!
The lameness of typedef (and in how enum is related to typedef) is one
of the saddest parts of C. (The other is the default promotion to int.)
It would be trivial to fix too -- for a "new" C, that is. Making it
backward compatible for legacy code would be tough, even with tooling to
help fix the worst issues. I've seen far too much code that would be
hard to fix by hand, e.g. some that even goes so far as to assume things
like arithmetic on enum values will produce other valid enum values.
Ideally enums could be a value in any native type, including float/double.
> IMHO, without your semantics, enums are pretty useless, #define is good
> enough and more clear.
Actually that's no longer true with a good modern toolchain, especially
with respect to the debugger. A good debugger can now show the enum
symbol for a (matching) value of a properly typedefed variable.
(In fact I never thouth that a #define macro was more clear, even before
debugger support -- the debugger support just gave me a better excuse to
use to explain my preference!)
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 17:32 ` Greg A. Woods@ 2020-05-11 18:25 ` Paul Winalski
2020-05-11 18:37 ` Clem Cole
2020-05-11 18:37 ` Larry McVoy0 siblings, 2 replies; 55+ messages in thread
From: Paul Winalski @ 2020-05-11 18:25 UTC (permalink / raw)
To: The Unix Heritage Society mailing list
On 5/11/20, Greg A. Woods <woods@robohack.ca> wrote:
>
> The lameness of typedef (and in how enum is related to typedef) is one
> of the saddest parts of C. (The other is the default promotion to int.)
I would add a third: file-scope declarations being global by default.
One must use the keyword "static" to restrict a file-scope declaration
to the file it's declared in. And why "static"? All file-scope
declarations have static allocation. Why isn't the keyword "local" or
"own"? Anyway, the way it ought to be is that file-scope declarations
are restricted to the file they're declared in. To make the symbol
visible outside its file, you should have to explicitly say "global".
> It would be trivial to fix too -- for a "new" C, that is. Making it
> backward compatible for legacy code would be tough, even with tooling to
> help fix the worst issues. I've seen far too much code that would be
> hard to fix by hand, e.g. some that even goes so far as to assume things
> like arithmetic on enum values will produce other valid enum values.
This ought to be easy to fix using a compiler command line option for
the legacy behavior. Many C compilers do this already to support K&R
semantics vs. standard C semantics.
> Ideally enums could be a value in any native type, including float/double.
Except pointers, of course.
>> IMHO, without your semantics, enums are pretty useless, #define is good
>> enough and more clear.
>
> Actually that's no longer true with a good modern toolchain, especially
> with respect to the debugger. A good debugger can now show the enum
> symbol for a (matching) value of a properly typedefed variable.
Indeed.
-Paul W.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 18:25 ` Paul Winalski
2020-05-11 18:37 ` Clem Cole@ 2020-05-11 18:37 ` Larry McVoy1 sibling, 0 replies; 55+ messages in thread
From: Larry McVoy @ 2020-05-11 18:37 UTC (permalink / raw)
To: Paul Winalski; +Cc: The Unix Heritage Society mailing list
On Mon, May 11, 2020 at 02:25:15PM -0400, Paul Winalski wrote:
> On 5/11/20, Greg A. Woods <woods@robohack.ca> wrote:
> >
> > The lameness of typedef (and in how enum is related to typedef) is one
> > of the saddest parts of C. (The other is the default promotion to int.)
>
> I would add a third: file-scope declarations being global by default.
> One must use the keyword "static" to restrict a file-scope declaration
> to the file it's declared in. And why "static"? All file-scope
I never cared for "static" either, seemed weird. All my code is
#define private static
private int
super_duper(void)
{
...
}
and everyone knows what that means at a glance.
> declarations have static allocation. Why isn't the keyword "local" or
> "own"? Anyway, the way it ought to be is that file-scope declarations
> are restricted to the file they're declared in. To make the symbol
> visible outside its file, you should have to explicitly say "global".
>
> > It would be trivial to fix too -- for a "new" C, that is. Making it
> > backward compatible for legacy code would be tough, even with tooling to
> > help fix the worst issues. I've seen far too much code that would be
> > hard to fix by hand, e.g. some that even goes so far as to assume things
> > like arithmetic on enum values will produce other valid enum values.
>
> This ought to be easy to fix using a compiler command line option for
> the legacy behavior. Many C compilers do this already to support K&R
> semantics vs. standard C semantics.
>
> > Ideally enums could be a value in any native type, including float/double.
>
> Except pointers, of course.
>
> >> IMHO, without your semantics, enums are pretty useless, #define is good
> >> enough and more clear.
> >
> > Actually that's no longer true with a good modern toolchain, especially
> > with respect to the debugger. A good debugger can now show the enum
> > symbol for a (matching) value of a properly typedefed variable.
>
> Indeed.
>
> -Paul W.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 18:37 ` Clem Cole@ 2020-05-11 19:12 ` Paul Winalski
2020-05-11 19:57 ` joe mcguckin0 siblings, 1 reply; 55+ messages in thread
From: Paul Winalski @ 2020-05-11 19:12 UTC (permalink / raw)
To: Clem Cole; +Cc: The Unix Heritage Society mailing list
On 5/11/20, Clem Cole <clemc@ccc.com> wrote:
>
> C++ is an example in my mind of not listening to Dennis' words:
>
> - “C is quirky, flawed, and an enormous success.”
Ditto Fortran.
> - “When I read commentary about suggestions for where C should go, I
> often think back and give thanks that it wasn't developed under the
> advice
> of a worldwide crowd.”
The old saying of an elephant being a mouse designed by committee comes to mind.
Language standards committees tend to be like a pack of dogs
contemplating a tree. Each dog isn't satisfied with the tree until
he's peed on it.
> - “A language that doesn't have everything is actually easier to program
> in than some that do”
Big, comprehensive languages such as PL/I, Ada, and C++ tend to have
more of their share of toxic language features--things that shouldn't
be used if you want reliable, easily maintained and understood code.
Ada failed for two reasons: [1] it had cooties because of its
military origins, and [2] it collapsed under the weight of all of its
features.
-Paul W.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-11 19:12 ` Paul Winalski@ 2020-05-11 19:57 ` joe mcguckin
2020-05-11 20:25 ` Larry McVoy0 siblings, 1 reply; 55+ messages in thread
From: joe mcguckin @ 2020-05-11 19:57 UTC (permalink / raw)
To: Paul Winalski; +Cc: The Unix Heritage Society mailing list
Maybe it’s time for C++ subset ‘G'
Joe McGuckin
ViaNet Communications
joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax
> On May 11, 2020, at 12:12 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> On 5/11/20, Clem Cole <clemc@ccc.com> wrote:
>>
>> C++ is an example in my mind of not listening to Dennis' words:
>>
>> - “C is quirky, flawed, and an enormous success.”
>
> Ditto Fortran.
>
>> - “When I read commentary about suggestions for where C should go, I
>> often think back and give thanks that it wasn't developed under the
>> advice
>> of a worldwide crowd.”
>
> The old saying of an elephant being a mouse designed by committee comes to mind.
>
> Language standards committees tend to be like a pack of dogs
> contemplating a tree. Each dog isn't satisfied with the tree until
> he's peed on it.
>
>> - “A language that doesn't have everything is actually easier to program
>> in than some that do”
>
> Big, comprehensive languages such as PL/I, Ada, and C++ tend to have
> more of their share of toxic language features--things that shouldn't
> be used if you want reliable, easily maintained and understood code.
> Ada failed for two reasons: [1] it had cooties because of its
> military origins, and [2] it collapsed under the weight of all of its
> features.
>
> -Paul W.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-12 17:35 ` ron@ 2020-05-12 17:42 ` Larry McVoy
2020-05-12 18:36 ` Paul Winalski1 sibling, 0 replies; 55+ messages in thread
From: Larry McVoy @ 2020-05-12 17:42 UTC (permalink / raw)
To: ron; +Cc: The Unix Heritage Society mailing list
Just a note, you seemed like you are replying to me (see below) but what
you quoted Paul wrote. I am most certainly NOT putting myself out there
as a C++ expert, I'm a C guy through and through.
On Tue, May 12, 2020 at 01:35:24PM -0400, ron@ronnatalie.com wrote:
> > On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:
>
> > o all std:: and STL functions
> >
> > The last two of these are mainly for performance reasons. throw and
> > catch play merry hell with compiler optimizations, especially of
> > global variables.
>
> You'll have to explain to me how templates or the standard library (which
> by the way includes all of the C stuff) affects performance. In fact, we
> use templates to INCREASE rather than decrease performance. Templating
> is almost entirely compile time rewrites.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-12 17:35 ` ron
2020-05-12 17:42 ` Larry McVoy@ 2020-05-12 18:36 ` Paul Winalski1 sibling, 0 replies; 55+ messages in thread
From: Paul Winalski @ 2020-05-12 18:36 UTC (permalink / raw)
To: The Unix Heritage Society mailing list
On 5/12/20, ron@ronnatalie.com <ron@ronnatalie.com> wrote:
>> On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:
>
>> o all std:: and STL functions
>>
>> The last two of these are mainly for performance reasons. throw and
>> catch play merry hell with compiler optimizations, especially of
>> global variables.
>
> You'll have to explain to me how templates or the standard library (which
> by the way includes all of the C stuff) affects performance. In fact, we
> use templates to INCREASE rather than decrease performance. Templating
> is almost entirely compile time rewrites.
The C++ standard libraries make heavy use of throw/catch exception
handling. If routine A calls routine B, and B is known by the
compiler to have the capability to throw exceptions, a bunch of
important optimizations can't be done. For example:
o You can't keep global values in registers around the call to B
because the handler that catches an exception that B throws might use
that global variable. So you have to spill the value around the call.
o You can't do value propagation of global variables around the call
to B because a handler might change their values.
And it gets a lot worse when you start doing parallel loop execution.
I implemented a new design for exception handling in a C/C++ compiler
back end, and I found lots of corner cases where the C++ standard was
silent as to what should happen when exceptions are thrown or caught
from parallel threads. Things such as the order of execution of
constructors and destructors for parallel routines when a thrown
exception is unwound, and which side of the parallelization executes
constructors and destructors under those conditions. The committee
just plain never considered those issues.
-Paul W.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-12 17:23 ` Paul Winalski
2020-05-12 17:35 ` ron@ 2020-05-13 23:36 ` Dave Horsfall
2020-05-14 0:42 ` John P. Linderman
` (2 more replies)1 sibling, 3 replies; 55+ messages in thread
From: Dave Horsfall @ 2020-05-13 23:36 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Tue, 12 May 2020, Paul Winalski wrote:
> Absolutely. The projects that I ran effectively used C++ as a
> stronger-typed version of C. A small subset of C++ features were
> allowed, but among the prohibited features were:
[...]
> 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.
I had to learn C++ for a project at $WORK years ago (the client demanded
it), and boy was I glad when I left...
-- Dave
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-13 23:36 ` Dave Horsfall@ 2020-05-14 0:42 ` John P. Linderman
2020-05-14 2:44 ` Rich Morin
2020-05-14 17:21 ` Larry McVoy
2020-05-14 4:21 ` Greg A. Woods
2020-05-14 17:32 ` Larry McVoy2 siblings, 2 replies; 55+ messages in thread
From: John P. Linderman @ 2020-05-14 0:42 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
I never liked call by reference. When I was trying to understand a chunk of
code, it was a great mental simplification to know that whatever a called
routine did, it couldn't have an effect on the code I was trying to
understand except through a returned value and (ghastly) global variables.
Operator overloading is far worse. Now I can't even be sure code I'm
looking at is doing what I thought it did.
On Wed, May 13, 2020 at 7:38 PM Dave Horsfall <dave@horsfall.org> wrote:
> On Tue, 12 May 2020, Paul Winalski wrote:
>
> > Absolutely. The projects that I ran effectively used C++ as a
> > stronger-typed version of C. A small subset of C++ features were
> > allowed, but among the prohibited features were:
>
> [...]
>
> > 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.
>
> I had to learn C++ for a project at $WORK years ago (the client demanded
> it), and boy was I glad when I left...
>
> -- Dave
>
[-- Attachment #2: Type: text/html, Size: 1572 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 0:42 ` John P. Linderman@ 2020-05-14 2:44 ` Rich Morin
2020-05-14 3:09 ` Charles Anthony
` (2 more replies)
2020-05-14 17:21 ` Larry McVoy1 sibling, 3 replies; 55+ messages in thread
From: Rich Morin @ 2020-05-14 2:44 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
> On May 13, 2020, at 17:42, John P. Linderman <jpl.jpl@gmail.com> wrote:
>
> I never liked call by reference. When I was trying to understand a chunk of code, it was a great mental simplification to know that whatever a called routine did, it couldn't have an effect on the code I was trying to understand except through a returned value and (ghastly) global variables. ...
A Fortran implementation I used years ago kept constants in a "literal pool". So, if you called a subroutine, passing in a constant, there was a possibility that the constant might be modified upon the routine's return. I don't recall this ever causing a problem in practice, but the possibility was amusing...
-r
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 2:44 ` Rich Morin@ 2020-05-14 3:09 ` Charles Anthony
2020-05-14 12:27 ` ron
` (2 more replies)
2020-05-14 7:38 ` Dave Horsfall
2020-05-14 17:13 ` Paul Winalski2 siblings, 3 replies; 55+ messages in thread
From: Charles Anthony @ 2020-05-14 3:09 UTC (permalink / raw)
To: Rich Morin; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Wed, May 13, 2020 at 7:45 PM Rich Morin <rdm@cfcl.com> wrote:
> > On May 13, 2020, at 17:42, John P. Linderman <jpl.jpl@gmail.com> wrote:
> >
> > I never liked call by reference. When I was trying to understand a chunk
> of code, it was a great mental simplification to know that whatever a
> called routine did, it couldn't have an effect on the code I was trying to
> understand except through a returned value and (ghastly) global variables.
> ...
>
> A Fortran implementation I used years ago kept constants in a "literal
> pool". So, if you called a subroutine, passing in a constant, there was a
> possibility that the constant might be modified upon the routine's return.
> I don't recall this ever causing a problem in practice, but the possibility
> was amusing...
>
Ah yes. A long time ago, some one came to me with a mysteriously behaving
Pr1me FORTRAN program; after much head scratching, I found where they were
changing the value of "0".
-- Charles
>
> --
X-Clacks-Overhead: GNU Terry Pratchett
[-- Attachment #2: Type: text/html, Size: 1700 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 2:44 ` Rich Morin
2020-05-14 3:09 ` Charles Anthony@ 2020-05-14 7:38 ` Dave Horsfall
2020-05-14 12:25 ` ron
2020-05-14 17:13 ` Paul Winalski2 siblings, 1 reply; 55+ messages in thread
From: Dave Horsfall @ 2020-05-14 7:38 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Wed, 13 May 2020, Rich Morin wrote:
> A Fortran implementation I used years ago kept constants in a "literal
> pool". So, if you called a subroutine, passing in a constant, there was
> a possibility that the constant might be modified upon the routine's
> return. I don't recall this ever causing a problem in practice, but the
> possibility was amusing...
As I dimly recall, Fortran has always used call by value/result (or
whatever the term is). So, if you modify an argument that happened to be
passed as a constant...
-- Dave
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 7:38 ` Dave Horsfall@ 2020-05-14 12:25 ` ron0 siblings, 0 replies; 55+ messages in thread
From: ron @ 2020-05-14 12:25 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
> On Wed, 13 May 2020, Rich Morin wrote:
>
>> A Fortran implementation I used years ago kept constants in a "literal
>> pool". So, if you called a subroutine, passing in a constant, there was
>> a possibility that the constant might be modified upon the routine's
>> return. I don't recall this ever causing a problem in practice, but the
>> possibility was amusing...
>
> As I dimly recall, Fortran has always used call by value/result (or
> whatever the term is). So, if you modify an argument that happened to be
> passed as a constant...
>
Fortran argument passing to functions is call by reference. Some
compilers had a non-standard exception to allow call by value.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 2:44 ` Rich Morin
2020-05-14 3:09 ` Charles Anthony
2020-05-14 7:38 ` Dave Horsfall@ 2020-05-14 17:13 ` Paul Winalski2 siblings, 0 replies; 55+ messages in thread
From: Paul Winalski @ 2020-05-14 17:13 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On 5/13/20, Rich Morin <rdm@cfcl.com> wrote:
>
> A Fortran implementation I used years ago kept constants in a "literal
> pool". So, if you called a subroutine, passing in a constant, there was a
> possibility that the constant might be modified upon the routine's return.
> I don't recall this ever causing a problem in practice, but the possibility
> was amusing...
Any modern compiler worth its salt does literal pooling. Fortunately
modern operating systems have the concept of read-only address space.
These days attempts to modify literal pool constants will give you a
memory access violation at the point where the illegal modification
was made.
-Paul W.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 0:42 ` John P. Linderman
2020-05-14 2:44 ` Rich Morin@ 2020-05-14 17:21 ` Larry McVoy
2020-05-17 16:34 ` Derek Fawcus1 sibling, 1 reply; 55+ messages in thread
From: Larry McVoy @ 2020-05-14 17:21 UTC (permalink / raw)
To: John P. Linderman; +Cc: The Eunuchs Hysterical Society
On Wed, May 13, 2020 at 08:42:55PM -0400, John P. Linderman wrote:
> I never liked call by reference. When I was trying to understand a chunk of
> code, it was a great mental simplification to know that whatever a called
> routine did, it couldn't have an effect on the code I was trying to
> understand except through a returned value and (ghastly) global variables.
Call by value is fine for things like a single integer or whatever. When
you have some giant array, you want to pass a pointer.
And "const" helps a lot with indicating the subroutine isn't going to
change it.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-13 23:36 ` Dave Horsfall
2020-05-14 0:42 ` John P. Linderman
2020-05-14 4:21 ` Greg A. Woods@ 2020-05-14 17:32 ` Larry McVoy
2020-05-14 22:32 ` Tony Finch2 siblings, 1 reply; 55+ messages in thread
From: Larry McVoy @ 2020-05-14 17:32 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
On Thu, May 14, 2020 at 09:36:57AM +1000, Dave Horsfall wrote:
> I had to learn C++ for a project at $WORK years ago (the client demanded
> it), and boy was I glad when I left...
Amen. I'm being a whiney grumpy old man, but I'm sort of glad I'm at the
tail end of my career. Going into it now, there are some bright spots,
and some dim ones, Go seems nice, Rust could have been nice but they just
had to come up with a different syntax, I can't see why anyone would do
anything other than an improved C like syntax, Java and C++ seem awful,
D tried but threw too much into the language like C++ did, if D had had
some restraint like Go does, D would probably be my language of choice.
Personally, I just want a modernized C. If you want to see what I want
take a look at https://www.little-lang.org/
It's got some perl goodness, regexps are part of the syntax, switches
work on strings or regexps as well as constants, it's pleasant. And
completely doable as an extension to C.
Oh, and it has reference counting on auto allocated stuff so when it
goes out of scope, free() is automatic.
--lm
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 17:32 ` Larry McVoy@ 2020-05-14 22:32 ` Tony Finch
2020-05-16 23:53 ` Steffen Nurpmeso0 siblings, 1 reply; 55+ messages in thread
From: Tony Finch @ 2020-05-14 22:32 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
Larry McVoy <lm@mcvoy.com> wrote:
>
> It's got some perl goodness, regexps are part of the syntax, ....
I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
riff on lex being its Swiss Army Knife. I came to appreciate lex
regrettably late: lex makes it remarkably easy to chew through a huge pile
of text and feed the pieces to some library code written in C. I've been
using re2c recently (http://re2c.org/), which is differently weird than
lex, though it still uses YY in all its variable names. It's remarkable
how much newer lexer/parser generators can't escape from the user
interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
Tony.
--
f.anthony.n.finch <dot@dotat.at> http://dotat.at/
Trafalgar: Cyclonic 6 to gale 8. Rough occasionally very rough in west and
south. Thundery showers. Good, occasionally poor.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 22:32 ` Tony Finch@ 2020-05-16 23:53 ` Steffen Nurpmeso
2020-05-16 23:59 ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
2020-05-17 0:35 ` [TUHS] v7 K&R C Larry McVoy
0 siblings, 2 replies; 55+ messages in thread
From: Steffen Nurpmeso @ 2020-05-16 23:53 UTC (permalink / raw)
To: Tony Finch; +Cc: The Eunuchs Hysterical Society
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
|Larry McVoy <lm@mcvoy.com> wrote:
|>
|> It's got some perl goodness, regexps are part of the syntax, ....
|
|I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
|Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
|riff on lex being its Swiss Army Knife. I came to appreciate lex
|regrettably late: lex makes it remarkably easy to chew through a huge pile
|of text and feed the pieces to some library code written in C. I've been
|using re2c recently (http://re2c.org/), which is differently weird than
|lex, though it still uses YY in all its variable names. It's remarkable
|how much newer lexer/parser generators can't escape from the user
|interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
P.S.: i really hate automated lexers. I never ever got used to
use them. For learning i once tried to use flex/bison, but
i failed really hard. I like that blood, sweat and tears thing,
and using a lexer seems so shattered, all the pieces. And i find
them really hard to read.
If you can deal with them they are surely a relief, especially in
rapidly moving syntax situations. But if i look at settled source
code which uses it, for example usr.sbin/ospfd/parse.y, or
usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
happy that i do not need to maintain that code.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C [really lexers]
2020-05-16 23:53 ` Steffen Nurpmeso@ 2020-05-16 23:59 ` Jon Steinhart
2020-05-17 0:04 ` Brantley Coile
2020-05-17 16:31 ` Paul Winalski
2020-05-17 0:35 ` [TUHS] v7 K&R C Larry McVoy
1 sibling, 2 replies; 55+ messages in thread
From: Jon Steinhart @ 2020-05-16 23:59 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Steffen Nurpmeso writes:
> Tony Finch wrote in
> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
> |Larry McVoy <lm@mcvoy.com> wrote:
> |>
> |> It's got some perl goodness, regexps are part of the syntax, ....
> |
> |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
> |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
> |riff on lex being its Swiss Army Knife. I came to appreciate lex
> |regrettably late: lex makes it remarkably easy to chew through a huge pile
> |of text and feed the pieces to some library code written in C. I've been
> |using re2c recently (http://re2c.org/), which is differently weird than
> |lex, though it still uses YY in all its variable names. It's remarkable
> |how much newer lexer/parser generators can't escape from the user
> |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>
> P.S.: i really hate automated lexers. I never ever got used to
> use them. For learning i once tried to use flex/bison, but
> i failed really hard. I like that blood, sweat and tears thing,
> and using a lexer seems so shattered, all the pieces. And i find
> them really hard to read.
>
> If you can deal with them they are surely a relief, especially in
> rapidly moving syntax situations. But if i look at settled source
> code which uses it, for example usr.sbin/ospfd/parse.y, or
> usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
> happy that i do not need to maintain that code.
>
> --steffen
Wow, I've had the opposite experience. I find lex/yacc/flex/bison really
easy to use. The issue, which I believe was covered in the early docs,
is that some languages are not designed with regularity in mind which makes
for ugly code. But to be fair, that code is at least as ugly with hand-crafted
code.
I believe that the original wisecrack was directed towards FORTRAN. My ancient
experience was that it was using lex/yacc for HSPICE was not going to work so I
had to hand-craft code for that.
Jon
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C [really lexers]
2020-05-16 23:59 ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
@ 2020-05-17 0:04 ` Brantley Coile
2020-05-17 1:23 ` Warner Losh
2020-05-17 16:31 ` Paul Winalski1 sibling, 1 reply; 55+ messages in thread
From: Brantley Coile @ 2020-05-17 0:04 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]
“The asteroid to kill this dinosaur is still in orbit.“
—- Plan 9 lex man page
I always hand craft my lexers and use yacc to parse. Most code on plan 9 does that as well.
Brantley
On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:
﻿Steffen Nurpmeso writes:
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
|Larry McVoy <lm@mcvoy.com> wrote:
|>
|> It's got some perl goodness, regexps are part of the syntax, ....
|
|I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
|Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
|riff on lex being its Swiss Army Knife. I came to appreciate lex
|regrettably late: lex makes it remarkably easy to chew through a huge pile
|of text and feed the pieces to some library code written in C. I've been
|using re2c recently (http://re2c.org/), which is differently weird than
|lex, though it still uses YY in all its variable names. It's remarkable
|how much newer lexer/parser generators can't escape from the user
|interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
P.S.: i really hate automated lexers. I never ever got used to
use them. For learning i once tried to use flex/bison, but
i failed really hard. I like that blood, sweat and tears thing,
and using a lexer seems so shattered, all the pieces. And i find
them really hard to read.
If you can deal with them they are surely a relief, especially in
rapidly moving syntax situations. But if i look at settled source
code which uses it, for example usr.sbin/ospfd/parse.y, or
usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
happy that i do not need to maintain that code.
--steffen
Wow, I've had the opposite experience. I find lex/yacc/flex/bison really
easy to use. The issue, which I believe was covered in the early docs,
is that some languages are not designed with regularity in mind which makes
for ugly code. But to be fair, that code is at least as ugly with hand-crafted
code.
I believe that the original wisecrack was directed towards FORTRAN. My ancient
experience was that it was using lex/yacc for HSPICE was not going to work so I
had to hand-craft code for that.
Jon
[-- Attachment #2: Type: text/html, Size: 4835 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-16 23:53 ` Steffen Nurpmeso
2020-05-16 23:59 ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
@ 2020-05-17 0:35 ` Larry McVoy1 sibling, 0 replies; 55+ messages in thread
From: Larry McVoy @ 2020-05-17 0:35 UTC (permalink / raw)
To: Tony Finch, Larry McVoy, The Eunuchs Hysterical Society
On Sun, May 17, 2020 at 01:53:08AM +0200, Steffen Nurpmeso wrote:
> Tony Finch wrote in
> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
> |Larry McVoy <lm@mcvoy.com> wrote:
> |>
> |> It's got some perl goodness, regexps are part of the syntax, ....
> |
> |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
> |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
> |riff on lex being its Swiss Army Knife. I came to appreciate lex
> |regrettably late: lex makes it remarkably easy to chew through a huge pile
> |of text and feed the pieces to some library code written in C. I've been
> |using re2c recently (http://re2c.org/), which is differently weird than
> |lex, though it still uses YY in all its variable names. It's remarkable
> |how much newer lexer/parser generators can't escape from the user
> |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>
> P.S.: i really hate automated lexers. I never ever got used to
> use them. For learning i once tried to use flex/bison, but
> i failed really hard. I like that blood, sweat and tears thing,
> and using a lexer seems so shattered, all the pieces. And i find
> them really hard to read.
They are not bad if you are good at it. One of my guys has a PhD in
compilers and he's good at it.
They are not good at performance. BitKeeper has an extensive printf
like (sort of, different syntax) language that can be used to customize
log output. Rob originally did all that in flex/bison but the performance
started to hurt so he rewrote it all:
/*
* This is a recursive-descent parser that implements the following
* grammar for dspecs (where [[...]] indicates an optional clause
* and {{...}} indicates 0 or more repetitions of):
*
* <stmt_list> -> {{ <stmt> }}
* <stmt> -> $if(<expr>){<stmt_list>}[[$else{<stmt_list>}]]
* -> $unless(<expr>){<stmt_list>}[[$else{<stmt_list>}]]
* -> $each(:ID:){<stmt_list>}
* -> ${<num>=<stmt_list>}
* -> <atom>
* <expr> -> <expr2> {{ <logop> <expr2> }}
* <expr2> -> <str> <relop> <str>
* -> <str>
* -> (<expr>)
* -> !<expr2>
* <str> -> {{ <atom> }}
* <atom> -> char
* -> escaped_char
* -> :ID:
* -> (:ID:)
* -> $<num>
* <logop> -> " && " | " || "
* <relop> -> "=" | "!=" | "=~"
* -> " -eq " | " -ne " | " -gt " | " -ge " | " -lt " | " -le "
*
* This grammar is ambiguous due to (:ID:) loooking like a
* parenthesized sub-expression. The code tries to parse (:ID:) first
* as an $each variable, then as a regular :ID:, then as regular text.
*
* Note that this is broken: $if((:MERGE:)){:REV:}
*
* The following procedures can be thought of as implementing an
* attribute grammar where the output parameters are synthesized
* attributes which hold the expression values and the next token
* of lookahead in some cases. It has been written for speed.
*
* NOTE: out==0 means evaluate but throw away.
*
* Written by Rob Netzer <rob@bolabs.com> with some hacking
* by wscott & lm.
*/
That stuff screams perf wise.
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C [really lexers]
2020-05-17 0:04 ` Brantley Coile@ 2020-05-17 1:23 ` Warner Losh
2020-05-17 1:36 ` Brantley Coile0 siblings, 1 reply; 55+ messages in thread
From: Warner Losh @ 2020-05-17 1:23 UTC (permalink / raw)
To: Brantley Coile; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]
On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley@coraid.com> wrote:
> “The asteroid to kill this dinosaur is still in orbit.“
>
> —- Plan 9 lex man page
>
>
> I always hand craft my lexers and use yacc to parse. Most code on plan 9
> does that as well.
>
Wow! That is the most awesome thing I've seen in a while....
Warner
Brantley
>
>
> On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:
>
> ﻿Steffen Nurpmeso writes:
>
> Tony Finch wrote in
>
> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
>
> |Larry McVoy <lm@mcvoy.com> wrote:
>
> |>
>
> |> It's got some perl goodness, regexps are part of the syntax, ....
>
> |
>
> |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
>
> |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
>
> |riff on lex being its Swiss Army Knife. I came to appreciate lex
>
> |regrettably late: lex makes it remarkably easy to chew through a huge pile
>
> |of text and feed the pieces to some library code written in C. I've been
>
> |using re2c recently (http://re2c.org/), which is differently weird than
>
> |lex, though it still uses YY in all its variable names. It's remarkable
>
> |how much newer lexer/parser generators can't escape from the user
>
> |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>
>
> P.S.: i really hate automated lexers. I never ever got used to
>
> use them. For learning i once tried to use flex/bison, but
>
> i failed really hard. I like that blood, sweat and tears thing,
>
> and using a lexer seems so shattered, all the pieces. And i find
>
> them really hard to read.
>
>
> If you can deal with them they are surely a relief, especially in
>
> rapidly moving syntax situations. But if i look at settled source
>
> code which uses it, for example usr.sbin/ospfd/parse.y, or
>
> usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
>
> happy that i do not need to maintain that code.
>
>
> --steffen
>
>
> Wow, I've had the opposite experience. I find lex/yacc/flex/bison really
> easy to use. The issue, which I believe was covered in the early docs,
> is that some languages are not designed with regularity in mind which makes
> for ugly code. But to be fair, that code is at least as ugly with
> hand-crafted
> code.
>
> I believe that the original wisecrack was directed towards FORTRAN. My
> ancient
> experience was that it was using lex/yacc for HSPICE was not going to work
> so I
> had to hand-craft code for that.
>
> Jon
>
>
[-- Attachment #2: Type: text/html, Size: 5765 bytes --]^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C [really lexers]
2020-05-17 1:23 ` Warner Losh@ 2020-05-17 1:36 ` Brantley Coile0 siblings, 0 replies; 55+ messages in thread
From: Brantley Coile @ 2020-05-17 1:36 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
It looks like only grap and pic have mkfiles that invoke lex.
> On May 16, 2020, at 9:23 PM, Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley@coraid.com> wrote:
> “The asteroid to kill this dinosaur is still in orbit.“
> —- Plan 9 lex man page
>
> I always hand craft my lexers and use yacc to parse. Most code on plan 9 does that as well.
>
> Wow! That is the most awesome thing I've seen in a while....
>
> Warner
>
>
> Brantley
>
>
>> On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:
>>
>> ﻿Steffen Nurpmeso writes:
>>> Tony Finch wrote in
>>> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
>>> |Larry McVoy <lm@mcvoy.com> wrote:
>>> |>
>>> |> It's got some perl goodness, regexps are part of the syntax, ....
>>> |
>>> |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
>>> |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
>>> |riff on lex being its Swiss Army Knife. I came to appreciate lex
>>> |regrettably late: lex makes it remarkably easy to chew through a huge pile
>>> |of text and feed the pieces to some library code written in C. I've been
>>> |using re2c recently (http://re2c.org/), which is differently weird than
>>> |lex, though it still uses YY in all its variable names. It's remarkable
>>> |how much newer lexer/parser generators can't escape from the user
>>> |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>>>
>>> P.S.: i really hate automated lexers. I never ever got used to
>>> use them. For learning i once tried to use flex/bison, but
>>> i failed really hard. I like that blood, sweat and tears thing,
>>> and using a lexer seems so shattered, all the pieces. And i find
>>> them really hard to read.
>>>
>>> If you can deal with them they are surely a relief, especially in
>>> rapidly moving syntax situations. But if i look at settled source
>>> code which uses it, for example usr.sbin/ospfd/parse.y, or
>>> usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
>>> happy that i do not need to maintain that code.
>>>
>>> --steffen
>>
>> Wow, I've had the opposite experience. I find lex/yacc/flex/bison really
>> easy to use. The issue, which I believe was covered in the early docs,
>> is that some languages are not designed with regularity in mind which makes
>> for ugly code. But to be fair, that code is at least as ugly with hand-crafted
>> code.
>>
>> I believe that the original wisecrack was directed towards FORTRAN. My ancient
>> experience was that it was using lex/yacc for HSPICE was not going to work so I
>> had to hand-craft code for that.
>>
>> Jon
^permalinkrawreply [flat|nested] 55+ messages in thread

*Re: [TUHS] v7 K&R C
2020-05-14 17:21 ` Larry McVoy@ 2020-05-17 16:34 ` Derek Fawcus0 siblings, 0 replies; 55+ messages in thread
From: Derek Fawcus @ 2020-05-17 16:34 UTC (permalink / raw)
To: tuhs
On Thu, May 14, 2020 at 10:21:07AM -0700, Larry McVoy wrote:
> On Wed, May 13, 2020 at 08:42:55PM -0400, John P. Linderman wrote:
> > I never liked call by reference. When I was trying to understand a chunk of
> > code, it was a great mental simplification to know that whatever a called
> > routine did, it couldn't have an effect on the code I was trying to
> > understand except through a returned value and (ghastly) global variables.
That has always been my issue with the C++ references, that one could not
read a piece of code in isolation, and know when a reference may be made.
I guess I'd be happy with references if the syntax always required one to
write '&x' when they're being created, then the called function can choose
if it either wishes to use a pointer or a reference, the only difference
being the syntax used to deref the reference.
As to Doug's point about new arithmetic types and overloading, I recall
a few years ago reading on the 9fans list about an extension there (in KenC?)
which supported them in C. I've not managed to dig up the details again,
maybe someone else could. As I recall it involved defining structs.
> Call by value is fine for things like a single integer or whatever. When
> you have some giant array, you want to pass a pointer.
>
> And "const" helps a lot with indicating the subroutine isn't going to
> change it.
However that is simply the ABI, i.e. it should be possible for a sufficiently
clever compiler to implement such a call-by-value as a call-by-constish-reference.
i.e. this:
somefn(struct s p) {...}
struct s ss; somefn(ss);
in effect becomes syntax sugar for:
somefn(constish ref struct s p) {...}
struct s ss; somefn(&ss);
Where 'constish' does not allow 'ss' to be altered even if somefn() assigns
to 'p', because in that case it would do sufficient copying so as to
make things work. There was a proposed MIPS ABI which stated this.
The current C semantics in effect do that, but with the ABIs always having
the caller make a copy and pass a reference to it, rather than allowing the
callee to make a copy if/when required.
DF
^permalinkrawreply [flat|nested] 55+ messages in thread