comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: How does your language grow? (Follow-up on comments on ADM Tuttle
Date: 20 Jul 93 20:01:53 GMT	[thread overview]
Message-ID: <EACHUS.93Jul20150153@spectre.mitre.org> (raw)

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

             reply	other threads:[~1993-07-20 20:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-07-20 20:01 Robert I. Eachus [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-07-20 13:59 How does your language grow? (Follow-up on comments on ADM Tuttle Jonathan Schilling
1993-07-19 16:49 Robert I. Eachus
1993-07-16 17:34 Michael Feldman
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox