Re: Recursion, Yo

On 15.04.2024 21:00, Keith Thompson wrote:

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 14.04.2024 02:29, Michael S wrote:

<Algol 68 code elided>

It looks closer to C than to Pascal, i.e. pointer can point to any
object rather than just to dynamically allocated object.

>
The major difference is that they are closely bound to the type.
In that respect they are more like Pascal pointers. C pointers
open the can of issues with arithmetic on pointer values. You
don't find that in Pascal or Algol 68.

[...]
>
How are C pointers not "closely bound to the type"?

>
  int i = 42;
  memcpy(&i, &(float){3.14}, sizeof i);
  printf("%d\n", i);
>
That looks like a pretty loose association between pointer and object
type to me.  This is not an accident or an unintended loophole.  It's by
design.
>
Certainly every pointer value in C has an associated type, but the
intention is that this association can be changed by pointer type
conversion as needed.
>
You often /have/ to make us of this.  For example, when calling qsort,
you will usually change the association between the pointer and the
pointed-to type (void) in order to do the comparison.  And C does not
even insist that you change it back to the original pointed-to type as
you can legally write a comparison function for, say, float data that
uses the representation as "raw" bytes.

 
OK.  The way I'd describe it is that C (non-void) pointers *are*
"closely bound to the type", but in addition C provides operations,
particularly pointer casts and implicit conversions to and from void*,
that can override that binding.
 
Janis mentioned pointer arithmetic.  I wouldn't say that overrides the
type binding; it merely provides a set of operations, that some other
languages lack, for constructing a pointer value from another pointer
value.  I don't know whether Janis meant that to be an example of not
being closely bound to the type, or as a distinct statement.

It's no "lacking operations". It's a deliberate design for safety.

Rutishauser spoke (for Algol 60) about "leaving the Can of Pandora
closed". And F. L. Bauer noted that "Pascal opened the Can of Pandora
but put a fly screen over it". (Pascal can here be seen as an example
of one language, other HLLs have done it basically the same way.)

The rest can probably be derived from inspecting how various HLL do
support that and how C does it. Basically,
- memory of appropriate size is allocated
- the reference is assigned to the variable
- access is done without address modification possible
You may consider that from a low level perspective a missing feature,
but I call it not unnecessarily opening a can of issues. - Examples...

Pascal:     var p : ^T;  new (p);  p^.x := ... ;

Algol 68:   REF T p = HEAP T;  x OF p := ... ;

Simula 67:  REF (T) p;  p :- new T;  p.x := ... ;


C:          T * p = (T *) malloc (sizeof(T));  (p+42) = ... ;

            Yes, you would not write that, but you can.
            And all sorts of casts makes it even worse.
            In the other languages mentioned you can't.

C++: with it's 'new' (and also 'malloc') is somewhat ambivalent.

(Disclaimers:
1. Code snippets may contain errors.
2. I don't know of newer C standards, just suppose that nothing
   substantial has changed in this respect to fix the inherent
   original C design criteria.)

Janis