From Newsgroup: comp.lang.misc

I wanted - depending on a global parameter 'n' - to define
an operator (or a procedure) _conditionally_ in Algol 68.[*]

I'm currently using

OP NEXT = (INT pos) INT :
( ODD n | ((pos+1) MOD 3) + 1 | (pos MOD 3) + 1 );

Since 'n' is a constant parameter throughout a dedicated scope
it would be interesting to have the conditional only evaluated
once with a _conditional definition_. - Is that possible here?

With procedures I may do

PROC cw = (INT pos) INT : (pos MOD 3) + 1;
PROC ccw = (INT pos) INT : ((pos+1) MOD 3) + 1;
PROC (INT) INT next := ( ODD n | ccw | cw );

where the assignment would evaluate the conditional (once) but
every call of 'next' would just call the assigned function.

But with operators that seems not possible...?

OP CW = (INT pos) INT : (pos MOD 3) + 1;
OP CCW = (INT pos) INT : ((pos+1) MOD 3) + 1;
OP (INT) INT CONT := ( ODD n | CCW | CW );

So I'll either have to use the 'OP NEXT' approach above or use
procedures to avoid the repeated evaluation of the conditional?

Janis

[*] Similar to what's possible in Unix shell by, e.g.,

if cond
then f() { code1; }
else f() { code2; }
fi

f # use of respective function with code1 or code2
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 13/09/2025 19:07, Janis Papanagnou wrote:
[...]

With procedures I may do
PROC cw = (INT pos) INT : (pos MOD 3) + 1;
PROC ccw = (INT pos) INT : ((pos+1) MOD 3) + 1;
PROC (INT) INT next := ( ODD n | ccw | cw );
where the assignment would evaluate the conditional (once) but
every call of 'next' would just call the assigned function.
But with operators that seems not possible...?

Well, not in A68, nor currently in A68G. Good luck in
persuading Marcel that it's an important enough omission to be
added to some future version! ...

OP CW = (INT pos) INT : (pos MOD 3) + 1;
OP CCW = (INT pos) INT : ((pos+1) MOD 3) + 1;
OP (INT) INT CONT := ( ODD n | CCW | CW );

... You have two syntax errors. (a) There are no operator
variables, so "OP ... CONT := whatever" is illegal. You need
"OP ... CONT = whatever". (b) In "( foo | goo | hoo )", "goo" and
"hoo" are serial clauses. An expression is a perfectly good serial
clause, so "ccw" [eg] in your working version is fine, but "CCW" is
not an expression [nor, for example, is "-"]. Operators need their
operands! [There are some delicate mode (type) identification
problems in general, bearing in mind that operators commonly apply
to several or even many modes of operand, and I certainly wouldn't
blame the committee for not opening up new cans of worms.]
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Haydn
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 14.09.2025 14:02, Andy Walker wrote:

On 13/09/2025 19:07, Janis Papanagnou wrote:
[...]

With procedures I may do
PROC cw = (INT pos) INT : (pos MOD 3) + 1;
PROC ccw = (INT pos) INT : ((pos+1) MOD 3) + 1;
PROC (INT) INT next := ( ODD n | ccw | cw );
where the assignment would evaluate the conditional (once) but
every call of 'next' would just call the assigned function.
But with operators that seems not possible...?

Well, not in A68, nor currently in A68G.

Thanks for the confirmation.

Good luck in
persuading Marcel that it's an important enough omission to be
added to some future version! ...

Erm.. - do you consider it important? (And an omission in Algol 68?)

To be honest; I didn't intend to ask for something that wasn't even
part of the Algol 68 definition (if that's actually the case). I
was merely unsure whether it's another inherent difference between
OPs and PROCs; there are already a couple differences here.

OP CW = (INT pos) INT : (pos MOD 3) + 1;
OP CCW = (INT pos) INT : ((pos+1) MOD 3) + 1;
OP (INT) INT CONT := ( ODD n | CCW | CW );

... You have two syntax errors.

Yes, sure. - That's just one variant I tried of about a dozen other
constructs. I picked this for the post because it's "syntactically
identical" (sort of) to the PROC thing (which works).

(a) There are no operator
variables, so "OP ... CONT := whatever" is illegal. You need
"OP ... CONT = whatever". (b) In "( foo | goo | hoo )", "goo" and
"hoo" are serial clauses. An expression is a perfectly good serial
clause, so "ccw" [eg] in your working version is fine, but "CCW" is
not an expression [nor, for example, is "-"].

Well, on that level of explanation, 'ccw' is also incomplete without
its arguments; the point was that it's not used as a call but as a
sort of reference to the PROC. I've just tried to make use of such a
definition also with OPs.

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 14/09/2025 18:02, Janis Papanagnou wrote:
[I wrote:]

Good luck in
persuading Marcel that it's an important enough omission to be
added to some future version! ...

Erm.. - do you consider it important?

No.

(And an omission in Algol 68?)

Well, anything that's not included is an omission!

To be honest; I didn't intend to ask for something that wasn't even
part of the Algol 68 definition (if that's actually the case).

I don't expect users in general to be familiar with the RR,
which really is too difficult for light bedtime reading [though not
as hard as the literature makes it seem], but it's perhaps worth
putting in my regular plea for those interested at least to get, and
scan, the Watt-Peck-Sintzoff one-page syntax chart [easily available
via Google (Algol Bulletin 37, p68 or Sigplan Notices 9/7 p39)].

(a) There are no operator
variables, so "OP ... CONT := whatever" is illegal. You need
"OP ... CONT = whatever". (b) In "( foo | goo | hoo )", "goo" and
"hoo" are serial clauses. An expression is a perfectly good serial
clause, so "ccw" [eg] in your working version is fine, but "CCW" is
not an expression [nor, for example, is "-"].

Well, on that level of explanation, 'ccw' is also incomplete without
its arguments; the point was that it's not used as a call but as a
sort of reference to the PROC.

It's a complete "PROC"; it's not a complete procedure /call/.
You could, for example, assign "ccw" to a variable of the appropriate
type, pass it as a parameter to a procedure call, use it as one branch
of a conditional clause, or use it as an operand. The real point in
the present context is that the compiler knows, from its declaration,
what its mode [type] is, and therefore knows how to compile the clause
of which it is part. Whereas ...

I've just tried to make use of such a
definition also with OPs.

... operators in general have different priorities and may have multiple definitions [think "-" or "ABS" or "PLUSAB"], so are impossible
to parse absent the operands. It would probably be possible to parse
some instances, but writing out a reliable description of which cases
can be parsed at compile time and which would be ambiguous [and thereby illegal] is non-trivial [and perhaps undecidable?]. Think of your
program embedded inside a larger program that had its own definitions
and uses of the operator "CCW"; local identifiers simply "hide" any
outside definitions, local operators can't -- you'd be cross if you
declared a new version of "+" to add two matrices and it zapped the
addition of two integers.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Liszt
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 15.09.2025 15:56, Andy Walker wrote:

On 14/09/2025 18:02, Janis Papanagnou wrote:

[ PROCs ]

[...] The real point in
the present context is that the compiler knows, from its declaration,
what its mode [type] is, and therefore knows how to compile the clause
of which it is part. Whereas ...

I've just tried to make use of such a
definition also with OPs.

... operators in general have different priorities and may have
multiple definitions [think "-" or "ABS" or "PLUSAB"], so are impossible
to parse absent the operands.

Yes, there's differences, I know. Specifically OPs quasi getting part
of the language, possibly changing syntax trees (with change of the
OP PRIO), and so on (W-grammar as keyword). This is different, e.g.,
from languages like C++ (with immutable priorities and, unlike Algol,
no option to introduce completely new operators), but with overloading possible.

It would probably be possible to parse
some instances, but writing out a reliable description of which cases
can be parsed at compile time and which would be ambiguous [and thereby illegal] is non-trivial [and perhaps undecidable?]. [...]

Yes, the non-overloading of OPs is a (the?) hindrance here [Algol 68].
(Unlike C++ where differentiations _based on argument types_ are
possible for both, functions and operators - but based on a simpler
grammar approach.)

In short; while Algol 68 could have been defined to distinguish by
types of function and operator signatures that is actually (as it is)
not the case, and with given consequences. - That's okay. And it's
good to have got obvious by explicitly stating the reason.

Thanks.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 16.09.2025 10:09, Janis Papanagnou wrote:

On 15.09.2025 15:56, Andy Walker wrote:

It would probably be possible to parse
some instances, but writing out a reliable description of which cases
can be parsed at compile time and which would be ambiguous [and thereby
illegal] is non-trivial [and perhaps undecidable?]. [...]

Yes, the non-overloading of OPs is a (the?) hindrance here [Algol 68]. (Unlike C++ where differentiations _based on argument types_ are
possible for both, functions and operators - but based on a simpler
grammar approach.)

Please ignore the nonsense I wrote here. Algol allows overloading OPs.
As you say, the OP ambiguity might be the problem. Because you cannot
overload PROCs you don't have that issue there. (While in C++ you can
overload both, operators and functions.)

(Need some [more] coffee...)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2