Ada 83 (in)famously had 63 reserved words, which was considered a lot at the
time (languages like C and Pascal had about half that). Considering only those
related to tasking, there were 7:

abort accept do entry select task terminate

Yet many of these have similar/related meanings, and perhaps some overloading
would have been a good idea.

entry and accept ... do go hand in hand. One could replace accept with something
like an entry body, eliminating 2 reserved words.

An entry is very like a procedure, so one could use procedure instead. It might
be necessary to distinguish between a "task procedure" (declared in a task spec)
and a "normal procedure" (declared anywhere else). Another reserved word eliminated.

abort/terminate are pretty much the same thing. We could eliminate abort and
just use terminate. (One could argue for using end, but given how often "end
Name;" appears when not terminating a task, that would be confusing.)

So we're left with select, task, and terminate, less than half as many. I
haven't looked in detail at the others, but presumably some reduction is
possible there.

Ada 95 added protected and requeue. Some Ada-83 compilers implemented "passive
tasks" that were similar to protected objects; formalizing that would have
required defining pragma Passive, leaving no need for protected.

There may be a need for requeue, but I've only used it to work around the
limitations on what a protected action may do, so I'm skeptical.

ISO/IEC 8652:2007 added synchronized. I think that could have simply reused task.

Ada 12 didn't expand this set of reserved words.

Ada 2X proposes adding parallel. Again, I think reusing task ("task begin" and
"task loop") would be fine.

So we will have 11 tasking-related reserved words (unless I've missed some), but
we only need select, task, and terminate (and maybe requeue), nearly a factor of
4 difference.

Maybe Ada 3X will add concurrent, and then there won't be any tasking terms that
aren't reserved words.

What do others think? Should Ada have made a greater effort at overloading
reserved words from the beginning? Should we belatedly object to adding parallel
when we have so many choices already? Or is having a large set of reserved
words, many of them with similar meanings, a good thing?

--
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

On 2021-05-31 22:51, Jeffrey R. Carter wrote:

> What do others think? Should Ada have made a greater effort at
> overloading reserved words from the beginning? Should we belatedly
> object to adding parallel when we have so many choices already? Or is
> having a large set of reserved words, many of them with similar
> meanings, a good thing?

I believe that most of reserved keywords can be simply unreserved.
Actually there is no syntactic necessity except for few. The rest is
kept reserved for the sake of regularity only.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

At least twice it was proposed that Ada have "keywords", identifiers with
special meaning in the syntax but that were not reserved. The last time (and
I forget precisely when that was), the ARG had a slight majority in favor of
unreserved keywords as well as reserved words. However, it was resoundly
rejected at the WG 9 level. At that time, WG 9 still voted by countries, and
it turned out that pretty much everyone in favor of unreserved keywords were
from North America. Most Europeans were appalled. Of course, that meant a WG
9 vote with 2 in favor and a large number against.

So whenever you think there are too many reserved words in Ada, be assured
that it was repeatedly suggested that they not all be reserved, but certain
countries would not allow it. At this point, we've given up, since it really
would not help much - the majority of words that likely ever be reserved
already are (it would most likely matter if a new proposal tried to reserve
some commonly used term - "yield" came up some some proposals for Ada 202x
that didn't go anywhere).

Jeff Carter should note the 8 different uses for "with" in the syntax before
he accuses anyone of not reusing reserved words in Ada. It's just the case
that it's hard to write something meaningful with the existing reserved
words (we almost always try).

"parallel" is an interesting case. In my world view, it is wildly different
from a task, because it is *checked*, does not *block* or *synchronize* with
another thread (all synchronization is via objects or completion), is
automatically created (in looping constructs) and therefore requires
substantial less care than writing a task. There is another world-view
where essentially the checking is not worthwhile and ergo must be
suppressed, that performance matters to the point at which a compiler isn't
allowed to make choices, and essentially requires *more* care than a task.
In that second world-view, parallel constructs are either harmful or
worthless. But even there, having a keyword makes it a lot easier to avoid
them than trying to figure out which libraries to block. :-)

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:s93kci$1f55$1@gioia.aioe.org...
> On 2021-05-31 22:51, Jeffrey R. Carter wrote:
>
>> What do others think? Should Ada have made a greater effort at
>> overloading reserved words from the beginning? Should we belatedly object
>> to adding parallel when we have so many choices already? Or is having a
>> large set of reserved words, many of them with similar meanings, a good
>> thing?
>
> I believe that most of reserved keywords can be simply unreserved.
> Actually there is no syntactic necessity except for few. The rest is kept
> reserved for the sake of regularity only.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

"Randy Brukardt" <randy@rrsoftware.com> writes:
> At least twice it was proposed that Ada have "keywords", identifiers with
> special meaning in the syntax but that were not reserved.

I remember this as a fundamental decision of PL/I that made PL/I quite
hard to parse using the automata-based methods developed not long
afterwards. I don't know what consequences that had for PL/I or
anything else, if any. But I think it was retrospectively considered a
mistake. It's a lot easier to separate parsing and scanning if you can
have reserved words.

OTOH I know that C compilers sometimes (usually?) handle typedefs by
having the parser tell the scanner to treat the typedef name as
keyword-like, after it sees that a typedef has been defined.

On 6/1/21 7:54 AM, Randy Brukardt wrote:
> At least twice it was proposed that Ada have "keywords", identifiers with
> special meaning in the syntax but that were not reserved.

Unreserved keywords are one approach, though I'm not aware if they come with any
negatives. Then the question becomes which reserved words could become
unreserved keywords. (This can be restricted to reserved words related to
tasking/concurrency to avoid going through all the reserved words.)

> At that time, WG 9 still voted by countries

Does that imply that the voting has since changed and such a proposal might now
be accepted?

> Jeff Carter should note the 8 different uses for "with" in the syntax before
> he accuses anyone of not reusing reserved words in Ada. It's just the case
> that it's hard to write something meaningful with the existing reserved
> words (we almost always try).

I agree that the ARG has done a good job in reusing reserved words in many
cases, "with" being the most obvious. I concentrated on tasking/concurrency
reserved words since that seems to be an exception.

--
Jeff Carter
"Violence is the last refuge of the incompetent."
Foundation
151

On 31/05/2021 21:51, Jeffrey R. Carter wrote:
> Ada 83 (in)famously had 63 reserved words, which was considered a lot at
> the time (languages like C and Pascal had about half that). Considering
> only those related to tasking, there were 7:
>
> abort accept do entry select task terminate

I think you're about 40 years too late to complain now :P

Luke.

"Randy Brukardt" <randy@rrsoftware.com> writes:

> At least twice it was proposed that Ada have "keywords", identifiers with
> special meaning in the syntax but that were not reserved. The last time (and
> I forget precisely when that was), the ARG had a slight majority in favor of
> unreserved keywords as well as reserved words.

interface, perhaps? I know we had quite a few identifiers with that
spelling!

TextUML is case-sensitive, so if you want to use a keyword as an
identifier you can capitalize it, or prefix it with a backslash

accept, entry vs. procedure, procedure body

This discussion really is 40 years late. But entries and procedures are in fact very different beasts.
A procedure is reentrant and has exactly one body.
An entry is not reentrant and cannot be called recursively; it has no body, rather it may have as many accept statements as you like or feel necessary (it may even have none - what the heck!).

So different keywords for them are quite reasonable.

Thinking about this:
Ultimatey, we could perhaps do with just one reserved word called keyword. Depending on the place where is stands makes it clear what it means:
keyword I keyword 1..10 keyword
X(I) := I + 1;
Keyword;

Hm, perhaps a bit extreme :-)

On 2021-06-02 20:13, AdaMagica wrote:

> This discussion really is 40 years late. But entries and procedures are in fact very different beasts.
> A procedure is reentrant and has exactly one body.
> An entry is not reentrant and cannot be called recursively; it has no body, rather it may have as many accept statements as you like or feel necessary (it may even have none - what the heck!).

Yes, but I would argue that these are implementation details. It might
have sense to consider them having same interface, as we do now, after
the dot-notation was introduced. In Ada 83 it was not so.

> So different keywords for them are quite reasonable.

So long the implementation details leak, as we have no tagged tasks and
protected objects and no multiple dispatch. Otherwise all calling
notations could be made fully equivalent for all bodies.

> Thinking about this:
> Ultimatey, we could perhaps do with just one reserved word called keyword. Depending on the place where is stands makes it clear what it means:
> keyword I keyword 1..10 keyword
> X(I) := I + 1;
> Keyword;

Yes, one needs only one pair of delimiters. It reminds me construction
of Z in ZFS using sets:

0 = Ø
1 = {Ø}
2 = {{Ø}}
...

Similarly the for-loop could be:

(<index>, <from>, <to>, <body>)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 02/06/2021 20:21, Dmitry A. Kazakov wrote:

>
> Yes, one needs only one pair of delimiters. It reminds me construction
> of Z in ZFS using sets:
>
>    0 = Ø
>    1 = {Ø}
>    2 = {{Ø}}
>    ...
>
> Similarly the for-loop could be:
>
>   (<index>, <from>, <to>, <body>)
>

Reminds me of extensive code I supported in VMS Basic - after 1500 odd
lines, the procedure ended with:

UNLESS Z

Z was not a local variable - global.

Try searching a massive code base for Z...

Took awhile dredging through the various callers

--
Chris

On 6/2/21 8:13 PM, AdaMagica wrote:
> accept, entry vs. procedure, procedure body
>
> This discussion really is 40 years late.

Regarding what we have in Ada, sure. Regarding whether we can or should do more
to avoid new reserved words in the future, no. And if there is ever a successor
language, this is something that should be considered.

> But entries and procedures are in fact very different beasts.

Under the hood, yes. In appearance and how they are called, not so much. And
that seems like the important thing.

> Ultimatey, we could perhaps do with just one reserved word called keyword. Depending on the place where is stands makes it clear what it means:
> keyword I keyword 1..10 keyword
> X(I) := I + 1;
> Keyword;

I'm pretty sure that last line should be

keyword keyword;

> Hm, perhaps a bit extreme :-)

Well, some people write Whitespace, but for Ada, probably.

--
Jeff Carter
"I did not rob a bank. If I'd robbed a bank, everything
would be great. I tried to rob a bank, is what happened,
and they got me."
Take the Money and Run
139

On 2 Jun 2021, AdaMagica wrote
(in article<827c60f6-b008-468b-9ab4-cf110edff252n@googlegroups.com>):

> Thinking about this:

> Ultimatey, we could perhaps do with just one reserved word called keyword.
> Depending on the place where is stands makes it clear what it means:

> keyword I keyword 1..10 keyword
> X(I) := I + 1;
> Keyword;

Should that not finish off thus:

keyword keyword;

? 8-)
--
Bill Findlay

On Tuesday, June 1, 2021 at 5:40:53 PM UTC+10, Paul Rubin wrote:
> "Randy Brukardt" <ra...@rrsoftware.com> writes:
> > At least twice it was proposed that Ada have "keywords", identifiers with
> > special meaning in the syntax but that were not reserved.
..
> I remember this as a fundamental decision of PL/I that made PL/I quite
> hard to parse using the automata-based methods developed not long
> afterwards. I don't know what consequences that had for PL/I or
> anything else, if any. But I think it was retrospectively considered a
> mistake.
..
It was definitely never considered a mistake in PL/I.
Not having reserved words means that you do not have
to steer clear of using any particular words when you
design a program.
It also means that a program will continue to compile
even when new keywords are introduced into the language.
Over the years, new keywords were introduced into PL/I,
without invalidating existing programs.
..
Reserved words are the bane of COBOL.
..
> It's a lot easier to separate parsing and scanning if you can
> have reserved words.
>
> OTOH I know that C compilers sometimes (usually?) handle typedefs by
> having the parser tell the scanner to treat the typedef name as
> keyword-like, after it sees that a typedef has been defined.

AdaMagica <christ-usch.grein@t-online.de> writes:
> accept, entry vs. procedure, procedure body
>
> This discussion really is 40 years late. But entries and procedures are in fact very different beasts.
> A procedure is reentrant and has exactly one body.
> An entry is not reentrant and cannot be called recursively; it has no body, rather it may have as many accept statements as you like or feel necessary (it may even have none - what the heck!).
>
> So different keywords for them are quite reasonable.
>
> Thinking about this:
> Ultimatey, we could perhaps do with just one reserved word called keyword. Depending on the place where is stands makes it clear what it means:
> keyword I keyword 1..10 keyword
> X(I) := I + 1;
> Keyword;
>
> Hm, perhaps a bit extreme :-)

In a case-sensitive language, you can have 128 variations of "keyword".

keyword I Keyword 1..10 keyWord
X(I) := I + 1;
keyworD keyWord

Much more legible.

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

On 2021-06-04 01:58, Keith Thompson wrote:
> AdaMagica <christ-usch.grein@t-online.de> writes:
>> accept, entry vs. procedure, procedure body
>>
>> This discussion really is 40 years late. But entries and procedures are in fact very different beasts.
>> A procedure is reentrant and has exactly one body.
>> An entry is not reentrant and cannot be called recursively; it has no body, rather it may have as many accept statements as you like or feel necessary (it may even have none - what the heck!).
>>
>> So different keywords for them are quite reasonable.
>>
>> Thinking about this:
>> Ultimatey, we could perhaps do with just one reserved word called keyword. Depending on the place where is stands makes it clear what it means:
>> keyword I keyword 1..10 keyword
>> X(I) := I + 1;
>> Keyword;
>>
>> Hm, perhaps a bit extreme :-)
>
> In a case-sensitive language, you can have 128 variations of "keyword".

In a Unicode language it is much more, because many Latin glyphs like k,
e, y, o repeat in other alphabets. Furthermore, F, K, C appear as
special entries as degrees etc.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de