From Newsgroup: comp.lang.misc


I started to create languages of my own in 1981. Then I thought it was
cool to use syntax elements and a few concepts from Algol68, even though
my language was much smaller and much simpler.

That is still the case, and I have been happy to acknowledge the influence.

However, that has now changed. My views of Algol68 have changed
significantly. I think now that while it introduced some fresh ideas,
the language itself is dreadful, it looks terrible, forces unnecessarily complex ideas upon you, and is overly pedantic in its syntax.

The recent discussions with its aficionados have been unpleasant. They
have a proprietorial attitude to the language, staunchly defend ALL of
it complexity, and insult anyone who questions the need to grapple with
that complexity, such as calling them morons.

So, I have decided cut any ties with that language.

Mine is anyway already vastly different, and still simpler and easier
while having dozens of more practical features.

FI OD and CASE

I've always used these (usually in lower case - I don't have that
stropping nonsense), but I also allow END, END IF and so on.

I will remove from examples in docs. I will try and avoid using them in
new code, or code fragments I post.

Internally, they are already tokens that are aliases for END IF, END DO
and END CASE, and will stay for the time being to support existing code.

(||) Short-forms

I support (a|b|c) 2-way selection, and (n|a,b,c...|z) N-way selection.
Those will stay, as I don't have an alternate syntax right now.

I have never supported the more complex forms with ":" and so on.

EXPRESSION-BASED LANGUAGE, and VOID

These will say. EXPRESSION-BASED is not exclusive to Algol-68, and VOID
comes up in other languages.

TYPE SYNTAX

I will basically keep REF, but will be on the lookout for an
alternative, as that seems too heavy. ^ from Pascal possibly.

Otherwise LTR type syntax is also not the exclusivity of Algol-68.

My bounds syntax is already different, while terms like 'real' is from
other languages.

MODE and UNIT

These terms (for 'type', and 'expression/statement') tend to be used
only inside my compilers. Since no one will see them, they can stay.

EQUALITY (=) and ASSIGNMENT (:=)

These were used in Algol60 and in Pascal (languages I'd actually coded
in) so are fine.

Augmented assignments are common in other languages.

FOR/TO LOOPS

These were already different: I write 'for i:=a to/downto b do', which
is also Pascal, and now also use 'in'.

My TO-loop is an independent feature, not a cut-down FOR-loop, as is my
WHILE.

PROC

I use 'proc' and 'function' (now also 'func'). In my language, a 'proc' doesn't return a value. It was taken from Pascal's PROCEDURE.

BEGIN-END and (...)

I've never used begin-end, but (...) to enclose expression terms, or a
list of expressions, or any statements in general, can stay. I can say
those come from Lisp.

GOTO (or lack of it).

I still allow 'goto' to be dropped from 'goto L' (but not from more
elaborate case). I will think about this.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2025-11-08 16:16:04 +0000, bart said:

I started to create languages of my own in 1981. Then I thought it was
cool to use syntax elements and a few concepts from Algol68, even
though my language was much smaller and much simpler.

That is still the case, and I have been happy to acknowledge the influence.

However, that has now changed. My views of Algol68 have changed significantly. I think now that while it introduced some fresh ideas,
the language itself is dreadful, it looks terrible, forces
unnecessarily complex ideas upon you, and is overly pedantic in its
syntax.

I think the complexity of the language matters less than the comlexity of
the definition of the language.

The recent discussions with its aficionados have been unpleasant. They
have a proprietorial attitude to the language, staunchly defend ALL of
it complexity, and insult anyone who questions the need to grapple with
that complexity, such as calling them morons.

So, I have decided cut any ties with that language.

Mine is anyway already vastly different, and still simpler and easier
while having dozens of more practical features.

FI OD and CASE

I've always used these (usually in lower case - I don't have that
stropping nonsense), but I also allow END, END IF and so on.

I think no synonymes is better. And END IF, END LOOP, &c. is better.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 11:30, Mikko wrote:

On 2025-11-08 16:16:04 +0000, bart said:

I started to create languages of my own in 1981. Then I thought it was
cool to use syntax elements and a few concepts from Algol68, even
though my language was much smaller and much simpler.

That is still the case, and I have been happy to acknowledge the
influence.

However, that has now changed. My views of Algol68 have changed
significantly. I think now that while it introduced some fresh ideas,
the language itself is dreadful, it looks terrible, forces
unnecessarily complex ideas upon you, and is overly pedantic in its
syntax.

I think the complexity of the language matters less than the comlexity of
the definition of the language.

The recent discussions with its aficionados have been unpleasant. They
have a proprietorial attitude to the language, staunchly defend ALL of
it complexity, and insult anyone who questions the need to grapple
with that complexity, such as calling them morons.

So, I have decided cut any ties with that language.

Mine is anyway already vastly different, and still simpler and easier
while having dozens of more practical features.

FI OD and CASE

I've always used these (usually in lower case - I don't have that
stropping nonsense), but I also allow END, END IF and so on.

I think no synonymes is better. And END IF, END LOOP, &c. is better.

I would say it is a matter of taste whether you use "if .. fi", "if ...
end", "if ... end if", "if ... begin ... end", "if ... { ... }", or
something else entirely. But I think it is best to be consistent.
Synonyms or alternatives here are a bad idea - they lead to inconsistent source code that is harder to other people to read and maintain.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2025-11-09 12:22, David Brown wrote:

I would say it is a matter of taste whether you use "if .. fi", "if ... end", "if ... end if", "if ... begin ... end", "if ... { ... }", or something else entirely.

... a matter of good and bad taste... (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 11:22, David Brown wrote:

On 09/11/2025 11:30, Mikko wrote:

On 2025-11-08 16:16:04 +0000, bart said:

I started to create languages of my own in 1981. Then I thought it
was cool to use syntax elements and a few concepts from Algol68, even
though my language was much smaller and much simpler.

That is still the case, and I have been happy to acknowledge the
influence.

However, that has now changed. My views of Algol68 have changed
significantly. I think now that while it introduced some fresh ideas,
the language itself is dreadful, it looks terrible, forces
unnecessarily complex ideas upon you, and is overly pedantic in its
syntax.

I think the complexity of the language matters less than the comlexity of
the definition of the language.

The recent discussions with its aficionados have been unpleasant.
They have a proprietorial attitude to the language, staunchly defend
ALL of it complexity, and insult anyone who questions the need to
grapple with that complexity, such as calling them morons.

So, I have decided cut any ties with that language.

Mine is anyway already vastly different, and still simpler and easier
while having dozens of more practical features.

FI OD and CASE

I've always used these (usually in lower case - I don't have that
stropping nonsense), but I also allow END, END IF and so on.

I think no synonymes is better. And END IF, END LOOP, &c. is better.

I would say it is a matter of taste whether you use "if .. fi", "if ... end", "if ... end if", "if ... begin ... end", "if ... { ... }", or something else entirely.  But I think it is best to be consistent.
Synonyms or alternatives here are a bad idea - they lead to inconsistent source code that is harder to other people to read and maintain.

Is this about what's enforced by the language, or guidelines?

If a language always requires exactly 'end if' for example, that is
going to be major annoyance for a lot of people.

However one the worst examples of too much choice must be
optional-brace-style as popularised by C (although this can also happen
with BEGIN-END). First it allows these combinations:

if () else ;
if () {} else;
if () else {}
if () {} else {}

(I won't comment on the semicolons.)

But then, so many tokens can lead to an explosion of placement styles.

At least with END-delimited syntax, it easy to see that all you need is:

if then else end

That is, the first block is already delimited by then-else, you only
need to delimit the last. Doing this with braces doesn't really work:

if () else }

Than unmatched } looks weird. And you still need some delimiter between condition and the first block, either ) or {.

So I think END style is generally better than braces, and better than indent-based, which has its own set of problems.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 15:09, bart wrote:

On 09/11/2025 11:22, David Brown wrote:

On 09/11/2025 11:30, Mikko wrote:

On 2025-11-08 16:16:04 +0000, bart said:

I started to create languages of my own in 1981. Then I thought it
was cool to use syntax elements and a few concepts from Algol68,
even though my language was much smaller and much simpler.

That is still the case, and I have been happy to acknowledge the
influence.

However, that has now changed. My views of Algol68 have changed
significantly. I think now that while it introduced some fresh
ideas, the language itself is dreadful, it looks terrible, forces
unnecessarily complex ideas upon you, and is overly pedantic in its
syntax.

I think the complexity of the language matters less than the
comlexity of
the definition of the language.

The recent discussions with its aficionados have been unpleasant.
They have a proprietorial attitude to the language, staunchly defend
ALL of it complexity, and insult anyone who questions the need to
grapple with that complexity, such as calling them morons.

So, I have decided cut any ties with that language.

Mine is anyway already vastly different, and still simpler and
easier while having dozens of more practical features.

FI OD and CASE

I've always used these (usually in lower case - I don't have that
stropping nonsense), but I also allow END, END IF and so on.

I think no synonymes is better. And END IF, END LOOP, &c. is better.

I would say it is a matter of taste whether you use "if .. fi",
"if ... end", "if ... end if", "if ... begin ... end", "if ...
{ ... }", or something else entirely.  But I think it is best to be
consistent. Synonyms or alternatives here are a bad idea - they lead
to inconsistent source code that is harder to other people to read and
maintain.

Is this about what's enforced by the language, or guidelines?

I'd rather see consistency enforced by the language, where practical.
Of course some things can only be guidelines. But the more flexible the language rules are, the more people will write code in completely
different ways. (I'm assuming a language that will be used by multiple independent people.)

If a language always requires exactly 'end if' for example, that is
going to be major annoyance for a lot of people.

I think that would be less of an annoyance than a language where some
people write "end if", others write "fi", and others write "end".

However one the worst examples of too much choice must be optional- brace-style as popularised by C (although this can also happen with BEGIN-END). First it allows these combinations:

  if () else ;
  if () {} else;
  if () else {}
  if () {} else {}

If you don't like C's syntax, don't use it for your language design. If
I were designing a language, I'd use braces like C - but they would not
be optional. (I'm not sure about requiring parentheses around the
conditional - probably not, but it would depend on other aspects of the language.)

However, C does not have multiple options for how to delimit the
enclosed code in a conditional (or loop). It has only one method - you
write "if (x) A" where "A" is a /single/ statement. One type of
"statement" is a "compound statement", consisting of a brace-delimited
list of declarations and statements (which of course can also be
compound statements or any other type of statement).

You might feel that C's syntax makes it a bit easy to make certain kinds
of mistakes in the code, especially in connection with "else" clauses.
Many people, including me, think that - which is why I said that if I
were making a language, I'd say "if (x) A" would require A to be a
compound statement, and why many C coding standards have similar rules.

However, C does not have the option of inconsistent block delimiters in
the manner you had suggested. C is not perfect (IMHO), but it is significantly less bad than allowing "end", "end if", and "fi".

(I won't comment on the semicolons.)

But then, so many tokens can lead to an explosion of placement styles.

At least with END-delimited syntax, it easy to see that all you need is:

  if then else end

That's no problem - it is a perfectly reasonable choice. The objection
was not to the use of "end", but to multiple synonyms for it.

That is, the first block is already delimited by then-else, you only
need to delimit the last. Doing this with braces doesn't really work:

  if () else }

Than unmatched } looks weird. And you still need some delimiter between condition and the first block, either ) or {.

So I think END style is generally better than braces, and better than indent-based, which has its own set of problems.

"end style" or braces is a matter of choice. I like braces, and find
them visually clearer and more suited to a clear and consistent
indentation style. What I would not support is allowing the user to
choose "end", "end if", or "fi" according to preference - the language
should use one and only one style.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 14:40, David Brown wrote:

On 09/11/2025 15:09, bart wrote:

So I think END style is generally better than braces, and better than
indent-based, which has its own set of problems.

"end style" or braces is a matter of choice.  I like braces, and find
them visually clearer and more suited to a clear and consistent
indentation style.  What I would not support is allowing the user to
choose "end", "end if", or "fi" according to preference - the language should use one and only one style.

There is another aspect to this.

My view is that matching bracket delimiters of any kind are best suited
to be used within the same line.

For delimiting content across multiple lines, as happens with braces, I
think they are poor. They are too insubstantial for a start.

For this reason, I sometimes provide compact alternatives, so there are
short forms and long forms, example:

record date1 = (int d, m, y)

record date2 =
int d
int m
int y
end

This doesn't stop anyone using a short form across multiple lines, or
long form on one line; I assume they'll be sensible.

This is a choice I provide. But you can remove the option, and still
find people imposing their own preferences. You'd need an ultra-strict
syntax to enforce layout.

Or there are always refactoring tools.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 16:17, bart wrote:

On 09/11/2025 14:40, David Brown wrote:

On 09/11/2025 15:09, bart wrote:

So I think END style is generally better than braces, and better than
indent-based, which has its own set of problems.

"end style" or braces is a matter of choice.  I like braces, and find
them visually clearer and more suited to a clear and consistent
indentation style.  What I would not support is allowing the user to
choose "end", "end if", or "fi" according to preference - the language
should use one and only one style.

There is another aspect to this.

My view is that matching bracket delimiters of any kind are best suited
to be used within the same line.

For delimiting content across multiple lines, as happens with braces, I think they are poor. They are too insubstantial for a start.

Okay - that's an opinion I do not share, but fair enough. (I think
you'd be happier with braces if you made better use of spaces, and
perhaps where you split lines, but that again is a matter of preference
and choice.)

For this reason, I sometimes provide compact alternatives, so there are short forms and long forms, example:

   record date1 = (int d, m, y)

   record date2 =
       int d
       int m
       int y
   end

This doesn't stop anyone using a short form across multiple lines, or
long form on one line; I assume they'll be sensible.

I think that is a bad idea. For one task, pick one good solution.
People can lay things out as they want, but the syntax should remain the
same.

This is a choice I provide. But you can remove the option, and still
find people imposing their own preferences. You'd need an ultra-strict syntax to enforce layout.

I don't think you'd need an "ultra-strict" syntax - you simply have to
have rules for lines and indentation. But I am not convinced that is a
good idea. (I am fairly convinced that white space alone should not
determine syntax.)

Or there are always refactoring tools.

Do you mean layout or reformatting tools? Refactoring is changing the
source code, such as renaming identifiers consistently, or pulling parts
of a function out to separate functions. If you think reformatting
tools are going to be heavily used in a language, then I think the
language design is questionable - and if the reformatting tools are
going to change something other than white space, the design has serious problems.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 16:42, David Brown wrote:

On 09/11/2025 16:17, bart wrote:

For this reason, I sometimes provide compact alternatives, so there
are short forms and long forms, example:

    record date1 = (int d, m, y)

    record date2 =
        int d
        int m
        int y
    end

This doesn't stop anyone using a short form across multiple lines, or
long form on one line; I assume they'll be sensible.

I think that is a bad idea.  For one task, pick one good solution.
People can lay things out as they want, but the syntax should remain the same.

This is an Ada Hello program:

with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
Put_Line ("Hello, World!");
end Hello;

Ada is about as respectable and serious a language as you can get. But
even here, that 'Hello' on the last line is optional.

For If statements, it appears to always need 'end if', but because the language is case-insensitive, you can also write 'End If' for example,
or write everything in all-caps, and it still works:

WITH ADA.TEXT_IO; USE ADA.TEXT_IO;
PROCEDURE HELLO IS
BEGIN
PUT_LINE ("Hello, World!");
END HELLO;

(I believe this has 60 letters, so there are a billion billion possible
case combinations that are all equivalent. It doesn't seem to be a
problem...)

(BTW when playing with on-line Ada, I was pleasantly surprised by how
many fewer inexplicable compiler errors I got compared with A68G. The
error messages were more down-to-earth too. It was like chalk and cheese.)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sun, 9 Nov 2025 12:30:10 +0200, Mikko wrote:

I think the complexity of the language matters less than the comlexity
of the definition of the language.

The two are equivalent.

Prove me wrong.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sun, 9 Nov 2025 15:17:54 +0000, bart wrote:

My view is that matching bracket delimiters of any kind are best
suited to be used within the same line.

How do you build complex data structures, then? Such structures are
very common in data-driven programming. E.g.

recognized_commands = \
{
# key is command name, value is dictionary with following fields:
# args -- nr required positional args, or tuple of min and max nr required positional args
# opts -- tuple of long option names. If a name ends in an equal sign, then it takes a value.
# multivalued -- optional tuple of option keywords which can occur multiple times
# required -- optional tuple of option keywords which must be present
# help_usage -- used to construct a usage string when giving help for the command.
# help_descr -- explanatory text shown when giving help for the command.
# action -- the function to invoke to actually perform the command.

"help" :
{
"args" : (0, 1),
"opts" : (),
"action" : cmd_help,
"help_usage" : "[cmd]",
"help_descr" : "gives help about the specified command",
},

"showinfo" :
{
"args" : 1,
"opts" : (),
"action" : cmd_showinfo,
"help_usage" : "«pdf file»",
"help_descr" : "shows metadata for the specified PDF file",
},

"getinfo" :
{
"args" : 2,
"opts" : ("default=",),
"action" : cmd_getinfo,
"help_usage" : "«pdf file» «keyword»",
"help_descr" :
"retrieves the specified metadata value from the Info"
" dictionary in the PDF file",
},

...

} # recognized_commands
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09/11/2025 23:35, Lawrence D’Oliveiro wrote:

On Sun, 9 Nov 2025 15:17:54 +0000, bart wrote:

My view is that matching bracket delimiters of any kind are best
suited to be used within the same line.

How do you build complex data structures, then? Such structures are
very common in data-driven programming. E.g.

Yes, delimiting sets of data of arbitrary length is a weak point. I've
managed to deal with a few patterns of use, but not all.

For example, I have a feature called 'tabledata' used to define parallel
sets of lists (and a related version where the first column is a set of enums). For your example, it might be something like this:

tabledata commands, args =
("help", [:]),
("showinfo", [:]),
("getinfo", [:]),
end

This defines a list of command strings, and corresponding dict data
('[:]' is an empty dict here). But this does away with the outermost set
of brackets that might span 100 lines.

A tweak to it might have only a single column, and made into a dict
rather than list.

But for this kind of application, I might base it on functions, so:

func cmd_help ...
func cmd_showinfo ...
func cmd_getargs ...

Then some built-in reflection is used to scan functions looking for a
handler for a specific command. Then it is taken from here.

Note that if such data is machine-generated and machine-processed, then
I don't have any objection to using brackets. I just think they are poor
for normal, human readable, line-oriented source code.

This stuff can also be done with configuration files, where you are free
to devise a format that doesn't rely on matching a "(" on line 1 with
")" on line 1315, with hundreds of intervening ( and ) along the way,
which may be unbalanced. (INI files for example.)


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Mon, 10 Nov 2025 00:56:05 +0000, bart wrote:

Note that if such data is machine-generated and machine-processed, then
I don't have any objection to using brackets.

That table example of mine was very much human-generated and human-
maintained.

We have discussed machine-generated data before; as I said then, I feel
such things, particularly long screeds of inscrutable-looking numbers,
have no place in human-maintained source code.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 01:02, Lawrence D’Oliveiro wrote:

On Mon, 10 Nov 2025 00:56:05 +0000, bart wrote:

Note that if such data is machine-generated and machine-processed, then
I don't have any objection to using brackets.

That table example of mine was very much human-generated and human- maintained.

We have discussed machine-generated data before; as I said then, I feel
such things, particularly long screeds of inscrutable-looking numbers,
have no place in human-maintained source code.

Well, I don't prohibit such uses of brackets, I just don't like them
used across multiple lines. I'm on the lookup for better, more robust
methods. But the ATM, they have to be used in many cases.

I also have a small problem with all those trailing commas.

Trailing semicolons on statements have been solved; could we do the same
with commas?

I did do some experiments, but it was too hard to be certain of being in
the right context (for newlines to map into commas rather than
semicolons), for a user to be confident of using the feature.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Mon, 10 Nov 2025 01:12:10 +0000, bart wrote:

I also have a small problem with all those trailing commas.

I don’t. I use them to indicate that there’s nothing special about the
last item in the list, you can add more after that if you want. This
is usually the case in high-level languages.

In C code, on the other hand, the last item in an array is often a
sentinel to indicate the end of the list, e.g.

static PyMethodDef discipline_methods[] =
{
{"makedict", discipline_makedict, METH_VARARGS,
"makedict(«tuple of pairs», «message»)\n\n"
"displays a message and makes a dictionary from a tuple"
" of (key, value) pairs. Raises a ValueError exception if"
" any key or value is ExceptMe."
},
{"factorize", discipline_factorize, METH_VARARGS,
"factorize(«n»)\n\n"
"returns a tuple of integer pairs («i», «r») representing the"
"prime factors of positive integer «n», where «i» is a prime"
" number and «r» is the number of times «i» occurs as a factor"
" of «n». Raises a ValueError exception if any «i» or «r» equals 5."
},
END_STRUCT_LIST
};

That lack of a comma means you shouldn’t be adding anything after that
last item.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 04:51, Lawrence D’Oliveiro wrote:

On Mon, 10 Nov 2025 01:12:10 +0000, bart wrote:

I also have a small problem with all those trailing commas.

I don’t. I use them to indicate that there’s nothing special about the last item in the list, you can add more after that if you want. This
is usually the case in high-level languages.

Trailing commas also make such tables and lists easier to maintain. You
can cut, copy and paste more easily, and adding new items only affects
the new lines - it does not mean changing existing lines. In a world of
git, svn, and other version control software, it is a significant
advantage if changes to code only affect the lines that have a
meaningful change.

In C code, on the other hand, the last item in an array is often a
sentinel to indicate the end of the list, e.g.

static PyMethodDef discipline_methods[] =
{
{"makedict", discipline_makedict, METH_VARARGS,
"makedict(«tuple of pairs», «message»)\n\n"
"displays a message and makes a dictionary from a tuple"
" of (key, value) pairs. Raises a ValueError exception if"
" any key or value is ExceptMe."
},
{"factorize", discipline_factorize, METH_VARARGS,
"factorize(«n»)\n\n"
"returns a tuple of integer pairs («i», «r») representing the"
"prime factors of positive integer «n», where «i» is a prime"
" number and «r» is the number of times «i» occurs as a factor"
" of «n». Raises a ValueError exception if any «i» or «r» equals 5."
},
END_STRUCT_LIST
};

That lack of a comma means you shouldn’t be adding anything after that
last item.

Fair enough.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 08:14, David Brown wrote:

On 10/11/2025 04:51, Lawrence D’Oliveiro wrote:

On Mon, 10 Nov 2025 01:12:10 +0000, bart wrote:

I also have a small problem with all those trailing commas.

I don’t. I use them to indicate that there’s nothing special about the >> last item in the list, you can add more after that if you want. This
is usually the case in high-level languages.

Trailing commas also make such tables and lists easier to maintain.  You can cut, copy and paste more easily, and adding new items only affects
the new lines - it does not mean changing existing lines.  In a world of git, svn, and other version control software, it is a significant
advantage if changes to code only affect the lines that have a
meaningful change.

Yeah, I made the same point about semicolons in the one of the A68
threads, and I was just insulted.

However, by trailing commas here, I meant the ones at the end of each
line when lists are laid out one item per line.

I was looking at ways to eliminate those, as semicolons are in many
languages, or at least made optional.

Tabulated data in printed material usually doesn't have such punctuation.

In C code, on the other hand, the last item in an array is often a
sentinel to indicate the end of the list, e.g.

     static PyMethodDef discipline_methods[] =
       {
         {"makedict", discipline_makedict, METH_VARARGS,
             "makedict(«tuple of pairs», «message»)\n\n"
             "displays a message and makes a dictionary from a tuple"
             " of (key, value) pairs. Raises a ValueError exception if"
             " any key or value is ExceptMe."
         },
         {"factorize", discipline_factorize, METH_VARARGS,
             "factorize(«n»)\n\n"
             "returns a tuple of integer pairs («i», «r») representing
the"
             "prime factors of positive integer «n», where «i» is a
prime"
             " number and «r» is the number of times «i» occurs as a
factor"
             " of «n». Raises a ValueError exception if any «i» or «r»
equals 5."
         },
         END_STRUCT_LIST
       };

That lack of a comma means you shouldn’t be adding anything after that
last item.

(Why not? Maybe you do want to add another option. Or you want to remove
or comment that last one. Same issue with semicolons. Make all lines
have the same rank.)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 12:00, bart wrote:

On 10/11/2025 08:14, David Brown wrote:

On 10/11/2025 04:51, Lawrence D’Oliveiro wrote:

On Mon, 10 Nov 2025 01:12:10 +0000, bart wrote:

I also have a small problem with all those trailing commas.

I don’t. I use them to indicate that there’s nothing special about the >>> last item in the list, you can add more after that if you want. This
is usually the case in high-level languages.

Trailing commas also make such tables and lists easier to maintain.
You can cut, copy and paste more easily, and adding new items only
affects the new lines - it does not mean changing existing lines.  In
a world of git, svn, and other version control software, it is a
significant advantage if changes to code only affect the lines that
have a meaningful change.

Yeah, I made the same point about semicolons in the one of the A68
threads, and I was just insulted.

I haven't followed all the posts there (since I don't know Algol), so I
can't comment on that.

However, by trailing commas here, I meant the ones at the end of each
line when lists are laid out one item per line.

That is what is meant by "trailing commas". What else might it mean?

enum colours = {
red,
green,
blue,
purple,
pale_fushia_with_a_hint_of_orange,
};

I was looking at ways to eliminate those, as semicolons are in many languages, or at least made optional.

How did we get back to semicolons here? You said they were "solved".
(I don't know what that means, since I don't know why you think they are
a problem in the first place, but that's for a different branch of the thread.) We are talking here about trailing commas in lists.

Tabulated data in printed material usually doesn't have such punctuation.

Tabulated data in printed material is for human consumption. It can be formatted in countless ways - often with significant spaces, perhaps
grid lines, and perhaps punctuation. That has no relevance in this context.

In C code, on the other hand, the last item in an array is often a
sentinel to indicate the end of the list, e.g.

     static PyMethodDef discipline_methods[] =
       {
         {"makedict", discipline_makedict, METH_VARARGS,
             "makedict(«tuple of pairs», «message»)\n\n" >>>              "displays a message and makes a dictionary from a tuple"
             " of (key, value) pairs. Raises a ValueError exception if"
             " any key or value is ExceptMe."
         },
         {"factorize", discipline_factorize, METH_VARARGS,
             "factorize(«n»)\n\n"
             "returns a tuple of integer pairs («i», «r») >>> representing the"
             "prime factors of positive integer «n», where «i» is a
prime"
             " number and «r» is the number of times «i» occurs as a
factor"
             " of «n». Raises a ValueError exception if any «i» or
«r» equals 5."
         },
         END_STRUCT_LIST
       };

That lack of a comma means you shouldn’t be adding anything after that >>> last item.

(Why not? Maybe you do want to add another option. Or you want to remove
or comment that last one. Same issue with semicolons. Make all lines
have the same rank.)

His point was that "END_STRUCT_LIST" is a sentinel - like the null
character at the end of a C-style string. It marks the end of the list,
so any added options must come /before/ END_STRUCT_LIST.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 13:13, David Brown wrote:

On 10/11/2025 12:00, bart wrote:

However, by trailing commas here, I meant the ones at the end of each
line when lists are laid out one item per line.

That is what is meant by "trailing commas".  What else might it mean?

enum colours = {
    red,
    green,
    blue,
    purple,
    pale_fushia_with_a_hint_of_orange,
};

There are 5 commas here on the ends of 5 lines, which is what I meant by trailing comma. This seemed as needless to me as having 5 semicolons
closing 5 lines, if you are delimiting each item by a newline anyway.

By a 'trailing comma' can also be taken to mean the one on that 5th
line, since the others are needed as separators. Some languages will
allow that last comma to simplify maintenance, in cases where there can
be an arbitrary number of items.

I was looking at ways to eliminate those, as semicolons are in many
languages, or at least made optional.

How did we get back to semicolons here?  You said they were "solved". (I don't know what that means, since I don't know why you think they are a problem in the first place, but that's for a different branch of the thread.)  We are talking here about trailing commas in lists.

Tabulated data in printed material usually doesn't have such punctuation.

Tabulated data in printed material is for human consumption.

I'm also talking about source code for human consumption. Since printing
has a long history of presenting such content, it might be worth
taking some inspiration from it.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 17:20, bart wrote:

On 10/11/2025 13:13, David Brown wrote:

On 10/11/2025 12:00, bart wrote:

However, by trailing commas here, I meant the ones at the end of each
line when lists are laid out one item per line.

That is what is meant by "trailing commas".  What else might it mean?

enum colours = {
     red,
     green,
     blue,
     purple,
     pale_fushia_with_a_hint_of_orange,
};

There are 5 commas here on the ends of 5 lines, which is what I meant by trailing comma.

Yes, that is intentional. I explained why I think that is a good thing, expanding on Lawrence's comments. Some people don't like to have
trailing commas, but enough people like them that they have been
explicitly added to languages that did not have them.

This seemed as needless to me as having 5 semicolons
closing 5 lines, if you are delimiting each item by a newline anyway.

In most languages, newlines are not syntactically different from other
white space. Some languages /do/ support newline as statement
terminators - it's a choice that can be made.

By a 'trailing comma' can also be taken to mean the one on that 5th
line, since the others are needed as separators.

Yes, that is what a "trailing comma" is in this discussion. No one has
been questioning commas between items in lists - the "trailing comma" is
a comma that comes at the end, after the last item.

Some languages will
allow that last comma to simplify maintenance, in cases where there can
be an arbitrary number of items.

Exactly.

I am very confused as to what you think "trailing comma" could possibly
mean, other than the fifth comma in the example I gave. I can
appreciate that you might not like having it there, while there is no
doubt that some people /do/ like the support. That's a matter of taste
and opinion.

I was looking at ways to eliminate those, as semicolons are in many
languages, or at least made optional.

How did we get back to semicolons here?  You said they were "solved".
(I don't know what that means, since I don't know why you think they
are a problem in the first place, but that's for a different branch of
the thread.)  We are talking here about trailing commas in lists.

Tabulated data in printed material usually doesn't have such
punctuation.

Tabulated data in printed material is for human consumption.

I'm also talking about source code for human consumption. Since printing
 has a long history of presenting such content, it might be worth
taking some inspiration from it.

"Taking inspiration" is different from "blind copying". I appreciate
that source code must be read by humans, but it also needs to be read by computers, and it needs to be edited by humans in many different ways.
Source code is a living thing, unlike a printed page.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 16:33, David Brown wrote:

On 10/11/2025 17:20, bart wrote:

Yes, that is what a "trailing comma" is in this discussion.  No one has been questioning commas between items in lists - the "trailing comma" is
a comma that comes at the end, after the last item.

Some languages will allow that last comma to simplify maintenance, in
cases where there can be an arbitrary number of items.

Exactly.

I am very confused as to what you think "trailing comma" could possibly mean, other than the fifth comma in the example I gave.  I can
appreciate that you might not like having it there, while there is no
doubt that some people /do/ like the support.  That's a matter of taste
and opinion.

My comments were about eliminating commas on all the lines, where the
comma is the last thing. For examples like this:

58, 189, 22
101, 199, 32

it'll be about the last comma on the line (the trailing one).

(A CDF data file will look like this; no comma at end-of-line, but those
will usually be one record per line too.)


So my preference is:

A
B
...
Z

But as that's not yet possible, I allow this:

A,
B,
...
Z,

This simplifies things as you and others have pointed out. But some
languages will require:

A,
B,
...
Z

A complication is that comma-separated items can occur in other contexts
where a trailing comma after the last item is not a good idea, even if
written one item per line:

F(w, x, y,)

This is ambiguous (is there an omitted 4th argument?). A short argument
list will not often have the list augmented or reduced.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/11/2025 22:01, bart wrote:

On 10/11/2025 16:33, David Brown wrote:

On 10/11/2025 17:20, bart wrote:

Yes, that is what a "trailing comma" is in this discussion.  No one
has been questioning commas between items in lists - the "trailing
comma" is a comma that comes at the end, after the last item.

Some languages will allow that last comma to simplify maintenance, in
cases where there can be an arbitrary number of items.

Exactly.

I am very confused as to what you think "trailing comma" could
possibly mean, other than the fifth comma in the example I gave.  I
can appreciate that you might not like having it there, while there is
no doubt that some people /do/ like the support.  That's a matter of
taste and opinion.

My comments were about eliminating commas on all the lines, where the
comma is the last thing. For examples like this:

   58, 189, 22
  101, 199, 32

it'll be about the last comma on the line (the trailing one).

Okay - that clears up what you mean.

I can't say I am at all keen on making newlines so "active" in this way
- sometimes they are just whitespace, sometimes they act like commas, sometimes like semicolons. But at least I now know what you are talking about!

(A CDF data file will look like this; no comma at end-of-line, but those will usually be one record per line too.)

So my preference is:

  A
  B
  ...
  Z

But as that's not yet possible, I allow this:

  A,
  B,
  ...
  Z,

This simplifies things as you and others have pointed out. But some languages will require:

  A,
  B,
  ...
  Z

Some languages are happy with just white space as separators. I am okay
with that too, but I am sceptical about overloading the meaning of new
lines. So if you think it's fine to have :

A
B
C

then it should also be fine to have

A B
C

A trailing comma at the end of the last item feels grammatically
incorrect to me, but I like it to be allowed because it gives advantages
in maintenance.

A complication is that comma-separated items can occur in other contexts where a trailing comma after the last item is not a good idea, even if written one item per line:

  F(w, x, y,)

This is ambiguous (is there an omitted 4th argument?). A short argument
list will not often have the list augmented or reduced.

This is a little different in that for function parameters, you
generally have a fixed number of parameters, and they are often
different types. It is more akin to a tuple or a struct than an array.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10.11.2025 14:13, David Brown wrote:

On 10/11/2025 12:00, bart wrote:

On 10/11/2025 08:14, David Brown wrote:

[ Trailing commas ]

I haven't followed all the posts there (since I don't know Algol), so I
can't comment on that.

Disclaimer: I also haven't followed all the posts, specifically skipped
the posts were just pointless repetitions took place; at some point it
makes no sense to answer (or even read in the first place) those types
of post any more.

[...]

That is what is meant by "trailing commas". What else might it mean?

enum colours = {
red,
green,
blue,
purple,
pale_fushia_with_a_hint_of_orange,
};

I was looking at ways to eliminate those, as semicolons are in many
languages, or at least made optional.

How did we get back to semicolons here?

(In case of that poster most probably by obsession.)

You said they were "solved". (I
don't know what that means, since I don't know why you think they are a problem in the first place, but that's for a different branch of the
thread.) We are talking here about trailing commas in lists.

Yes, your case was obvious [to me]; it's the most common case in many programming languages.

Since you mentioned Algol 68 above (and the relation to semicolons)
I'd like to show one feature that illustrates an existing relation.

In some recent post I had mentioned the semicolon as sequencing token
and that in Algol 68 there's also a collateral token, the comma. E.g.

BEGIN
INT n := 0, SEMA consume = LEVEL 0, produce = LEVEL 3;
PAR BEGIN
# produce one #
DO DOWN produce;
print (n +:= 1);
UP consume
OD,
# consume one #
DO DOWN consume;
print (n -:= 1);
UP produce
OD,
# consume one #
DO DOWN consume;
print (n -:= 1);
UP produce
OD
END
END

Here you see a simple sample to illustrate parallel processing ('PAR'),
but the possibility of collateral statements is not restricted to such
parallel processing in Algol 68; you can apply it where it fits, and
the compiler can work with that semantics.

A trailing comma makes no sense if there's nothing to execute after
the third parallel instance (like here with comma in the collateral
case it's the same with semicolons in the sequenced case).

Algol 68's syntax is very coherent as we can see. It's a conceptual
general principle, and while obvious above, in case of the parallel
executed program parts, it can generally be applied, or also replaced
by sequenced building blocks (comma -> semicolon), or vice versa.

(That's BTW another instance where folks that focus on lexical and
syntax details (not you!) miss the whole picture of language design
decisions.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 11/11/2025 11:59, Janis Papanagnou wrote:

On 10.11.2025 14:13, David Brown wrote:

(In case of that poster most probably by obsession.)

For Fuck's Sake - let it alone.

You said they were "solved". (I
don't know what that means, since I don't know why you think they are a
problem in the first place, but that's for a different branch of the
thread.) We are talking here about trailing commas in lists.

Yes, your case was obvious [to me]; it's the most common case in many programming languages.

Since you mentioned Algol 68 above (and the relation to semicolons)
I'd like to show one feature that illustrates an existing relation.

In some recent post I had mentioned the semicolon as sequencing token
and that in Algol 68 there's also a collateral token, the comma. E.g.

BEGIN
INT n := 0, SEMA consume = LEVEL 0, produce = LEVEL 3;

So what is the significance of using commas here? Since it is not clear
what is being declared (/because/ the commas make it look like one
declaration statement), I'm asking about the differences between these
two lines:

INT a:=0, INT b:=a;
INT a:=0; INT b:=a;

A trailing comma makes no sense if there's nothing to execute after
the third parallel instance (like here with comma in the collateral
case it's the same with semicolons in the sequenced case).

I mentioned that in some contexts, a trailing comma is not needed and
can be ambiguous. However a language can simply choose to make a
trailing comma legal.

Algol 68's syntax is very coherent as we can see. It's a conceptual
general principle, and while obvious above, in case of the parallel
executed program parts, it can generally be applied, or also replaced
by sequenced building blocks (comma -> semicolon), or vice versa.

(That's BTW another instance where folks that focus on lexical and
syntax details (not you!)

Another incredibly subtle dig.

miss the whole picture of language design

decisions.)

Half of PL design /is/ to do with lexical and syntactic matters. 80% of
what I dislike about C is to do with that.

I can tell you that 'comma' is too inconsequential a symbol to separate important, multi-line blocks of code.

'PAR' is an unusual construct in that its input is N distinct blocks of
code. It is similar to this in my syntax:

switch/case expr
when ... then
when ... then
else ...
end

Each when-then, and the optional else, is followed by a block (naturally delimited by the next 'when', 'else' or 'end').

Here, 1 of N possibilities is evaluated (and with SWITCH, all
comparisons are done, effectively, in parallal).

With PAR, N of N are evaluated, in parallel. But because there is no
qualifier (the 'when') for each block, it leaves the syntax naked. I
suggest then an auxialiary keyword to introduce each block. Say that is 'then'; it would look like this in a Bart-style syntax:

par
then ...
then ...
then ...
end par

No commas are needed; no semicolons either except to separate things
wihin a line. No 'dance' with commas either when augmenting or reducing
the number of blocks.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Tue, 11 Nov 2025 15:08:50 +0000, bart wrote:

So what is the significance of using commas here?

Revised Report section 3.3, “Collateral and parallel clauses”:

Collateral-clauses allow an arbitrary merging of streams of
actions. Parallel-clauses provide, moreover, levels of
coordination for the synchronization (10.2.4) of that merging.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 11/11/2025 20:44, Lawrence D’Oliveiro wrote:

On Tue, 11 Nov 2025 15:08:50 +0000, bart wrote:

So what is the significance of using commas here?

Revised Report section 3.3, “Collateral and parallel clauses”:

Collateral-clauses allow an arbitrary merging of streams of
actions. Parallel-clauses provide, moreover, levels of
coordination for the synchronization (10.2.4) of that merging.

Which means what? That items in a list could be executed in abitrary order?

Remember my example was:

INT a:=0, INT b:=a;

which assumes that 'a' is defined and initialised first.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 08/11/2025 16:16, bart wrote:

So, I have decided cut any ties with that language [Algol68]

FI OD and CASE

I meant 'ESAC' here.

TYPE SYNTAX

I will basically keep REF, but will be on the lookout for an
alternative, as that seems too heavy. ^ from Pascal possibly.

I actually made the changes soon after posting. So:

FI, OD, ESAC are deprecated; you have to write 'END' or 'END kwd' instead.

REF is replaced by ^, which is from Pascal. It looked odd at first,
especally in an infix context like "...]^[...", but I'm getting used to it.

'^' is also used for a postfix explicit deference op. These should not
clash, even though sequences like "...]^[..." can occur in both
typespecs, and expressions:


[10]^[]int A
...
x := A[i]^[j]

However, the second ^ can be implicit, so you write A[i][j], which can
then be reduced to A[i,j]. So in practice it will not appear in source
code much.

VOID may as well stay in. In this language, this was only really used following REF. Now that becomes ^VOID. I'd already been using a
single-token alias called IVOID; that is no longer needed. Unless I can
think of far better name for what had been REF VOID.

I'd updated my current codebases and those work fine. FI/OD/ESAC/REF are
still recognised for now, to allow existing programs to compile.

EXPRESSION-BASED will stay as I'd stated.

Actually, that ability is used very little: mainly it allows RETURN to
be left out. Because of that, at one time I switched to separate
statements and expressions, as it simplified things, and worked like
that for a few years.

But it was added back to both languages because it seemed cool.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 08/11/2025 16:16, bart wrote:

So, I have decided cut any ties with that language. [Algol68]

Mine is anyway already vastly different, and still simpler and easier
while having dozens of more practical features.

I promise this will be my final post on the subject (concerning
Algol68), I will try to ignore any provocative posts that may follow.

I have a systems language and a higher level dynamic one, that share the
same syntax.

So here are a number of those practical features, written with the
systems language in mind, but many apply to both. A few at the end apply
to the dynamic one only.

This is why an old-fashioned, stilted language like Algol68 to me is now
more of a curiosity; it's a toy.

Features not natively present in Algol68 (that I know of, but of course
I haven't read the full spec):

* Fully case-insensitive

* Module scheme

* Namespaces

* Scope-control attributes

* Whole-program compilation (while having multiple modules!)

* 'main' entry-point function that is automatically called

* Mostly semicolon-free syntax (newline terminates statements
unless they clearly continue onto the next line)

* Full FFI with full support for machine-specific types

* Full control of record layouts and alignment

* Full out-of-order definitions for all entities

* Textual code inclusion

* String/binary file inclusion (embed any text or binary file as data)

* Int is the main signed, numeric integer type, defaulting to 64 bits

* Word is a 64-bit type used for unsigned numbers, and bit-patterns
that may not be numeric (Haskell also has Int and Word types)

* Label pointers and computed goto

* Bit/Bitfield indexing ops for both l- and r-values

* Bit-fields within records

* CASE statement that sequentially checks a control expr against N
possibilies (not the same as A68's 'case')

* SWITCH statement that checks a control expr against N possibilies
in parallel

* SELECT statement that evaluates one of N possibilities according to an
index 1..N. This is most like A68's 'case; it only exists as compact
syntax

* Simple enumerations

* ENUMDATA defines a set of enumerations in parallel with corresponding
data arrays

* TABLEDATA defines parallel data arrays without any enums

* SWAP operator

* Chained comparisons: a = b = c; a <= b < c

* 'IN' operator: if a in b..c, or if a in [b, c, d]

* ++ and -- operators, including value-returning versions

* Pointer arithmetic

* Simple macros

* Character constants: value such as 'A' up to 'ABCDEFGH' occupy one
Word value

* Multiple assignments: (a, b, c) := (x, y, z)

* Multiple function return values: (a, b) := f(x)

* Experimental piping operator: x -> F -> G means G(F(x))

* Default function arguments

* Named keyword arguments

* For-loops that work over the values of a collection rather than an
integer range

* REPEAT-UNTIL

* Looping CASE and SWITCH: DOCASE and DOSWITCH

* Loop controls EXIT, REDO, NEXT can work with nested loops

* ELSE clause for FOR-loops (as in Python)

* Two special forms of DOSWITCH: DOSWITCHU uses multi-point dispatch
code (to work better with branch prediction), of use within bytecode
dispatch loops

* And DOSWITCHX; needs extra setup code but can be 5% faster

* Function tables which can be interrogated at runtime for function
names and addresses

* Built-in READ+READLN and PRINT+PRINTLN /statements/

* Type-punning conversions including of r-values

* Encapsulation: anything defined in a Record type can be accessed via
the namespace scheme

Following are dynamic language only:

* Arbitrary precision decimal floating point arithmetic

* Pascal-style bit-sets: ['A'..'Z', 'a'..'z']

* Bit-arrays (actually of u1/u2/u4 elements) and bit pointers

* Built-in hash-table arrays

* 'IN' operator where RHS is a collection

* Basic exceptions

* First-class types and operators

I haven't mentioned my tools or their performance. Let's just say the self-hosted systems compiler builds itself in 0.1 seconds, on the same
machine that A68G builds in 35 seconds, if fast-tracked. They're nippy.

--- Synchronet 3.21a-Linux NewsLink 1.2