TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date:
Wed, 25 Nov 1998 10:08:05 -0600
Reply-To:
Samuel Mize <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
<[log in to unmask]> from "Tucker Taft" at Nov 25, 98 10:13:26 am
Content-Type:
text/plain; charset=US-ASCII
From:
Samuel Mize <[log in to unmask]>
Parts/Attachments:
text/plain (55 lines)
Tucker Taft wrote:

> In general, I find the heavy use of pragmas unpleasant.

I agree with that as an aesthetic judgement.

However, part of the promise of the ASIS interface -- as I understand
it -- is that it will let us do more automated semantic analysis of
code.  I see three general ways to indicate which semantic constraints
should be checked for a given chunk of code:

- mandate that it should always be true

- use a non-semantic marker, like a file extension, comment flag,
  or type name postfix

- use a pragma to indicate that a given semantic constraint should
  apply to a given chunk (package, subprogram, type, or whatever)

So I expect to see new pragmas that define various semantic
constraints, and ASIS tools that will check them, and that this
overall will move more error-detection and correction into
earlier phases of development.

I am assuming that an ASIS-compliant compiler will indicate
pragmas via the ASIS interface.  I have not yet learned a lot about
ASIS.  (Can someone recommend a good tutorial?  If it isn't
handy, don't bother -- I'll track it down through adahome later.)


> Ada ... has more in common with Common Lisp Object System
> and Haskell, where there can be multiple "controlling" operands, and they are
> all "inside" the parentheses.  This has a number of advantages.

I agree.  I would consider the C++ style to be a less-powerful
subset of the Ada approach.

Some folks wants to use a subset of the base capability of the
language, like using "positive" instead of "integer."

I think it's great that they can do so, and have the flexibility to
step out of those limits when it makes sense.

I think it may help them to understand Ada's potential to see a
way to limit Ada usage down to their familiar idiom, and I think
it may be an epiphany for them to realize that it *would* require
limiting Ada to match C++.

Best,
Sam Mize

--
Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

ATOM RSS1 RSS2