Re: How does your language grow? (Follow-up on comments on ADM Tuttle

Re: How does your language grow? (Follow-up on comments on ADM Tuttle

[Michael Feldman]

In article <9307141657.AA27874@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael
 D Shapiro) writes:
>
[stuff deleted]

>
>Perhaps one of Ada's acceptance problems is that experimentation
>allowing expansion and contraction of the language have been
>discouraged.  This mode has given gradual growth of most other
>programming languages, supporting new programming paradigms as they
>arise.  Periodic standardization describes a consensus of the
>then-current state of the language.  The new features allow the
>languages to increase their level of helping programmers in writing
>programs.

I agree with your second sentence, but find your first sentence
unsupportable. The _validation_ process has certainly emphasized the
notion that subsets and supersets create dialects and therefore Babel.
But that's only the _validation_ process. NOTHING has prevented the
development of experimental - unvalidated - versions of Ada. 

One could argue that the "if it ain't validated it ain't Ada" policy of
the early years inhibited this kind of experimentation, but the policy
was changed de facto as early as (roughly) 1986, and _officially_
in 1988, when the Ada trademark was allowed to lapse. 1988, guys.
That's a long time. Anyone wishing to develop extended Ada's (indeed
contracted ones, too, but that's not where the action is), was free not
only to do so but also to call it Ada. 

Even if such a system could not legally be validated, it could certainly
have been used for any project that wasn't production DoD work. Let's
debunk this myth once and for all. I think we can forgive DoD for insisting
that compilers used for its serious projects be validated and therefore not
support dialects - after all, that's what eliminating the language Babel
is all about. But that never stood in the way of the rest of us.

I've promised not to contribute to flame wars, so I'll not engage in
speculation about why this experimentation didn't really happen. But
facts are facts - I NEVER heard anyone discourage experimentation, 
except when it came to serious compilers for serious DoD projects. 
University or other lab projects could darn well have done the kind
of stuff you mention. I'll leave it to the flamers to fight endlessly
about _why_ they didn't do it, but this does _not_ mean they _couldn't_.
I've hung around this business for ten years; I think I have my facts
straight.
>
>Ada has had some preprocessor work, but for the most part changes have
>had to wait for the next giant step, Ada 9X.  While large-scale program
>managers may get warm feelings from this approach, many language
>experimenters (who might significantly improve the definition) become
>uncomfortable waiting for the next orders.  They choose to ignore Ada.

Phooey. Why should "the rest of us" in language experimentation stand
around waiting for orders? Nobody stopped us from moving ahead. Nobody.

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-5296 (fax) - mfeldman@seas.gwu.edu (Internet)
"Pork is what those other guys get from the Government."
------------------------------------------------------------------------

Re: How does your language grow? (Follow-up on comments on ADM Tuttle

[Robert I. Eachus]

In article <1993Jul16.173441.22720@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:

  > That's a long time. Anyone wishing to develop extended Ada's (indeed
  > contracted ones, too, but that's not where the action is), was free not
  > only to do so but also to call it Ada. 

     I usually don't disagree with Mike, but this is more of a reminder
of things he may not have thought of...

     First of all, the original policy was, no subsets, no
UNAUTHORIZED supersets, but the expected authorized supersets for
things like database, graphics, etc. never materialized.  This was
mostly due to a strong preference in the Ada community for "legal Ada"
package interfaces instead of preprocessors.  Much more surprising has
been the almost total lack of implementation defined pragmas and
attributes outside of VAX Ada.

  > Even if such a system could not legally be validated, it could
  > certainly have been used for any project that wasn't production
  > DoD work. Let's debunk this myth once and for all. I think we can
  > forgive DoD for insisting that compilers used for its serious
  > projects be validated and therefore not support dialects - after
  > all, that's what eliminating the language Babel is all about. But
  > that never stood in the way of the rest of us.

    And doesn't stand in the way of the DoD using, say, DRAGOON on a
project for which it makes sense.  It just requires a waiver (or an
exception on Air Force projects if you use a preprocessor which
generates Ada).

  > I've promised not to contribute to flame wars, so I'll not engage
  > in speculation about why this experimentation didn't really
  > happen. But facts are facts - I NEVER heard anyone discourage
  > experimentation, except when it came to serious compilers for
  > serious DoD projects.  University or other lab projects could darn
  > well have done the kind of stuff you mention. I'll leave it to the
  > flamers to fight endlessly about _why_ they didn't do it, but this
  > does _not_ mean they _couldn't_.  I've hung around this business
  > for ten years; I think I have my facts straight.

    There has been a significant amount of experimentation, a lot of
it funded by the DoD!  Successful experiments have, for the most part,
fallen in three categories:

    1)  Object-oriented programming extensions.
    2)  Distribution of Ada environments.
    3)  Annotations for design purposes.

    In addition there are the user/implementor teams for Ada 9X.  Note
that the first two areas made it into Ada 9X, and the concensus in the
design language area has been that the annotations should be
structured comments.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: How does your language grow? (Follow-up on comments on ADM Tuttle

[Jonathan Schilling]

In article <EACHUS.93Jul19114911@spectre.mitre.org> eachus@spectre.mitre.org (R
obert I. Eachus) writes:
>                                        Much more surprising has
>been the almost total lack of implementation defined pragmas and
>attributes outside of VAX Ada.

How do you define "almost total lack"?  Just to pick two examples,
the Sun Ada native compiler for SPARC has by my count 16 implementation-
defined pragmas and three implementation-defined attributes, while the
DDC-I cross compiler for MIL-STD-1750A has 13 implementation-defined
pragmas and one implementation-defined attribute.  (By comparison,
DEC Ada has 26 implementation-defined pragmas and five implementation-
defined attributes, although the pragma total is somewhat inflated by 
having different EXPORT and IMPORT pragmas for different language entities,
rather than "overloading" them.) 

Are there specific pragma- or attribute-based capabilities that you 
expected Ada compilers to have, that have never materialised?

-- 
Jonathan Schilling
DDC-I, Inc.
uunet!ddciiny!jls

Re: How does your language grow? (Follow-up on comments on ADM Tuttle

[Robert I. Eachus]

In article <CAGuuH.A4v@ddciiny.UUCP> jls@ddciiny.UUCP (Jonathan Schilling) writ
es:

  > How do you define "almost total lack"?  Just to pick two examples,
  > the Sun Ada native compiler for SPARC has by my count 16
  > implementation- defined pragmas and three implementation-defined
  > attributes...

    SunAda 1.1 has by my count seven optimizer directives with no
expected semantic effect:

    pragma INITIALIZE     pragma INLINE_ONLY    pragma NO_IMAGE
    pragma NON_REENTRANT  pragma OPTIMIZE_CODE  pragma PASSIVE
    pragma SHARE_CODE

pragmas conserned with linking to other languages or the run-time:

    pragma BUILT_IN       pragma EXTERNAL     pragma EXTRANAL_NAME
    pragma INTERFACE_NAME pragma LINK_WITH    pragma NOT_ELABOATED
    pragma RTS_INTERFACE  

and a pragma and an attribute for code inserts:

    pragma IMPLICIT_CODE  and 'REF

which leaves pragma VOLITILE and 'TASK_ID as the only semantically
significant extensions which can appear as part of "pure" Ada code.

  > Are there specific pragma- or attribute-based capabilities that
  > you expected Ada compilers to have, that have never materialised?

    Yes.  Attributes like 'READ and 'WRITE (or whatever they are now)
in Ada 9X, attributes and pragma to support garbage collection,
additional attributes for record components, and additional record and
array layout pragmas, etc.  But all that most compiler vendors supply
are command line argument and linker directive equivalents, and the
few things absolutely needed--like pragma BUILT_IN--for building
compilers.

    As I said, I don't think this reflects a failure on the part of
the compiler vendors.  It is just a recognition of the market reality
that most Ada programmers want to, as far as possible, write truely
portable code, so package interfaces are more acceptable than
compiler extensions.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...