On Sun, 14 Apr 2024 11:17:36 +0100, Ben Bacarisse wrote:

> In Algol 68, the mode (AKA type) "void" is,
> conceptually, a collection of values like any other.

It has only a single value, EMPTY. Therefore, the number of bits required
to store a VOID value is ... zero.

That’s what “throwing away” means.

On 4/14/2024 3:44 PM, Lawrence D'Oliveiro wrote:
> On Sun, 14 Apr 2024 11:17:36 +0100, Ben Bacarisse wrote:
>
>> In Algol 68, the mode (AKA type) "void" is,
>> conceptually, a collection of values like any other.
>
> It has only a single value, EMPTY. Therefore, the number of bits required
> to store a VOID value is ... zero.

How to denote EMPTY?

n0 := EMPTY
n1 := EMPTY
n2 := EMPTY

So, this takes zero bits to store? I must be missing something here. Sorry.

>
> That’s what “throwing away” means.

On 14.04.2024 02:29, Michael S wrote:
> On Sun, 14 Apr 2024 00:23:44 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Sat, 13 Apr 2024 00:13:36 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> On Fri, 12 Apr 2024 14:35:47 +0200, Janis Papanagnou wrote:
>>>>
>>>>> It seems that's one of the fundamental differences between
>>>>> (low-level) languages that want to provide such technical factors
>>>>> explicit to the user and between languages that want to provide a
>>>>> higher abstraction.
>>>>>
>>>>> Algol 60, Pascal, Simula 67 and Algol 60, Eiffel, etc. all took
>>>>> that approach.
>>>>
>>>> Pascal had explicit pointers, though. Algol 68 and Ada did not.
>>>
>>> Of course, Ada has pointers. The are called access types.
>>> https://en.wikibooks.org/wiki/Ada_Programming/Types/access
>>>
>>> I never learned Algol-68, but considering your reputation I'd want
>>> to see confirmation from more reliable source.
>>
>> I suppose it all depends on what constitutes a pointer, but Algol 68
>> has pointers to this extent:
>>
>> BEGIN
>> INT i := 42;
>> [3] INT a := (1, 2, 3);
>>
>> REF INT p := i; CO p is a "pointer" to i
>> CO REF INT(p) := 99; CO changes i via p
>> CO p := a[2]; CO p now points to the second element of array a
>> CO REF INT(p) := 99; CO change that element via p
>> CO
>>
>> print((i, a[1], a[2], a[3]))
>> END
>>
>> I'd call p a pointer.
>>
>
> Thank you.
> 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. WRT 'REF' you have to
understand that it's a sort of "technical" reference item that
is used to link structures as pointers do. And besides that you
also have allocators for stack or heap objects. You combine the
two to get what you have in other languages. Usually you don't
see the stack allocator because Algol 68 allows abbreviations
to write only brief declarations what we also know from other
programming languages. For example the following are the same

INT a := 42;

REF INT a = LOC INT := 42;

It says that a is an integer 'REF' ("lvalue"), identical to a
local (stack) item - where LOC is the generator -, and finally
the value assigned.

You can replace the 'LOC' by 'HEAP' if you want the heap generator
to allocate the memory. For example

HEAP INT a;

REF INT a = HEAP INT;

In Algol 68 (as in Pascal) these references are bound to the type
(in the above examples to 'INT').

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 14.04.2024 02:29, Michael S wrote:
>> On Sun, 14 Apr 2024 00:23:44 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> On Sat, 13 Apr 2024 00:13:36 -0000 (UTC)
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>>> On Fri, 12 Apr 2024 14:35:47 +0200, Janis Papanagnou wrote:
>>>>>
>>>>>> It seems that's one of the fundamental differences between
>>>>>> (low-level) languages that want to provide such technical factors
>>>>>> explicit to the user and between languages that want to provide a
>>>>>> higher abstraction.
>>>>>>
>>>>>> Algol 60, Pascal, Simula 67 and Algol 60, Eiffel, etc. all took
>>>>>> that approach.
>>>>>
>>>>> Pascal had explicit pointers, though. Algol 68 and Ada did not.
>>>>
>>>> Of course, Ada has pointers. The are called access types.
>>>> https://en.wikibooks.org/wiki/Ada_Programming/Types/access
>>>>
>>>> I never learned Algol-68, but considering your reputation I'd want
>>>> to see confirmation from more reliable source.
>>>
>>> I suppose it all depends on what constitutes a pointer, but Algol 68
>>> has pointers to this extent:
>>>
>>> BEGIN
>>> INT i := 42;
>>> [3] INT a := (1, 2, 3);
>>>
>>> REF INT p := i; CO p is a "pointer" to i
>>> CO REF INT(p) := 99; CO changes i via p
>>> CO p := a[2]; CO p now points to the second element of array a
>>> CO REF INT(p) := 99; CO change that element via p
>>> CO
>>>
>>> print((i, a[1], a[2], a[3]))
>>> END
>>>
>>> I'd call p a pointer.
>>>
>>
>> Thank you.
>> 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"?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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.

--
Ben.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sun, 14 Apr 2024 11:17:36 +0100, Ben Bacarisse wrote:
>
>> In Algol 68, the mode (AKA type) "void" is,
>> conceptually, a collection of values like any other.
>
> It has only a single value, EMPTY. Therefore, the number of bits required
> to store a VOID value is ... zero.
>
> That’s what “throwing away” means.

I did not have any trouble understanding what you meant by "throwing
away". I was simply pointing out that there is another way to look at
the voiding coercion that is entirely consistent with what Janis had
said.

--
Ben.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 4/14/2024 3:44 PM, Lawrence D'Oliveiro wrote:
>> On Sun, 14 Apr 2024 11:17:36 +0100, Ben Bacarisse wrote:
>>
>>> In Algol 68, the mode (AKA type) "void" is,
>>> conceptually, a collection of values like any other.
>> It has only a single value, EMPTY. Therefore, the number of bits required
>> to store a VOID value is ... zero.
>
> How to denote EMPTY?

Algol 68 has no denotation for the empty value.

--
Ben.

On 15.04.2024 05:35, Chris M. Thomasson wrote:
> On 4/14/2024 3:44 PM, Lawrence D'Oliveiro wrote:
>> On Sun, 14 Apr 2024 11:17:36 +0100, Ben Bacarisse wrote:
>>
>>> In Algol 68, the mode (AKA type) "void" is,
>>> conceptually, a collection of values like any other.
>>
>> It has only a single value, EMPTY. Therefore, the number of bits required
>> to store a VOID value is ... zero.
>
> How to denote EMPTY?
>
> n0 := EMPTY
> n1 := EMPTY
> n2 := EMPTY
>
> So, this takes zero bits to store? I must be missing something here. Sorry.

I suppose it's just the way how one looks onto it. If I program in
"C" I always seem to have some bits and bytes in mind, as opposed
to Algol 68 where I seem to be thinking more abstract (high-level).

I usually don't think about whether there's a -1, 0, 42, value used
to represent 'EMPTY' in memory. This may stem from the CS education
where I've learned not to assume a physical von Neumann architecture
with registers etc. to be a precondition for an implementation. Such
cases (while they likely are) need not be implemented using numbers
in a memory [in theory].

Other such values like 'EMPTY' are also known from other languages;
like the Algol 68 terms 'NIL' ('null', 'NULL', 'nil'), and 'SKIP'.

If any of these keywords will be internally represented by special
values (like 0 or -1) and special CPU commands (like 'NOP') is not
really important since you don't work with such low-level entities
(in cases there are such low-level entities in the first place).
If you use a 'NIL' you just test with 'ISNT NIL', for example.

Algol 68 and C are so different that mutual understanding might be
difficult depending on personal background, focus, and fantasy. :-)

Your question: "So, this takes zero bits to store?" - I can't tell.

We could look into the Algol 68 Genie compiler, but you wouldn't
get a general answer, just a very specific (useless) information.

Janis

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.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 15/04/2024 20: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.

Implicit in every C non-void object pointer, is that it points to an
element of an array, so that you access neighbouring elements via P+1,
P-2, ++P and so on.

That is the case whether or not P actually points within such a sequence.

That assumption appears to be missing from those other languages.

C itself doesn't seem that bothered; it just treats any isolated object
that a pointer refers to, as though it was part of an imaginary
1-element array.

Then any attempt to refer beyond it via pointer arithmetic, is a mere
bounds error. But it's a bit more serious than that. It's like treating
*NULL as a bounds error, because it might be a few MB away from the
nearest valid object.

(My own lower level language allows similar pointer arithmetic. But it
doesn't allow P[i] syntax; pointers and arrays are more distinct and
therefore safer.

With an older dynamic language, pointers had a length attribute
attached. So that (IIRC) single targets had a length of 1 so pointer
arithmetic was limited.)

bart <bc@freeuk.com> writes:

> On 15/04/2024 20: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.
>
> Implicit in every C non-void object pointer, is that it points to an
> element of an array, so that you access neighbouring elements via P+1, P-2,
> ++P and so on.
>
> That is the case whether or not P actually points within such a
> sequence.

No that is not implicit in every non-void object pointer. In fact, it
is explicitly stated in the language standard that you /can't/ access
/anything/ via the "neighbouring" pointers except when the original is a
pointer into an array and those neighbouring elements are also in the
same array.

> That assumption appears to be missing from those other languages.

It's missing in C too. Address arithmetic and access is permitted only
within an array.

> C itself doesn't seem that bothered; it just treats any isolated object
> that a pointer refers to, as though it was part of an imaginary 1-element
> array.

This is true, and it's not implicit -- it is explicitly stated in the
language standard.

--
Ben.

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

On 15.04.2024 22:39, Janis Papanagnou wrote:
>
> C: T * p = (T *) malloc (sizeof(T)); (p+42) = ... ;
>
> (Disclaimers:
> 1. Code snippets may contain errors.

One error I made...

*(p+42) = ... ;

or
p[42] = ... ;

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.

My use of the word "lack" wasn't meant as a value judgement.

Certainly C allows the association of a pointer with the type of the
object it points to be overridden. I'd still say (again) that C
non-void pointers are "closely bound to the type" -- closely, but not
irrevocably.

Many more type-strict languages permit similar overriding of that
association, perhaps with a more explicit syntax (see "unsafe" in Rust,
"Unchecked_Conversion" in Ada).

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Mon, 15 Apr 2024 17:50:45 +0100, Ben Bacarisse wrote:

> Algol 68 has no denotation for the empty value.

Section 8.1.5.1 of the Revised Report:

void denotation : empty symbol.

On Mon, 15 Apr 2024 20:36:58 +0200, Janis Papanagnou wrote:

> I usually don't think about whether there's a -1, 0, 42, value used to
> represent 'EMPTY' in memory. This may stem from the CS education where
> I've learned not to assume a physical von Neumann architecture with
> registers etc. ...

The concept of “bits” comes from information theory. It has nothing to do
with von Neumann or Paul Newman or Gary Oldman or anything else. If you
have zero information to convey, then the number of bits of information is
zero.

> Other such values like 'EMPTY' are also known from other languages; like
> the Algol 68 terms 'NIL' ('null', 'NULL', 'nil'), and 'SKIP'.

Those are all entirely different concepts in Algol 68.

On Mon, 15 Apr 2024 20:36:58 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
> Algol 68 and C are so different that mutual understanding might be
> difficult depending on personal background, focus, and fantasy. :-)
>

Interesting take.
I never learned Algol-68, but from pieces of info that I occasionally
got I was always thinking of it as rather similar to 'C'.
Both languages originated from common ancestor (Algol-60) and changed
it in similar directions, e.g. blurring the line between operators and
expression, making function pointers first class citizen, allowing
declaration of variables at block scope.
I think, in the past, when I remembered more about Algol-68, I had seen
more similarities.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Mon, 15 Apr 2024 17:50:45 +0100, Ben Bacarisse wrote:
>
>> Algol 68 has no denotation for the empty value.
>
> Section 8.1.5.1 of the Revised Report:
>
> void denotation : empty symbol.

Thanks. If I had ever known that, I had forgotten. It's almost never
used because values are coerced to void all the contexts where it might
be otherwise required. I'm pretty sure I've never written it.

--
Ben.

On Wed, 17 Apr 2024 18:09:06 +0100, Ben Bacarisse wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Mon, 15 Apr 2024 17:50:45 +0100, Ben Bacarisse wrote:
>>
>>> Algol 68 has no denotation for the empty value.
>>
>> Section 8.1.5.1 of the Revised Report:
>>
>> void denotation : empty symbol.
>
> Thanks. If I had ever known that, I had forgotten. It's almost never
> used because values are coerced to void all the contexts where it might
> be otherwise required. I'm pretty sure I've never written it.

I also did a quick test in a68g that “BEGIN EMPTY END” is a valid program
(at least compiles without errors). But the last time I posted such a
thing, someone claimed that a68g was not necessarily a fully conforming
Algol 68 implementation ...

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 15 Apr 2024 20:36:58 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> Algol 68 and C are so different that mutual understanding might be
>> difficult depending on personal background, focus, and fantasy. :-)
>
> Interesting take.
> I never learned Algol-68, but from pieces of info that I occasionally
> got I was always thinking of it as rather similar to 'C'.
> Both languages originated from common ancestor (Algol-60) and changed
> it in similar directions, e.g. blurring the line between operators and
> expression, making function pointers first class citizen, allowing
> declaration of variables at block scope.
> I think, in the past, when I remembered more about Algol-68, I had seen
> more similarities.

Algol 60 already had block scope declarations.

Algol 60 may not have had (pointer to) function/procedure variables,
but it did allow procedure identifiers as arguments to a procedure
call, and procedure variables are an obvious generalization.

Relative to Algol 60, C slightly expanded what forms are allowed in
expressions, but mainly as a way to simplify the language syntax:

* no separate cases for assignment / function call statements

* so for()'s are more general and don't need specializing

In contrast, in Algol 68 the notion of "expression" is expanded
to allow the possibility of arbitrary variable declarations and
loops (IIANM; certainly I am not an expert on Algol 68).

Furthermore there are some significant differences between C and
Algol 60:

* Algol allows nested functions (aka procedures), but C doesn't

* Algol has call by name, C is strictly call by value

* Arrays are first class types in Algol, but not in C (and C
has pointer arithmetic as an essential part of the language,
which TTBOMK is not the case in any Algol-derived language)

* Algol is "strict" whereas C is "lax" - for example, in Algol
the controlling expression of an 'if' statement must be a
'Boolean expression', whereas in C it's just any expression

To me, Algol 68 represents an expansion and extension of the
Algol 60 language philosophy, whereas C represents a deliberate
departure from that philosophy; not necessarily a radical
departure, but a departure nonetheless. Certainly C has some
similarities to Algol 68, but I wouldn't say C and Algol 68
are similar languages, only that they have a few similarities.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Michael S <already5chosen@yahoo.com> writes:
>
>> On Mon, 15 Apr 2024 20:36:58 +0200
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> Algol 68 and C are so different that mutual understanding might be
>>> difficult depending on personal background, focus, and fantasy. :-)
>>
>> Interesting take.
>> I never learned Algol-68, but from pieces of info that I occasionally
>> got I was always thinking of it as rather similar to 'C'.
>> Both languages originated from common ancestor (Algol-60) and changed
>> it in similar directions, e.g. blurring the line between operators and
>> expression, making function pointers first class citizen, allowing
>> declaration of variables at block scope.
>> I think, in the past, when I remembered more about Algol-68, I had seen
>> more similarities.
>
>Algol 60 already had block scope declarations.
>
>Algol 60 may not have had (pointer to) function/procedure variables,
>but it did allow procedure identifiers as arguments to a procedure
>call, and procedure variables are an obvious generalization.

Call-by-name.

On 19/04/2024 16:26, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> On Mon, 15 Apr 2024 20:36:58 +0200
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> Algol 68 and C are so different that mutual understanding might be
>>> difficult depending on personal background, focus, and fantasy. :-)
>>
>> Interesting take.
>> I never learned Algol-68, but from pieces of info that I occasionally
>> got I was always thinking of it as rather similar to 'C'.
>> Both languages originated from common ancestor (Algol-60) and changed
>> it in similar directions, e.g. blurring the line between operators and
>> expression, making function pointers first class citizen, allowing
>> declaration of variables at block scope.
>> I think, in the past, when I remembered more about Algol-68, I had seen
>> more similarities.
>
> Algol 60 already had block scope declarations.
>
> Algol 60 may not have had (pointer to) function/procedure variables,
> but it did allow procedure identifiers as arguments to a procedure
> call, and procedure variables are an obvious generalization.
>
> Relative to Algol 60, C slightly expanded what forms are allowed in
> expressions, but mainly as a way to simplify the language syntax:
>
> * no separate cases for assignment / function call statements
>
> * so for()'s are more general and don't need specializing
>
> In contrast, in Algol 68 the notion of "expression" is expanded
> to allow the possibility of arbitrary variable declarations and
> loops (IIANM; certainly I am not an expert on Algol 68).
>
> Furthermore there are some significant differences between C and
> Algol 60:
>
> * Algol allows nested functions (aka procedures), but C doesn't
>
> * Algol has call by name, C is strictly call by value
>
> * Arrays are first class types in Algol, but not in C (and C
> has pointer arithmetic as an essential part of the language,
> which TTBOMK is not the case in any Algol-derived language)
>
> * Algol is "strict" whereas C is "lax" - for example, in Algol
> the controlling expression of an 'if' statement must be a
> 'Boolean expression', whereas in C it's just any expression
>
> To me, Algol 68 represents an expansion and extension of the
> Algol 60 language philosophy, whereas C represents a deliberate
> departure from that philosophy; not necessarily a radical
> departure, but a departure nonetheless. Certainly C has some
> similarities to Algol 68, but I wouldn't say C and Algol 68
> are similar languages, only that they have a few similarities.

I can't see any connection between Algol68 and C; I'm surprised at
people who say they do.

C was put together together as a systems language to do a job, not to
implemement some esoteric concept of a language that few could understand.

I understood it was based on languages like B and BCPL.

Actually there is a closer connection between my systems language,
created 10 years after C, which was also created for purely practical
purposes, and Algol68, largely because I borrowed much of its syntax
(including the interchangeability of statements and expressions).

But I would be first to admit that the similarity stops there.

scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 15 Apr 2024 20:36:58 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>
>>>> Algol 68 and C are so different that mutual understanding might be
>>>> difficult depending on personal background, focus, and fantasy. :-)
>>>
>>> Interesting take.
>>> I never learned Algol-68, but from pieces of info that I occasionally
>>> got I was always thinking of it as rather similar to 'C'.
>>> Both languages originated from common ancestor (Algol-60) and changed
>>> it in similar directions, e.g. blurring the line between operators and
>>> expression, making function pointers first class citizen, allowing
>>> declaration of variables at block scope.
>>> I think, in the past, when I remembered more about Algol-68, I had seen
>>> more similarities.
>>
>>Algol 60 already had block scope declarations.
>>
>>Algol 60 may not have had (pointer to) function/procedure variables,
>>but it did allow procedure identifiers as arguments to a procedure
>>call, and procedure variables are an obvious generalization.
>
> Call-by-name.

Yes, the article you replied to already mentioned call by name, in text
that you snipped.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> * Algol is "strict" whereas C is "lax" - for example, in Algol
> the controlling expression of an 'if' statement must be a
> 'Boolean expression', whereas in C it's just any expression

Small quibble: the controlling expression in C must be of scalar type.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

bart <bc@freeuk.com> writes:

> On 19/04/2024 16:26, Tim Rentsch wrote:
....
>> ... Certainly C has some
>> similarities to Algol 68, but I wouldn't say C and Algol 68
>> are similar languages, only that they have a few similarities.
>
> I can't see any connection between Algol68 and C; I'm surprised at people
> who say they do.

"Connection" is vague, but Dennis Ritchie has written about the
influence of Algol 68 on C.

> C was put together together as a systems language to do a job, not to
> implemement some esoteric concept of a language that few could understand.
>
> I understood it was based on languages like B and BCPL.

BCPL had assignment statements but B followed Algol 68 and made
assignment an expression operator (along with the +=, -= etc versions).
This, of course, fed directly into C.

DMR also cites Algol 68's type composition as an influence on C's type
semantics, and casts come straight from Algol 68.

--
Ben.