Top 10 Language Constructs (Ada)

Top 10 Language Constructs (Ada)

[Bruno Gustavs]

What do you think are the top ten language constructs in Ada?
Please don't answer in terms of OO concepts, but try to restrict
yourself to those statements you really use to cope with your
daily work.

Curious why I'm asking this question? In spite of all requirements
engineering effort we know exactly *how* to solve problems
with computer languages but know fairly, *what* we're doing
during this process.

Regards
Bruno Gustavs

Re: Top 10 Language Constructs (Ada)

[David Kristola]

On Fri, 14 Jul 2000 1:40:45 -0700, Bruno Gustavs wrote
(in message <8kmjja$l5h$1@pollux.ip-plus.net>):

> What do you think are the top ten language constructs in Ada?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.
> 
> Curious why I'm asking this question? In spite of all requirements
> engineering effort we know exactly *how* to solve problems
> with computer languages but know fairly, *what* we're doing
> during this process.
> 
> Regards
> Bruno Gustavs
> 
> 

(It is almost light out, and i am avoiding going to sleep for
reasons well beyond the scope of this news group, so please
be advised that my answer should be taken with a grain of
salt.  ;-)

I'm not sure what you mean by language constructs, and even
if i knew what you meant, i'm not sure there is any way to
prioritize them so that i could give you the top ten.

If this fits the description of a language construct...
Currently, i am fascinated by fixed point types (they are
really very interesting) and reference counting smart
pointers (very powerful).  I have found that bit buckets
can decouple otherwise hoplessly intertwined systems.

I know what i am doing during the process.  I am usually
consuming a beverage (often with caffeine).  Sometimes
i have music playing (but i rarely listen to the music).
I am constructing virtual machines that manupulate data
across time and space (memory or communications hardware).
I am weighing alternatives, considering threads of
executions, and contemplating puzzles with complex
interlocking peices.  I am trying to reduce that complexity
to the lowest level, to what is only inherent in the
problem domain.  Sometimes i add complexity, turn the
problem over in my mind, and see an even simpler way
to address it (thus removing more complexity then was
just added).

Sometimes, i even stop and wonder why they pay me so well
to do a job that is so fun.  Then i remember the impossible
schedules, the endless meetings, the ever changing
requirements, and the idiotic constraints and wonder why i
work there when they are paying me so little.

--djk

Re: Top 10 Language Constructs (Ada)

[Samuel T. Harris]

Bruno Gustavs wrote:
> 
> What do you think are the top ten language constructs in Ada?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.
> 
> Curious why I'm asking this question? In spite of all requirements
> engineering effort we know exactly *how* to solve problems
> with computer languages but know fairly, *what* we're doing
> during this process.
> 
> Regards
> Bruno Gustavs

My number one is block statements.

Being able to arbitrarily introduce a new declarative region
has been invaluable to me in avoiding numerous kinds of coding
errors. Having to place all working variables within the subprogram
declarative region can cause many kinds of problems. The more
complex the subprogram the greater the need. There are also
many situations where one simply does not have enough information
to satify a variable declaration (e.g. string constraints)
until later in the algorithm.

The localization of the scope of temporary variables is a very
attractive style of coding for me. The different logic paths
within the algorithm need only concern themselves with just
the variables each needs. Less clutter, less fuss, less muss!

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Top 10 Language Constructs (Ada)

[Simon Wright]

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:

> My number one is block statements.

Which of course have been available since the year dot .. for example,
CORAL 66

  'begin'
     'integer' x;
     x := 2;
     y := x;  "y is external to the block .."
  'end'

or C

  {
    int x;
    x = 2;
    y = x;
  }

Personally I find myself using the C version very frequently, no doubt
if I still had to write CORAL I would do so there too .. spare me,
spare me

Re: Top 10 Language Constructs (Ada)

[Nick Keighley]

In article <x7vitu7b9cw.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:
>
> > My number one is block statements.
>
> Which of course have been available since the year dot .. for example,
> CORAL 66

or Algol-60 (even Algol-58?)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Top 10 Language Constructs (Ada)

[Andrew Hately]

Bruno Gustavs wrote:
> 
> What do you think are the top ten language constructs in Ada?

Previously I used c and c++. I have also worked in fortran and basic
(many) as well as tinkering with bcpl and various assembly languages.
For me:

1 packages
 - separate spec and body
   (I laugh at c++ with its puny class. 
    "Hey, object, I can see your inner workings")
 - decent name space management
 - its just the natural way to do it


2 ability to declare procedures other than at the global level
 (vs c where everything is global or global with a hidden name)


3 enumerated types and case statements with no "when others"


4 types
 - also arrays with known size
   (not just pointers)
 - also run time checking


5 agregate assignement


6 named parameters in procedure/function calls and 
  named values in agregates


7 the compiler resolves calling, not the linker
 (bonus: overloading by function return type)


8 generics
 (vs c macros, especially when debugging)


9 the compiler can work out what to compile and in what order


10 a syntax in which common typing errors do not yield other, 
   unexpected but syntactically valid programs



Andrew

Re: Top 10 Language Constructs (Ada)

[David Botton]

1. declare blocks = Usage of the stack over heap e.g. usable garbage
collection and efficient strings
2. human compatible language = No problems worrying about did I type = or
==, etc.
3. tasking = Language constructs instead of function calls, etc.
4. bounds checking = I've spent tons of time tracking down bounds issues in
distributed systems
5. strong typing = Errors caught by the compiler before they crash my
applications
6. 'Image = Easy to get textual representaions for debugging, asserts, etc.
7. Slices = The way array access should aways be
8. declaring types at run time = Make strong typing work for you
9. enumerations as array index = Very cool stuff can be done with this
10 representational clauses = no playing with bits

----- Original Message -----
From: "Bruno Gustavs" <GustavsB@ch.sibt.com>

> What do you think are the top ten language constructs in Ada?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.

Re: Top 10 Language Constructs (Ada)

[Marc A. Criley]

Bruno Gustavs wrote:
> 
> What do you think are the top ten language constructs in Ada?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.
> 
> Curious why I'm asking this question? In spite of all requirements
> engineering effort we know exactly *how* to solve problems
> with computer languages but know fairly, *what* we're doing
> during this process.
> 
> Regards
> Bruno Gustavs

I don't find looking at Ada in terms of "Top 10 Constructs" especially
enlightening.  (I'm not criticizing that approach, it just isn't in sync with my
point of view :-)

The critical foundation of the Ada programming language is its "type model". (In
claiming this I want to credit Doug Bryan for triggering this insight for me at
an Ada conference seminar about a dozen years ago.)

Any decent programming language has to have some programming paradigm that it
seeks to embody with syntax and semantics.  This paradigm can be obvious within
the language or somewhat obscured, depending on how well it is defined and
captured in the programming constructs.

- Smalltalk's programming paradigm is clearly inheritance
- A variety of languages are oriented around logical expressions (Lisp, Prolog)
- Java's paradigm appears to focus on the "interface" concept, though that's not
particularly obvious at first glance, given as its technical hype is typically
"C++ with garbage collection"
- C manages memory contents and addresses (it's effectively a portable assembly
language, and I don't intend that in the perjorative sense).

For COBOL, Fortran, Eiffel, etc., I'll leave it for others with hands on
experience to characterize those.


Ada, then, is built around its type model.  In a strongly typed language, a
startingly signifiant amount of information can be embedded within the code
through the intelligent use of types.  Most of the technical advocacy for Ada
that mentions its strong typing aspect usually centers around range checking,
and neglects almost everything else strong typing provides.

Experienced Ada programmers almost take for granted attributes like 'first,
'last, 'pred, 'succ, 'image, 'value, 'length, 'range, and the many others. 
Well, without Ada's typing model, you get at best a subset of these, and likely
only a handful.

Consider the parameter of this procedure specification:

  procedure Process_Data(Data : in out A_Data_Array_Type);

Knowing that Data is an array, consider all the attributes available to extract
all the information possible about that Data parameter given only what's
provided in the declaration you see.

Contrast that with a corresponding C declaration:

   void processData(aDataArrayType *data);

What can you determine about this *data parameter?


When tries to determine what paradigm Ada's syntax and semantics are trying to
embody, the majority of it centers around the type model.

- Concurrency is provided as protected types, task types, or tasks (which is
really a degenerate task type)
- Generics provide static polymorphism
- Tagged types provide inheritance and dynamic polymorphism
- Dynamic invocation is implemented by "access subprograms", i.e., "subprogram
types"

Certainly other languages employ the same type-centric approach for their
corresponding constructs (and of course inheritance is pretty much type-centric
by definition), but none to the same unified level of capability and consistency
as Ada.

(In fact, the only significant construct that could have been type-centric, but
wasn't, was exceptions.  And even those have started sliding that way in Ada 95
with its introduction of "exception objects".)

By exploiting Ada's type model, programmers embed an incredible amount of
supporting information within their software...and can then extract it and put
it to work through the use of Ada's attributes.

This, to my mind, is the most powerful and fundamental construct of Ada: the
type model that underlies the language and serves as a repository of information
for aiding the production, quality, and reliability of software.

Marc A. Criley

Re: Top 10 Language Constructs (Ada)

[David Botton]

Dude.... (Americanism for wow, I never thought of it exactly that way)

Are there any articles that elaborate on this (if not, would you consider
one for AdaPower).

Thinking about things in that way gives me a new found respect for Ada's use
of type extensions to deliver OO inheritance, a better angle on how to best
teach Ada standing on one foot and express why use Ada, and why C++ calling
itself strongly typed is a joke and a half.

David Botton

"Marc A. Criley" <mcriley@icdc.com> wrote in message
news:3970F56F.F3A70FAD@icdc.com...
> The critical foundation of the Ada programming language is its "type
model". (In
> claiming this I want to credit Doug Bryan for triggering this insight for
me at
> an Ada conference seminar about a dozen years ago.)

Re: Top 10 Language Constructs (Ada)

[David Kristola]

On Sat, 15 Jul 2000 16:36:15 -0700, Marc A. Criley wrote
(in message <3970F56F.F3A70FAD@icdc.com>):

> The critical foundation of the Ada programming language is its "type model". 
> (In claiming this I want to credit Doug Bryan for triggering this insight 
> for me at an Ada conference seminar about a dozen years ago.)

I'd like to second David Botton's "Dude!".

Besides being strongly typed, Ada has a very robust type model.  Just
the ability to create subtypes with limited ranges seems to escape many
popular languages.  Add to that the long list of types, and you have a
very powerful means of expressing information.

The other day, i came across a message field in an interface document
that i was coding against.  The field is 16 bits, with the high order
bit being a sign bit, the next highest order bit has the value 2^1,
the third highest bit is 2^0, and so on down to the low order bit,
which is 2^(-13).  The note said that the field is 2's complement.
No problem....

   type Plasma_Volts_Type is delta 0.00012207 range -4.0 .. 3.99987793;
   for Plasma_Volts_Type'Size use 16;

I love fixed point types!  I happen to know that the software on the
other side of that interface is in C.  I wonder how they deal with
that field.

Another important feature of Ada types that people seem to miss:
a type does not have to have a size.  Take boolean for example.  Is
it 8 bits or 1?  That all depends on where you put it.  I could pack
8 boolean flags into a byte, or i could take up that whole byte with
just 1 boolean.  My needs dictate how i use the type.

A word of caution.  Types are the foundation of many programs.
Poorly laid out types can cause all kinds of problems.  I've seen
a case where a bad type choice at a fundamental level caused type
converts to be needed in hundreds of places throughout the code.


-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Top 10 Language Constructs (Ada)

[Bill Brennan]

David Kristola wrote:

> The other day, i came across a message field in an interface document
> that i was coding against.  The field is 16 bits, with the high order
> bit being a sign bit, the next highest order bit has the value 2^1,
> the third highest bit is 2^0, and so on down to the low order bit,
> which is 2^(-13).  The note said that the field is 2's complement.
> No problem....
> 
>    type Plasma_Volts_Type is delta 0.00012207 range -4.0 .. 3.99987793;
>    for Plasma_Volts_Type'Size use 16;

Actually, this doesn't compile in GNAT, I presume because it rounds
Plasma_Volts_Type'Last to something which won't fit in 16 bits.

Besides the fact that this type definition isn't portable (for GNAT
anyway), 
it doesn't really reflect what you're trying to say.  Without your
description,
I would have no idea that 0.00012207 ~= 2^(-13) or that 
3.99987793 ~= 4 - 2^(-13).

Personally, I think it's clearer to state it as

   type Plasma_Volts_Type is
      delta  2#000.0_0000_0000_0001#     --  approx 0.00012207
      range -2#100.0_0000_0000_0000# ..  --        -4
             2#011.1_1111_1111_1111#;    --  approx 3.99987793

   for Plasma_Volts_Type'Size use 16;
 
which will compile, and more accurately expresses what is intended.

This ability to express literals fairly transparently using any
numerical
base of convenience is yet another reason to value Ada.  (though I'm not
sure it's important enough to go on my top 10 list.)

-- Bill Brennan

Re: Top 10 Language Constructs (Ada)

[Dr. Joachim Schr�er]

Bill Brennan <william.c.brennan@lmco.com> schrieb in im Newsbeitrag:
39751555.4E40A4A7@lmco.com...
> David Kristola wrote:
>
> > The other day, i came across a message field in an interface document
> > that i was coding against.  The field is 16 bits, with the high order
> > bit being a sign bit, the next highest order bit has the value 2^1,
> > the third highest bit is 2^0, and so on down to the low order bit,
> > which is 2^(-13).  The note said that the field is 2's complement.
> > No problem....
> >
> >    type Plasma_Volts_Type is delta 0.00012207 range -4.0 .. 3.99987793;
> >    for Plasma_Volts_Type'Size use 16;
>
> Actually, this doesn't compile in GNAT, I presume because it rounds
> Plasma_Volts_Type'Last to something which won't fit in 16 bits.
>
> Besides the fact that this type definition isn't portable (for GNAT
> anyway),
> it doesn't really reflect what you're trying to say.  Without your
> description,
> I would have no idea that 0.00012207 ~= 2^(-13) or that
> 3.99987793 ~= 4 - 2^(-13).
>
> Personally, I think it's clearer to state it as
>
>    type Plasma_Volts_Type is
>       delta  2#000.0_0000_0000_0001#     --  approx 0.00012207
>       range -2#100.0_0000_0000_0000# ..  --        -4
>              2#011.1_1111_1111_1111#;    --  approx 3.99987793
>
>    for Plasma_Volts_Type'Size use 16;
>
> which will compile, and more accurately expresses what is intended.
>
> This ability to express literals fairly transparently using any
> numerical
> base of convenience is yet another reason to value Ada.  (though I'm not
> sure it's important enough to go on my top 10 list.)
>
> -- Bill Brennan

What about this version:

type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 - 2.0**(-13);
for Plasma_Volts_Type'Size use 16;

And if the required range and the 'delta allow 'delta < 'small you have to
write a rep-clause for 'small like:

for Plasma_Volts_Type'Small use 2.0**(-13);

Joachim Schroeer

Re: Top 10 Language Constructs (Ada)

[Bill Brennan]

"Dr. Joachim Schr�er" wrote:
> 
> Bill Brennan <william.c.brennan@lmco.com> schrieb in im Newsbeitrag:
> >    type Plasma_Volts_Type is
> >       delta  2#000.0_0000_0000_0001#     --  approx 0.00012207
> >       range -2#100.0_0000_0000_0000# ..  --        -4
> >              2#011.1_1111_1111_1111#;    --  approx 3.99987793
> >
> >    for Plasma_Volts_Type'Size use 16;
> >
> 
> What about this version:
> 
> type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 - 2.0**(-13);
> for Plasma_Volts_Type'Size use 16;

While your version is more concise and arguably easier to read
(all right, it *is* easier to read ;-)), I chose my representation,
long-winded as it is, to demonstrate that the 'First and 'Last were
chosen 
to be the most extreme values in the possible range of this 16-bit
representation.  
In fact, I had to prove this to myself on paper first, by mapping out
the bits,
and just decided to transfer my notes to Ada.  If this information isn't
particularly useful to demonstrate in the code, then the concise version 
wins for sure.

Isn't it nice that we have the choice, and that both options convey the
information with slightly differing emphasies?  
(Are there other interesting representations?)

-- Bill Brennan

Re: Top 10 Language Constructs (Ada)

[Scott Ingram`]

Bill Brennan wrote:

> "Dr. Joachim Schr�er" wrote:
> >
> > Bill Brennan <william.c.brennan@lmco.com> schrieb in im Newsbeitrag:
> > >    type Plasma_Volts_Type is
> > >       delta  2#000.0_0000_0000_0001#     --  approx 0.00012207
> > >       range -2#100.0_0000_0000_0000# ..  --        -4
> > >              2#011.1_1111_1111_1111#;    --  approx 3.99987793
> > >
> > >    for Plasma_Volts_Type'Size use 16;
> > >
> >
> > What about this version:
> >
> > type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 - 2.0**(-13);
> > for Plasma_Volts_Type'Size use 16;
>
> While your version is more concise and arguably easier to read
> (all right, it *is* easier to read ;-)), I chose my representation,
> long-winded as it is, to demonstrate that the 'First and 'Last were
> chosen
> to be the most extreme values in the possible range of this 16-bit
> representation.
> In fact, I had to prove this to myself on paper first, by mapping out
> the bits,
> and just decided to transfer my notes to Ada.  If this information isn't
> particularly useful to demonstrate in the code, then the concise version
> wins for sure.
>
> Isn't it nice that we have the choice, and that both options convey the
> information with slightly differing emphasies?
> (Are there other interesting representations?)
>
> -- Bill Brennan

I found all three eminently readable...after looking at C and Perl all
day almost ANY Ada spangs into my consciouness without effort!

And having the options to write it in a way that makes sense to the
author while typically being readable...  As the only Ada user in my
shop, I find that my programmers have no trouble reading my proggies
even though none of know Ada.

Re: Top 10 Language Constructs (Ada)

[Keith Thompson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

"Dr. Joachim Schr�er" <joachim.schroeer@vs.dasa.de> writes:
[...]
> type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 - 2.0**(-13);
> for Plasma_Volts_Type'Size use 16;
> 
> And if the required range and the 'delta allow 'delta < 'small you have to
> write a rep-clause for 'small like:
> 
> for Plasma_Volts_Type'Small use 2.0**(-13);

Or better yet:

for Plasma_Volts_Type'Small use Plasma_Volts_Type'Delta;

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Top 10 Language Constructs (Ada)

[Dr. Joachim Schr�er]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]


Keith Thompson <kst@cts.com> schrieb in im Newsbeitrag:
yec1z0m29bg.fsf@king.cts.com...
> "Dr. Joachim Schr�er" <joachim.schroeer@vs.dasa.de> writes:
> [...]
> > type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 -
2.0**(-13);
> > for Plasma_Volts_Type'Size use 16;
> >
> > And if the required range and the 'delta allow 'delta < 'small you have
to
> > write a rep-clause for 'small like:
> >
> > for Plasma_Volts_Type'Small use 2.0**(-13);
>
> Or better yet:
>
> for Plasma_Volts_Type'Small use Plasma_Volts_Type'Delta;

At least with GNAT 3.12p this statement does not compile. The error message
is:

testfixpoint.adb:9:01: representation item appears too late
testfixpoint.adb:9:01: warning: no more representation items for type
"Plasma_Volts_Type" defined at line 7

Joachim Schr�er

Re: Top 10 Language Constructs (Ada)

[Florian Weimer]

"Dr. Joachim Schr�er" <joachim.schroeer@vs.dasa.de> writes:

> > for Plasma_Volts_Type'Small use Plasma_Volts_Type'Delta;
> 
> At least with GNAT 3.12p this statement does not compile. The error message
> is:
> 
> testfixpoint.adb:9:01: representation item appears too late
> testfixpoint.adb:9:01: warning: no more representation items for type
> "Plasma_Volts_Type" defined at line 7

The expression in the attribute definition clause is static
[3.5.10(2)], static expressions cause freezing [13.14(8)], as a
result, the corresponding type is frozen [13.14(10)]. [13.1(9)]
reads:

  9. A representation item that directly specifies an aspect of a
     subtype or type shall appear after the type is completely defined,
     see 3.11.1, and before the subtype or type is frozen, see 13.14. 
     [...]

I don't know what "before" means in this context exactly, but I think
the GNAT behavior is correct, even though the expression which causes
freezing doesn't appear before the representation item, strictly
speaking.

Re: Top 10 Language Constructs (Ada)

[David Kristola]

On Tue, 25 Jul 2000 7:47:13 -0700, Dr. Joachim Schr�er wrote
(in message <8lk9hm$s21@newsserv.vs.dasa.de>):

> Keith Thompson <kst@cts.com> schrieb in im Newsbeitrag: 
> yec1z0m29bg.fsf@king.cts.com...
>> "Dr. Joachim Schr�er" <joachim.schroeer@vs.dasa.de> writes:
>> [...]
>>> type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 - 2.0**(-13);
>>> for Plasma_Volts_Type'Size use 16;
>>> 
>>> And if the required range and the 'delta allow 'delta < 'small you have to
>>> write a rep-clause for 'small like:
>>> 
>>> for Plasma_Volts_Type'Small use 2.0**(-13);
>> 
>> Or better yet:
>> 
>> for Plasma_Volts_Type'Small use Plasma_Volts_Type'Delta;
> 
> At least with GNAT 3.12p this statement does not compile. The error message 
> is:
> 
> testfixpoint.adb:9:01: representation item appears too late 
> testfixpoint.adb:9:01: warning: no more representation items for type 
> "Plasma_Volts_Type" defined at line 7
> 
> Joachim Schr�er
> 

Rational Apex says pretty much the same thing.  As specified, i'm
pretty sure every possible bit pattern within the 16 bit field
is a valid Plasma_Volts_Type.  Not that it matters much, as per
other requirements, the only value i can output is 0.0, which
properly maps to all bits being zero.


-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Top 10 Language Constructs (Ada)

[Keith Thompson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Keith Thompson <kst@cts.com> writes:
> "Dr. Joachim Schr�er" <joachim.schroeer@vs.dasa.de> writes:
> [...]
> > type Plasma_Volts_Type is delta 2.0**(-13) range -4.0 .. 4.0 - 2.0**(-13);
> > for Plasma_Volts_Type'Size use 16;
> > 
> > And if the required range and the 'delta allow 'delta < 'small you have to
> > write a rep-clause for 'small like:
> > 
> > for Plasma_Volts_Type'Small use 2.0**(-13);
> 
> Or better yet:
> 
> for Plasma_Volts_Type'Small use Plasma_Volts_Type'Delta;

Or if that doesn't work (due to freezing rules, as others have pointed
out):

    Plasma_Volts_Small : constant := 2.0**(-13);
    type Plasma_Volts_Type is delta Plasma_Volts_Small
                              range -4.0 .. 4.0 - Plasma_Volts_Small;
    for Plasma_Volts_Type'Size use 16;
    for Plasma_Volts_Type'Small use Plasma_Volts_Small;

(This compiles under GNAT 3.12p.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Top 10 Language Constructs (Ada)

[David Kristola]

On Tue, 18 Jul 2000 19:41:25 -0700, Bill Brennan wrote
(in message <39751555.4E40A4A7@lmco.com>):

> Actually, this doesn't compile in GNAT, I presume because it rounds 
> Plasma_Volts_Type'Last to something which won't fit in 16 bits.
> 
> Besides the fact that this type definition isn't portable (for GNAT anyway), 
> it doesn't really reflect what you're trying to say.  Without your 
> description, I would have no idea that 0.00012207 ~= 2^(-13) or that 
> 3.99987793 ~= 4 - 2^(-13).

Idiot me.  :-)  I punched 2^(-13) into my calculator, and entered the
value i got into my code.  I should have either used binary (as you
suggested) or "2 ** (-13)" as Dr. Schr�er suggested.  There's nothing
like making a fool of yourself for all the world to see.  ;-)


-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Top 10 Language Constructs (Ada)

[Scott Ingram`]

David Kristola wrote:

> On Sat, 15 Jul 2000 16:36:15 -0700, Marc A. Criley wrote
> (in message <3970F56F.F3A70FAD@icdc.com>):
>
> > The critical foundation of the Ada programming language is its "type model".
> > (In claiming this I want to credit Doug Bryan for triggering this insight
> > for me at an Ada conference seminar about a dozen years ago.)
>
> I'd like to second David Botton's "Dude!".

I am also going to second David's "Dude!"  And nod in
Doug's direction as well!  Marc's post is one of those
nuggets that just makes life for the sweaty masses out
here worthwhile.  (Knowing that I am an Adaphile in
my small town causes small children to cast stones at me,
dogs to bark when I walk the street, and I am convinced
that I catch no fish because of it :)

> A word of caution.  Types are the foundation of many programs.
> Poorly laid out types can cause all kinds of problems.  I've seen
> a case where a bad type choice at a fundamental level caused type
> converts to be needed in hundreds of places throughout the code.
>
> --
> --djk, keeper of arcane lore & trivial fluff
> Home: David95036 plus 1 at america on-line
> Spam: goto.hades@welovespam.com

As with any extremely powerful tool, Ada can bite you.  I have
written things that "I am not proud of."  Fortunately, its much
rarer in Ada.

Re: Top 10 Language Constructs (Ada)

[Stefan Skoglund]

David Kristola wrote:
>    type Plasma_Volts_Type is delta 0.00012207 range -4.0 .. 3.99987793;
>    for Plasma_Volts_Type'Size use 16;
> 
> I love fixed point types!  I happen to know that the software on the
> other side of that interface is in C.  I wonder how they deal with
> that field.

I need a pointer to a book which explains in an easily understood way
the more
unusual parts of Ada like for example data representation clauses.

For now i only have one of the Ada 95 CS1 books (which doesn't cover
the more advanced features of Ada)

Re: Top 10 Language Constructs (Ada)

[Richard Riehle]

"Marc A. Criley" wrote:

> The critical foundation of the Ada programming language is its "type model". (In
> claiming this I want to credit Doug Bryan for triggering this insight for me at
> an Ada conference seminar about a dozen years ago.)
>

Marc's exposition of the type model is interesting and comprehensive.   He is
correct that it is
an essential element of the Ada language.   It is also an essential element of many
other
languages, including Modula-3, Oberon, Eiffel, and even C++.

The real secret is not the type model, as important and unique as it is in Ada.
Almost never do I
encounter a programmer who has difficulty understanding the type model.   More
often, Ada
programmers, novice and experienced alike, have trouble with the rules of ALRM
Chapter 8,
Scope and Visibility.   In particular, they have difficulty with the difference
between scope and
visibility and with the visibility rules themselves.

No other programming language defines with such care the difference between scope
and visibility.
C++ has its scoping rules, but suffers from the ancestral rules of C.   Coupled with
scope and
visibility is the difference between name-equivalence and structural equivalence for
types.  Modula-3,
and several other languages suffer from reliance on structural equivalence.   It is
subtle distinction
that Dr. Stroustrup was careful to insist upon in C++ just as we do in Ada.

How many Ada programmers do you know who have read and understand the meaning of the
rules
in Chapter 8 of the ALRM.   Probably very few.   Yet more programming problems, more
compiler
error messages, originate in misunderstandings of this chapter than in any other set
of rules, excepting
perhaps the new accessibility rules for access and tagged types.

The Ada type model is not nearly as strong as one might think without the rules of
Chapter 8.

Richard Riehle.

The Ada type model (was Re: Top 10 Language Constructs (Ada))

[Marc A. Criley]

My point is not that programmer's have trouble understanding the Ada
type model (whence Richard then goes on to discuss an area where 
programmer's do sometimes have difficulty).  It's that programmers, of
Ada or other languages, generally don't consciously grasp that strong
typing, as exemplified by Ada, permits and encourages the embedding
of a huge amount of domain information within the software which can
subsequently be extracted via attributes.

Instead of passing an array and the number of elements in it to a
subprogram, Ada permits passing a slice and then provides 'First,
'Last, 'Range, etc. to get at the information associated with that
slice.

You don't have to explicitly pass around or make visible "Maximum_X
constants", "Minimum_X constants", or "Current_Length" values.  In a
well-designed software system, all that information can be extracted
directly from the data items because of their employment of strong
typing.

To provide a similar kind of strong typing behavior in C++ or Java,
one has to constuct a class for each such data item, and then
_explicitly_ implement the strong typing behavior that is desired
(such as range checking for C++).

Ada, in contrast, provides most desired typing features and
information extraction attributes "for free" because of the
nature of the language's implementation of its strong typing
model.

Marc


Richard Riehle wrote:
> 
> "Marc A. Criley" wrote:
> 
> > The critical foundation of the Ada programming language is its "type model". (In
> > claiming this I want to credit Doug Bryan for triggering this insight for me at
> > an Ada conference seminar about a dozen years ago.)
> >
> 
> Marc's exposition of the type model is interesting and comprehensive.   He is
> correct that it is
> an essential element of the Ada language.   It is also an essential element of many
> other
> languages, including Modula-3, Oberon, Eiffel, and even C++.
> 
> The real secret is not the type model, as important and unique as it is in Ada.
> Almost never do I
> encounter a programmer who has difficulty understanding the type model.   More
> often, Ada
> programmers, novice and experienced alike, have trouble with the rules of ALRM
> Chapter 8,
> Scope and Visibility.   In particular, they have difficulty with the difference
> between scope and
> visibility and with the visibility rules themselves.
> 
> No other programming language defines with such care the difference between scope
> and visibility.
> C++ has its scoping rules, but suffers from the ancestral rules of C.   Coupled with
> scope and
> visibility is the difference between name-equivalence and structural equivalence for
> types.  Modula-3,
> and several other languages suffer from reliance on structural equivalence.   It is
> subtle distinction
> that Dr. Stroustrup was careful to insist upon in C++ just as we do in Ada.
> 
> How many Ada programmers do you know who have read and understand the meaning of the
> rules
> in Chapter 8 of the ALRM.   Probably very few.   Yet more programming problems, more
> compiler
> error messages, originate in misunderstandings of this chapter than in any other set
> of rules, excepting
> perhaps the new accessibility rules for access and tagged types.
> 
> The Ada type model is not nearly as strong as one might think without the rules of
> Chapter 8.
> 
> Richard Riehle.