Version 1.1 of acs/ac-00312.txt

Unformatted version of acs/ac-00312.txt version 1.1
Other versions for file acs/ac-00312.txt

!standard 4.5.2(7)          18-12-14 AC95-00312/00
!class Amendment 18-12-03
!status received no action 18-12-03
!status received 18-10-19
!subject Equality Operator
!summary
!appendix

From: Mark Holland
Sent: Thursday, November 8, 2018  4:10 PM

Dear Working Group Technical Committee of the subject matter ,

I have noticed the publication of the use of the so-called ' non equality ' 
symbolic character  /=  @ the adaic.org so-called Ada operators to the 
C11® CPL and the so-called Java®

A most logical symbol is:

                       ' # '

A crossed out with two soldus  'equal too' symbol character the so-called 
'hash' key.

in the absence of a symbol with one so-called ' soldus ' through the 
equals/equality symbol character.

I anticipate Your enthusiastic interest in My communication.

***************************************************************

From: Randy Brukardt
Sent: Monday, November 12, 2018  9:53 PM

There are both administrative and technical responses to this submission.
(Note that the technical responses reflect my personal opinions and not 
necessarily those of the entire working group.)

First, the administrative concerns:

(1) This message is labeled "Private", but it was sent to a public mailing 
    list which is distributed automatically to all interested parties. We do 
    not accept private correspondence; all correspondence is part of the 
    permanent public record.

(2) While we accept submissions at any time, the deadline for inclusion in the 
    upcoming Ada 2020 revision was January 15th, 2018. So any proposed 
    significant changes to Ada will not be considered until the next revision 
    starts (most likely not until 2022 or later).

(3) All submissions for language changes should include a problem statement.
    Ada has been in use for nearly 40 years, and there is no desire to make 
    any changes to it unless they fix significant problems. Read a more 
    extensive description of what we need here:
       http://www.adaic.org/2017/08/community-input-for-ada/.

If you want this (or any other proposal) to be taken seriously, please 
resubmit it with an appropriate problem statement.

---

And some technical comments:

(1) Ada was originally defined in the late 1970s, and has been a standard 
    since 1983. Something as fundamental as the inequality operator has been 
    in wide use since that time. Changing the operator used would wildly 
    incompatible with the millions of lines of existing Ada code and as 
    such would never be considered.

(2) One of Ada's most important goals is readability. See the introduction of 
    the Standard, Design Goals.
    (http://www.ada-auth.org/standards/2xrm/html/RM-0-3.html, for instance).
    Having multiple inequality operators is likely to make Ada harder to read.
    One would need a significant problem in order to consider that; you didn't 
    provide any problem statement at all.

(3) The number sign ('#') already has a use in Ada. While I don't think that a
    '#' operator would conflict with that use (in based number literals), it 
    surely would make Ada harder to read:

    if A /= 16#FF# then -- Current Ada.

    if A # 16#FF# then -- Proposed use.

(4) We previously considered allowing additional operators using Unicode 
    characters. At the time, it was decided to avoid that so that Ada code 
    could be written using only Latin-1 characters (which are near-universal).
    Unicode still poses problems in display and interpretation on many 
    systems. (We do require that compilers be able to accept UTF-8 code 
    including Unicode characters, but allowing something and mandating it are
    different things.) We may revisit that at some point in the future (as 
    Unicode becomes even more prevalent), but not for the current revision.

    I bring this up mainly because Unicode has a not equals symbol that we 
    could consider as an alternative for "/=". I think that would make much 
    more sense than using any other Latin-1 character -- but it would require 
    a willingness to move away from Latin-1 only source code.

***************************************************************

Questions? Ask the ACAA Technical Agent