How does your language grow? (Follow-up on comments on ADM Tuttle comments) 
Author Message
 How does your language grow? (Follow-up on comments on ADM Tuttle comments)


...

Quote:
> The extent of the misinformation about C++, for example, has now
> infiltrated AT&T's C courses where it is now taught that C++ IS a
> compiler (it's a precompiler that churns out C code with no regard
> to the C compiler backend) and that C++ makes faster running code
> than C (it does not because anything done in C++ can be programmed
> to run faster in C).

...

C++ started as a preprocessor for C code.  It allowed new ideas to
evolve and be tested, as C++ grew, without requiring major
reconstruction of parts of the language processor for each change.
Certain inefficiencies exist in this type of language processing,
although (as I've taught in compiler construction courses) it's a
convenient way to build new compilers.  Someone wanting to improve the
efficiency of the compiling process (usually for commercial advantage)
will combine the two language processors into one, a true C++ compiler.
I've been out of the compiler business for a few years, but I believe
this has been done.

This approach has been very common in compilers and language processors
over the years.  We try new ideas and features with preprocessors.
When the ideas gel and are accepted into the language, people start
including them in compilers.  fortran started out as a fixed format
language (with boundaries based on the character and word size of the
IBM 704/709 and successors).  When on-line Teletype preparation of
programs came along, preprocessors translated free format input to the
standard layout.

I recall controversy over one such preprocessor that I described in a
paper at the 1970 ACM FORTRAN Forum.  (The work was part of Purdue's
PTSS effort, extending the PUFFT Fortran system with a terminal front
end.)  One question seemed to be whether a language that allowed
free-format input could (or should) be called FORTRAN.  Well, a form
similar to what I described is now in the standard for what is now
called Fortran.

A few years later, Kernighan and Plauger's RATFOR introduced C-like
statement concepts as an extension for FORTRAN.  Features from that and
similar language efforts were accepted as the way the language should
evolve and are now in the Fortran standard.  On the other hand, some
features of early FORTRANs (for example, the FREQUENCY and READ INPUT
TAPE statements) were recognized as obsolete and have disappeared.

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.

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.

                Michael Shapiro

(These views are my opinion.  My employer may or may not agree.)



Mon, 01 Jan 1996 00:57:59 GMT  
 How does your language grow? (Follow-up on comments on ADM Tuttle comments)

[stuff deleted]

Quote:

>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.

Quote:

>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

"Pork is what those other guys get from the Government."
------------------------------------------------------------------------



Wed, 03 Jan 1996 01:34:41 GMT  
 How does your language grow? (Follow-up on comments on ADM Tuttle comments)

  > 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...



Sat, 06 Jan 1996 00:49:11 GMT  
 How does your language grow? (Follow-up on comments on ADM Tuttle comments)

Quote:
>                                        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



Sat, 06 Jan 1996 21:59:04 GMT  
 How does your language grow? (Follow-up on comments on ADM Tuttle comments)

  > 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...



Sun, 07 Jan 1996 04:01:53 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Ralph Crafts comments about Adm. Tuttle

2. comments to the following Fortran programmes needed

3. Counting commented lines (full-line comments only)

4. comments on comments

5. meta-comments for comments on proposals

6. comments on comments

7. comments on comments

8. Single Pound # comments versus Double Pound ## comments

9. How Google Grows...and Grows...and Grows

10. Suggested language change wrt end comments for class/routine definitions

11. Comments on proposed Eiffel language changes

12. Requesting comments for forth-like macro language

 

 
Powered by phpBB® Forum Software