Re: [TUHS] v7 K&R C

Re: [TUHS] v7 K&R C

[Noel Chiappa]

    > 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

Re: [TUHS] v7 K&R C

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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@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
>
>

[-- Attachment #2: Type: text/html, Size: 1132 bytes --]

Re: [TUHS] v7 K&R C

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Sat, Apr 25, 2020, 7:18 AM Rob Pike <robpike@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@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
>>
>>

[-- Attachment #2: Type: text/html, Size: 1855 bytes --]

Re: [TUHS] C and C++ Regrets

[ron]

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.

Re: [TUHS] v7 K&R C

[Noel Chiappa]

    > From: Rob Pike

    > To make chaining of calls simpler. Write
    >   f()->g()->h()->i()
    > the other way

You mean:

  (*f)((*g)((*h)((*i)())))

I dunno, it doesn't seem that much worse to me.


What I like about the explicit notation (i.e. (*f) ()) is that it forces the
programmer to recognize what's going on.

On the other hand, I guess, the whole concept of compiled languages is to get
the programmer's nose out of the low-level details, so they can focus on the
high level. So I guess one could see allowing f() in place of (*f)() as an
instance of that.

Then again, down that road you find a lot of modern code, where a programmer
writes something that is e.g. horribly inefficient and slow, precisely because
they are so divorced from the low-level of what the code they wrote turns into...


Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))),
no matter what the notation was; it would be awfully hard to recognize what
all the possible call chains are. But then again I guess a lot of e.g. AI code
does things like that...

       Noel

Re: [TUHS] v7 K&R C

[Michael Kjörling]

On 25 Apr 2020 14:03 -0400, from jnc@mercury.lcs.mit.edu (Noel Chiappa):
> Then again, down that road you find a lot of modern code, where a programmer
> writes something that is e.g. horribly inefficient and slow, precisely because
> they are so divorced from the low-level of what the code they wrote turns into...

...and then there's an exceptionally complicated CPU execution
pipeline in which code is rearranged to try to allow the CPU to
execute it as fast as possible while preserving "observable" behavior.

As we know, down that road lies... security vulnerabilities.

That said, I agree; I don't know how many times I've nearly headdesked
coming across code that looks like someone typed the first thing that
entered their mind, instead of actually thinking the problem through
first and _then_ coding a solution. I'm almost certainly not innocent
there myself, either, although I do try.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [TUHS] v7 K&R C

[Brian L. Stuart]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

 On Saturday, April 25, 2020, 04:11:58 PM EDT, Michael Kjörling <michael@kjorling.se> wrote:
> That said, I agree; I don't know how many times I've nearly headdesked
> coming across code that looks like someone typed the first thing that
> entered their mind, instead of actually thinking the problem through
> first and _then_ coding a solution. I'm almost certainly not innocent
> there myself, either, although I do try.

I know that feeling all too well. I try to think of it in
the same terms as "Let him who is without sin cast
the first stone." But students coming to me with code
that is clearly created using the random walk method
of programming lead to me not always being as patient
with my counsel as I should be.

BLS
  

[-- Attachment #2: Type: text/html, Size: 873 bytes --]

Re: [TUHS] v7 K&R C

[emanuel stiebler]

On 2020-04-25 14:03, Noel Chiappa wrote:

> You mean:
>   (*f)((*g)((*h)((*i)())))

Are we still discussing LISP or C?
Sorry, couldn't resist ;-)

Re: [TUHS] v7 K&R C

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 59 bytes --]

>
> You mean:
>
>   (*f)((*g)((*h)((*i)())))
>
>
No.

-rob

[-- Attachment #2: Type: text/html, Size: 318 bytes --]

Re: [TUHS] v7 K&R C

[Derek Fawcus]

On Sat, Apr 25, 2020 at 02:03:57PM -0400, Noel Chiappa wrote:
>     > From: Rob Pike
> 
>     > To make chaining of calls simpler. Write
>     >   f()->g()->h()->i()
>     > the other way
> 
> You mean:
> 
>   (*f)((*g)((*h)((*i)())))
> 
> I dunno, it doesn't seem that much worse to me.

No, I think he means something like:

   (*((*((*((*f)()->g))()->h))()->i))()

but I can't recall the relative priority of '*' and '->' in
the above, so I may have added unnecessary parens.

Or was he thinking of having to use '.' as well to access
the member pointers within the structs?

DF

Re: [TUHS] v7 K&R C

[Derek Fawcus]

On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
> No, I think he means something like:
> 
>    (*((*((*((*f)()->g))()->h))()->i))()
> 
> but I can't recall the relative priority of '*' and '->' in
> the above, so I may have added unnecessary parens.

Actually trying it, while the above does the right thing,
I can also get the following to compile with a modern compiler

    (*(*(*(*f)()->g)()->h)()->i)();

So maybe that was the answer?

I guess I'd have to question why someone would wish to write
such a construct, as error handling seems awkward.  Even in
the modern form.

DF

Re: [TUHS] v7 K&R C

[Rich Morin]

> On Apr 26, 2020, at 13:10, Derek Fawcus wrote:
> 
> I guess I'd have to question why someone would wish to write such a construct,
> as error handling seems awkward.

FWIW, I do most of my programming these days in Elixir.  It's a functional
programming language with pervasive pattern matching, Rubyish syntax, and
Lispish macros.  It runs on the Erlang virtual machine, so it has a good
story for Actor-based concurrency, distribution, etc.  For details, see:

  https://en.wikipedia.org/wiki/Elixir_(programming_language)

Anyway, compilation is mostly handled by Lispish macros, so it can support
some fairly cool metaprogramming.  In particular, I can write things like:

out_map = inp_list     |>
Enum.filter(filter_fn) |>
Enum.map(map_fn)       |>
Enum.reduce(%{}, reduce_fn)

Piped values are handed in as the first argument to each function and most
functions expect this behavior.  For extra credit, there is a set of Stream
functions (really, macros) that process one element at a time and handle
errors in a reasonable manner.

-r

Re: [TUHS] v7 K&R C

[Noel Hunt]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Tom Cargill makes (made) frequent use of this construction in 'pi'
(process inspector, first in Eight Edition), e.g.,

asm.c:  _asm->core->process()->openmemory(addr);
frame.c: return core->process()->frame(level-1)->regloc((int)v->range.lo,
v->type.size_of());
phrase.c:  frame->symtab()->core()->process()->openmemory(expr->val.lng);


On Mon, Apr 27, 2020 at 6:11 AM Derek Fawcus <
dfawcus+lists-tuhs@employees.org> wrote:

> On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
> > No, I think he means something like:
> >
> >    (*((*((*((*f)()->g))()->h))()->i))()
> >
> > but I can't recall the relative priority of '*' and '->' in
> > the above, so I may have added unnecessary parens.
>
> Actually trying it, while the above does the right thing,
> I can also get the following to compile with a modern compiler
>
>     (*(*(*(*f)()->g)()->h)()->i)();
>
> So maybe that was the answer?
>
> I guess I'd have to question why someone would wish to write
> such a construct, as error handling seems awkward.  Even in
> the modern form.
>
> DF
>

[-- Attachment #2: Type: text/html, Size: 2077 bytes --]

Re: [TUHS] v7 K&R C

[Nemo Nusquam]

On 04/26/20 16:10, Derek Fawcus wrote:
> On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
>> No, I think he means something like:
>>
>>     (*((*((*((*f)()->g))()->h))()->i))()
>>
>> but I can't recall the relative priority of '*' and '->' in
>> the above, so I may have added unnecessary parens.
> Actually trying it, while the above does the right thing,
> I can also get the following to compile with a modern compiler
>
>      (*(*(*(*f)()->g)()->h)()->i)();
>
> So maybe that was the answer?

K&R 1, Sect. 6.2. (with no mention of Rob Pike's influence).

N.

>
> I guess I'd have to question why someone would wish to write
> such a construct, as error handling seems awkward.  Even in
> the modern form.
>
> DF

Re: [TUHS] v7 K&R C

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

Yes, that's the issue, which arose in C++ programs. The question at the
time was whether C would allow the same syntax.

Nothing to do with me.

-rob


On Mon, Apr 27, 2020 at 9:58 AM Nemo Nusquam <cym224@gmail.com> wrote:

> On 04/26/20 16:10, Derek Fawcus wrote:
> > On Sun, Apr 26, 2020 at 08:37:04PM +0100, Derek Fawcus wrote:
> >> No, I think he means something like:
> >>
> >>     (*((*((*((*f)()->g))()->h))()->i))()
> >>
> >> but I can't recall the relative priority of '*' and '->' in
> >> the above, so I may have added unnecessary parens.
> > Actually trying it, while the above does the right thing,
> > I can also get the following to compile with a modern compiler
> >
> >      (*(*(*(*f)()->g)()->h)()->i)();
> >
> > So maybe that was the answer?
>
> K&R 1, Sect. 6.2. (with no mention of Rob Pike's influence).
>
> N.
>
> >
> > I guess I'd have to question why someone would wish to write
> > such a construct, as error handling seems awkward.  Even in
> > the modern form.
> >
> > DF
>
>

[-- Attachment #2: Type: text/html, Size: 1562 bytes --]

Re: [TUHS] v7 K&R C

[Hellwig Geisse]

On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa 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?

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

Re: [TUHS] v7 K&R C

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 59 bytes --]

The compilers have caught up, -Wswitch-enum is worthwhile.

[-- Attachment #2: Type: text/html, Size: 84 bytes --]

Re: [TUHS] v7 K&R C

[Brian L. Stuart]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

 On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse <hellwig.geisse@mni.thm.de> wrote:
> On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
> > 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.

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
  

[-- Attachment #2: Type: text/html, Size: 990 bytes --]

Re: [TUHS] v7 K&R C

[Michael Kjörling]

On 25 Apr 2020 19:01 +0000, from blstuart@bellsouth.net (Brian L. Stuart):
>  On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse <hellwig.geisse@mni.thm.de> 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.
> 
> 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.

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@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [TUHS] v7 K&R C

[Brian L. Stuart]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

 On Saturday, April 25, 2020, 04:17:14 PM EDT, Michael Kjörling <michael@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
  

[-- Attachment #2: Type: text/html, Size: 1285 bytes --]

Re: [TUHS] v7 K&R C

[arnold]

"Brian L. Stuart" <blstuart@bellsouth.net> wrote:

>  On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse <hellwig.geisse@mni.thm.de> wrote:
> > On Sa, 2020-04-25 at 09:11 -0400, Noel Chiappa wrote:
> > > 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.
>
> 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
>   
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

[TUHS] s-for-v7, was Re: v7 K&R C

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1303 bytes --]