On 12/04/2024 06:32, Janis Papanagnou wrote:
> On 12.04.2024 04:31, Lawrence D'Oliveiro wrote:
>> On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:
>>
>>> As someone who cut his teeth on
>>> Unix V6, an empty parameter list is less self-documenting than an
>>> explicit (void).
>>
>> Should that apply when calling the function as well?
>>
>> res = func(void);
>>
>> instead of
>>
>> res = func();

(What happens in Python when 'func' has multiple /optional/ parameters
which have all been omitted; do you need to document them in the call to
distinguish this from a call to a function which genuinely has no
arguments?)

>>
>> ?
>
> Ideally it would be (without syntactic ballast) just
>
> res = func;
>
> (as many programming languages have it designed), in
> function definition and function call; no parameters,
> no unnecessary parenthesis.

I used to allow 'func' to call a function with no args. Later I switched
to using func() as being more informative, since just:

func

doesn't impart very much. Maybe it's a function call; maybe it's a goto
to label 'func' (as I still allow); maybe it's a macro invocation; maybe
it's just evaluating a variable 'func' then discarding the value.

Using func() becomes more necessary with dynamic code; if P is a
reference to a function, then what does this mean:

Q := P

Is this copying the reference to Q, or calling P() and copying the
result? Using &P to disambiguate won't work here: that will create a
reference to the reference!

So F() is really doing CALL F; it's making it explicit.

On 12.04.2024 09:34, Lawrence D'Oliveiro wrote:
> On Fri, 12 Apr 2024 07:32:33 +0200, Janis Papanagnou wrote:
>
>> Ideally it would be (without syntactic ballast) just
>>
>> res = func;
>
> Then there is no way to express a reference to the function itself, as
> distinct from a call to it.
>
> Unless you do what Algol 68 did, and introduce the “deproceduring
> coercion”, analogous to “dereferencing” which allowed doing away with any
> explicit “address of x” and “the thingy whose address is in x” constructs.

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.

Languages syntactically derived from C or borrowed its syntax didn't.

It's, BTW, one of the reasons I like all these languages and not only
from a conceptual point of view, but by far not the only reason; the
way that programmers are not forced to consider low-level technical
stuff but can focus on the algorithm. Some things should be the task
of the compiler, not the programmer. A lot of inherent issues with C
stem from it's low-level design.

>
>> (Even Algol 68, where I've seen 'void' mentioned for the first time,
>> does not use 'void' for an empty function argument list definition
>> or function call.)
>
> I just rechecked the Revised Report (always got to do it before opening my
> mouth), and a “statement” is always “strong void”, which means any value
> it returns can always be thrown away without having to explicitly say so.

In Algol 68 everything is an expression. Statements are of type 'void'.
You have, to keep it most simple here, for example,

PROC f = INT : 3.1415

PROC p = VOID : SKIP

There's nothing "thrown away" (as in C). This is a completely different
view, and a different path that C has chosen to go, where everything is
a function (as they say).

> [ snip ]

Janis

In article <20240411204846.381@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-04-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:
>>
>>> As someone who cut his teeth on
>>> Unix V6, an empty parameter list is less self-documenting than an
>>> explicit (void).
>>
>> Should that apply when calling the function as well?
>
>Scott is getting burned by the current resident imbecile,
>how embarrassing.
>
>> res = func(void);
>>
>> instead of
>>
>> res = func();
>
>Well, according to the eccentric coding conventions followed by your
>team of one, indeed, yes; shouldn't it be:
>
> res = func(/* void */);
>
>No, wait:
>
> res = func(
> /* void = nothing */
> ); /* func( */

LOL. Despite punching down, that was very funny.

- Dan C.

On 12.04.2024 09:30, David Brown wrote:
>
> I prefer the consistency of function calls using parenthesis. The
> consistent alternative, found in some other languages, is that they
> never need parenthesis - "foo a b" calls "foo" with parameters "a" and "b".

Mind that this is just one "consistency" aspect.

Another one is that you can write (e.g. in Algol 68 or many other
higher level languages) the equivalent of - again a simple example -

int x = 2 * pi * r

without necessity to know whether pi is a constant, the result of a
function (calculation), the result of a function implicitly called
just once on demand, or whatever else. Conceptually as a programming
language user you want the value.

I don't say one or the other is "better", just that consistence is
not an absolute property. (But also that Algol 68, WRT a consistent
formal language design, is indeed very different from C in quality.)

>
> (Of course you'd need some syntax for referring to the function itself,
> or its address - "fp = &foo;" would not be too onerous, IMHO.)

All repliers to my post mentioned references or addresses; I think,
beyond personal preferences, it is a key observation that this is
unnecessary if the language (and its compiler) handles that per its
semantics. In Algol 68 you can define fp = foo but you don't need
an "address value" introduced.

Preferences are probably heavily influenced by the set of languages
one started with, so it's not useful to dispute here. But I think it's
noteworthy to anticipate that it's not a "legacy" thing with languages
that evolved around 1967 to 1972; Eiffel and other important languages
(I think also Ada) later also took that path. It's also noteworthy
that these languages focus on programming safety; and I suppose that
there's no dissent here about the programming safety in C as opposed
to the languages mentioned in the other reply I just gave.

Janis

On 12.04.2024 11:38, bart wrote:
>
> I used to allow 'func' to call a function with no args. Later I switched
> to using func() as being more informative, since just:
>
> func

I wasn't aware that C allows that. (Or are you talking about your own
language(s) here?)

>
> doesn't impart very much. Maybe it's a function call; maybe it's a goto
> to label 'func' (as I still allow); maybe it's a macro invocation; maybe
> it's just evaluating a variable 'func' then discarding the value.

You seem to be writing that [since] you "allow" a lot of non-standard
things thus needing some syntax to restrict that initial freedom again.

Anyway; I have no connection to your tools (if that's what you were
speaking about), so I abstain.

Janis

> [...]

On 12/04/2024 15:03, Janis Papanagnou wrote:
> On 12.04.2024 09:30, David Brown wrote:
>>
>> I prefer the consistency of function calls using parenthesis. The
>> consistent alternative, found in some other languages, is that they
>> never need parenthesis - "foo a b" calls "foo" with parameters "a" and "b".
>
> Mind that this is just one "consistency" aspect.

True.

>
> Another one is that you can write (e.g. in Algol 68 or many other
> higher level languages) the equivalent of - again a simple example -
>
> int x = 2 * pi * r
>
> without necessity to know whether pi is a constant, the result of a
> function (calculation), the result of a function implicitly called
> just once on demand, or whatever else. Conceptually as a programming
> language user you want the value.
>

But is that a good thing? For some programming, especially with
higher-level languages, then it is fine. For other types of
programming, you want to know if functions are called in order to have a
better idea of the flow of control and the efficiency of the code, plus
perhaps thread safety.

> I don't say one or the other is "better", just that consistence is
> not an absolute property.

Fair enough, and I agree that this is not a matter that has a single
correct answer. It is not uncommon that being consistent in one way
necessitates being inconsistent in another way.

Just for fun, this is a way to let you define a function-like object
"pi" in C++ that is called automatically, without parentheses :

#include <numbers>

template <auto f>
class Auto_executor {
public :
using T = decltype(f());
operator T () {
return f();
}
};

static Auto_executor<[](){ return std::numbers::pi; }> pi;

double circumferance(double r) {
return 2 * pi * r;
}

I am not giving an opinion as to whether or not this is a good idea (and
obviously it is completely redundant in the case of a compile-time
constant). Some people might think C++ is great because it lets you use
tricks like this, some people might think C++ is terrible because it
lets you use tricks like this :-)

On 12/04/2024 14:07, Janis Papanagnou wrote:
> On 12.04.2024 11:38, bart wrote:
>>
>> I used to allow 'func' to call a function with no args. Later I switched
>> to using func() as being more informative, since just:
>>
>> func
>
> I wasn't aware that C allows that. (Or are you talking about your own
> language(s) here?)

In my language I used to allow 'func' for a function call with no args
until I decided to require 'func()'.

>>
>> doesn't impart very much. Maybe it's a function call; maybe it's a goto
>> to label 'func' (as I still allow); maybe it's a macro invocation; maybe
>> it's just evaluating a variable 'func' then discarding the value.

On 12/04/2024 13:35, Janis Papanagnou wrote:
> On 12.04.2024 09:34, Lawrence D'Oliveiro wrote:
>> On Fri, 12 Apr 2024 07:32:33 +0200, Janis Papanagnou wrote:
>>
>>> Ideally it would be (without syntactic ballast) just
>>>
>>> res = func;
>>
>> Then there is no way to express a reference to the function itself, as
>> distinct from a call to it.
>>
>> Unless you do what Algol 68 did, and introduce the “deproceduring
>> coercion”, analogous to “dereferencing” which allowed doing away with any
>> explicit “address of x” and “the thingy whose address is in x” constructs.
>
> 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.
>
> Languages syntactically derived from C or borrowed its syntax didn't.

You don't say anything about C itself. C sometimes is explicit and
sometimes it isn't:

&F; // both take the address of a function F
F;

P(); // both call a function via a pointer P
(*P)();

So you can use an explicit & or * operator, not not.

On Fri, 12 Apr 2024 15:03:08 +0200, Janis Papanagnou wrote:

> Another one is that you can write (e.g. in Algol 68 or many other higher
> level languages) the equivalent of - again a simple example -
>
> int x = 2 * pi * r
>
> without necessity to know whether pi is a constant, the result of a
> function (calculation), the result of a function implicitly called just
> once on demand, or whatever else. Conceptually as a programming language
> user you want the value.

In Python you can’t do this with an unqualified name, but you can with a
qualified one, e.g.

x = 2 * math.pi * r

Which one of these might be true?

* “math” is a module, and “pi” is a variable defined within it
* “math” is a class, and “pi” is a variable defined within it
* “math” is an instance of a class, and “pi” is a variable defined either
within that instance or the class
* “math” is an instance of a class, and “pi” is a “property”, which is
computing a value, on demand, via an implicit method call

Note that the fourth possibility does an implicit method call without
argument parentheses.

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.

> Languages syntactically derived from C or borrowed its syntax didn't.

Is there anything higher level than λ-calculus? In that notation, you
always know whether you are referring to a function, or calling it.

Lisp makes function calls explicit in the same way. And no one would
accuse it of “deriving from C”, given that it originated about a decade
earlier.

> In Algol 68 everything is an expression. Statements are of type 'void'.
> You have, to keep it most simple here, for example,
>
> PROC f = INT : 3.1415
>
> PROC p = VOID : SKIP
>
> There's nothing "thrown away" (as in C).

Yes there is--it’s called “voiding”.

bart <bc@freeuk.com> writes:
> On 12/04/2024 06:32, Janis Papanagnou wrote:
>> On 12.04.2024 04:31, Lawrence D'Oliveiro wrote:
>>> On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:
>>>
>>>> As someone who cut his teeth on
>>>> Unix V6, an empty parameter list is less self-documenting than an
>>>> explicit (void).
>>>
>>> Should that apply when calling the function as well?
>>>
>>> res = func(void);
>>>
>>> instead of
>>>
>>> res = func();
>
> (What happens in Python when 'func' has multiple /optional/ parameters
> which have all been omitted; do you need to document them in the call
> to distinguish this from a call to a function which genuinely has no
> arguments?)

Nothing special. Python requires parentheses on all function calls.
res = func() assigns to res the value returned by the function func.
res = func assigns to res a value of type "function".

It's similar to what C does, except that in C there's no way res can be
assignment-compatible with both func and func().

In Ada, a procedure or function call with no arguments doesn't use
parentheses:

res := func;

Ada has no values of function type (which is why it can get away with
omitting parentheses for calls with no arguments), though it does have
are the equivalent of pointers to functions. (The lack of parentheses
on calls with no arguments is something that always annoyed me about
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 */

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

> [properties of some other languages]
>
> But we use C here, so we have to take what's given.

It would be nice if more participants in this newsgroup
would follow that precept.

On 12.04.2024 16:51, David Brown wrote:
> On 12/04/2024 15:03, Janis Papanagnou wrote:
>>
>> Another one is that you can write (e.g. in Algol 68 or many other
>> higher level languages) the equivalent of - again a simple example -
>>
>> int x = 2 * pi * r
>>
>> without necessity to know whether pi is a constant, the result of a
>> function (calculation), the result of a function implicitly called
>> just once on demand, or whatever else. Conceptually as a programming
>> language user you want the value.
>>
>
> But is that a good thing?

In my book it is a good thing (but I wouldn't overestimate it)...

> For some programming, especially with
> higher-level languages, then it is fine. For other types of
> programming, you want to know if functions are called in order to have a
> better idea of the flow of control and the efficiency of the code, plus
> perhaps thread safety.

....because the (in practice valid!) topics you mention _should_ not
be of concern to the programmer. The "idea of the flow" should, IMO,
certainly not depend on parenthesis. I'll try an example from a C++
context... - Say, I want to get the "length" of a container. What I
indeed care about is the complexity of that operation, but that
should be part of the library specification. C++/STL provides me
with O(1), O(N), O(x) information that I can count on. Though the
procedure to determine some length() might depend on the type of
the container; it may be just an attribute access, it might be a
difference computation (last-first+1), or it might be an iteration.
Despite that could be hidden in a function length() you need the
O(x) information to be sure about efficiency. (Or to look into the
function's source code of the function, if available, to analyze
the algorithm.)

What I'm basically trying to say is that length() doesn't provide
the certainty or information that one needs or likes to have. All
it provides is a syntactical, technical detail of the language.
With it you get the uncertainty of "Uh-oh, there's parentheses;
now does it mean that it's expensive to use it?" - But you don't
get relevant information from the parentheses!

For the [general, non-C] programmer it's (IMO) clearer to not put
(unnecessary) syntactical burden on him. He wants a value 'len'?
He just gets the value 'len' (and not len())!

I think I've already said that it's to a large degree probably
personal experience and preferences whether one comes to the
conclusion that it's a good thing, a bad thing, or even "mostly
harmless" (meaningless).

(These are the thoughts from someone who did not start his CS life
with C-like languages. From someone who has seen a lot of languages
with good concepts that needed decades to only slowly - if at all -
find their way into the modern, mainstream, or hyped languages. I
thought that evolution in programming languages would benefit from
good concepts. But "Not Invented Here" principle seems to dominate.
<end-of-rant>)

>
> Just for fun, this is a way to let you define a function-like object
> "pi" in C++ that is called automatically, without parentheses :
> [...]
> I am not giving an opinion as to whether or not this is a good idea (and
> obviously it is completely redundant in the case of a compile-time
> constant). Some people might think C++ is great because it lets you use
> tricks like this, some people might think C++ is terrible because it
> lets you use tricks like this :-)

(Nice example.) - Well, to me C++ is (or was) great because it
supported what I've learned to love from using Simula; classes
and inheritance, the whole OO paradigm, "living objects" and a
lot more that's still "undiscovered" by other languages. What I
found terrible was that it inherited the whole uncertainty from
using a low level language like C.

Janis

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.

On 13.04.2024 02:13, Lawrence D'Oliveiro 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.

Pascal has pointers bound to the object (as opposed to C pointers).
It's similar in Algol 68 were you model your complex linked object
structures with "references" on the heap. (WRT Ada, I'm not deeply
familiar with it, so cannot tell.)

> [...]
>
>> In Algol 68 everything is an expression. Statements are of type 'void'.
>> You have, to keep it most simple here, for example,
>>
>> PROC f = INT : 3.1415
>>
>> PROC p = VOID : SKIP
>>
>> There's nothing "thrown away" (as in C).
>
> Yes there is--it’s called “voiding”.

What do you mean - mind to elaborate with examples? (Then it will
be simpler for me to explain our probably different views.)

For the moment I just want to expand on the samples above (and
thereby fixing the INT/REAL typo)...

PROC f = REAL : 3.1415;
PROC p = VOID : SKIP;

PROC n = VOID : 2.71828;
PROC q = REAL : SKIP;

REAL x = f;
p;
REAL y = n;
q;
REAL z = q;

This is *not* functioning Algol 68 code! - But maybe you can explain
where or how there's something "thrown away".

I suppose you have something in mind like C's (void) f(); ?

Janis

On 13/04/2024 19:17, Janis Papanagnou wrote:
> On 12.04.2024 16:51, David Brown wrote:
>> On 12/04/2024 15:03, Janis Papanagnou wrote:
>>>
>>> Another one is that you can write (e.g. in Algol 68 or many other
>>> higher level languages) the equivalent of - again a simple example -
>>>
>>> int x = 2 * pi * r
>>>
>>> without necessity to know whether pi is a constant, the result of a
>>> function (calculation), the result of a function implicitly called
>>> just once on demand, or whatever else. Conceptually as a programming
>>> language user you want the value.
>>>
>>
>> But is that a good thing?
>
> In my book it is a good thing (but I wouldn't overestimate it)...
>
>> For some programming, especially with
>> higher-level languages, then it is fine. For other types of
>> programming, you want to know if functions are called in order to have a
>> better idea of the flow of control and the efficiency of the code, plus
>> perhaps thread safety.
>
> ...because the (in practice valid!) topics you mention _should_ not
> be of concern to the programmer. The "idea of the flow" should, IMO,
> certainly not depend on parenthesis. I'll try an example from a C++
> context... - Say, I want to get the "length" of a container. What I
> indeed care about is the complexity of that operation, but that
> should be part of the library specification. C++/STL provides me
> with O(1), O(N), O(x) information that I can count on. Though the
> procedure to determine some length() might depend on the type of
> the container; it may be just an attribute access, it might be a
> difference computation (last-first+1), or it might be an iteration.
> Despite that could be hidden in a function length() you need the
> O(x) information to be sure about efficiency. (Or to look into the
> function's source code of the function, if available, to analyze
> the algorithm.)
>

For most C++ programming, if you read code :

int len = xs.length;

you'll assume that is O(1). But if you read :

int len = xs.length();

you won't make that assumption. If you need to know the complexity,
you'll check exactly what type of container "xs" is, and look up the
complexity guarantees. (And while I showed a way to make calls in C++
without parentheses, I am not suggesting it's a good idea to invalidate
the assumptions readers will typically make about code.)

Again, this stuff is often not important, or at least not critical - but
sometimes it is.

> What I'm basically trying to say is that length() doesn't provide
> the certainty or information that one needs or likes to have. All
> it provides is a syntactical, technical detail of the language.
> With it you get the uncertainty of "Uh-oh, there's parentheses;
> now does it mean that it's expensive to use it?" - But you don't
> get relevant information from the parentheses!
>

Agreed. But it will often lead to assumptions.

However, those assumptions are based on the language. People who are
used to Pascal or Ada would have other assumptions (or lack of
assumptions) when reading Pascal or Ada.

> For the [general, non-C] programmer it's (IMO) clearer to not put
> (unnecessary) syntactical burden on him. He wants a value 'len'?
> He just gets the value 'len' (and not len())!
>
> I think I've already said that it's to a large degree probably
> personal experience and preferences whether one comes to the
> conclusion that it's a good thing, a bad thing, or even "mostly
> harmless" (meaningless).
>
> (These are the thoughts from someone who did not start his CS life
> with C-like languages. From someone who has seen a lot of languages
> with good concepts that needed decades to only slowly - if at all -
> find their way into the modern, mainstream, or hyped languages. I
> thought that evolution in programming languages would benefit from
> good concepts. But "Not Invented Here" principle seems to dominate.
> <end-of-rant>)

I started with BASIC (a half dozen varieties), then assembly and machine
code on multiple systems, brief flirtations with Logo, Forth, and even
Prolog and APL (/very/ briefly for these), then Pascal, then university
with Orwell (very similar to Haskell), Modula 2, C, Occam, then real
life with Pascal, assembly (many types), C, C++, Python, some hardware
design languages, and bits and pieces of a number of other languages for
fun or profit. It's nice to have a variety of experiences, even if the
great majority of work is in only a few of these languages.

>
>>
>> Just for fun, this is a way to let you define a function-like object
>> "pi" in C++ that is called automatically, without parentheses :
>> [...]
>> I am not giving an opinion as to whether or not this is a good idea (and
>> obviously it is completely redundant in the case of a compile-time
>> constant). Some people might think C++ is great because it lets you use
>> tricks like this, some people might think C++ is terrible because it
>> lets you use tricks like this :-)
>
> (Nice example.) - Well, to me C++ is (or was) great because it
> supported what I've learned to love from using Simula; classes
> and inheritance, the whole OO paradigm, "living objects" and a
> lot more that's still "undiscovered" by other languages. What I
> found terrible was that it inherited the whole uncertainty from
> using a low level language like C.
>

A lot of C++'s poorer parts are due to compatibility with C.
Compatibility with C is of course useful in many ways too, but it has
always been a millstone around C++'s neck.

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.

--
Ben.

On Sat, 13 Apr 2024 19:37:37 +0200, Janis Papanagnou wrote:

> Pascal has pointers bound to the object (as opposed to C pointers).

Nothing fundamentally different. C pointers (at least as of ANSI C) are
just as typesafe as Pascal ones. Don’t understand what you mean about
“bound to the object”.

> But maybe you can explain where or how there's something "thrown away".

This is a valid Algol 68 program (just tested with a68g):

BEGIN PROC f = REAL : 3.1415; f END

It calls f, which returns a real, which is then cast to VOID -- i.e.
thrown away.

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.

On Sat, 13 Apr 2024 20:33:03 +0300, Michael S wrote:

> On Sat, 13 Apr 2024 00:13:36 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Pascal had explicit pointers, though. Algol 68 and Ada did not.
>>
> Of course, Ada has pointers.

That’s why I said “explicit”.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 13 Apr 2024 20:33:03 +0300, Michael S wrote:
>
>> On Sat, 13 Apr 2024 00:13:36 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> Pascal had explicit pointers, though. Algol 68 and Ada did not.
>>>
>> Of course, Ada has pointers.
>
> That’s why I said “explicit”.

How is "*" (C) more explicit than "access" (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 */

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

> On Sat, 13 Apr 2024 19:37:37 +0200, Janis Papanagnou wrote:
....
>> But maybe you can explain where or how there's something "thrown away".
>
> This is a valid Algol 68 program (just tested with a68g):
>
> BEGIN PROC f = REAL : 3.1415; f END
>
> It calls f, which returns a real, which is then cast to VOID -- i.e.
> thrown away.

You are just arguing about how you want to use an informal term: namely
to "throw away". In Algol 68, the mode (AKA type) "void" is,
conceptually, a collection of values like any other. The coercion
called voiding converts a value of some other type to the single value
of type void. You could describe this a "throwing away the value", or
you could agree with Janis and say that the serial-clause you wrote
yields the sole value of type void.

--
Ben.

On 14/04/2024 11:17, Ben Bacarisse wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 13 Apr 2024 19:37:37 +0200, Janis Papanagnou wrote:
> ...
>>> But maybe you can explain where or how there's something "thrown away".
>>
>> This is a valid Algol 68 program (just tested with a68g):
>>
>> BEGIN PROC f = REAL : 3.1415; f END
>>
>> It calls f, which returns a real, which is then cast to VOID -- i.e.
>> thrown away.
>
> You are just arguing about how you want to use an informal term: namely
> to "throw away". In Algol 68, the mode (AKA type) "void" is,
> conceptually, a collection of values like any other. The coercion
> called voiding converts a value of some other type to the single value
> of type void. You could describe this a "throwing away the value", or
> you could agree with Janis and say that the serial-clause you wrote
> yields the sole value of type void.

It looks to me as though it yields a type REAL, as would this:

BEGIN 1.23 END

If the context has no need for such a type, then it is discarded
(although my own language would report an error for constructs like this
that make no sense by themselves; most likely it is an actual mistake).

But in one like this:

REAL x := BEGIN 1.23 END

Then that REAL value would be utilised.

Maybe you mean that in the first case, that REAL value is coerced to
VOID, and that process is what causes it to be discarded. To me that
sounds unwieldy.

bart wrote:
>
> That's not an interesting use of a local function! You can move square()
> outside, and it would still work, putting aside any clashes with
> existing names called 'square'.
>
> The challenges of local functions are to do with accessing transient
> variables belonging to their enclosing function. Especially when a
> reference to the local function is called from outside the lexical scope
> of the enclosing function, with extra difficulties when the enclosing
> function is no longer active.
>

very good point

bart <bc@freeuk.com> writes:

> On 14/04/2024 11:17, Ben Bacarisse wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Sat, 13 Apr 2024 19:37:37 +0200, Janis Papanagnou wrote:
>> ...
>>>> But maybe you can explain where or how there's something "thrown away".
>>>
>>> This is a valid Algol 68 program (just tested with a68g):
>>>
>>> BEGIN PROC f = REAL : 3.1415; f END
>>>
>>> It calls f, which returns a real, which is then cast to VOID -- i.e.
>>> thrown away.
>> You are just arguing about how you want to use an informal term: namely
>> to "throw away". In Algol 68, the mode (AKA type) "void" is,
>> conceptually, a collection of values like any other. The coercion
>> called voiding converts a value of some other type to the single value
>> of type void. You could describe this a "throwing away the value", or
>> you could agree with Janis and say that the serial-clause you wrote
>> yields the sole value of type void.
>
> It looks to me as though it yields a type REAL, as would this:
>
> BEGIN 1.23 END
>
> If the context has no need for such a type, then it is discarded (although
> my own language would report an error for constructs like this that make no
> sense by themselves; most likely it is an actual mistake).
>
> But in one like this:
>
> REAL x := BEGIN 1.23 END
>
> Then that REAL value would be utilised.

But what post posted was a whole program. The context -- it being the
top-level serial clause matters. I think. I say I think because I'd
like to find the wording that makes this so. a68g says it, but a68g is
an implementation and not the final word.

--
Ben.