Question for the folks who designed Ada95

Question for the folks who designed Ada95

[Corey Ashford]

About modular types.

In general, I think they are pretty good, but
there is one thing that has been brought up several
times on this newsgroup and I consider that the
solutions offered were less than adequate.

Shifts!

Why didn't Ada95 make a shift operator a first-class
operator on modular types.

There wouldn't be any need to introduce new syntax.
Something like this would be good:

type reg32 is mod 2**32;

...
x : reg32;
y : reg32;
z : natural;

...

x := reg32'shift_left(y, z);


The problem with the interfaces package shift
operators is that they have fixed types.  So it's
difficult to write code for types whose size can vary.

Any thoughts as to why the shift operator wasn't given
a better treatment?  Or am I all wet, and there's really a good way to do shifts?

(Please don't suggest using divides or multiplies as
the efficiency of the code generated can vary widely across different
compilers and optimization levels).


Thanks

- Corey

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g2qu4$ca4$1@usenet.rational.com>,
  "Corey Ashford" <yeroca@rocketmail.com> wrote:
>
> The problem with the interfaces package shift
> operators is that they have fixed types.  So it's
> difficult to write code for types whose size can vary.

What we do in GNAT to address this problem is to make the
shift operators intrinsics. Here is a typical declaration
from the Interfaces spec:

   pragma Import (Intrinsic, Shift_Left);

The nice thing about this approach is that indeed you
*can* apply this intrinsic to a user defined type. For
example you can put the following in your code.


  type My_Modular is mod 2**Integer'Size;
  function Shift_Left
     (Value  : My_Modular;
      Amount : Natural)
      return   My_Modular;
  pragma Import (Intrinsic, Shift_Left);

and this will work fine. Of course this is not guaranteed
to be portable (perhaps the ARG should look at this one,
since it is a perfectly legitimate implementation
decision).



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Tarjei Tj�stheim Jensen]

Robert Dewar wrote :

>What we do in GNAT to address this problem is to make the
>shift operators intrinsics. Here is a typical declaration
>from the Interfaces spec:
>
>   pragma Import (Intrinsic, Shift_Left);
>
>The nice thing about this approach is that indeed you
>*can* apply this intrinsic to a user defined type. For
>example you can put the following in your code.
>
>
>  type My_Modular is mod 2**Integer'Size;
>  function Shift_Left
>     (Value  : My_Modular;
>      Amount : Natural)
>      return   My_Modular;
>  pragma Import (Intrinsic, Shift_Left);


I think the person who asked the question whould have preferred something that
was inline instead of a function call. At least that would _look_ efficient.

>and this will work fine. Of course this is not guaranteed
>to be portable (perhaps the ARG should look at this one,
>since it is a perfectly legitimate implementation
>decision).


While you are at it, why not get us [ and ] for arrays (in addtion to, not
instead of parenthesises). I really want to write a[4] := 3 instead of a(4) :=
3.

I know that when Ada 83 was defined one could not rely on [ and ] being
available (Pascal used (. and .) instead of [ and ] if my memory serves me
right). However these days I see no reason not to comply with the common use of
square brackets with arrays.

Arrays as functions? Since when could you assign to a function??

Greetings,

Re: Question for the folks who designed Ada95

[Larry Kilgallen]

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

In article <7g4ae3$hjh2@ftp.kvaerner.com>, "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> writes:

> While you are at it, why not get us [ and ] for arrays (in addtion to, not
> instead of parenthesises). I really want to write a[4] := 3 instead of a(4) :=
> 3.

No !  Making it easy for writers is _not_ the priority for Ada.
The priority is making it easy for readers.  As I see it, that
_not_ involve adding superfluous spellings of the same thing.

Larry Kilgallen

Re: Question for the folks who designed Ada95

[Robert Dewar]

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

In article <7g4ae3$hjh2@ftp.kvaerner.com>,
  "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no>
wrote:
> I think the person who asked the question whould have
> preferred something that was inline instead of a function
> call. At least that would _look_ efficient.

Perhaps you were missing a smiley here, but assuming this
comment is a serious one, of COURSE intrinsic functions
are generated inline, that's the whole point of them!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Corey Ashford]

Robert Dewar wrote:
> 
> In article <7g4ae3$hjh2@ftp.kvaerner.com>,
>   "Tarjei Tj stheim Jensen" <tarjei.jensen@kvaerner.no>
> wrote:
> > I think the person who asked the question whould have
> > preferred something that was inline instead of a function
> > call. At least that would _look_ efficient.
> 
> Perhaps you were missing a smiley here, but assuming this
> comment is a serious one, of COURSE intrinsic functions
> are generated inline, that's the whole point of them!
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

I tried out this technique, by the way, on Apex.  Works like
a champ and inlines exactly as you said.

Many thanks for your help, Robert.  This cleaned up my code
nicely and got rid of some preprocessor code.

- Corey

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <3726A2B1.5793E3BE@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:
> I tried out this technique, by the way, on Apex.  Works
> like a champ and inlines exactly as you said.

Note that there is no requirement at all that this work,
but it is not surprising to find that it would work
(accidentally? is it documented, I am not sure that it
is properly documented for GNAT either come to think
about it) since it is an obvious way of implementing
things.

All the more reason for the ARG to insist on it.

There are issues of what types it can be applied to. Shift
operations applied for example to non-binary modular types
are quite a puzzle.

In GNAT, we allow shifts to be applied to any signed or
binary unsigned integer type whose size is 8, 16, 32, or
64 (i.e. natural machine sizes for which shifts make
sense).

It would be interesting to know what restrictions other
compilers impose on this usage.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> There are issues of what types it can be applied to. Shift
> operations applied for example to non-binary modular types
> are quite a puzzle.

And then generic contract problems rear their ugly heads.

> In GNAT, we allow shifts to be applied to any signed or
> binary unsigned integer type whose size is 8, 16, 32, or
> 64 (i.e. natural machine sizes for which shifts make
> sense).

What does GNAT do if it's a generic formal modular type?
I would guess it just checks the rule in the instance.
That's fine for an implementation-defined gizmo, but for
a language-defined feature, we would never want to do that.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <wccd80ohhdg.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> What does GNAT do if it's a generic formal modular type?
> I would guess it just checks the rule in the instance.
> That's fine for an implementation-defined gizmo, but for
> a language-defined feature, we would never want to do
> that.


except for pragma Restrictions :-)


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> except for pragma Restrictions :-)

Link-time doesn't count.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Corey Ashford]

Robert Dewar wrote:
> 
> In article <3726A2B1.5793E3BE@rocketmail.com>,
>   Corey Ashford <yeroca@rocketmail.com> wrote:
> > I tried out this technique, by the way, on Apex.  Works
> > like a champ and inlines exactly as you said.
> 
> Note that there is no requirement at all that this work,
> but it is not surprising to find that it would work
> (accidentally? is it documented, I am not sure that it
> is properly documented for GNAT either come to think
> about it) since it is an obvious way of implementing
> things.
> 
> All the more reason for the ARG to insist on it.
> 
> There are issues of what types it can be applied to. Shift
> operations applied for example to non-binary modular types
> are quite a puzzle.
> 
> In GNAT, we allow shifts to be applied to any signed or
> binary unsigned integer type whose size is 8, 16, 32, or
> 64 (i.e. natural machine sizes for which shifts make
> sense).
> 
> It would be interesting to know what restrictions other
> compilers impose on this usage.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

It seems to me that the way to handle it is the way
"and", "or", etc, were dealt with on non power-of-two modular
types.  That is, do the operation, then do a mod operation
afterward.

I haven't tried a non power-of-two pragma import(intrinsic, ...)
yet.  I'll try it and let you know what happens.

- Corey

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <3727EC39.E460C803@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:
> It seems to me that the way to handle it is the way
> "and", "or", etc, were dealt with on non power-of-two
> modular types.

Now, *without* going to the Ada RM, let's see if we can
remember exactly what's going on with the etc here. Hands
up those who remember how NOT works on non-binary modular
types (hint: the above quote is wrong wrt NOT :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Geert Bosch]

If I remember correctly, "not" is defined as the Base-1 complement
of the value. So "not 4" in a modulo 13 type would be 8.
I'm not positive that this is right though, but it is the
only reasonable definition I can think of...

Robert Dewar wrote:
> Now, *without* going to the Ada RM, let's see if we can
> remember exactly what's going on with the etc here. Hands
> up those who remember how NOT works on non-binary modular
> types (hint: the above quote is wrong wrt NOT :-)

Re: Question for the folks who designed Ada95

[Fraser Wilson]

paene lacrimavi postquam Robert Dewar  scripsit:

>Now, *without* going to the Ada RM, let's see if we can
>remember exactly what's going on with the etc here. Hands
>up those who remember how NOT works on non-binary modular
>types (hint: the above quote is wrong wrt NOT :-)

not X = Y: X + Y = 0 ?

Here's a question: has anyone ever used a modular type which was not
a power of 2, and lived to tell the tale?  What was the context?

Fraser.

Re: Question for the folks who designed Ada95

[Tucker Taft]

Fraser Wilson wrote:
> 
> paene lacrimavi postquam Robert Dewar  scripsit:
> 
> >Now, *without* going to the Ada RM, let's see if we can
> >remember exactly what's going on with the etc here. Hands
> >up those who remember how NOT works on non-binary modular
> >types (hint: the above quote is wrong wrt NOT :-)
> 
> not X = Y: X + Y = 0 ?

Close.  X + not(X) + 1 = 0.

> Here's a question: has anyone ever used a modular type which was not
> a power of 2, and lived to tell the tale?  What was the context?

It is convenient for hash functions where you want to use
a prime number as the modulus.  It works even if the 
multiply or add would otherwise overflow.  

It is also convenient for cyclic buffers, though I will admit
that you end up having to put a comment on the "X := X + 1;" line
to avoid confusing the reader, because most readers are not
used to thinking about wrap-around arithmetic.  Though, of course,
this comment is appropriate for both binary as well as non-binary 
moduli, when wrap-around is expected (rather than being just a 
relatively rare "overflow" effect).

> Fraser.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Question for the folks who designed Ada95

[Mark A Biggar]

Fraser Wilson wrote:
> 
> paene lacrimavi postquam Robert Dewar  scripsit:
> 
> >Now, *without* going to the Ada RM, let's see if we can
> >remember exactly what's going on with the etc here. Hands
> >up those who remember how NOT works on non-binary modular
> >types (hint: the above quote is wrong wrt NOT :-)
> 
> not X = Y: X + Y = 0 ?

That works.  The RM defines it as (Modulus - X) which is the same value.
 
> Here's a question: has anyone ever used a modular type which was not
> a power of 2, and lived to tell the tale?  What was the context?

Yeah, two different things: 

1) the index into a circular queue defined as:

type Queue_index is mod Queue_size;
type Queue is array (Queue_index) of Element;

(Actual implementation was a generic package)

2) Index type for a hash table where table size was largest prime < 32676.
This made the hash function very simple.

Sorry, I can't give detailed code examples as both cases involved code for
classified government projects.
--
Mark Biggar
mark.a.biggar@lmco.com

Re: Question for the folks who designed Ada95

[Tucker Taft]

Mark A Biggar wrote:
> 
> Fraser Wilson wrote:
> >
> > paene lacrimavi postquam Robert Dewar  scripsit:
> >
> > >Now, *without* going to the Ada RM, let's see if we can
> > >remember exactly what's going on with the etc here. Hands
> > >up those who remember how NOT works on non-binary modular
> > >types (hint: the above quote is wrong wrt NOT :-)
> >
> > not X = Y: X + Y = 0 ?
> 
> That works.  The RM defines it as (Modulus - X) which 
> is the same value.

Not ;-).  The RM defines "not(X)" as mod_type'Base'Last - X
(see paragraph 4.5.6(5)).   In any case, I think Robert has 
proven his point!

> ...
> Mark Biggar
> mark.a.biggar@lmco.com

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Question for the folks who designed Ada95

[Marin David Condic]

Fraser Wilson wrote:
> 
> Here's a question: has anyone ever used a modular type which was not
> a power of 2, and lived to tell the tale?  What was the context?
> 
Reasonably often. I've found them useful as cycle counters or in
creating some form of circular queue. Certainly not as frequently as one
would, say, use the standard Integer, but often enough that I find it a
convenience.

I've seen a number of times in code something equivalent to:

X := X + 1 ;
if (X > Some_Max_Limit) then
    X := 0 ;
end if ;

A modular type of a non-power-of-2 makes this a natural thing because it
is the compiler's problem to figure out if we've hit the wraparound
point & it will likely do this as efficiently as possible.

I think I've seen this most frequently in some form of bus communication
where raw data is being buffered, buffers are being toggled or where
data is being read and dropping stale data is "a good thing". But I also
see it in code that deals with cyclic events - not all of which happen
in powers of two and quite frequently you want the ability to "tune" the
number of cycles by recompiling with new constants.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: Question for the folks who designed Ada95

[David Brown]

>>>>> On Thu, 29 Apr 1999 18:32:55 GMT, fraser@synopsys.com (Fraser Wilson) said:

> Here's a question: has anyone ever used a modular type which was not
> a power of 2, and lived to tell the tale?  What was the context?

DSP algorithms.  Filters can be all sorts of sizes.  The modulus type
makes it easy to walk through the buffer by just adding.
Unfortunately, they aren't dynamic, so if you need a filter that can
work with dynamically sized filters, they don't work anyway.

Dave Brown
dlbrown@acm.org

Re: Question for the folks who designed Ada95

[Corey Ashford]

Corey Ashford wrote:
> 
> Robert Dewar wrote:
> >
> > In article <3726A2B1.5793E3BE@rocketmail.com>,
> >   Corey Ashford <yeroca@rocketmail.com> wrote:
> > > I tried out this technique, by the way, on Apex.  Works
> > > like a champ and inlines exactly as you said.
> >
> > Note that there is no requirement at all that this work,
> > but it is not surprising to find that it would work
> > (accidentally? is it documented, I am not sure that it
> > is properly documented for GNAT either come to think
> > about it) since it is an obvious way of implementing
> > things.
> >
> > All the more reason for the ARG to insist on it.
> >
> > There are issues of what types it can be applied to. Shift
> > operations applied for example to non-binary modular types
> > are quite a puzzle.
> >
> > In GNAT, we allow shifts to be applied to any signed or
> > binary unsigned integer type whose size is 8, 16, 32, or
> > 64 (i.e. natural machine sizes for which shifts make
> > sense).
> >
> > It would be interesting to know what restrictions other
> > compilers impose on this usage.
> >
> > -----------== Posted via Deja News, The Discussion Network ==----------
> > http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
> 
> It seems to me that the way to handle it is the way
> "and", "or", etc, were dealt with on non power-of-two modular
> types.  That is, do the operation, then do a mod operation
> afterward.

Here's the code I tried:


procedure Testnp2 is
    type Foo is mod 15;

    function Shift_Left (Value : Foo; Amount : Natural) return Foo;
    pragma Import (Intrinsic, Shift_Left);

    A : Foo := 7;
    B : Foo;
begin
    B := Shift_Left (A, 4);
end Testnp2;

                ****   DISASSEMBLER  ****


disassembly for .Rational/Compilation/testnp2.2.o

section .text
_R_testnp2.ibov6gf6nmnlgv9i0i()
           0:  84 10 20 07         mov          7, %g2
           4:  91 28 b0 04         sllx         %g2, 4, %o0
           8:  82 0a 20 ff         and          %o0, 255, %g1
           c:  81 c3 e0 08         retl         
          10:  01 00 00 00         nop          



So it doesn't do a mod operation on it afterward... just ands with
a mask that's a multiple of a byte in length and at least as big as modulus-1.
(I confirmed this by trying some other oddball moduluses)

I guess that's reasonable enough.

- Corey

Re: Question for the folks who designed Ada95

[bill]

In article <7g4ae3$hjh2@ftp.kvaerner.com>, "Tarjei says...
 
>
>While you are at it, why not get us [ and ] for arrays (in addtion to, not
>instead of parenthesises). I really want to write a[4] := 3 instead of a(4) :=
>3.

good point.
 
since we are making changes, can I have this change also: how about adding
"()" to function and procedure calls, even though there are no parameters
being passed?

I find it more clear to see

pkg.foo();

instead of

pkg.foo;

where foo is a procedure or function that takes no args.

becuase if I see () next to the name, I know the name is a function or
procedure, instead of just a variable.

please please, can we make this change in Ada 200X ?

Bill.

Re: Question for the folks who designed Ada95

[dennison]

In article <7g4gjk$luq@drn.newsguy.com>,
  bill@nospam.com wrote:
> In article <7g4ae3$hjh2@ftp.kvaerner.com>, "Tarjei says...
>
> >
> >While you are at it, why not get us [ and ] for arrays (in addtion to, not
> >instead of parenthesises). I really want to write a[4] := 3 instead of a(4)
:=
> >3.
>
> good point.
>
> since we are making changes, can I have this change also: how about adding
> "()" to function and procedure calls, even though there are no parameters
> being passed?
>
> I find it more clear to see
>
> pkg.foo();

Yeah! I really miss those vestigal parens. Just to make it even, we could
require a '()' around constants so that we don't loose source portability
between constants and functions when the change is made.

And while we're making silly changes whose only non-debatable effect will be
to break older code, I have a few ideas myself:

Why do we call tasks "task" when they are really threads? That's confusing.
Let's change the name of the keyword to "thread".

Also, why do we need an "end" keyword? I prefer Draco and the sh shell's way
of just spelling the starting keyword backwards. That should be fixed!

Oh yeah. I don't like the way arrays have the last index vary fastest instead
of the first index. I personally find that much less clear, so of course it
has to be changed too.

The comment introducer is also confusing. "--" implies something is being
taken away from the source, when really you are trying to *add* something
when you comment your code. Therefore "++" should be used instead.


(note: Transcripts of this posting are available for the sarcasm-impaired.
Please send your checks or money-orders for $5 US to the email address listed
at the top of the posting).

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g4rof$42c$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

I quite realize that Ted's post was intended to be jokes
and I appreciate it as that, but one interesting serious
issue is raised.


> Why do we call tasks "task" when they are really threads?
> That's confusing.

In fact the idea of the original design was that task is
a much higher level concept, and that whether a given task
is implemented as a thread is an implementation detail.
Most certainly the expectation was that some tasks would
not be threads at all. Consider this example from the Ada
83 RM:

Example of task specification and corresponding body:

    task PROTECTED_ARRAY is
       --  INDEX and ITEM are global types
       entry READ (N : in INDEX; V : out ITEM);
       entry WRITE(N : in INDEX; E : in  ITEM);
    end;

    task body PROTECTED_ARRAY is
       TABLE : array(INDEX) of ITEM := (INDEX =>
                                          NULL_ITEM);
    begin
       loop
          select
             accept READ (N : in INDEX; V : out ITEM) do
                V := TABLE(N);
             end READ;
          or
             accept WRITE(N : in INDEX; E : in  ITEM) do
                TABLE(N) := E;
             end WRITE;
          end select;
       end loop;
    end PROTECTED_ARRAY;

The intention was most certainly that this be implemented
without a separate thread, using an approach similar to
the protected records of Ada 95, and indeed several Ada
83 compilers including DEC Ada and Verdix implemented
"passive" tasks in this manner.

There was a minority thread of opinion in the Ada 95 design
(notably held by Paul Hilfinger and me) that the whole
business of protected records was a mis-step, and that a
better approach would have been to formalize the notion of
a passive task.

The objection to this was not so much technical as
conceptual. I remember one person at a RTWG meeting saying
"I don't care what you say, a task is a thread, and nothing
you can say will make me change that opinion".

Given this unshakable view of what a task is, then you
can see that the notion of abstraction inversion (it is
silly to implement locks in terms of threads) is a strong
argument.

I personally do not like the protected types of Ada 95 at
all. Why not? Because they are abstraction impaired. They
have all kinds of restrictions that are from a semantic
point of view nonsense, and which mean that you cannot
compose them. You can for example call a procedure from a
protected procedure, but only if it does not do a
potentially blocking operation. This means that
conceptually every subprogram, since it might be called
from a protected procedure, must reveal in its spec whether
it can do any blocking calls.

What happens in practice is that people ignore this, and
either through  illicit knowledge of what is in bodies, or
through shear luck, they avoid blocking calls.

A much worse outcome -- very common in practice -- is that
people DO blocking calls, and they work just fine, because
the protected records are implemented with general locks.
FOr most implementations the restrictions against
potentially blocking operations are totally unnecessary.

Indeed these restrictions are only there to serve the needs
of high efficiency bare board implementations, and often
have little relevance to implementations over operating
systems.

Anyway, bare in mind that the above arguments were fully
presented and explored during the Ada 95 design, and were
rejected soundly, so they must be wrong!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> Example of task specification and corresponding body:
> 
>     task PROTECTED_ARRAY is
>        --  INDEX and ITEM are global types
>        entry READ (N : in INDEX; V : out ITEM);
>        entry WRITE(N : in INDEX; E : in  ITEM);
>     end;
> 
>     task body PROTECTED_ARRAY is
>        TABLE : array(INDEX) of ITEM := (INDEX =>
>                                           NULL_ITEM);
>     begin
>        loop
>           select
>              accept READ (N : in INDEX; V : out ITEM) do
>                 V := TABLE(N);
>              end READ;
>           or
>              accept WRITE(N : in INDEX; E : in  ITEM) do
>                 TABLE(N) := E;
>              end WRITE;
>           end select;
>        end loop;
>     end PROTECTED_ARRAY;
> 
> The intention was most certainly that this be implemented
> without a separate thread, using an approach similar to
> the protected records of Ada 95, and indeed several Ada
> 83 compilers including DEC Ada and Verdix implemented
> "passive" tasks in this manner.
> 
> There was a minority thread of opinion in the Ada 95 design
> (notably held by Paul Hilfinger and me) that the whole
> business of protected records was a mis-step, and that a
> better approach would have been to formalize the notion of
> a passive task.

One of the things that convinced me you and Paul were wrong is to
consider the semantics of a conditional entry call, eg:

    select
        PROTECTED_ARRAY.WRITE(...);
    else
        ...
    end select;

The above task is almost always able to accept a call to Write, but
there are small windows of time during which it won't.  That semantics
seems fishy to me.  For the "equivalent" protected object, you can write
it so that it will *always* be able to accept a call to Write.  Or, in a
different example, you can set things up so that the PO is always in one
of *two* states (able to accept this entry, or eble to accept that
entry), and the transition between states is atomic (that is, callers
can't see the PO in the transitory state).  So a caller could use a
conditional entry call, and know that if the Foo entry isn't available,
the Bar entry must have been.  That kind of semantics seems cleaner to
me.  Contrast with a server task, where there's always a window of time
while the task loops back to the beginning of the selective accept --
and that window is externally visible.  Seems like asking for trouble --
the worst kind of bug, where it only happens once in a blue moon.  And
some implementations might even optimize away the bug.

> I personally do not like the protected types of Ada 95 at
> all. Why not? Because they are abstraction impaired. They
> have all kinds of restrictions that are from a semantic
> point of view nonsense, and which mean that you cannot
> compose them. You can for example call a procedure from a
> protected procedure, but only if it does not do a
> potentially blocking operation. This means that
> conceptually every subprogram, since it might be called
> from a protected procedure, must reveal in its spec whether
> it can do any blocking calls.

I agree somewhat with that criticism.  Nonetheless, I  prefer
using protected objects to using rendezvous.

> Anyway, bare in mind that the above arguments were fully
> presented and explored during the Ada 95 design, and were
> rejected soundly, so they must be wrong!

I don't see a smily.  Minorities (even minorities of one) are often
right!

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g4gjk$luq@drn.newsguy.com>,
  bill@nospam.com wrote:
> since we are making changes, can I have this change also:
> how about adding "()" to function and procedure calls,
> even though there are no parameters
> being passed?
>
> I find it more clear to see
>
> pkg.foo();
>
> instead of
>
> pkg.foo;
>
> where foo is a procedure or function that takes no args.
>
> becuase if I see () next to the name, I know the name is
> a function or
> procedure, instead of just a variable.
>
> please please, can we make this change in Ada 200X ?
>
> Bill.


No we can't!

This is something that people feel strongly about one way
or the other. It partly depends on your previous
experience, C programmers actually like the (), but
Algol tradition programmers find them ugly.

I personally think they are distracting and very annoying,
but my personal tastes are not important.

What *is* important is that this issue has been discussed
at length, in both 83 and 95, and every discussion made it
clear that the constituency that hates the null parens is
(a) in the clear majority and (b) feels strongly about it.

To suggest making such a change at this stage is out of
the question. It would be a horrendous incompatibility that
would annoy the majority of Ada users!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Al Christians]

Robert Dewar wrote:
> 
> 
> What *is* important is that this issue has been discussed
> at length, in both 83 and 95, and every discussion made it
> clear that the constituency that hates the null parens is
> (a) in the clear majority and (b) feels strongly about it.
> 
> To suggest making such a change at this stage is out of
> the question. It would be a horrendous incompatibility that
> would annoy the majority of Ada users!
> 

Couldn't the ()'s for a 0-parameter call be optional for clarity for
those who think they enhance clarity?

Al

Re: Question for the folks who designed Ada95

[Larry Kilgallen]

In article <3726039A.916FC0F3@easystreet.com>, Al Christians <achrist@easystreet.com> writes:

> Couldn't the ()'s for a 0-parameter call be optional for clarity for
> those who think they enhance clarity?

Certainly, so long as you guarantee that the text will automatically
change to suit the tastes of the person reading it, even from hardcopy
at the bus stop.  For precedent see the dictionary reference to "Pooka"
in the play "Harvey".

Until paper engineering catches up with literature, favoring readers
should mean standardised (..ized? :-) spellings.

Larry Kilgallen

Re: Question for the folks who designed Ada95

[Al Christians]

Well, we've been over this before. I believe.  The proper 
level of standardization of the optional elements of the 
program is the development organization, ie, one development 
shop <=> one style. There are optional elements wrt 
whitespace, case, comments, etc. I hope we don't ban these 
because any particular arrangement thereof might not 
exactly suit the reader; it is reasonable for an 
organization to prescribe a standard usage of these.  One 
more optional element isn't going to hurt that much.  

I expect that multi-language projects will become more 
common, and that allowing the optional inclusion of 
some extraneous typography to make Ada more readable 
for those who don't do Ada continuously  might be 
advantageous.

I realize that you are justifiably frightened that somewhere, 
someplace, somebody will commit some deplorable vice totally 
beyond our control with optional empty parentheses after a 
function call not requiring parentheses, if these were allowed.  
Please let me know what that perversion is, so that I may 
salivate in longing depravity, even though the chance of 
getting  such a libertine proposition past the powers that be 
of the Ada world is insignificant.  

Al

Larry Kilgallen wrote:
> 
> In article <3726039A.916FC0F3@easystreet.com>, Al Christians <achrist@easystreet.com> writes:
> 
> > Couldn't the ()'s for a 0-parameter call be optional for clarity for
> > those who think they enhance clarity?
> 
> Certainly, so long as you guarantee that the text will automatically
> change to suit the tastes of the person reading it, even from hardcopy
> at the bus stop.  For precedent see the dictionary reference to "Pooka"
> in the play "Harvey".
> 
> Until paper engineering catches up with literature, favoring readers
> should mean standardised (..ized? :-) spellings.
>

Re: Question for the folks who designed Ada95

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> This is something that people feel strongly about one way
> or the other. It partly depends on your previous
> experience, C programmers actually like the (), but
> Algol tradition programmers find them ugly.

Not entirely -- I'm a counter example.  I was raised on Pascal, and have
spent most of my career programming in Ada, but I still prefer the empty
parens, because they add information -- they help me understand the
program.  In a functional language I might not care, but in a language
like Ada, where a function can go off and do who-knows-what, it seems
(to me) nice to distinguish function calls from variable references
syntactically.

> What *is* important is that this issue has been discussed
> at length, in both 83 and 95, and every discussion made it
> clear that the constituency that hates the null parens is
> (a) in the clear majority and (b) feels strongly about it.

More importantly, Jean Ichbiah was in the anti-null-parens group, and
his vote counted more than anybody else's.  That's as it should be --
the lead language designer should get the final say in such matters.

Note that there was a preliminary version of Ada that required null
parens.  I think folks were worried about examples like:

    function F(X: Integer) return Character;
    function F(X: Integer := 3) return String;
    ...
    C: constant Character := F(3); -- Ambiguous, one would hope.

which is a little bit tricky for the compiler writer -- but not such a
big deal if you know about it before designing your overload resolution
stuff.

> To suggest making such a change at this stage is out of
> the question. It would be a horrendous incompatibility that
> would annoy the majority of Ada users!

Quite right.  Even if everybody liked empty parens, it would be
impossible to change now, due to upward compatibility.  The idea of
making them optional doesn't fly, either -- it defeats the whole purpose
of having a clear syntactic indicator.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <wccg15khi6o.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> More importantly, Jean Ichbiah was in the
> anti-null-parens group, and his vote counted more than
> anybody else's.

True, but on this point (unlike some others), he had
considerable support.

For an example where JDI's vote did count more than anyone
else's and probably a good thing too, consider the issue
of derived types, the vote was N-1 to get rid of them in
Ada 83, but the 1 was JDI, so they stayed :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Matthew Heaney]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> For an example where JDI's vote did count more than anyone
> else's and probably a good thing too, consider the issue
> of derived types, the vote was N-1 to get rid of them in
> Ada 83, but the 1 was JDI, so they stayed :-)


Funny you should characterize the inclusion of derived types as "a good
thing."  Without them, Ada83 would have been simpler (yes?).  

Derived types are not an aspect of the language understood by most
working Ada(83) programmers anyway.  (Although that's probably less
true today, now that derivation is the mechanism for type extension.)

So I'm curious: why do you think it's better that derived types were
included in the language?

Re: Question for the folks who designed Ada95

[Jean-Pierre Rosen]

Matthew Heaney a �crit dans le message ...
>Robert Dewar <robert_dewar@my-dejanews.com> writes:
>
>> For an example where JDI's vote did count more than anyone
>> else's and probably a good thing too, consider the issue
>> of derived types, the vote was N-1 to get rid of them in
>> Ada 83, but the 1 was JDI, so they stayed :-)
>
>Funny you should characterize the inclusion of derived types as "a
good
>thing."  Without them, Ada83 would have been simpler (yes?).
Ada would also have been simpler without tasking, user defined types,
overloading, generics...
(Do I need a smiley here?)

>Derived types are not an aspect of the language understood by most
>working Ada(83) programmers anyway.  (Although that's probably less
>true today, now that derivation is the mechanism for type extension.)

Derived types are a fundamental aspect of the language. If your
statement that most Ada programmers do not understand them is true, it
means that most Ada programmers are not well trained.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <m3vhegrqgd.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Robert Dewar <robert_dewar@my-dejanews.com> writes:
> So I'm curious: why do you think it's better that derived
> types were included in the language?

Because they provided the smooth platform for inclusion of
record extension in Ada 95.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[David Starner]

"Tarjei Tj�stheim Jensen" wrote:
> I know that when Ada 83 was defined one could not rely on [ and ] being
> available (Pascal used (. and .) instead of [ and ] if my memory serves me
> right). However these days I see no reason not to comply with the common use of
> square brackets with arrays.
> 
> Arrays as functions? Since when could you assign to a function??

But that was a deliberate choice. IIRC, Ada 83 depended on ASCII which
supplied [], so they could have gone with brackets. Now, you can't
change (my Fortran teacher is still complaining about Fortran 77
breaking character assignment, and you want to break all arrays in
Ada95?), and there's really no reason to add syntax fluff, at least
here.

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <3725C49E.8106A44B@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> But that was a deliberate choice. IIRC, Ada 83 depended
> on ASCII which supplied [], so they could have gone with
> brackets.

This is bad history! The requirement for the character set
in Ada 83 was much more strenuous, it included
compatibility with current common usage, which included
EBCDIC (e.g. IBM keypunches) which did NOT provide the []
characters.

But even now there are those who do not like at all to
create referential non-transparency between arrays and
functions, since they regard these as two alternative
low level implementations of the abstract mathematical
concept of a function or map.

In other words:

  a(5)

is a reference to a mapping, and you want the range value
given the domain value 5. Whether this is implemented by
an array or a function is an implementation detail that
should not affect the syntactic form of reference.

I personally like the [] since I was immersed in the Algol
world so long, and I particularly liked this usage in
A68, but the above argument is definitely a legitimate one!



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[David Starner]

Robert Dewar wrote:
> 
> In article <3725C49E.8106A44B@aasaa.ofe.org>,
>   David Starner <dstarner98@aasaa.ofe.org> wrote:
> > But that was a deliberate choice. IIRC, Ada 83 depended
> > on ASCII which supplied [], so they could have gone with
> > brackets.
> 
> This is bad history! The requirement for the character set
> in Ada 83 was much more strenuous, it included
> compatibility with current common usage, which included
> EBCDIC (e.g. IBM keypunches) which did NOT provide the []
> characters.

Interesting. Then why was support for package ASCII required, and how
was it supposed to be supported in a non-ASCII enviroment?

Re: Question for the folks who designed Ada95

[Samuel Mize]

David Starner quoted Robert Dewar:

...The requirement for the character set
>> in Ada 83 was much more strenuous, it included
>> compatibility with current common usage, which included
>> EBCDIC (e.g. IBM keypunches) which did NOT provide the []
>> characters.
> 
> Interesting. Then why was support for package ASCII required, and how
> was it supposed to be supported in a non-ASCII enviroment?

Don't confuse the character set that the program can manipulate,
with the character set that it is written in.

An Ada program on an EBCDIC machine would manipulate a non-EBCDIC
representation of characters, but it might have been typed up in
EBCDIC to be compiled.

The type Character is an enumeration (of character literals),
representing each character with a specified code.

My 83 Rationale isn't handy.  I'd guess Character was defined this
way specifically so that data would easily interchange between
Ada programs, and so the programmer could reason about the
ordering of the characters (e.g., digits are in the range 0 .. 9).

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <3725EE85.54163275@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> Interesting. Then why was support for package ASCII
> required, and how
> was it supposed to be supported in a non-ASCII
> enviroment?

Package ASCII has nothing whatsoever to do with the
issues of representing source. There is no formal
connection whatsoever between source representation and
the type Standard.Character.

The graphics associated with characters in I/O situations
are device and implementation dependent, and are not
specified by the language.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Tarjei Tj�stheim Jensen]

Robert Dewar wrote :
>
>In other words:
>
>  a(5)
>
>is a reference to a mapping, and you want the range value
>given the domain value 5. Whether this is implemented by
>an array or a function is an implementation detail that
>should not affect the syntactic form of reference.


What would a(5) := 4; mean then? You cannot assign to a function as far as I
know. Which in my opinion voids the function opposition to the common
convention of using square brackets for array indices.

I don't mind if the function addicts still writes a(5) := 4, if I can write
a[5] := 4.

Greetings,

Re: Question for the folks who designed Ada95

[Robert A Duff]

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

"Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> writes:

> I don't mind if the function addicts still writes a(5) := 4, if I can write
> a[5] := 4.

I do (mind).  I like a[5] better, too, but it seems to me that having
both syntaxes is worse than having either one.  Suppose I'm used to
writing (and therefore reading) a[5] -- then I can't read other people's
code so easily, if they like the other convention.  Reading other
people's code is important.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Robert Dewar]

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

In article <7g72rf$hjh3@ftp.kvaerner.com>,
  "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no>
wrote:
> What would a(5) := 4;

if a represents a function from an abstract point of view,
it does not mean a blithering thing. The fact that a is
implemented as an array is irrelevant. Indeed presumably
a reasonable choice for implementing a conceptual function
as an array would be to use a constant array, where the
above assignment would be illegal.

Which in my opinion voids the function opposition to the
common convention of using square brackets for array
indices.

There is no such *common* convention. There are *two*
common conventions in this case () and [], and plenty
of examples of languages using both (for example, Fortran,
PL/1, COBOL, Ada, all use (), and Algol derived languages
tend to use []).

But to call one of these common is simply tunnel vision.
You cannot argue this point on the basis of what is common.
Sure, for a given person (I assume you grew up in a C
heritage) one usage may seem more natural [the brackets
seem more natural to me because I am used to them from
Algol-68], but that's not a useful way to argue.

The referential transparency argument is a quite reasonable
one, and your assignment example does not refute it!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> There is no such *common* convention. There are *two*
> common conventions in this case () and [], ...

I guess the most *common* convention, or at least the most traditional
one, is to write a subscript in a smaller font, lowered slightly with
respect to the preceding text, as in:

    A
     i

(sort of -- I can't type what I mean here).  Haven't mathemeticians been
doing that for hundreds of years, and wasn't the A[i] notation invented
to get around the fact that the traditional subscript notation was
impossible using typical computer equipment?

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Tarjei Tj�stheim Jensen]

Robert Dewar wrote :
>There is no such *common* convention. There are *two*
>common conventions in this case () and [], and plenty
>of examples of languages using both (for example, Fortran,
>PL/1, COBOL, Ada, all use (), and Algol derived languages
>tend to use []).

I forgot about cobol and fortran. It's been a long time since I have anything
in either.
>
>But to call one of these common is simply tunnel vision.
>You cannot argue this point on the basis of what is common.
>Sure, for a given person (I assume you grew up in a C
>heritage) one usage may seem more natural [the brackets
>seem more natural to me because I am used to them from
>Algol-68], but that's not a useful way to argue.

I grew up with Pascal (UCSD and Turbo).

>The referential transparency argument is a quite reasonable
>one, and your assignment example does not refute it!


That was not the argument which the example was supposed to refute. The
argument was about the view of an array as a function. I was hoping that nobody
would remember the referential transparancy argument.

While it is a valid argument it is just as weak as any other argument since
things subject to such use should be wrapped in a (inlined) function in the
first place.


Greetings,

Re: Question for the folks who designed Ada95

[Bill Ghrist]

We have tens of thousands of lines of safety-critical code written in
PL/M-86, which uses "()" for both arrays and functions.  I'm pretty
certain that we have never had any problems caused by people confusing
the two usages. 

Regards,
Bill Ghrist

Robert Dewar wrote:
> 
> In article <7g72rf$hjh3@ftp.kvaerner.com>,
>   "Tarjei Tj stheim Jensen" <tarjei.jensen@kvaerner.no>
> wrote:
> > What would a(5) := 4;
> 
> if a represents a function from an abstract point of view,
> it does not mean a blithering thing. The fact that a is
> implemented as an array is irrelevant. Indeed presumably
> a reasonable choice for implementing a conceptual function
> as an array would be to use a constant array, where the
> above assignment would be illegal.
> 
> Which in my opinion voids the function opposition to the
> common convention of using square brackets for array
> indices.
> 
> There is no such *common* convention. There are *two*
> common conventions in this case () and [], and plenty
> of examples of languages using both (for example, Fortran,
> PL/1, COBOL, Ada, all use (), and Algol derived languages
> tend to use []).
> 
> But to call one of these common is simply tunnel vision.
> You cannot argue this point on the basis of what is common.
> Sure, for a given person (I assume you grew up in a C
> heritage) one usage may seem more natural [the brackets
> seem more natural to me because I am used to them from
> Algol-68], but that's not a useful way to argue.
> 
> The referential transparency argument is a quite reasonable
> one, and your assignment example does not refute it!
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: Question for the folks who designed Ada95

[dennison]

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

In article <7g72rf$hjh3@ftp.kvaerner.com>,
  "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> wrote:
>
> Robert Dewar wrote :
> >
> >In other words:
> >
> >  a(5)
> >
> >is a reference to a mapping, and you want the range value
> >given the domain value 5. Whether this is implemented by
> >an array or a function is an implementation detail that
> >should not affect the syntactic form of reference.
>
> What would a(5) := 4; mean then? You cannot assign to a function as far as I
> know. Which in my opinion voids the function opposition to the common
> convention of using square brackets for array indices.

A mapping is typically static, and would thus be represented by a *constant*
array. Assigning to that is illegal as well.

I have actually had this come in handy. I had a data structure that was a
mapping implemented as a constant array that was used by about 10 other s/w
engineers. Things got complicated and I had to reimplement it as a function.
None of them had to change a line of code.


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g7g3j$f95$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> I have actually had this come in handy. I had a data
> structure that was a mapping implemented as a constant
> array that was used by about 10 other s/w engineers.
> Things got complicated and I had to reimplement it as a
> function. None of them had to change a line of code.

And that of course is what referential transparency is
all about. Nice to hear of an actual case where the theory
turned out to be pragmatically useful.

What is missing from this discussion is an argument that
it is advantageous to distinguish array and function
references ... Yes, people want [] because they are
used to it from (some) other languages, but that's a
very weak argument.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> What is missing from this discussion is an argument that
> it is advantageous to distinguish array and function
> references ... Yes, people want [] because they are
> used to it from (some) other languages, but that's a
> very weak argument.

Function calls can have side effects; array indexing does not.
It seems useful to distinguish those two.

I have also pondered the idea of having a language where function calls
with side effects have a different notation than function calls without.
Or perhaps I mean function calls with side effects or that depend on
side effects, vs pure mathematical functions.  This would require a fair
amount of additional information in the program about which functions
can read/write which variables.  Of course the rules would be
conservative, as all compile-time rules must be (unless, of course, you
can figure out how to solve the halting problem ;-)) -- I guess
memo-izing functions would have to look impure to the compiler, even
though they might be provably pure at some level of abstraction.  Ada
has pragma Pure, which is a step in the direction I'm thinking about.

You can tell I'm not in the fanatically anti-side-effect camp.  It seems
to me that *most* side effects in functions are bad, but some are fairly
harmless, and it would at least be nice to be able to tell the
difference easily when reading the code.  In fact, the ability to tell
the difference easily would make side effects *less* harmful -- the main
reason they're bad, is that they surprise you.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Brian Hanson]

Robert A Duff wrote:

> Robert Dewar <robert_dewar@my-dejanews.com> writes:
>
> > What is missing from this discussion is an argument that
> > it is advantageous to distinguish array and function
> > references ... Yes, people want [] because they are
> > used to it from (some) other languages, but that's a
> > very weak argument.
>
> Function calls can have side effects; array indexing does not.
> It seems useful to distinguish those two.

Arrays are potentially modifiable, functions are not.

giving

    pure functions =similar to= constant arrays
    functions with side affects
    non constant arrays.

Should it be usefull to syntatically distinguish between all these.

Brian Hanson

Re: Question for the folks who designed Ada95

[bill]

In article <37278218.ADE17A46@lawson.com>, Brian says...
 >
>> Robert Dewar <robert_dewar@my-dejanews.com> writes:
>>
>> > What is missing from this discussion is an argument that
>> > it is advantageous to distinguish array and function
>> > references ... Yes, people want [] because they are
>> > used to it from (some) other languages, but that's a
>> > very weak argument.
>>

>> Function calls can have side effects; array indexing does not.
>> It seems useful to distinguish those two.
>
>Arrays are potentially modifiable, functions are not.
>
>giving
>
>    pure functions =similar to= constant arrays
>    functions with side affects
>    non constant arrays.
>
>Should it be usefull to syntatically distinguish between all these.
 
you guys are all arguing like language lawyers (may be because you are :)

we, your average run-of-the-mill programmers do not care about all this
mumble jumble.  

All what we know, is that looking at something written as a[i] tells 
right away that it is an array, while with a(i) you are not sure what 
it is in Ada.

If Iam maintaining someone else's code, it helps me to understand the code 
faster that way.

Someone argument about them modifying the array to a function and not breaking
someone else code (becuase in Ada "()" is used instead of "[]") is a 
very weak argument. In the real world, one would design their data to 
be hidden from users, and have access methods to read/write to it, (can we
says OO here?) and so, users would never care if you used arrays or 
functions anyway. you should use 'messages' :)

bill

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g8390$225c@drn.newsguy.com>,
  bill@nospam wrote:

> All what we know, is that looking at something written as
> a[i] tells  right away that it is an array, while with
> a(i) you are not sure what it is in Ada.
>
> If I am maintaining someone else's code, it helps me to
> understand the code faster that way.

This seems a very weak argument to me. It is only narrowly
separated from the peculiar thinking that leads to people
actually liking so-called Hungarian notion in which type
information is encoded in variable names.

I must say (as someone who slightly favors [] just because
of familiarity) that I have never seen well written code
with well chosen names where this kind of confusion arose.
Maybe bill@nospam is too used to reading junk code which
is not well written in this sense :-)

You dismiss arguments as being to "language lawyer" but
that may mean you don't fully understand them. In fact
the referential transparency argument is a strong one.
If you don't see that, then you are definitely missing
something (in general in a technical argument if you cannot
argue both sides of an issue, it means you don't understand
it well enough to be arguing :-)

You can still decide that the RT argument is not strong
enough to win out, but to dismiss it means you are missing
something.

P.S. The notion that everything should be done with
messages makes as much sense as any fad (e.g. purely
applicative programming with no assignments, single
assignment languages, dataflow languages, purely
functional programming, pure logic programming) etc
all these are useful techniques, but when you try to
say they are the ONLY technique that should be used
you are treading on dangerous ground.

By the way, please don't get abstract data types and
objects mixed up in your mind (such a common mistake
for C++ programmers to make, not surprising given the
design of the language). Yes, data abstraction is
definitely a powerful tool, one that has very wide
applicability, as has been known for at least 30 years.
The notion of object oriented programming (also of course
known for over 30 years -- remember the language name is
Simula 67 :-) is also a powerful tool, but they are not
by any means synonymous.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Pat Rogers]

Robert Dewar <robert_dewar@my-dejanews.com> wrote in message
news:7g8g5j$cmt$1@nnrp1.dejanews.com...
<snip>
> If you don't see that, then you are definitely missing
> something (in general in a technical argument if you cannot
> argue both sides of an issue, it means you don't understand
> it well enough to be arguing :-)

The ability to argue both sides is certainly one of your signature
characteristics!  :-)

(Said as a compliment.)


--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com       Software Fault Tolerance
(281)648-3165                        Real-Time/OO Languages

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <925355990.675.30@news.remarQ.com>,
  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> The ability to argue both sides is certainly one of your
> signature characteristics!  :-)
>
> (Said as a compliment.)

Thankyou, I take it as a compliment :-)

Once John Goodenough and I were planning a debate at a
SigAda meeting, where the topic would be announced in
advance, but we would decide by a flip of a coin at the
start of the session who would take which side, but we
did not get around to following through. A pity, would
have been fun :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[dennison]

In article <7g9kef$aco$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <925355990.675.30@news.remarQ.com>,
>   "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> > The ability to argue both sides is certainly one of your
> > signature characteristics!  :-)
> >
> > (Said as a compliment.)
>
> Thankyou, I take it as a compliment :-)
>
> Once John Goodenough and I were planning a debate at a
> SigAda meeting, where the topic would be announced in
> advance, but we would decide by a flip of a coin at the
> start of the session who would take which side, but we
> did not get around to following through. A pity, would
> have been fun :-)

Frankly, I'm not sure anyone else would have noticed the difference. :-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Pat Rogers]

<dennison@telepath.com> wrote in message
news:7g9s54$ho0$1@nnrp1.dejanews.com...
> In article <7g9kef$aco$1@nnrp1.dejanews.com>,
>   Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> > In article <925355990.675.30@news.remarQ.com>,
> >   "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> > > The ability to argue both sides is certainly one of your
> > > signature characteristics!  :-)
> > >
> > > (Said as a compliment.)
> >
> > Thank you, I take it as a compliment :-)
> >
> > Once John Goodenough and I were planning a debate at a
> > SigAda meeting, where the topic would be announced in
> > advance, but we would decide by a flip of a coin at the
> > start of the session who would take which side, but we
> > did not get around to following through. A pity, would
> > have been fun :-)
>
> Frankly, I'm not sure anyone else would have noticed the difference.
:-)

Sometimes it would be noticeable.  I have it on good authority that
Robert was once told by Christine Anderson, prior to a meeting in which
they were to convince some group of people that Ada 9X was a "good
thing", words to the effect that "once we get them convinced don't
switch sides!!".

:-)

Re: Question for the folks who designed Ada95

[Robert S. White]

In article <7g8390$225c@drn.newsguy.com>, bill@nospam says...
>
>All what we know, is that looking at something written as a[i] tells 
>right away that it is an array, while with a(i) you are not sure what 
>it is in Ada.

  And just why do you need to know the implementation when you are just
an oo user of the object?   Can we say "loosely coupled" here?

>If Iam maintaining someone else's code, it helps me to understand the code 
>faster that way.

   Ah but a maintainer _hopefully_ has a smart editor/browser that knows
how to quickly pop up the body's source text - like "visit body" under
Rational Apex.

>Someone argument about them modifying the array to a function and not breaking
>someone else code (becuase in Ada "()" is used instead of "[]") is a 
>very weak argument.

  But, but,  IMHO it is a good argument!  The users of the object/package
don't have to edit their source code when the implementation changes.  No
module version control check outs, edits, check ins, code inspections, etc.
Just a new full up link and integration/regression tests are required.  A
lot less staff effort and expense!

> In the real world, one would design their data to 
>be hidden from users, and have access methods to read/write to it, (can we
>says OO here?) and so, users would never care if you used arrays or 
>functions anyway. you should use 'messages' :)

  Nope...don't use "messages", instead just use accessor functions.
Seems like my "real world" and yours differs :)
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of ( add .'s ):  net mcleodusa shift2 r white
             or do a "Reply To All" for direct eMailed cc'd followups.

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g8drh$1q00$1@odie.mcleod.net>,
  RSWhite@nospam.somewhere.ia.us (Robert S. White) wrote:
> In article <7g8390$225c@drn.newsguy.com>, bill@nospam
says...
> >
> >All what we know, is that looking at something written
> >as a[i] tells
> >right away that it is an array, while with a(i) you are
> >not sure what
> >it is in Ada.
>
>   And just why do you need to know the implementation
>  when you are just
> an oo user of the object?   Can we say "loosely coupled"
> here?

What has oo got to do with this. It is just a matter of
data abstraction. Abstract data types and objects are not
the same thing!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert S. White]

In article <7g9kgl$adp$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com says...
>
>In article <7g8drh$1q00$1@odie.mcleod.net>,
>  RSWhite@nospam.somewhere.ia.us (Robert S. White) wrote:

>>   And just why do you need to know the implementation
>>  when you are just
>> an oo user of the object?   Can we say "loosely coupled"
>> here?
>
>What has oo got to do with this. It is just a matter of
>data abstraction. Abstract data types and objects are not
>the same thing!

  I was reacting to the general oo comments in the previous post.
Does not oo use data abstraction as one of its building blocks?  But
I see your point in that what we are discussing in a more 
general sense are features of using ADTs.

  I'm caught again arguing with a professor ;-)
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of ( add .'s ):  net mcleodusa shift2 r white
             or do a "Reply To All" for direct eMailed cc'd followups.

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g8drh$1q00$1@odie.mcleod.net>,
  RSWhite@nospam.somewhere.ia.us (Robert S. White) wrote:
>  Ah but a maintainer _hopefully_ has a smart
>  editor/browser that knows
> how to quickly pop up the body's source text - like
> "visit body" under Rational Apex.

This is a very important function, and I think of it as
one of the most important features in GNAT Ada mode that
you can get to the declaration of any identifier with a
click (visit body sounds a bit too specific, how do you
know it is a function -- that's the point here, right?)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert S. White]

In article <7g9qm9$g5f$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com says...
>
>In article <7g8drh$1q00$1@odie.mcleod.net>,
>  RSWhite@nospam.somewhere.ia.us (Robert S. White) wrote:
>>  Ah but a maintainer _hopefully_ has a smart
>>  editor/browser that knows
>> how to quickly pop up the body's source text - like
>> "visit body" under Rational Apex.
>
>This is a very important function, and I think of it as
>one of the most important features in GNAT Ada mode that
>you can get to the declaration of any identifier with a
>click (visit body sounds a bit too specific, how do you
>know it is a function -- that's the point here, right?)

  Right.  "visit body" seems to do the right thing when
you are pointing at a pure data item - so maybe a better
semantic term should have been "show implementation".

  That reminds me that I need to update/reinstall NT EMACS
and GNAT Ada mode on this home PC.
 
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of ( add .'s ):  net mcleodusa shift2 r white
             or do a "Reply To All" for direct eMailed cc'd followups.

Re: Question for the folks who designed Ada95

[dennison]

In article <7gav03$pbu$2@odie.mcleod.net>,
  RSWhite@nospam.somewhere.ia.us (Robert S. White) wrote:

>   That reminds me that I need to update/reinstall NT EMACS
> and GNAT Ada mode on this home PC.

If you are using Gnat 3.11p then you get the latest Ada mode automagicly when
you run Gnat's install shield. I think that is the latest official version of
emacs-Ada mode, and all further work on the mode will be based off of it.

If you need to reinstall things, I'd suggest the following process:

  o  uninstall Gnat  o	reinstall emacs  o  if you have a custom
site-start.el in site-lisp, save that off to a backup file  o  install Gnat
3.11p  o  copy the contents of your backed-up site-start.el to the front of
the new site-start.el that the Gnat installer created

(Note: This is just a suggestion. Although it has worked for me in the past, I
take no responsibility for any system damage that may occur as the result of
following the above steps)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <wcczp3sd2s8.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> I have also pondered the idea of having a language where function
> calls with side effects have a different notation than function calls
> without.

But the trouble is that the concept of a function with side effects
is a conceptual one, not one that can be usefully defined or
enforced.

Which of the following have side effects

1. A function that delays ten seconds before returning by looping
2. A memo function using an internal table
3. A function with instrumentation logging parameters used to call it

I would say typically that 1. had side effects, and that 2 and 3 do
not, but any formal attempt to distinguish the concepts (let alone
insist on different syntax) would probably make exactly the opposite
categorization!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Larry Kilgallen]

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

In article <7g72rf$hjh3@ftp.kvaerner.com>, "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> writes:

> What would a(5) := 4; mean then? You cannot assign to a function as far as I
> know. Which in my opinion voids the function opposition to the common
> convention of using square brackets for array indices.

As you obviously figured out, it works for X := A(5).
Yes, this is not symmetric, the way Bliss structures are.
But Ada is not Bliss, and like all languages it is a compromise.

> I don't mind if the function addicts still writes a(5) := 4, if I can write
> a[5] := 4.

I don't care what you write, I just want uniformity in what I read,
which is why I want uniformity in what compilers accept.  I would
not have minded if [] had been used all around instead of (), but
that was not the case.

Larry Kilgallen

Re: Question for the folks who designed Ad

[David Kristola]

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


In article hjh3@ftp.kvaerner.com, "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> () writes:
>
>Robert Dewar wrote :
>>
>>In other words:
>>
>>  a(5)
>>
>>is a reference to a mapping, and you want the range value
>>given the domain value 5. Whether this is implemented by
>>an array or a function is an implementation detail that
>>should not affect the syntactic form of reference.
>
>
>What would a(5) := 4; mean then? You cannot assign to a function as far as I
>know. Which in my opinion voids the function opposition to the common
>convention of using square brackets for array indices.
>
>I don't mind if the function addicts still writes a(5) := 4, if I can write
>a[5] := 4.
>
>Greetings,
>
>
>

a(5).some_value := 4;

Maybe the function a returns a pointer to a record structure...

--djk
Home: David95037 at aol dot com
Work: use my home email address

Re: Question for the folks who designed Ad

[Paul Duquennoy]

David Kristola wrote:
> 
> In article hjh3@ftp.kvaerner.com, "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> () writes:
> >
> >Robert Dewar wrote :
> >>
> >>In other words:
> >>
> >>  a(5)
> >>
> >>is a reference to a mapping, and you want the range value
> >>given the domain value 5. Whether this is implemented by
> >>an array or a function is an implementation detail that
> >>should not affect the syntactic form of reference.
> >
> >
> >What would a(5) := 4; mean then? You cannot assign to a function as far as I
> >know. Which in my opinion voids the function opposition to the common
> >convention of using square brackets for array indices.
> >
> >I don't mind if the function addicts still writes a(5) := 4, if I can write
> >a[5] := 4.
> >
> >Greetings,
> >
> >
> >
> 
> a(5).some_value := 4;
> 
> Maybe the function a returns a pointer to a record structure...
> 

Absolutely, and this is useful. An early version of a package can use an array 
to implement a feature, but later it can be changed to a more sophisticated
approach 
using a cache (e.g. if there are too many unused entries in the array) without
disturbing the existing code.

It is then clear that the 'a(5)' is a way to access some data, regardless of
its 
implementation. Ada allows very minimal impact on the code in such circumstances.

The 'auto-dereferencing' of pointers in Ada (vs '->' in C) also gives more flexibility
to change the implementation from actual data to accesses and vice-versa.

Re: Question for the folks who designed Ada95

[Aidan Skinner]

On Tue, 27 Apr 1999 14:18:38 +0200, Tarjei Tj�stheim Jensen
<tarjei.jensen@kvaerner.no> wrote: 

>Arrays as functions? Since when could you assign to a function??

Dont think of it as 
      a(5) := b;
     
but as
     a(5).all := b;

where you're not assigning to a function, but to an object via a pointer.

- Aidan
-- 
"Rotary barrel death stars: for when you absoloutely, positively, have
to obliterate every planet in the system"
http://www.skinner.demon.co.uk/aidan/
http://www.gla.ac.uk/Clubs/WebSoc/~9704075s/

Re: Question for the folks who designed Ada95

[Matthew Heaney]

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

aidan@skinner.demon.co.uk (Aidan Skinner) writes:

> On Tue, 27 Apr 1999 14:18:38 +0200, Tarjei Tj�stheim Jensen
> <tarjei.jensen@kvaerner.no> wrote: 
> 
> >Arrays as functions? Since when could you assign to a function??
> 
> Dont think of it as 
>       a(5) := b;
>      
> but as
>      a(5).all := b;
> 
> where you're not assigning to a function, but to an object via a pointer.


The Dijkstra/Gries school views an array as a function.  Instead of
assigment to one element of the array, you look at it as changing the
entire value of the function.  

The Science of Programming, by David Gries
A Discpline of Programming, by Edsger Dijkstra








  

  

Re: Question for the folks who designed Ada95

[Corey Ashford]

Robert Dewar wrote:
> 
> In article <7g2qu4$ca4$1@usenet.rational.com>,
>   "Corey Ashford" <yeroca@rocketmail.com> wrote:
> >
> > The problem with the interfaces package shift
> > operators is that they have fixed types.  So it's
> > difficult to write code for types whose size can vary.
> 
> What we do in GNAT to address this problem is to make the
> shift operators intrinsics. Here is a typical declaration
> from the Interfaces spec:
> 
>    pragma Import (Intrinsic, Shift_Left);
> 
> The nice thing about this approach is that indeed you
> *can* apply this intrinsic to a user defined type. For
> example you can put the following in your code.
> 
>   type My_Modular is mod 2**Integer'Size;
>   function Shift_Left
>      (Value  : My_Modular;
>       Amount : Natural)
>       return   My_Modular;
>   pragma Import (Intrinsic, Shift_Left);
> 
> and this will work fine. Of course this is not guaranteed
> to be portable (perhaps the ARG should look at this one,
> since it is a perfectly legitimate implementation
> decision).
> 

Thanks for the idea!  I'll look into this one.

- Corey

Re: Question for the folks who designed Ada95

[Samuel Mize]

Corey Ashford <yeroca@rocketmail.com> wrote:
> 
> About modular types.
...
> Why didn't Ada95 make a shift operator a first-class
> operator on modular types.
...
> The problem with the interfaces package shift
> operators is that they have fixed types.  So it's
> difficult to write code for types whose size can vary.
...
> Any thoughts as to why the shift operator wasn't given
> a better treatment?

I'm not one of "the folks who designed Ada95" but I have a guess.

I expect it was because shifting is usually a low-level thing to do,
which comes up in interfaces to the machine.  So, the concern was to
make it available for the types that have direct machine support on a
given architecture.  Nobody cared about other moduluses (modulii?).

Also, bear in mind that modular types don't have to have a power-of-2
modulus.  Consider a mod 5 type.  If its value before shifting is
three, its lowest four bits are:

  0011

Shift left 1, and its bits are:

  0110

which is 6, which is out of range for the type.  Should we get a
constraint error, or should it saturate to 5, or should it wrap to 6
mod 5 (0001)?  The last makes the most sense, in terms of modular
numbers, and would do what you want for a power-of-two modulus.  But
it destroys the meaning of shifting.

Any of the above adds complexity -- you're no longer doing an
efficient shift operation, but shifting and checking constraints.  Of
course, you could expect a compiler to elide all this in the case of a
power-of-two modulus.  But you can't test for that, so you can't make
it a requirement.  It's reasonable behavior to expect, but so is
implementing division by a constant power of two as a simple shift.


> Or am I all wet, and there's really a good way to do shifts?

For a non-hardware-supported power-of-two-modulus unsigned type, you
will need to do a shift, then mask the result down under your modulus.
You can do this with a type from Interfaces that has more bits than
your type.  For instance:

  with Interfaces; use Interfaces;
  ...
  type My_Type is mod 2 ** 30;
  My_Var: My_Type;
  ...
  My_Var := My_Type (Shift_Left (Unsigned_32 (My_Var), 3) mod 2 ** 30);

The conversion to Unsigned_32 should take no cycles, it's implicit
in reading the value into a register to work on it.

The mod 2**30 has to be done anyway, as I described above, since the
machine doesn't directly support a mod 2**30 type (or it would be in
Interfaces).  I'd expect a mod operation using a static power of two
to be implemented as a simple bit-mask operation.

I wouldn't expect the conversion to My_Type to do a range check, since
the compiler can tell statically that the value can't be out of range.
If you're extremely exercised about CPU time you'll be compiling with
range-checks off anyway.

So this should be as efficient as possible.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Question for the folks who designed Ada95

[Samuel Mize]

Samuel Mize <smize@imagin.net> wrote:
> Corey Ashford <yeroca@rocketmail.com> wrote:
>> 
>> About modular types.
> ...
>> Why didn't Ada95 make a shift operator a first-class
>> operator on modular types.

I looked again at Matthew Heany's response, and this time noted the
second A.  For those who don't know, the AARM is the Annotated Ada
Reference Manual.

His reference, AARM B.2 (9.a), says that they didn't want to add a new
operator, and that "all predefined operations should be operators (not
functions named by identifiers)."  I'm not sure what that means, in
light of existing Intrinsic attribute functions like 'Min and 'Pred.

Besides the points in my other post, I'd note that Ada generally
assumes you're using a compiler that optimizes well, if optimization
is an issue.  So we expect the compiler to manage things like deciding
whether to shift or divide, and the programmer manage things like data
structures, algorithms and high-level programming constructs.  If you
have to hand-optimize a million-line program, you're doomed anyway.

When you *do* need to worry about it, for some small program or for a
crucial section, you can generally find an optimal way to code things.
But this isn't the first concern of the language, so the first approach
you think of won't always be the right one.

If you have to worry about line-by-line efficiency, you really have to
cuddle up to your compiler and learn a lot about it.  But that's true
for any language.  It's easier in C to convince yourself that you're
hand-optimizing something, but I've seen cases where doing so caused
SLOWER execution times, because the higher-level version was more
amenable to machine optimization.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <7g4mic$1sr0@news2.newsguy.com>,
  Samuel Mize <smize@imagin.net> wrote:
> If you have to worry about line-by-line efficiency, you
> really have to cuddle up to your compiler and learn a lot
> about it.

The issue here (as described in detail in the AARM) has
nothing whatsoever to do with compiler or runtime
efficiency, it is purely a semantic concern). Here is
the full quote from the AARM if people do not have it
at hand:

<<AARM B.2 (9-a)>>

9.a   Reason:  We considered making shifting and rotating
be primitive operations of all modular types.  However, it
is a design principle of Ada that all predefined operations
should be operators (not functions named by identifiers).
(Note that an early version of Ada had "abs" as an
identifier, but it was changed to a reserved word operator
before standardization of Ada 83.)  This is important
because the implicit declarations would hide
non-overloadable declarations with the same name,
whereas operators are always overloadable.

Therefore, we would have had to make shift and rotate into
reserved words, which would have been upward incompatible,
or else invent new operator symbols, which seemed like too
much mechanism.

<<end of quote>>

This seems quite straightforward and convincing!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Samuel Mize]

Robert Dewar <robert_dewar@my-dejanews.com> wrote:
>Here is
> the full quote from the AARM if people do not have it
> at hand:
...
> This seems quite straightforward and convincing!

Well, not to me, but only because I don't understand it.
I copied the AARM quote below.

Can someone explain to me why, for instance, 'Min isn't considered a
predefined operation?  It's predefined, it operates on objects of the
given type.  But it wasn't made an operator, so it apparently wasn't
considered a predefined operation.

I'm not arguing against the passage, I'd just like some help
understanding it.

Best,
Sam

> 
> <<AARM B.2 (9-a)>>
> 
> 9.a   Reason:  We considered making shifting and rotating
> be primitive operations of all modular types.  However, it
> is a design principle of Ada that all predefined operations
> should be operators (not functions named by identifiers).
> (Note that an early version of Ada had "abs" as an
> identifier, but it was changed to a reserved word operator
> before standardization of Ada 83.)  This is important
> because the implicit declarations would hide
> non-overloadable declarations with the same name,
> whereas operators are always overloadable.
> 
> Therefore, we would have had to make shift and rotate into
> reserved words, which would have been upward incompatible,
> or else invent new operator symbols, which seemed like too
> much mechanism.
> 
> <<end of quote>>

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Question for the folks who designed Ada95

[Samuel Mize]

Samuel Mize <smize@imagin.net> wrote:
> Robert Dewar <robert_dewar@my-dejanews.com> wrote:
>>Here is
>> the full quote from the AARM if people do not have it
>> at hand:
> ...
>> This seems quite straightforward and convincing!
> 
> Well, not to me, but only because I don't understand it.

Robert Duff's comment in another branch of this thread
clarified this point, thanks.

Sam

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Question for the folks who designed Ada95

[Corey Ashford]

Robert Dewar wrote:
[snip]
> 
> Therefore, we would have had to make shift and rotate into
> reserved words, which would have been upward incompatible,
> or else invent new operator symbols, which seemed like too
> much mechanism.
> 
> <<end of quote>>
> 
> This seems quite straightforward and convincing!

Sure, but it still doesn't explain why 'shift_left, etc.
weren't defined, when 'max, 'pred already set a precedence
for making operators named by identifiers.

- Corey

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <3726A3FF.E999AB49@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:
> Sure, but it still doesn't explain why 'shift_left, etc.
> weren't defined, when 'max, 'pred already set a
> precedence for making operators named by identifiers.

max, pred etc are NOT operators!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Corey Ashford]

Robert Dewar wrote:
> 
> In article <3726A3FF.E999AB49@rocketmail.com>,
>   Corey Ashford <yeroca@rocketmail.com> wrote:
> > Sure, but it still doesn't explain why 'shift_left, etc.
> > weren't defined, when 'max, 'pred already set a
> > precedence for making operators named by identifiers.
> 
> max, pred etc are NOT operators!
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Operator was the wrong word.  Function would be more accurate.
Why no 'shift_left function?

- Corey

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <3727EA10.34D0AB3B@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:
> Why no 'shift_left function?

That seems to me to be unnecesary complexity. It would
mean having to define the shifts for all possible modular
types, which is really overkill.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Fraser Wilson]

paene lacrimavi postquam Robert Dewar scripsit:

>In article <3727EA10.34D0AB3B@rocketmail.com>,
>  Corey Ashford <yeroca@rocketmail.com> wrote:
>> Why no 'shift_left function?

>That seems to me to be unnecesary complexity. It would
>mean having to define the shifts for all possible modular
>types, which is really overkill.

I'm torn.  On the one hand, restricting modular types to powers of 2 would
have been an arbitrary-looking quite un-Ada-like restriction.  On the
other, modular types which aren't a power of 2 cause an astonishingly
low gain to pain ratio.

Were it not for the non-power-of-2 modular types, I can't see that
Shift_Left and Shift_Right attributes would be difficult to justify.

Fraser.
(trying and failing to think of a good syntax for a modular type
the expresses only the power of 2 that forms the modulus ... hmmmm)

Re: Question for the folks who designed Ada95

[Robert Dewar]

In article <925401850.901.27@news.remarQ.com>,
  Fraser Wilson <fraser@sinopsis.com> wrote:
> I'm torn.  On the one hand, restricting modular types to
> powers of 2 would have been an arbitrary-looking quite
> un-Ada-like restriction.

Oh I don't know, perhaps you might even have decided
on a declaration something like

  A : Unsigned 16;

where 16 is the number of bits :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Question for the folks who designed Ada95

[Marin David Condic]

Fraser Wilson wrote:
> 
> I'm torn.  On the one hand, restricting modular types to powers of 2 would
> have been an arbitrary-looking quite un-Ada-like restriction.  On the
> other, modular types which aren't a power of 2 cause an astonishingly
> low gain to pain ratio.
> 
> Were it not for the non-power-of-2 modular types, I can't see that
> Shift_Left and Shift_Right attributes would be difficult to justify.
> 
> Fraser.
> (trying and failing to think of a good syntax for a modular type
> the expresses only the power of 2 that forms the modulus ... hmmmm)

I like the notion of creating two different classes similar to Fixed and
Decimal types - giving you a choice of underlying implementation. You
could have "Modular" types which are restricted to powers of 2 and
"Wraparound" types which have no restrictions:

type My_Type is wrap 234..567 ;

That lets someone slide the wraparound semantics anywhere that is useful
to them and would probably make compilation simpler because of never
having to detect special cases.

Of course, now that Modular types are defined without restrictions to
powers of two, its impossible to ever get the situation reversed. Too
many programs will have some dependency on non-powers-of-2 so future
compilers will have to support it. No sense inventing a new class at
that point...

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: Question for the folks who designed Ada95

[Corey Ashford]

Samuel Mize wrote:
[snip]
> Besides the points in my other post, I'd note that Ada generally
> assumes you're using a compiler that optimizes well, if optimization
> is an issue.  So we expect the compiler to manage things like deciding
> whether to shift or divide, and the programmer manage things like data
> structures, algorithms and high-level programming constructs.  If you
> have to hand-optimize a million-line program, you're doomed anyway.
> 
> When you *do* need to worry about it, for some small program or for a
> crucial section, you can generally find an optimal way to code things.
> But this isn't the first concern of the language, so the first approach
> you think of won't always be the right one.
> 
> If you have to worry about line-by-line efficiency, you really have to
> cuddle up to your compiler and learn a lot about it.  But that's true
> for any language.  It's easier in C to convince yourself that you're
> hand-optimizing something, but I've seen cases where doing so caused
> SLOWER execution times, because the higher-level version was more
> amenable to machine optimization.

Thanks for all your thoughts, Samuel.

A couple of comments:

1) I decided not to go with divides and multiplies because the amount of the
shift that I need in my code is variable, so the expression would have to
be of the form  x * (2 ** y), where y is the amount of the shift.  I'd bet
most compilers and optimizers aren't set up to recognize this case as a variable
shift.  In fact, I know Apex doesn't because I tried it at full optimization.
Currently the compiler ends up treating it as a generic exponentiation operation
and calls a runtime routine for exponentiating modular values.  Note that Apex
does a fine job with x * (2 ** K), where K is a static constant, optimizing this to
a shift.

2) The code I'm writing is very time critical and has to use shifts.  I can't
afford for the compiler to generate any other code.  Believe me.  It ain't
a million lines... it's pretty small really, but it has to be portable across
several architectures and ABI's (64-bit vs. 32-bit, etc.).

3) Doing conversions to Interfaces.Unsigned_32 (or the like) doesn't work.  The
code has to be able to run on both 64-bit and 32-bit machines, and I need to
use the largest modular type possible.  On a 64-bit machine, it would be
Unsigned_64, but Interfaces.Unsigned_64 doesn't exist in the Interfaces package
on a 32-bit machine, so I would get a compilation error there.

So, using a combination of "type largest_modular_type is mod system.max_binary_modulus;"
and the "pragma import(Intrinsic, ...);" nicely solved the problem, at least for
Apex.

Thanks again,

- Corey

Re: Question for the folks who designed Ada95

[Corey Ashford]

Samuel Mize wrote:
[snip]
> Besides the points in my other post, I'd note that Ada generally
> assumes you're using a compiler that optimizes well, if optimization
> is an issue.  So we expect the compiler to manage things like deciding
> whether to shift or divide, and the programmer manage things like data
> structures, algorithms and high-level programming constructs.  If you
> have to hand-optimize a million-line program, you're doomed anyway.
> 
> When you *do* need to worry about it, for some small program or for a
> crucial section, you can generally find an optimal way to code things.
> But this isn't the first concern of the language, so the first approach
> you think of won't always be the right one.
> 
> If you have to worry about line-by-line efficiency, you really have to
> cuddle up to your compiler and learn a lot about it.  But that's true
> for any language.  It's easier in C to convince yourself that you're
> hand-optimizing something, but I've seen cases where doing so caused
> SLOWER execution times, because the higher-level version was more
> amenable to machine optimization.

Thanks for all your thoughts, Samuel.

A couple of comments:

1) I decided not to go with divides and multiplies because the amount of the
shift that I need in my code is variable, so the expression would have to
be of the form  x * (2 ** y), where y is the amount of the shift.  I'd bet
most compilers and optimizers aren't set up to recognize this case as a variable
shift.  In fact, I know Apex doesn't because I tried it at full optimization.
Currently the compiler ends up treating it as a generic exponentiation operation
and calls a runtime routine for exponentiating modular values.  Note that Apex
does a fine job with x * (2 ** K), where K is a static constant, optimizing this to
a shift.

2) The code I'm writing is very time critical and has to use shifts.  I can't
afford for the compiler to generate any other code.  Believe me.  It ain't
a million lines... it's pretty small really, but it has to be portable across
several architectures and ABI's (64-bit vs. 32-bit, etc.).

3) Doing conversions to Interfaces.Unsigned_32 (or the like) doesn't work.  The
code has to be able to run on both 64-bit and 32-bit machines, and I need to
use the largest modular type possible.  On a 64-bit machine, it would be
Unsigned_64, but Interfaces.Unsigned_64 doesn't exist in the Interfaces package
on a 32-bit machine, so I would get a compilation error there.

So, using a combination of "type largest_modular_type is mod system.max_binary_modulus;"
and the "pragma import(Intrinsic, ...);" nicely solved the problem, at least for
Apex.

Thanks again,

- Corey

Re: Question for the folks who designed Ada95

[Matthew Heaney]

"Corey Ashford" <yeroca@rocketmail.com> writes:

> Why didn't Ada95 make a shift operator a first-class
> operator on modular types.

See AARM95 B.1 (9.a)

Re: Question for the folks who designed Ada95

[Matthew Heaney]

Matthew Heaney <matthew_heaney@acm.org> writes:

> "Corey Ashford" <yeroca@rocketmail.com> writes:
> 
> > Why didn't Ada95 make a shift operator a first-class
> > operator on modular types.
> 
> See AARM95 B.1 (9.a)
               ^

Oops!  That should be AARM95 B.2 (9.a)

Re: Question for the folks who designed Ada95

[Corey Ashford]

Matthew Heaney wrote:
> 
> "Corey Ashford" <yeroca@rocketmail.com> writes:
> 
> > Why didn't Ada95 make a shift operator a first-class
> > operator on modular types.
> 
> See AARM95 B.1 (9.a)

Thanks, I did find that reference after posting, but I found the
explanation lame.  They didn't want to introduce a new
operator syntax and didn't want a function with a name
part of the language definition.
How was the max and min functions handled?  With attributes...
I don't see how this case is really any different.
Perhaps they didn't think of it, or at least didn't address
this possibility in the RM.

- Corey

Re: Question for the folks who designed Ada95

[Robert A Duff]

Corey Ashford <yeroca@rocketmail.com> writes:

> Thanks, I did find that reference after posting, but I found the
> explanation lame.  They didn't want to introduce a new
> operator syntax and didn't want a function with a name
> part of the language definition.
> How was the max and min functions handled?  With attributes...
> I don't see how this case is really any different.

You're right.  I'm not sure we ever thought about attributes, though it
seems obvious now.

Two other issues:

We didn't think it was necessary -- you can always multiply by 2 or
whatever.  Optimizing that to a shift instruction is trivial, and if you
care about efficiency, surely you should be using an optimizing compiler
that is *at least* that smart.  (After all, I want that optimization for
signed integers, too!)

It's not clear what shifting should mean if the modulus is not a power
of 2.  Robert has stated many times that that should never have been
allowed, and I tend to agree.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Keith Thompson]

Robert A Duff <bobduff@world.std.com> writes:
[...]
> We didn't think it was necessary -- you can always multiply by 2 or
> whatever.  Optimizing that to a shift instruction is trivial, and if you
> care about efficiency, surely you should be using an optimizing compiler
> that is *at least* that smart.  (After all, I want that optimization for
> signed integers, too!)

That's fine if the size of the shift is a constant, but as someone
else has pointed out, it's more difficult if it's a variable.  I
suppose a compiler could optimize
    
    X := X * 2**N;

to a shift instruction, but I'd hate to have to depend on it.

> It's not clear what shifting should mean if the modulus is not a power
> of 2.  Robert has stated many times that that should never have been
> allowed, and I tend to agree.

Do you mean that shifting should not be allowed for such types, or
that the types themselves should not be allowed?  Either way, I also
tend to agree.  Non-power-of-two modular types remind me of
enumeration representation clauses -- something that was added for the
sake of completeness, but that's more trouble to define and implement
than it's really worth.

If non-power-of-two modular types are really worth having in the
language, it might have been nice to make them a distinct class of
type, like decimal fixed-point vs. ordinary fixed-point.  That would
allow providing shifts as attributes without running into generic
contract model problems.  I think.

Disclaimer: I've been mostly out of touch with Ada for the last couple
of years, so I've probably made some mistakes.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.

Re: Question for the folks who designed Ada95

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> That's fine if the size of the shift is a constant, but as someone
> else has pointed out, it's more difficult if it's a variable.  I
> suppose a compiler could optimize
>     
>     X := X * 2**N;
> 
> to a shift instruction, but I'd hate to have to depend on it.

I suppose in this variable case it's not so trivial as to be universally
available, but it's still a feasible optimization (assuming the "2**"
is sitting there for the compiler to see).

One of our recently-validated compilers was in use for several months
(and of course passed all of the validation tests) before we discovered
a bug in our exponentiation run-time routine.  Apparently, the vast
majority of cases encountered in practise (and in the ACVC) where "**"
is used are static expressions, and so were correctly calculated at
compile time.  This implies that if the above optimization isn't done,
it's not commonly useful.  Which also implies that variable-length shift
operators are not commonly useful.

> > It's not clear what shifting should mean if the modulus is not a power
> > of 2.  Robert has stated many times that that should never have been
> > allowed, and I tend to agree.
> 
> Do you mean that shifting should not be allowed for such types, or
> that the types themselves should not be allowed?

I meant that Robert strongly believes that the language should not allow
non-power-of-two modular types.  And I (weakly) agree.  Actually, I have
a lot of complaints about the modular type feature.

Note that this feature was completely redesigned several times during
the Ada 9X design.  Sometimes I think the one we ended up with wasn't
particularly *better* than the others, it just happened to be the one
that was sitting there in the proposed standard document around the time
when we were starting to freeze things (no more large technical
changes).

> If non-power-of-two modular types are really worth having in the
> language, it might have been nice to make them a distinct class of
> type, like decimal fixed-point vs. ordinary fixed-point.  That would
> allow providing shifts as attributes without running into generic
> contract model problems.  I think.

At the expense of extra syntax and rules...

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Question for the folks who designed Ada95

[Marin David Condic]

Corey Ashford wrote:

> Thanks, I did find that reference after posting, but I found the
> explanation lame.  They didn't want to introduce a new
> operator syntax and didn't want a function with a name
> part of the language definition.
> How was the max and min functions handled?  With attributes...
> I don't see how this case is really any different.
> Perhaps they didn't think of it, or at least didn't address
> this possibility in the RM.
> 
One possible explanation for not making it an attribute is that it would
then have to apply to all possible modular types even if there were no
natural, underlying machine instruction to support it. For example if
you had:

type My_Type is mod 13 ;
X : My_Type ;

You would have to support:

X := My_Type'Shift_Left (X) ;

I'm not even sure if such an operation would make sense, much less be
something that could be implemented at all efficiently.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic