Version 1.1 of acs/ac-00067.txt

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

!standard 1.1.3(04)          03-08-04 AC95-00067/01
!class amendment 03-08-04
!status received no action 03-08-04
!status received 03-01-17
!subject Ada should disallow syntactic and semantic extensions
!summary
!appendix

!topic Ada should disallow syntactic and semantic extensions
!reference RM95-1.1.3(4), RM95-2.1(4)
!from Dan Eilers 03-01-17
!discussion

RM95-1.1.3(4) requires an implementation to identify all programs
containing errors.  This seems like a reasonable rule.

However RM95-2.1(4) states that the coded representation of the
characters making up the text of a program is implementation defined.

Is an implementation allowed to accept arbitrary syntactic and
semantic extensions in standard mode by somehow taking advantage of
the freedom granted by RM95-2.1(4) to define the coded representation
of characters?  If so, RM95-1.1.3(4) should be amended to say that an
implementation is _not_ required to identify programs containing
errors.

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

From: Randy Brukardt
Sent: Friday, January 17, 2003  7:20 PM

This question was essentially discussed in 1996 in AI-134, in response to a
very similar question from you. The AI says that the intent of the Standard
is clearly noted in the AARM 2.1(18a). This starts out "Any source
representation is valid so long as the implementer can produce an
(information-preserving) algorithm for translating both directions between
the representation and the standard character set.".

That would make semantic extensions very difficult (I'd say impossible, but
I don't want to underestimate the cleverness of implementers). Syntax
extensions would be pretty easy, if there was a reasonable mapping to
existing features.

The separate private parts discussed last month definitely have this
property. It is simple to build a tool which would convert from one format
to the other.

   with P1;
   package P is
      -- (1)
   private is separate;
   end P;

   with P2;
   package private P is
      -- (2)
   end P;

is easily converted to:

   with P1;
   private with P2;
   package P is
      -- (1)
   private
      -- (2)
   end P;

And the reserve conversion is not difficult, either.

Clearly, supporting such a feature and the required tool does not harm
portability much, if any, as all that would be required to port the code is
to run the tool, and the source would now be in the standard form.

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

From: Dan Eilers
Sent: Friday, January 17, 2003  8:08 PM

> This question was essentially discussed in 1996 in AI-134, in response to a
> very similar question from you. The AI says that the intent of the Standard
> is clearly noted in the AARM 2.1(18a). This starts out "Any source
> representation is valid so long as the implementer can produce an
> (information-preserving) algorithm for translating both directions between
> the representation and the standard character set.".

What is an algorithm in this context??

Does the implementer actually have to code up this algorithm or can he just
keep it in his head?  If he has to code it up, does he have to distribute it?
If he has to distribute it, does it have to be free?  On what platforms?
Does he have to distribute it to all users of other compilers who want to be
able to compile published code written using the extensions?

> Clearly, supporting such a feature and the required tool does not harm
> portability much, if any, as all that would be required to port the code is
> to run the tool, and the source would now be in the standard form.

I don't believe this at all.  If vendor A implements an extension, no
matter how trivial, and his customers start publishing code using the
extension, then all other vendors have to implement the same extension,
or else their customers are at a disadvantage in using the published code.

Such customers can't be told to just go buy vendor A's preprocessor,
because the output of such preprocessor, even if it was readily
available, is likely to be an unmaintainable mess.

Preprocessors can be arbitrarily complicated, with the output bearing
absolutely no resemblance to the original.  We sell what could be
considered to be a C preprocessor that accepts Ada syntax.  But we
claim to be selling a C compiler.  And we don't tell people that if
their C compiler doesn't also accept Ada syntax they can just run our
preprocessor first and use the generated C.

To the extent that the rule disallowing extension and the rule
allowing freedom of representation of characters is in conflict,
the rule disallowing extensions should win.  The representation
of characters can easily be limited to just ISO standard character
sets without harming the language at all.  But a language that prides
itself on unmatched portability can't be allowed to have arbitrary
preprocessing extensions in standard mode without becoming a laughingstock.

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

From: Robert Dewar
Sent: Friday, January 17, 2003  8:33 PM

The answer to these questions is obviously no, the standard can never create
any obligation to distribute anything.

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

From: Robert Dewar
Sent: Friday, January 17, 2003  8:35 PM

> Preprocessors can be arbitrarily complicated, with the output bearing
> absolutely no resemblance to the original.  We sell what could be
> considered to be a C preprocessor that accepts Ada syntax.  But we
> claim to be selling a C compiler.  And we don't tell people that if
> their C compiler doesn't also accept Ada syntax they can just run our
> preprocessor first and use the generated C.

There are many ways to write unusable Ada compilers, the standard should
not be in the business of preventing this, because it cannot do so!

> To the extent that the rule disallowing extension and the rule
> allowing freedom of representation of characters is in conflict,
> the rule disallowing extensions should win.  The representation
> of characters can easily be limited to just ISO standard character
> sets without harming the language at all.  But a language that prides
> itself on unmatched portability can't be allowed to have arbitrary
> preprocessing extensions in standard mode without becoming a laughingstock.

I think this is a tempest in a teapot, and trying to solve it will be a
complete waste of time.

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

From: Dan Eilers
Sent: Friday, January 17, 2003  8:52 PM

> The answer to these questions is obviously no, the standard can never create
> any obligation to distribute anything.

Since the purpose of the conversion tool is presumably to mitigate
the portability hazard, and since as you point out, there can be no
requirement to distribute the conversion tool, what you are left with
is an unmitigated portability hazard.

> There are many ways to write unusable Ada compilers, the standard should
> not be in the business of preventing this, because it cannot do so!

The standard can easily prevent extensions in standard mode, and it can
easily prevent non-traditional character encodings.  Why do you think
otherwise?

> I think this is a tempest in a teapot, and trying to solve it will be a
> complete waste of time.

Given that we have an actual proposal on the table to end-run the
standardization process with a proprietary extension of Ada' syntax
having to do with private parts, this issue seems quite important to
resolve.

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

From: Randy Brukardt
Sent: Friday, January 17, 2003  9:09 PM

> Given that we have an actual proposal on the table to end-run the
> standardization process with a proprietary extension of Ada' syntax
> having to do with private parts, this issue seems quite important to
> resolve.

Do you think that the standard can somehow prevent an implementor from
implementing anything they like? There is nothing anywhere that says that
they have to implement anything at all, and they can call anything they want
"Ada". That that prevents horrible abuses is market pressure.

If that wasn't true, both of our companies would have been out of business
long ago. 'cause neither company has provided a complete implementation of
Ada 95 for most of the last seven years.

I would have preferred market pressure to have done a better job keeping
implementations compatible, but I can hardly complain that it has failed. In
any case, there is nothing useful that the standard can do in this area; the
implementers would just ignore the standard.

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

From: Dan Eilers
Sent: Saturday, January 18, 2003  1:32 AM

> Do you think that the standard can somehow prevent an implementor from
> implementing anything they like? There is nothing anywhere that says that
> they have to implement anything at all, and they can call anything they want
> "Ada". That that prevents horrible abuses is market pressure.

Yes, I think the standard can say whatever it wants.  It can perfectly
well say extensions are not allowed in standard mode.   And it absolutely
should say that.  It is perhaps the single most important rule in the entire
document.  And it should not be sacrificed in favor of what is perhaps
the least important rule in the entire language, the freedom to change
character encodings.

As far as I know, no vendor has ever implemented a syntax extension
masquerading as a character encoding and called it standard Ada.  So yes
I am very optimistic that this trend will continue.  If a vendor did such
a thing, I suspect they would get sued for false advertising.

If you think the standard has no power to prevent implementors from
implementing anything they like and calling it standard Ada, then
why in the world do you bother trying to improve the standard?

> If that wasn't true, both of our companies would have been out of business
> long ago. 'cause neither company has provided a complete implementation of
> Ada 95 for most of the last seven years.

The issue is what the vendor is claiming about the product.  Marketing
a non-conforming compiler as such is not an abuse.  In fact, it was
officially encouraged during the transition period.

> I would have preferred market pressure to have done a better job keeping
> implementations compatible, but I can hardly complain that it has failed. In
> any case, there is nothing useful that the standard can do in this area; the
> implementers would just ignore the standard.

The issue isn't whether implementers will ignore the standard.  If the
standard doesn't meet their customers' needs, vendors should ignore the
standard.  The issue is whether the standard should permit the vendors
to ignore the standard and still claim to be conforming.

On the private type issue, we will probably do something similar to
what ACT is proposing, allowing private parts in separate files.
I think the private-with proposal is too short-sighted.  The ARG
should take note that there are vendors who are tempted to go way
out on really shaky limbs to end-run this AI.  But we don't intend
to claim that allowing private parts in separate files is standard
Ada (unless of course the AI changes).

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

From: Robert Dewar
Sent: Saturday, January 18, 2003 10:50 AM

> Yes, I think the standard can say whatever it wants.  It can perfectly
> well say extensions are not allowed in standard mode.   And it absolutely
> should say that.  It is perhaps the single most important rule in the entire
> document.  And it should not be sacrificed in favor of what is perhaps
> the least important rule in the entire language, the freedom to change
> character encodings.

Of course what "standard mode" means cannot possibly be legislated. For
example in gnu-c, the standard mode is achieved by using -pedantic, and
in COBOL, the validation procedures mandate the presence of somekind of
switch to flag all extensions.

> On the private type issue, we will probably do something similar to
> what ACT is proposing, allowing private parts in separate files.
> I think the private-with proposal is too short-sighted.  The ARG
> should take note that there are vendors who are tempted to go way
> out on really shaky limbs to end-run this AI.  But we don't intend
> to claim that allowing private parts in separate files is standard
> Ada (unless of course the AI changes).

The standard has nothing whatever to say about files. The notion that one
compilation unit belongs in one file (a notion that seems fixed in Dan's
mind) is nowhere in the standard, nor should it be.

The question of whether a compilation is in one file or many files is for
example also something that is (and always has been) implementation dependent.

What Dan wants to do in his compiler, is certainly fine. But the notion that
failing to enforce this non-standard requirement of one compilation being
in one file as somehow being a "shaky limb" is either muddled thinking or
special pleading.

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

From: Robert Dewar
Sent: Saturday, January 18, 2003 11:21 AM

> Since the purpose of the conversion tool is presumably to mitigate
> the portability hazard, and since as you point out, there can be no
> requirement to distribute the conversion tool, what you are left with
> is an unmitigated portability hazard.

If a vendor is determined to inhibit portability, then the standard cannot
stop it (for example, a vendor could apply licensing terms saying that any
code submitted to the compiler was not permitted to be submitted to any
other compiler. Whether that was allowed would be up to the courts of a
particular standard, not the ISO standard!) One would assume that a market
place interested in portability would reject compilers that did not allow
easy portability of code.

> The standard can easily prevent extensions in standard mode, and it can
> easily prevent non-traditional character encodings.  Why do you think
> otherwise?

Because the standard has nothing *whatever* to say about source representation.
It is simply not in that business at all. The idea that source representation
involves character encodings at all is a construction nowhere supported by
the standard.

When you write

   a := b;

the "a" there has absolutely NOTHING whatever to do with the encoding of
"a" in Standard.Character.

Typically it is possible for Text_IO to read compiler sources, but there is
absolutely nothing in the standard to suggest that this might be possible,
and indeed it might easily not be possible. For example, on the old Univac
systems, all sources were automatically maintained within the source
version control system, and all compilers used special access methods to
read the desired version (including printing out update information
automatically). In such a system, Text_IO (unless radically extended) would
not be able to read source files at all.

> Given that we have an actual proposal on the table to end-run the
> standardization process with a proprietary extension of Ada' syntax
> having to do with private parts, this issue seems quite important to
> resolve.

There is no end-run here, this is simply a source representation issue,
and the standard has nothing whatever to say about source representation.
You are free to decide that anyone moving in this direction is making a
mistake, but it is simply empoty rhetoric to claim it is non-standard.
Presumably if Ada users agree with you (this incidentally to remind you
is the constitutency the standard serves directly), no doubt they will
avoid compilers making this mistake.

In practice of course, in the case of GNAT, just as we work to make sure
that GNAT can accomodate bizarre file naming schemes required by other
compilers, if we implement this very useful representation, we will have
tools to convert from *and to* this representation from the more usual
ones (just as we provide gnatchop to convert from the "multiple-files-
per-compilation" representation to the individual files used naturally
by GNAT.

Dan, you really need to go back to the RM to remind yourself that the
standard has nothing to say about source representation.

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

From: Dan Eilers
Sent: Saturday, January 18, 2003  1:29 PM

> Of course what "standard mode" means cannot possibly be legislated.  ...

This claim is so absurd I don't know that it deserves a response.
The sole purpose of the RM is of course to legislate what standard
mode means.

The RM explicitly claims to specify "the form of a program written
in Ada" (RM 1.1.1(2)).

The RM explicitly claims that conforming implementations shall
detect the violation of all its rules (RM 1.1.3(4)).

The RM explicitly claims that "with" clauses have to appear at the
beginning of the sequence of tokens that make up a compilation unit
(not at the beginning of the private part as we both propose), and
the RM explicitly claims that the syntax for package specs does not
allow anything like "private is separate" (as we both propose).

There is a fundamental rule of jurisprudence applicable to any
potential claim of fraudulent misrepresentation of conformance to the
ISO Ada standard, which is known informally as "walks like a duck,
quacks like a duck, looks like a duck, is a duck."  We both propose
to violate the clear intent of the standard to solve an urgent need
that the ARG seems unwilling to address.  But legal sophistry needed
to call this an allowable character encoding runs afoul of the
"walks like a duck" rule and such attempts generally do not go over
well with judges or juries.

There is another fundamental rule of jurisprudence that you seem to
be blithely ignoring.  It states that one rule should not be interpreted
in such a way as to nullify the meaning of other rules.  By your
argument, RM 1.1.3(4) requiring the detection of errors has no
meaning, and consequently none of Ada's rules have any meaning.
This is an absurd interpretation.

> The standard has nothing whatever to say about files.

True.  The standard refers to sequences of tokens, composed of sequences
of characters, the encoding of which is implementation defined.
But it does not allow the tokens making up "with" clauses to appear at
the beginning of private parts, nor does it allow the token sequence
"private is separate" to appear in a package spec.


> If a vendor is determined to inhibit portability, then the standard cannot
> stop it ...

The sole purpose of the Ada standard "is to promote the portability of
Ada programs" (RM 1.1/1).  Just because the achieved level of portability
does not quite reach 100% does not mean that the standard's sole purpose
should be completely abandoned.


> Presumably if Ada users agree with you (this incidentally to remind you
> is the constitutency the standard serves directly), no doubt they will
> avoid compilers making this mistake.

No, customers like compiler extensions.  It allows them to do the things
they need to do but are otherwise prohibited from doing.  Customers don't
avoid compilers because of extensions.  But customers also like honesty.
If there is an extension, they want it to be called an extension, rather
than a clever character encoding.


> In practice of course, in the case of GNAT, just as we work to make sure
> that GNAT can accomodate bizarre file naming schemes required by other
> compilers, ...

This is a red herring.  Source file naming schemes are clearly outside
the standard, and have nothing at all to do with Ada's syntax or semantic
rules.

> Dan, you really need to go back to the RM to remind yourself that the
> standard has nothing to say about source representation.

I am very clear that compilations consist of a sequence of tokens,
which in turn consist of a sequence of characters, whose encoding
is implementation defined.

AI 134 states that "source representation does not represent a gaping
loophole."  Yet, you would have us believe that there is no limit to
the size of a truck which could be safely driven through it.

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

From: Robert Dewar
Sent: Saturday, January 18, 2003 10:59 PM

> This claim is so absurd I don't know that it deserves a response.
> The sole purpose of the RM is of course to legislate what standard
> mode means.


No you misunderstood entirely what I said (if you think I am saying something
"so absurd", it is quite likely that this is the case :-)

What I means was that the notion of how "standard mode" might be specified
is of course not legislated by the standard. There must be some mode. I think
if you reread my message you will see I was clear enough since I gave a
couple of examples of what I was talking about.

> True.  The standard refers to sequences of tokens, composed of sequences
> of characters, the encoding of which is implementation defined.
> But it does not allow the tokens making up "with" clauses to appear at
> the beginning of private parts, nor does it allow the token sequence
> "private is separate" to appear in a package spec.

Well I disagree. You certainly cannot determine that I am wrong from the
standard, you are simply expressing a subjective opinion. The idea of
having "private is separate" in a sense that is NOT a token sequence is
perfectly within the standard for me. Going back to the UNIVAC example
(UNISYS), a source line would have many "tokens" in it that are not part
of the Ada standard, including the version number in which each line was
introduced and who introduced it.

Indeed, one can perfectly well imagine an Ada compiler that reads directly
from some complex internal source management system, where the actual
sequence of bits is nothing like a set of simple character codes.

The point is that the actual bits that are stored must *represent* a series
of characters in the sense of the RM. To say that they must *be* a series
of characters makes no sense (files contain bits they do not contain
characters).

> There is another fundamental rule of jurisprudence that you seem to
> be blithely ignoring.  It states that one rule should not be interpreted
> in such a way as to nullify the meaning of other rules.  By your
> argument, RM 1.1.3(4) requiring the detection of errors has no
> meaning, and consequently none of Ada's rules have any meaning.
> This is an absurd interpretation.

Sorry I agree it is an absurd intepretation, but it is also irrelevant
nonsense that has nothing whatever to do with what I said.

> True.  The standard refers to sequences of tokens, composed of sequences
> of characters, the encoding of which is implementation defined.
> But it does not allow the tokens making up "with" clauses to appear at
> the beginning of private parts, nor does it allow the token sequence
> "private is separate" to appear in a package spec.


Absolutely true, the "private is separate" are obviously NOT tokens in the
sense of the standard (unless the ARG provides some extension, or you want
to consider this a language extension), They are some kind of extra language
junk that helps the compiler find the rest of the file.

The reason I prefer to consider this as a source representation issue rather
than an extension is that if you think of it as a source representation issue,
then it

a) ensures that there is a simple transformation to convert from this
extended form to the standard form. For example, suppose we did NOT have
the private with extension. Now if you start putting the private part in
a separate file, then it would degfinitely be a (significant) extension
to say that WITH statements in the private part apply only the the private
part. Such an extension would take you out of the realm of things that
can be considered as source representatoin issues.

b) if you regard something as a source transformation, then clearly you
provide the utility program that does this simple transformation aiding
portability.

If you get in the true extension business (like the WITH TYPE extension in
GNAT), then you are in a completely different realm where portability *is*
a real issue. Anyone using WITH TYPE is really compromising portability
badly. However, putting private parts in a separate file does not compromise
portability precisely because there is a simple transformation.

That's the ONLY sense in which I think it is useful to make the distinction
(between an extension, and a source representation transformation). As long
as something can be represented as a source transformation, it is far less
damaging to portability.

In the case of GNAT, we are NOT willing to introduce any kind of semantic
extensions for this kind of faciltiy, which is why we want to keep it in the
realm of simple source transformation. We would want this even if Ada0Y had
a new feature in this area, since it will be a long time before Ada0Y
compilers are in common use.

> No, customers like compiler extensions.  It allows them to do the things
> they need to do but are otherwise prohibited from doing.  Customers don't
> avoid compilers because of extensions.  But customers also like honesty.
> If there is an extension, they want it to be called an extension, rather
> than a clever character encoding.

Well clearly it is reasonable to have switches that enable or enable such
things, but I think it is important from a customers point of view to
distinguish between

a) true extensions that may compromise portability because there is no
simple transformation to standard Ada.

b) what I call source representation approaches, which guarantee that there
IS a simple transformation to standard Ada, achievable by running trivial
simple tools that are provided, and which does NOT compromise portability
in any way.

if the word source-representation-method gets you so hot under the collar,
please rename it in your mind as
extension-which-is-easily-transformed-into-standard-Ada-with-tool-provided
I could not care less which of these two terms anyone prefers to use, but
the distinction is an important one.

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

From: Robert Dewar
Sent: Sunday, January 19, 2003  7:00 AM

> This question was essentially discussed in 1996 in AI-134, in response to a
> very similar question from you. The AI says that the intent of the Standard
> is clearly noted in the AARM 2.1(18a). This starts out "Any source
> representation is valid so long as the implementer can produce an
> (information-preserving) algorithm for translating both directions between
> the representation and the standard character set.".


That's essentially exactly my position, and the only reasonable one. I really
think we are retreading old and tired ground here and the discussion is a
bit of a waste of time.

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

From: Robert Dewar
Sent: Sunday, January 19, 2003  7:03 AM

> Is an implementation allowed to accept arbitrary syntactic and
> semantic extensions in standard mode by somehow taking advantage of
> the freedom granted by RM95-2.1(4) to define the coded representation
> of characters?  If so, RM95-1.1.3(4) should be amended to say that an
> implementation is _not_ required to identify programs containing
> errors.

Dan has seen someone light a match and has called out the fire department :-)

Of course it is not the case that the source representation freedom can
allow arbitrary syntactic and semantic transformations. No one has ever
suggested that it can, either in principle or by specific example.

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

From: Dan Eilers
Sent: Monday, January 20, 2003  2:00 AM


> No you misunderstood entirely what I said

No, I didn't misunderstand at all.

It is perfectly clear that you are attempting to achieve through
the back door what you can't get through the front door.
Your new syntax of "private is separate" is clearly outlawed,
as are all syntax extensions in Ada, no matter how minor.

The intent of outlawing syntax extension is so fundamental that
even the RM's optional annexes do not contain syntax extensions.

This sort of virtual-preprocessing subterfuge was denounced in
no uncertain terms in an article which I quote:

 "Just because you discover some way of inventively reading the RM to allow
  an implementation to do something amazing (I regard the computation model
  Tom suggests as pretty amazing) does not mean that this reading is consistent
  with Ada. That applies to any language standard. For example, the C++
  reference manual clearly requires all C++ programs to solve the halting
  problem -- that does NOT mean this was an intentional part of the semantics
  of C++, it is just a perfectly understandable oversight that comes from not
  having looked carefully enough at the issues of elaboration order.

  However, there is nothing to preclude an Ada compiler providing this
  interesting model of computation as an extension. Clearly it can't be
  the only model, or the model under which you expect to validate, since it
  is not part of the standard. However, there is nothing to stop you
  implementing such an extension. Furthermore, you don't have to stand on
  your head to justify this as not being an extension. The requirement of
  the standard and validation is that you have a mode where you exactly support
  the standard without intentional extensions. Of course you have have an
  integrated system in which there are optional configurations that proivide
  extensions (even the checks off switch of almost all Ada compilers is
  in this category, since it clearly causes the Ada texts compile to
  behave differently from what's in the RM).

  Actually let's persue the checks off switch. Some Ada implementors have felt
  nervous about this, and felt that they must justify it by talking about
  "as if" models in which the sources are modified by insertion of pragmas.
  But that kind of subterfuge is silly. It serves no purpose, and furthermore,
  once you allow this kind of implicit virtual preprocessing, you can obviously
  implement any extensions you like -- Ada is Turing complete after all.

  Instead the honest approach is to define this switch as resulting in
  processing that is modified from what is in the RM in a well defined
  manner."

see:
http://groups.google.com/groups?q=%22virtual+preprocessing%22&hl=en&lr=&ie=UTF-8&selm=2kg09a%24f19%40schonberg.cs.nyu.edu&rnum=1


> if the word source-representation-method gets you so hot under the collar,
> please rename it in your mind as
> extension-which-is-easily-transformed-into-standard-Ada-with-tool-provided
> I could not care less which of these two terms anyone prefers to use, but
> the distinction is an important one.

Since you are the one proposing the extension to your product, what matters
is how you represent it, not how I might "rename it in my mind".

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

From: Robert Dewar
Sent: Monday, January 19, 2003  3:25 PM

<<Since you are the one proposing the extension to your product, what matters
is how you represent it, not how I might "rename it in my mind".>>

So, since you have not the *foggiest* idea exactly what we will implement
or how we should present it, may I suggest terminating your tirade until
you know the answer to these two questions. And for me, that's the end of
the thread (I just killed it :-)

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

From: Alexandre Kopilovitch
Sent: Monday, January 20, 2003  1:04 PM

Both Robert's position and Dan's position represent different sides of truth,
and as such, these positions aren't fundamentally antagonistic.

>if the word source-representation-method gets you so hot under the collar,
>please rename it in your mind as
>extension-which-is-easily-transformed-into-standard-Ada-with-tool-provided

I propose the term "pseudo-extension" for such cases.

>I could not care less which of these two terms anyone prefers to use, but
>the distinction is an important one.

I believe the term "pseudo-extension" may satisfy Dan, as it points at "extension",
and at the same time Robert may tolerate it, because it clearly says that there
is no actual extension. And this term may be introduced in the Standard, and
explained there, basically using Robert's rule:

>b) if you regard something as a source transformation, then clearly you
>provide the utility program that does this simple transformation...

with a little addition: that utility program must be not only "provided", but
also strictly documented in all its details.

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

From: Robert Dewar
Sent: Monday, January 19, 2003  3:27 PM

<<I believe the term "pseudo-extension" may satisfy Dan, as it points at
"extensio n", and at the same time Robert may tolerate it, because it clearly
says that there is no actual extension. And this term may be introduced in the
Standard, and explained there, basically using Robert's rule:>>

Well I really don't care what it is called, it is fine to call it an
extension as far as I am concerned. I am not at all allergic to extensions
(and neither is the ARG, they have been in that business for a while :-)

The important point is that it is a completely different kind of extension
from "WITH TYPE", since there exists both a simple method for recreating
the "standard" source representation (standard in quotes, since the
standard does not include details on source representation), and a tool
for implementing this simple method. That's what's important from a users
point of view.

Another interesting way of viewing things is that if you have a .adp
file around (containing the private part), then the program is not in
Ada at all, but in Ada+ which has this feature. That way you don't need
a special switch (after all the gcc compiler viewed as a gnat compiler
will also compiler C, you just have to use a .c extension for the file
name. Perhaps this will also make Dan fulminate :-)

Other approaches are to only go look for the .adp file if the last line
in the file is a formatted comment that says -- private part in adp file
or some such (that's the way I really regard the "private is separate"
line, but I don't mind making that a comment if someone really thinks
it makes a big difference, of course if the only someone in the world
is Dan Eilers, last time I looked he was not one of our customers, so
I am not sure how much say he has :-)

Actually from our customers point of view this is a tempest in a teapot.
This will not cause them any portability problems. What does and will
cause portability problems is implementation dependent pragmas and
attributes, which is why I think
pragma Restrictions (No_Implementation_Pragmas) is so important (I
seem to remember that this got pseudo-standardized, if so good, if
not bad :-)

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

From: Dan Eilers
Sent: Monday, January 20, 2003  7:02 PM


Alexander Kopilovitch wrote:
> I believe the term "pseudo-extension" may satisfy Dan, as it points
> at "extension", and at the same time Robert may tolerate it, because it
> clearly says that there is no actual extension. And this term may be
> introduced in the Standard, and explained there, basically using Robert's
> rule:
>
> >b) if you regard something as a source transformation, then clearly you
> >provide the utility program that does this simple transformation...
>
> with a little addition: that utility program must be not only "provided",
> but also strictly documented in all its details.

Unfortunately, this suggestion doesn't work.  As Robert pointed out
in the c.l.a. article I quoted, Ada is a Turing complete language,
so if you let the camel's nose into the tent in the form of what
seem to be "simple" extensions defined as a virtual preprocessor,
you have effectively allowed any conceivable syntactic or semantic
extension.

Robert has also confirmed that Ada can't require an implementer to
widely distribute the utility program that does the simple transformation,
so rule (b) is of little practical benefit.

Robert has also confirmed in the c.l.a. article I quoted that there
is no point in trying to call an extension a non-extension, since
there is nothing wrong with extensions per se, provided of course
that you have a way of turning them off in standard mode, which is
not the least bit an onerous requirement.

An implementor can of course categorize his extensions as simple or
complex, or however he wishes to categorize them, just so long as he
doesn't call something a non-extension that is in all respects
indistinguishable from an extension.

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

From: Robert Dewar
Sent: Monday, January 19, 2003  11:08 PM

Actually Dan, an implementor can do whatever they like, the standard
does not prevent anything. Sorry to disillusion you :-)

As for extensions not called extensions, in practice pragmas and
attributes allow arbitrarily radical extensions that are not
technically extensions (you may recall my pragma Fortran example
from the DR days), and for sure 'Unrestricted_Access in GNAT is
a (significant) language extension for example, even though the RM
says that it is not an extension.

As always it is the market place that determines what is and what
is not reasonable. After all there are a couple of companies around
selling
"Ada" compilers that do not even pretend to be 100% conformant with
the standard :-) That's perfectly permissible as far as I am concerned,
and if some segment of the market place finds these products useful
that's OK by me.

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

From: Dan Eilers
Sent: Tuesday, January 21, 2003  3:22 AM

Don't worry, I am not the least bit disillusioned.  I'm fully capable
of distinguishing between areas the language nails down tightly,
and those where certain implementation freedoms are allowed.

You have provided quite a litany of implementation freedoms:
pragmas, attributes, character encodings, source-file naming rules,
UNIVAC text-file formats, source management systems, etc.  However,
none of those freedoms have the slightest bearing on the fact that
Ada's syntax is unambiguously defined, and intentionally does not
allow extensions in standard mode.

My opinion of any proposed syntax extension in standard mode is
fully consistent with that of your alter ego, who taught that:

Just because you discover some way of inventively reading the RM
to allow an implementation to do something amazing, it does not mean
that this reading is consistent with Ada.  If such a thing is needed,
nothing precludes an Ada compiler from providing it as an extension.
But clearly it can't be the the only model, or the model under which
you expect to validate, since it is not part of the standard.

Furthermore, you don't have to stand on your head to justify such a
thing as not being an extension.  That kind of subterfuge is silly.
It serves no purpose, and furthermore, once you allow this kind of
implicit virtual preprocessing, you can obviously implement any
extensions you like -- Ada is Turing complete after all.  Instead the
honest approach is to define this switch as resulting in processing
that is modified from what is in the RM in a well defined manner.
(condensed from your previously referenced c.l.a. posting)

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


Questions? Ask the ACAA Technical Agent