25 Apr
2020
25 Apr
'20
7:11 p.m.
From: Rob Pike
Convenient though the shorthand may be, it always
bothered me as
inconsistent and misleading.
As someone who made very extensive use of procedure pointers (most notably in
upcalls, which never caught on, alas), I couldn't agree more.
Two very different things are happenging, but with the shorthand notation,
they share an identical representation. And for what? To save three characters?
Noel
25 Apr
25 Apr
7:18 p.m.
New subject: v7 K&R C
To make chaining of calls simpler. Write
f()->g()->h()->i()
the other way and you'll see why Bjarne asked for the shorthand.
-rob
On Sat, Apr 25, 2020 at 11:12 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
From: Rob Pike
Convenient though the shorthand may be, it always
bothered me as
inconsistent and misleading.
As someone who made very extensive use of procedure pointers (most notably
in
upcalls, which never caught on, alas), I couldn't agree more.
Two very different things are happenging, but with the shorthand notation,
they share an identical representation. And for what? To save three
characters?
Noel
8:57 p.m.
New subject: v7 K&R C
On Sat, Apr 25, 2020, 7:18 AM Rob Pike <robpike(a)gmail.com> wrote:
To make chaining of calls simpler. Write
f()->g()->h()->i()
the other way and you'll see why Bjarne asked for the shorthand.
Yea. The other way looks way too lispy...
Warner
-rob
On Sat, Apr 25, 2020 at 11:12 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
> > From: Rob Pike
>
> > Convenient though the shorthand may be, it always bothered me as
> > inconsistent and misleading.
>
> As someone who made very extensive use of procedure pointers (most
> notably in
> upcalls, which never caught on, alas), I couldn't agree more.
>
> Two very different things are happenging, but with the shorthand notation,
> they share an identical representation. And for what? To save three
> characters?
>
> Noel
>
>
10:13 p.m.
New subject: C and C++ Regrets
The two things I'd wish had happened in C or C++
1. That when they fixed structs/unions to have proper assignment and
function argument and return behavior (i.e., making them full-fledged
types), that they would have done the same for arrays. This inane "treat
it like a pointer" has always been problematic.
2. That the default behavior in C++ is to *ALWAYS* initialize an object,
even if it is POD, no matter how it is allocated.
7:35 p.m.
New subject: v7 K&R C
On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
The subject can be looked at from another angle. Consider
the call f(42). This might be read as first naming f (and
thus constructing a pointer to f) and then calling the
function which the pointer is pointing to. So at least
it should be possible to write the call as (*f)(42), which
indeed is equivalent to f(42). So it can be argued that
this notational shorthand should be allowed with all
function pointers.
Hellwig
From: Rob Pike
Convenient though the shorthand may be, it always
bothered me as
inconsistent and misleading.
As someone who made very extensive use of procedure pointers (most notably in
upcalls, which never caught on, alas), I couldn't agree more.
Two very different things are happenging, but with the shorthand notation,
they share an identical representation. And for what? To save three characters? 
26 Apr
26 Apr
1:01 a.m.
New subject: v7 K&R C
On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse
<hellwig.geisse(a)mni.thm.de> wrote:
On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
This is the way that I've taken to looking at it for the
last 10 years or so. In fact, I see it as the same thing
as an array. Specifically, I've taken to thinking of []
as a postfix indexing operator and () as a postfix
calling operator, and the thing on the left is a pointer
in both cases.
BLS
Two very different things are happenging, but
with the shorthand notation,
they share an identical representation. And for what? To save three characters?
The subject can be looked at from another angle. Consider
the call f(42). This might be read as first naming f (and
thus constructing a pointer to f) and then calling the
function which the pointer is pointing to. 
2:07 a.m.
New subject: v7 K&R C
On 25 Apr 2020 19:01 +0000, from blstuart(a)bellsouth.net (Brian L. Stuart):
On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig
Geisse <hellwig.geisse(a)mni.thm.de> wrote:
That's an interesting way of looking at it.
I was thinking: couldn't we apply the same kind of reasoning to
variables as well?
Bear with me for a second.
If we have
int z = 123;
then "z" is a mnenomic way of referring to an int-sized memory
location, which after initialization holds the value 123. In C, we can
take the address of any variable stored in memory, and we can
dereference any address into memory. (How _meaningful_ especially the
latter is varies, particularly on memory-protected architectures, but
it's still possible.)
So, is there any material difference between
printf("%d", z);
and
printf("%d", *(&z));
If there is, then certainly GCC isn't indicating that it's there. Both
print 123, and both variants compile cleanly even with -Wall -pedantic.
OpenBSD clang 8.0.1 cc also gives identical output for both variants.
So if "z" and "*(&z)" (take the address of z, then dereference
that
address, then use the value stored there) are equivalent, then in the
name of consistency, why _shouldn't_ f() and (*f)() (dereference the
address of f, then call) also be equivalent? After all, what is "f"
here, other than a mnenomic name for a memory location?
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
The subject can be looked at from another angle.
Consider
the call f(42). This might be read as first naming f (and
thus constructing a pointer to f) and then calling the
function which the pointer is pointing to.
This is the way that I've taken to looking at it for the
last 10 years or so. In fact, I see it as the same thing
as an array. Specifically, I've taken to thinking of []
as a postfix indexing operator and () as a postfix
calling operator, and the thing on the left is a pointer
in both cases.
3:34 a.m.
New subject: v7 K&R C
On Saturday, April 25, 2020, 04:17:14 PM EDT, Michael Kjörling
<michael(a)kjorling.se> wrote:
I was thinking: couldn't we apply the same kind
of reasoning to
variables as well?
...
In short, yes. In the language Bliss, all identifiers
stood for the address of that thing. A prefix dot (.)
dereferences that thing. So copying x to y would be
something like
y = .x;
In C, rvalues have an implicit dereference happening.
I've actually created a toy language that I subject
my students to that revives the Bliss view to drive
home in their minds the difference between the
address of a memory location and the contents
of a memory location. I want them to have some
concept of how the program connects to the machine
before they find themselves so mired in abstraction
that everything is treated as magic.
One of my TAs in that class last fall was taking a
class in the winter where she was using C seriously
for the first time and having trouble understanding
pointers. When I explained how C pointers worked
in terms of the variables and dots of this other
language it became much more clear for her.
BLS
12:40 p.m.
New subject: v7 K&R C
"Brian L. Stuart" <blstuart(a)bellsouth.net> wrote:
On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig
Geisse <hellwig.geisse(a)mni.thm.de> wrote:
Algol 68 had a concept "deproceduring" similar to
"dereferencing". If you
think of
foo(arg)
where plain "foo" is a pointer to a function and adding the parentheses
does the call, then it's the same with a procedure name or with
a function pointer.
This is pretty much what BLS said. Thinking of [] and () as operators
is explicit in C++ (for good and for ill).
Arnold
On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa
wrote:
This is the way that I've taken to looking at it for the
last 10 years or so. In fact, I see it as the same thing
as an array. Specifically, I've taken to thinking of []
as a postfix indexing operator and () as a postfix
calling operator, and the thing on the left is a pointer
in both cases.
BLS
Two very different things are happenging, but
with the shorthand notation,
they share an identical representation. And for what? To save three characters?
The subject can be looked at from another angle. Consider
the call f(42). This might be read as first naming f (and
thus constructing a pointer to f) and then calling the
function which the pointer is pointing to. 
28 Apr
28 Apr
12:47 a.m.
New subject: s-for-v7, was Re: v7 K&R C
If anyone else could use it, “s” slightly modified from Miller’s sources (via Udo Munk’s
repository) to build on out-of-the-box v7 + C compiler:
https://github.com/athornton/s/tree/v7 <https://github.com/athornton/s/tree/v7>
It’s a reimplementation of Paul Ruizendall’s work. The changes are:
1) the indirect function call syntax needs to be (*fcn)(arg) rather than fcn(arg).
2) scr_delr and scr_delc needed to be shortened by a character because the linker puts an
underscore in front of the name and truncates the symbol to 8 characters, and without that
fix they are not distinguishable.
3) isprint() in v7 didn't recognize the space as a printable character
Screen repainting doesn’t seem to be entirely reliable, but…it still works a lot like vi,
which I find more pleasant than ed.
Adam
1700
days inactive
1702
days old
10 comments
10 participants
participants (10)
-
Adam Thornton -
arnold＠skeeve.com -
Brian L. Stuart -
Hellwig Geisse -
jnc＠mercury.lcs.mit.edu -
Michael Kjörling -
Richard Salz -
Rob Pike -
ron＠ronnatalie.com -
Warner Losh