[-- Attachment #1: Type: text/plain, Size: 698 bytes --] The C in v7 is, canonically, the language described in K&R, right? I must be doing something dumb. I am getting Webb Miller’s “s” editor built there, and I am down to one function. /* chop_arg - chop a function's argument to a maximum length */ static chop_arg(fcn, arg, maxlen) int (*fcn)(); int maxlen; char *arg; { char save; save = arg[maxlen]; arg[maxlen] = '\0'; fcn(arg); arg[maxlen] = save; } This doesn’t like the function pointer. $ cc -c choparg.c choparg.c:11: Call of non-function So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7? Adam [-- Attachment #2: Type: text/html, Size: 2250 bytes --]
[-- Attachment #1: Type: text/plain, Size: 236 bytes --] 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); -- Charles [-- Attachment #2: Type: text/html, Size: 940 bytes --]
[-- Attachment #1: Type: text/plain, Size: 484 bytes --] > 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 <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: 1877 bytes --]
[-- Attachment #1: Type: text/plain, Size: 192 bytes --] Getting closer! $ cc -c s *.o $ ./s Makefile ./s: cannot execute $ ls -l s -rw-rw-r-- 1 dmr 61644 Apr 23 11:06 s $ chmod +x s $ ./s usage: s file $ ./s Makefile Memory fault - core dumped [-- Attachment #2: Type: text/html, Size: 1015 bytes --]
[-- Attachment #1: Type: text/plain, Size: 917 bytes --] 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: 2098 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --] 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: 3045 bytes --]
I hate enums. I thought they would be type checked and they are just ints. I love C but enums suck. On Sat, Apr 25, 2020 at 12:54:27PM +1000, 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 > >> > >> -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --] Amen bro. I always felt that they got added because pascal had something that C didn’t, and yet it really was not the same. I always felt they were a feature that was only partly implemented and if they were not going to be fully typed then just leave them out and use cpp like we had always done before. On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm@mcvoy.com> wrote: > I hate enums. I thought they would be type checked and they are just ints. > I love C but enums suck. > > On Sat, Apr 25, 2020 at 12:54:27PM +1000, 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 > > >> > > >> > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 3873 bytes --]
[-- 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
What Clem said, that is precisely how I feel. I'd be fully for them if they fully type checked but without that, yeah, cpp is fine, enums are just a distraction. On Fri, Apr 24, 2020 at 11:30:26PM -0400, Clem Cole wrote: > Amen bro. I always felt that they got added because pascal had something > that C didn???t, and yet it really was not the same. I always felt they were > a feature that was only partly implemented and if they were not going to > be fully typed then just leave them out and use cpp like we had always done > before. > > On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm@mcvoy.com> wrote: > > > I hate enums. I thought they would be type checked and they are just ints. > > I love C but enums suck. > > > > On Sat, Apr 25, 2020 at 12:54:27PM +1000, 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 > > > >> > > > >> > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > > -- > Sent from a handheld expect more typos than usual -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
Larry McVoy writes:
> What Clem said, that is precisely how I feel. I'd be fully for them if they
> fully type checked but without that, yeah, cpp is fine, enums are just a
> distraction.
Enums are implemented badly, but it's possible to do even worse. This is from
linux /usr/include/sys/mount.h - can anyone explain the point of it to me?
enum
{
MS_RDONLY = 1, /* Mount read-only. */
#define MS_RDONLY MS_RDONLY
MS_NOSUID = 2, /* Ignore suid and sgid bits. */
#define MS_NOSUID MS_NOSUID
MS_NODEV = 4, /* Disallow access to device special files. */
#define MS_NODEV MS_NODEV
MS_NOEXEC = 8, /* Disallow program execution. */
#define MS_NOEXEC MS_NOEXEC
MS_SYNCHRONOUS = 16, /* Writes are synced at once. */
#define MS_SYNCHRONOUS MS_SYNCHRONOUS
MS_REMOUNT = 32, /* Alter flags of a mounted FS. */
#define MS_REMOUNT MS_REMOUNT
MS_MANDLOCK = 64, /* Allow mandatory locks on an FS. */
#define MS_MANDLOCK MS_MANDLOCK
MS_DIRSYNC = 128, /* Directory modifications are synchronous. */
#define MS_DIRSYNC MS_DIRSYNC
MS_NOATIME = 1024, /* Do not update access times. */
#define MS_NOATIME MS_NOATIME
MS_NODIRATIME = 2048, /* Do not update directory access times. */
#define MS_NODIRATIME MS_NODIRATIME
MS_BIND = 4096, /* Bind directory at different place. */
#define MS_BIND MS_BIND
MS_MOVE = 8192,
#define MS_MOVE MS_MOVE
MS_REC = 16384,
#define MS_REC MS_REC
MS_SILENT = 32768,
#define MS_SILENT MS_SILENT
MS_POSIXACL = 1 << 16, /* VFS does not apply the umask. */
#define MS_POSIXACL MS_POSIXACL
MS_UNBINDABLE = 1 << 17, /* Change to unbindable. */
#define MS_UNBINDABLE MS_UNBINDABLE
MS_PRIVATE = 1 << 18, /* Change to private. */
#define MS_PRIVATE MS_PRIVATE
MS_SLAVE = 1 << 19, /* Change to slave. */
#define MS_SLAVE MS_SLAVE
MS_SHARED = 1 << 20, /* Change to shared. */
#define MS_SHARED MS_SHARED
MS_RELATIME = 1 << 21, /* Update atime relative to mtime/ctime. */
#define MS_RELATIME MS_RELATIME
MS_KERNMOUNT = 1 << 22, /* This is a kern_mount call. */
#define MS_KERNMOUNT MS_KERNMOUNT
MS_I_VERSION = 1 << 23, /* Update inode I_version field. */
#define MS_I_VERSION MS_I_VERSION
MS_STRICTATIME = 1 << 24, /* Always perform atime updates. */
#define MS_STRICTATIME MS_STRICTATIME
MS_LAZYTIME = 1 << 25, /* Update the on-disk [acm]times lazily. */
#define MS_LAZYTIME MS_LAZYTIME
MS_ACTIVE = 1 << 30,
#define MS_ACTIVE MS_ACTIVE
MS_NOUSER = 1 << 31
#define MS_NOUSER MS_NOUSER
};
Adam Thornton wrote:
> Getting closer!
>
> $ cc -c s *.o
> $ ./s Makefile
> ./s: cannot execute
-c says to make an object file, right? Try -o instead.
On 24 Apr 2020 20:54 -0700, from jon@fourwinds.com (Jon Steinhart): > Enums are implemented badly, but it's possible to do even worse. This is from > linux /usr/include/sys/mount.h - can anyone explain the point of it to me? > > enum > { > MS_RDONLY = 1, /* Mount read-only. */ > #define MS_RDONLY MS_RDONLY > MS_NOSUID = 2, /* Ignore suid and sgid bits. */ > #define MS_NOSUID MS_NOSUID If you mean the #defining to itself, check out the discussion starting at <https://minnie.tuhs.org/pipermail/tuhs/2019-November/019429.html>. If you have the archive locally, that's Message-ID <201911131802.xADI2fxE752068@darkstar.fourwinds.com> from 13 Nov 2019 10:02 -0800 / 18:02 UTC. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
[-- Attachment #1: Type: text/plain, Size: 3099 bytes --] On Fri, Apr 24, 2020 at 11:31 PM Clem Cole <clemc@ccc.com> wrote: > Amen bro. I always felt that they got added because pascal had something > that C didn’t, and yet it really was not the same. I always felt they were > a feature that was only partly implemented and if they were not going to > be fully typed then just leave them out and use cpp like we had always done > before. > Aww shucks; I actually kinda like enums. When creating sequentially numbered constants, they're convenient. That said, the typing issues I have a lot of sympathy for. For true constants, it's a shame that `const` didn't make it in earlier, though we have it now. Abusing enum to define constants certainly feels like, well, abuse. - Dan C. On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm@mcvoy.com> wrote: > >> I hate enums. I thought they would be type checked and they are just >> ints. >> I love C but enums suck. >> >> On Sat, Apr 25, 2020 at 12:54:27PM +1000, 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 >> > >> >> > >> >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > -- > Sent from a handheld expect more typos than usual > [-- Attachment #2: Type: text/html, Size: 4770 bytes --]
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.
[-- 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 --]
[-- 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 --]
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
[-- 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 --]
On 10 May 2020 17:28 -0700, from scj@yaccman.com: > 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. Isn't that at least pretty close to how Ada does it? -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
[-- 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 --]
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.
[-- Attachment #1: Type: text/plain, Size: 895 bytes --] On Mon, May 11, 2020 at 2:25 PM Paul Winalski <paul.winalski@gmail.com> wrote: > 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. > Hrrrumph Point taken but ... C++ is an example in my mind of not listening to Dennis' words: - “C is quirky, flawed, and an enormous success.” <https://www.inspiringquotes.us/quotes/2Rki_bGM7zqTA> - “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.” <https://www.inspiringquotes.us/quotes/eDQR_hqwtHAC9> - “A language that doesn't have everything is actually easier to program in than some that do” <https://www.inspiringquotes.us/quotes/R86z_ybYw9JTS> [-- Attachment #2: Type: text/html, Size: 2197 bytes --]
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
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.
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.
Isn't that effectively what companies do now? Don't they all have a "Here is what you can use, this and nothing else" doc? On Mon, May 11, 2020 at 12:57:01PM -0700, joe mcguckin wrote: > 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. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:
> Isn't that effectively what companies do now? Don't they all have a
> "Here is what you can use, this and nothing else" doc?
>
> On Mon, May 11, 2020 at 12:57:01PM -0700, joe mcguckin wrote:
>> Maybe it???s time for C++ subset ???G'
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 multiple inheritance
o operator overloading
o friend classes
o C++ exception handling
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.
-Paul W.
> 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.
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
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.
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 #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 --]
> 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
[-- 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 --]
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --] At Thu, 14 May 2020 09:36:57 +1000 (EST), Dave Horsfall <dave@horsfall.org> wrote: Subject: Re: [TUHS] v7 K&R C > > On Tue, 12 May 2020, Paul Winalski 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. Well in the true OO world the ability to "overload" a message (aka what is sometimes effectively an operator) allows a wise designer to apply the traditional meaning of that message (operator) to a new kind of object. Attempts to change the meaning of a message (operator) when applied to already well known objects is forbidden by good taste and sane reviewers. C++ being a bit of a dog's breakfast seems to have given some people the idea that they can get away with abusing operator overloading for what can only amount to obfuscation. -- 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 --]
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --] On Wed, May 13, 2020, 10:22 PM Greg A. Woods <woods@robohack.ca> wrote: > At Thu, 14 May 2020 09:36:57 +1000 (EST), Dave Horsfall <dave@horsfall.org> > wrote: > Subject: Re: [TUHS] v7 K&R C > > > > On Tue, 12 May 2020, Paul Winalski 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. > > Well in the true OO world the ability to "overload" a message (aka what > is sometimes effectively an operator) allows a wise designer to apply > the traditional meaning of that message (operator) to a new kind of > object. Attempts to change the meaning of a message (operator) when > applied to already well known objects is forbidden by good taste and > sane reviewers. > > C++ being a bit of a dog's breakfast seems to have given some people the > idea that they can get away with abusing operator overloading for what > can only amount to obfuscation. > Queue rant about << and >> overloading... Warner -- > 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: Type: text/html, Size: 2518 bytes --]
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
> 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.
> 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".
>
It was right up there when I traced a bug to find someone had added this
line to one of the headers:
#define notdef 1
> 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".
>
It was right up there when I traced a bug to find someone had added this
line to one of the headers:
#define notdef 1
> 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".
>
It was right up there when I traced a bug to find someone had added this
line to one of the headers:
#define notdef 1
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.
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.
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
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.
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)
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 #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 --]
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.
[-- 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 --]
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
Brantley Coile <brantley@coraid.com> wrote on Sun, 17 May 2020 01:36:16 +0000: >> It looks like only grap and pic have mkfiles that invoke lex. Both of those are Brian Kernighan's work, and from the FIXES file in his nawk, I can offer this quote: >> ... >> Aug 9, 1997: >> somewhat regretfully, replaced the ancient lex-based lexical >> analyzer with one written in C. it's longer, generates less code, >> and more portable; the old one depended too much on mysterious >> properties of lex that were not preserved in other environments. >> in theory these recognize the same language. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------
Regarding lex/yacc/flex/bison, I remember (ca. 1980) when DEC's compiler group first got their hands on lex and yacc. For yucks they put the BLISS grammar through yacc. It came back with an error message that the grammar was ambiguous. And it turned out that, yes, Wulf's grammar for BLISS had an obscure corner case that *was* ambiguous. That caused quite a stir. -Paul W.
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
[-- Attachment #1: Type: text/plain, Size: 3284 bytes --] I also gave up on lex for parsing fairly early. The problem was reserved words. These looked like identifiers, but the state machine to pick out a couple of dozen reserved words out of all identifiers was too big for the PDP-11. When I wrote spell, I ran into the same problem. I had some rules that wanted to convert plurals to singular forms that would be found in the dictionary. Writing a rule to recognize .*ies and convert the "ies" to "y" blew out the memory after only a handful of patterns. My solution was to pick up words and reverse them before passing them through lex, so I looked for the pattern "sei.*", converted it to "y" and then reversed the word again. As it turned out, I only owned spell for a few weeks because Doug and others grabbed it and ran with it... Steve --- On 2020-05-16 18:23, Warner Losh 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 [-- Attachment #2: Type: text/html, Size: 8802 bytes --]
scj@yaccman.com wrote:
> As it turned out, I only owned spell for a few weeks because Doug and
> others grabbed it and ran with it...
>
> Steve
Who else besides Doug worked on spell?
Do I understand correctly that you invented the original pipeline based
spell:
tr ... | # split words to one line
tr ... | # lower case
sort -u | # sort and uniq
comm -12 - dict # find words not in dictionary
I didn't know that you'd worked on a rewrite in C.
Thanks,
Arnold
[-- Attachment #1: Type: text/plain, Size: 330 bytes --] Does anyone have the Usenix paper (80's timeframe I think) about making lex go fast? It was by Vern Paxson or Van Jacobson IIRC. Maybe only an abstract was published. The talk ended with a chart showing some CPU times, and the modified lex was only slightly slower than cat. Maybe Vern since he contributed to what became flex. [-- Attachment #2: Type: text/html, Size: 362 bytes --]
Interesting. My "speak" program had a trivial lexer that recognized literal tokens, many of which were prefixes of others, by maximum-munch binary search in a list of 1600 entries. Entries gave token+translation+rewrite. The whole thing fit in 15K. Many years later I wrote a regex recognizer that special-cased alternations of lots of literals. I believe Gnu's regex.c does that, too. (My regex also supported conjunction and negation-- legitimate regular-language operations--implemented by continuation-passing to avoid huge finite-state machines.) We have here a case of imperfect communication in 1127. Had I been conscious of the lex-explosion problem, I might have thought of speak and put support for speak-like tables into lex. As it happened, I only used yacc/lex once, quite successfully, for a small domain-specific language. Doug Steve Johnson wrote: I also gave up on lex for parsing fairly early. The problem was reserved words. These looked like identifiers, but the state machine to pick out a couple of dozen reserved words out of all identifiers was too big for the PDP-11. When I wrote spell, I ran into the same problem. I had some rules that wanted to convert plurals to singular forms that would be found in the dictionary. Writing a rule to recognize .*ies and convert the "ies" to "y" blew out the memory after only a handful of patterns. My solution was to pick up words and reverse them before passing them through lex, so I looked for the pattern "sei.*", converted it to "y" and then reversed the word again. As it turned out, I only owned spell for a few weeks because Doug and others grabbed it and ran with it.
Hi Rich,
> Does anyone have the Usenix paper (80's timeframe I think) about making lex
> go fast? It was by Vern Paxson or Van Jacobson IIRC. Maybe only an
> abstract was published. The talk ended with a chart showing some CPU
> times, and the modified lex was only slightly slower than cat. Maybe Vern
> since he contributed to what became flex.
Google Scholar's ‘Vancouver’ style citation:
Jacobson V. Tuning UNIX Lex or it's NOT true what they say
about Lex. InUSENIX Conference Proceedings (Washington,
DC, Winter 1987) 1987 (pp. 163-164).
Lack of space after ‘In’ is Google, not me.
I didn't find the paper itself, just citations of it.
--
Cheers, Ralph.
Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> Hi Rich,
>
> > Does anyone have the Usenix paper (80's timeframe I think) about making lex
> > go fast? It was by Vern Paxson or Van Jacobson IIRC. Maybe only an
> > abstract was published. The talk ended with a chart showing some CPU
> > times, and the modified lex was only slightly slower than cat. Maybe Vern
> > since he contributed to what became flex.
>
> Google Scholar's ‘Vancouver’ style citation:
>
> Jacobson V. Tuning UNIX Lex or it's NOT true what they say
> about Lex. InUSENIX Conference Proceedings (Washington,
> DC, Winter 1987) 1987 (pp. 163-164).
>
> Lack of space after ‘In’ is Google, not me.
>
> I didn't find the paper itself, just citations of it.
I'm pretty sure I have those proceedings. Given that it's 2 pages,
it's probably just an abstract. If there's interest, I can try to scan
the pages.
Arnold
Hi Arnold, > I'm pretty sure I have those proceedings. Given that it's 2 pages, > it's probably just an abstract. Yes, it's just the abstract, says https://compilers.iecc.com/comparch/article/87-05-012 -- Cheers, Ralph.
On Sun, Jun 14, 2020 at 03:48:19PM +0100, Ralph Corderoy wrote: > Hi Arnold, > > > I'm pretty sure I have those proceedings. Given that it's 2 pages, > > it's probably just an abstract. > > Yes, it's just the abstract, says > https://compilers.iecc.com/comparch/article/87-05-012 Clem was kind enough to send the scan to me, and it's now here: https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_USENIX_Winter_1987_pp163_164.pdf Cheers, Warren
On Mon, Jun 15, 2020 at 11:12:30AM +1000, Warren Toomey wrote:
> Clem was kind enough to send the scan to me, and it's now here:
> https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_USENIX_Winter_1987_pp163_164.pdf
John R. Levine might be a person to ask to see if he has a copy of
the paper.
Warren
Warren Toomey <wkt@tuhs.org> wrote:
> On Mon, Jun 15, 2020 at 11:12:30AM +1000, Warren Toomey wrote:
> > Clem was kind enough to send the scan to me, and it's now here:
> > https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_USENIX_Winter_1987_pp163_164.pdf
>
> John R. Levine might be a person to ask to see if he has a copy of
> the paper.
> Warren
I've just done so, by posting to comp.compilers.
Arnold