status of Ada STL?

status of Ada STL?

[Russ]

I am trying to determine the status of the Ada version of the C++
Standard Template Library. I see that this has been discussed in the
past on comp.lang.ada, but I don't see much on it in the past year or
so. Is it still in the works somewhere? How far along is it compared
to the C++ STL? And does Ada have any fundamental limitations that
preclude the full functionality of the C++ version? Thanks.

Re: status of Ada STL?

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> I am trying to determine the status of the Ada version of the C++
> Standard Template Library. I see that this has been discussed in the
> past on comp.lang.ada, but I don't see much on it in the past year or
> so. Is it still in the works somewhere? How far along is it compared
> to the C++ STL? And does Ada have any fundamental limitations that
> preclude the full functionality of the C++ version? Thanks.

As I recall, there is no one "Ada version of the STL"; there are
instead several. 

One is the Booch components, one is my SAL, there are others. See
http://www.adapower.com/ | Source Code | Source Code Packages for
reuse | scroll down to "component libraries". (Hmm, mine isn't
there!).

Hmm, I guess Grace could evolve into "the one", but that's not
currently it's stated goal.

-- 
-- Stephe

Re: status of Ada STL?

[Ted Dennison]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206132321.23d72ac8@posting.google.com>...
> I am trying to determine the status of the Ada version of the C++
> Standard Template Library. I see that this has been discussed in the

I vaguely remember someone talking about trying to clone the STL. I
don't think that's being actively worked on now.

There are efforts underway to expand Ada's standard library to include
a bit more stuff, including some stuff similar to things in the STL.
(Eg: Lists and Maps).

> to the C++ STL? And does Ada have any fundamental limitations that
> preclude the full functionality of the C++ version? Thanks.

As far as cloning the STL goes, one would run into a couple of
problems, I think. The first is that C++ templates use a kind of
structural equivalence for templates, rather than named equivalence
like Ada uses for generics. That means that its easier to make all the
C++ templates interoperate with each other than it would be for Ada
generics (there are drawbacks to that, though, which is why Ada
doesn't do it).

The second issue is that C++ templates allow a lot more options for
default template parameters than Ada generics do. This isn't fatal for
an Ada STL, but it would make the Ada clone of the STL much harder to
use than the C++ STL is.

Thirdly, there's a fair bit of stuff in the STL that Ada already has
or does not need. Strings, vectors, and bit sets are some examples.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: status of Ada STL?

[Ehud Lamm]

There were attempts by Musser and Stepanov using Ada IIRC, but the current
design of the STL uses many C++ specific "tricks".

There are many great Ada libraries around. What we still don't have is
containers and algorithms as part of the Ada standard library.

Many people are trying to help solve this problem. Check out the previous
couple on months on comp.lang.ada.

A few of us are going to meet an discuss how to help push this along, during
the Ada-Europe'2002 conference next week.
(http://www.auto.tuwien.ac.at/AE2002/program.html)

(If anyone reading this is at the conference, I'd love to chat about this
issue, over a glass of beer or a cup of coffee :-).

Ehud Lamm

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206132321.23d72ac8@posting.google.com...
> I am trying to determine the status of the Ada version of the C++
> Standard Template Library. I see that this has been discussed in the
> past on comp.lang.ada, but I don't see much on it in the past year or
> so. Is it still in the works somewhere? How far along is it compared
> to the C++ STL? And does Ada have any fundamental limitations that
> preclude the full functionality of the C++ version? Thanks.

Re: status of Ada STL?

[Dan Andreatta]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206132321.23d72ac8@posting.google.com>...
> I am trying to determine the status of the Ada version of the C++
> Standard Template Library. I see that this has been discussed in the
> past on comp.lang.ada, but I don't see much on it in the past year or
> so. Is it still in the works somewhere? How far along is it compared
> to the C++ STL? And does Ada have any fundamental limitations that
> preclude the full functionality of the C++ version? Thanks.

There is a SGL library around (Standard Generic Library ??), but
doesn't seem to be actively developed. Here is a link:

http://www.cs.columbia.edu/~akonstan/presentations/SGL/

Dan

Re: status of Ada STL?

[Russ]

"Ehud Lamm" <mslamm@huji.ac.il> wrote in message news:<aedgoc$to7$1@news.iucc.ac.il>...
> There were attempts by Musser and Stepanov using Ada IIRC, but the current
> design of the STL uses many C++ specific "tricks".

If only someone could get them interested again.

> There are many great Ada libraries around. What we still don't have is
> containers and algorithms as part of the Ada standard library.

I am an aerospace engineer at a government research center with a
major program on air traffic management. The controller support
systems developed here have traditionally been written in C, with a
gradual migration toward C++. I am trying to push Ada, but I am
encountering all kinds of resistance.

The main objection is usually that Ada programmers are too hard to
find. More recently, a top expert (a gcc maintainer) is claiming that
the STL overcomes many of the objections to C++. If Ada doesn't soon
have something comparable to STL that is reasonably stable and at
least on track for standardization, it could be in trouble.

A few years ago, the FAA was demanding that all our conroller support
systems eventually be rewritten in Ada. Now I have to practically beg
to get anyone to even consider Ada. It doesn't bode well, but perhaps
there is hope.

I also happen to think that Ada's awkward syntax is part of the
problem. My proposal for a cleaner Ada syntax option can be found at
http://RussP.org/Ada.htm

> Many people are trying to help solve this problem. Check out the previous
> couple on months on comp.lang.ada.
> 
> A few of us are going to meet an discuss how to help push this along, during
> the Ada-Europe'2002 conference next week.
> (http://www.auto.tuwien.ac.at/AE2002/program.html)

I wish you success.

> Ehud Lamm
> 
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0206132321.23d72ac8@posting.google.com...
> > I am trying to determine the status of the Ada version of the C++
> > Standard Template Library. I see that this has been discussed in the
> > past on comp.lang.ada, but I don't see much on it in the past year or
> > so. Is it still in the works somewhere? How far along is it compared
> > to the C++ STL? And does Ada have any fundamental limitations that
> > preclude the full functionality of the C++ version? Thanks.

Re: status of Ada STL?

[David Marceau]

> I am an aerospace engineer at a government research center with a
> major program on air traffic management. The controller support
> systems developed here have traditionally been written in C, with a
> gradual migration toward C++. I am trying to push Ada, but I am
> encountering all kinds of resistance.
Real numbers is what your boss wants.  Here's recent numbers :)
Page 24 of 
http://www.stsc.hill.af.mil/CrossTalk/2002/mar/mar02ind.asp
"Correctness by construction" 
This gives compelling evidence shows that focus on bug prevention rather
than
bug detection raises quality and saves time and money.
This approach was done using Spark(an ada subset) and full ada.

-try looking at March 2002 "COTS journal"
http://www.rtcgroup.com/cotsjournal/2002/03/cots03-cotsview.pdf
This gives a list of factors making ada increasingly popular.

> encountering all kinds of resistance.
IMHO Concerning pushing ada in a C/C++(or java) shop, be very careful
how you present your arguments for using Ada.
Make sure you catch him when he's feeling good and doesn't seem
preoccupied.
BTW it is practically a one-shot deal because if you approach him too
many times on wanting to change his direction,
he might think you're being insubordinate, you're not a team player,
you're not focusing on producing your c++ code 
and ..... Let's stay positive :)

I hope this helps.

Sant� bonheur,
David Marceau

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> The main objection is usually that Ada programmers are too hard to
> find. 

No worries, we get the same story from everywhere ;)

> More recently, a top expert (a gcc maintainer) is claiming that
> the STL overcomes many of the objections to C++. If Ada doesn't soon
> have something comparable to STL that is reasonably stable and at
> least on track for standardization, it could be in trouble.

Even if I don't agree with the claim that STL is the solution to have
Ada more widle used, did you look at the Booch Components ?

Every peoples have a "if Ada do that it will not be a dead language"
idea... but at this point there is so much :)

> I also happen to think that Ada's awkward syntax is part of the
> problem. My proposal for a cleaner Ada syntax option can be found at
> http://RussP.org/Ada.htm

Of course this is not Ada anymore... Do you think it is a good idea to
push a new language to have Ada more widely used ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Russ]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uu1o31wbb.fsf@wanadoo.fr>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > I also happen to think that Ada's awkward syntax is part of the
> > problem. My proposal for a cleaner Ada syntax option can be found at
> > http://RussP.org/Ada.htm
> 
> Of course this is not Ada anymore... Do you think it is a good idea to
> push a new language to have Ada more widely used ?

Yes, it IS still essentially Ada, because you can still use standard
Ada compilers. A simple pre-processor could convert the cleaner
dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
STANDARD ADA 95 COULD CONTINUE TO DO SO.

I really don't understand the objection to my proposal. Ada advocates
keep telling me they like Ada's syntax and it doesn't need to be
changed. But the question is not whether CURRENT Ada users like it;
the question is why so few OTHER programmers are showing any interest
in Ada, despite it's superior fundamental design.

When programmers take a first look at a new language, the first thing
they see is the syntax. Ever heard the old expression, "The first
impression is the most important one."? And no, I am not claiming that
my syntax proposal is the entire answer, but I do believe it would be
a modest step in the right direction.

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> I really don't understand the objection to my proposal. Ada advocates
> keep telling me they like Ada's syntax and it doesn't need to be
> changed. 

Have you ever considered that this could be true ?

> But the question is not whether CURRENT Ada users like it;
> the question is why so few OTHER programmers are showing any interest
> in Ada, despite it's superior fundamental design.

Because they want to use hyped language (today it is Java).
 
> When programmers take a first look at a new language, the first thing
> they see is the syntax. Ever heard the old expression, "The first
> impression is the most important one."?

Yep, and first time I have seen Ada it was a delightment for me... I think
that I would be free of the C crap... and I'm still free today :)


> And no, I am not claiming that
> my syntax proposal is the entire answer, but I do believe it would be
> a modest step in the right direction.

Good, go ahead, create the parser and let the futur decide...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Vinzent Hoefler]

18k11tm001@sneakemail.com (Russ) wrote:

>Yes, it IS still essentially Ada, because you can still use standard
>Ada compilers. A simple pre-processor could convert the cleaner
>dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
>STANDARD ADA 95 COULD CONTINUE TO DO SO.

Mmh. How do you convert a "/=" construct then?

And your "anyone who wants..." is no real argument. You then could
write a C++ to Ada-Preprocessor to get the same effect. We can going
on using Ada and the rest of the world can do their C++. Or do the
preprocessor the other way around, it might be easier.

>I really don't understand the objection to my proposal. Ada advocates
>keep telling me they like Ada's syntax and it doesn't need to be
>changed.

Yup. More or less this is the case. IMO the syntax is well chosen,
perhaps not perfect, but very good and clear.

>But the question is not whether CURRENT Ada users like it;
>the question is why so few OTHER programmers are showing any interest
>in Ada, despite it's superior fundamental design.

Because they are using C-like languages.

>When programmers take a first look at a new language, the first thing
>they see is the syntax.

Yes. But it is not this impression only that should let you decide.

>Ever heard the old expression, "The first
>impression is the most important one."? And no, I am not claiming that
>my syntax proposal is the entire answer, but I do believe it would be
>a modest step in the right direction.

And the next step would be to replace "begin end" by "{ }"? Well, if I
wanted C++, I wouldn't have chosen Ada. :->

Personally I like ":=" much more than "=". Although in Ada there would
be no possibility to do "if (a = b)" vs. "if (a == b)" like in C, I
like the slightly mathematically approach of saying "this gives"
instead of "this is equal" for assignments definitely more.

And what I definitely *hate* are those short-cut-constructs like "*="
that never say what they really do. I consider them as totally
unreadable: "a multiplied (with?) equal is 2? - What the heck is
that?" This goes against the data flow. An assignment operation should
be simple, left side is *where* to assign, right side is *what* to
assign.
Today's compilers are smart enough to let you not do such optimization
constructs and could let you use a clear and readable construct for
assigning a new value.

I love the way Ada does. You want an assignment? - So do that. Not the
C way: Ok, you can do it *this way* or you can do it *that way*.

I think the C++-way is wrong, so considering it integrating into an
Ada-like language would be the totally false way, IMO.

Sorry, just my opinion. But a lot of my arguments for the more clear
Ada-syntax simply would vanish in a haze then. :-)


Vinzent.

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> I really don't understand the objection to my proposal. 

I've read them all. I see nothing here that will make Ada read better. You
have 7 rules, all of them are very minor points and in each time your proposal
seems just more confusing to me.

I don't know if you have a more extensive description for your changes ? Do
you have examples ?

Let's try a simple one :

Here is the Ada version:

   procedure Dummy is

      subtype My_Int is Integer range 1 .. 1_024;

      procedure Proc (C : out My_Int; A, B : in My_Int := 1) is
         I : constant Integer := 9;
      begin
         if A = 12 then
            C := A + B + I;
         end if;

         C := C * (A + 2 * B);
      end Proc;

      R : My_Int;

   begin
      Proc (A => 2, B => 8, C => R);
   end Dummy;

Here is the Ada-F version :

   procedure Dummy is

      subtype My_Int is Integer range 1 : 1_024;

      procedure Proc (C : out My_Int; A, B = 1 : in My_Int) is
         I = 9 : constant Integer;
      begin
         if A == 12 then
            C = A + B + I
         end if;

         C *= (A + 2 * B)
      end Proc;

      R : My_Int;

   begin
      Proc (A = 2, B = 8, C = R)
   end Dummy

(I have not use rule 1 nor 7)

Are you still saying that Ada-F is looking better than Ada ?

One very nasty effect is "A, B = 1 : in My_Int" it looks like only B is
set to 1.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uu1o31wbb.fsf@wanadoo.fr>...
> 
>>Of course this is not Ada anymore... Do you think it is a good idea to
>>push a new language to have Ada more widely used ?
> Yes, it IS still essentially Ada, because you can still use standard
> Ada compilers. A simple pre-processor could convert the cleaner
> dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
> STANDARD ADA 95 COULD CONTINUE TO DO SO.

Then write the preprocessor and use it. If its so much better, other 
people will too.

I don't think I'd ever use it though. First off, I think it would make 
my sources much uglier. Secondly, it throws away some purposeful design 
  decisions (eg: not using similar looking operators like "==" and "=") 
for the apparent purpose of making the language look more like C. That's 
a stupid purpose in my book. Complaining that Ada doesn't look like C is 
the last gasp excuse of folks who just don't like Ada because it *isn't* 
C. There's nothing you can do to reach out to those folks. Just let them 
use C and be happy.

Re: status of Ada STL?

[Jeffrey Carter]

Vinzent Hoefler wrote:
> 
> Personally I like ":=" much more than "=". Although in Ada there would
> be no possibility to do "if (a = b)" vs. "if (a == b)" like in C, I
> like the slightly mathematically approach of saying "this gives"
> instead of "this is equal" for assignments definitely more.

Certainly ":=" is better than "=" for assignment, and replacing "=" with
"==" for equality is just stupid. But I've thought for decades that the
assignment symbol should not contain the "=" character at all. "<-"
would probably be good.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail

Re: status of Ada STL?

[Russ]

Ted Dennison <dennison@telepath.com> wrote in message news:<3D0D18D5.2020601@telepath.com>...
> Russ wrote:
> > Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uu1o31wbb.fsf@wanadoo.fr>...
> > 
> >>Of course this is not Ada anymore... Do you think it is a good idea to
> >>push a new language to have Ada more widely used ?
> > Yes, it IS still essentially Ada, because you can still use standard
> > Ada compilers. A simple pre-processor could convert the cleaner
> > dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
> > STANDARD ADA 95 COULD CONTINUE TO DO SO.
> 
> Then write the preprocessor and use it. If its so much better, other 
> people will too.
> 
> I don't think I'd ever use it though. First off, I think it would make 
> my sources much uglier. Secondly, it throws away some purposeful design

I think you have a funny definition of ugly, but so be it. EVEN IF MY
PROPOSAL WERE ADOPTED YOU COULD CONTINUE TO USE THE CURRENT SYNTAX.

>   decisions (eg: not using similar looking operators like "==" and "=") 
> for the apparent purpose of making the language look more like C. That's 
> a stupid purpose in my book. Complaining that Ada doesn't look like C is 
> the last gasp excuse of folks who just don't like Ada because it *isn't* 
> C. There's nothing you can do to reach out to those folks. Just let them 
> use C and be happy.

Take a look at how Python handles the "=" vs. "==" "problem". They
simply do not allow assignment inside an "if" test. Problem solved.

And I must say that I am getting tired of people claiming that I want
to "make Ada look more like C". How does the lack of semicolons
resemble C? C actually does some things right, but much of what I
propose to "borrow" from C did not originate with C anyway. To say
that my proposal simply makes Ada look more like C is highly
misleading. But I hear it so much that I wonder if some Ada folks
aren't obsessed with envy over the popularity of C and C++.

Re: status of Ada STL?

[Russ]

Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3d0ce154_5@news.bluewin.ch>...
> 18k11tm001@sneakemail.com (Russ) wrote:
> 
> >Yes, it IS still essentially Ada, because you can still use standard
> >Ada compilers. A simple pre-processor could convert the cleaner
> >dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
> >STANDARD ADA 95 COULD CONTINUE TO DO SO.
> 
> Mmh. How do you convert a "/=" construct then?

x /= y -- new syntax
x := x / y; -- old syntax


> And your "anyone who wants..." is no real argument. You then could
> write a C++ to Ada-Preprocessor to get the same effect. We can going
> on using Ada and the rest of the world can do their C++. Or do the
> preprocessor the other way around, it might be easier.

Wrong. Converting from C++ to Ada would be infinitely more complicated
than going from Ada-F to Ada.

> >I really don't understand the objection to my proposal. Ada advocates
> >keep telling me they like Ada's syntax and it doesn't need to be
> >changed.
> 
> Yup. More or less this is the case. IMO the syntax is well chosen,
> perhaps not perfect, but very good and clear.

Let me repeat: YOU'S STILL BE ABLE TO USE IT EVEN IF MY PROPOSAL WAS
ADOPTED.

> >But the question is not whether CURRENT Ada users like it;
> >the question is why so few OTHER programmers are showing any interest
> >in Ada, despite it's superior fundamental design.
> 
> Because they are using C-like languages.

Maybe. Maybe not. But so what?

> >When programmers take a first look at a new language, the first thing
> >they see is the syntax.
> 
> Yes. But it is not this impression only that should let you decide.
> 
> >Ever heard the old expression, "The first
> >impression is the most important one."? And no, I am not claiming that
> >my syntax proposal is the entire answer, but I do believe it would be
> >a modest step in the right direction.
> 
> And the next step would be to replace "begin end" by "{ }"? Well, if I
> wanted C++, I wouldn't have chosen Ada. :->

I would not go that far.

> Personally I like ":=" much more than "=". Although in Ada there would
> be no possibility to do "if (a = b)" vs. "if (a == b)" like in C, I
> like the slightly mathematically approach of saying "this gives"
> instead of "this is equal" for assignments definitely more.

I heard that ":=" was originally chosen by some early language
designer (can't remember who) who actually wanted to use "<=", but his
ancient ancient keyboard didn't have "<". You've fooled yourself into
thinking it has some deep meaning. Einstein said, "Everything should
be made as simple as possible, but not simpler." So Einstein agrees
with me.

> And what I definitely *hate* are those short-cut-constructs like "*="
> that never say what they really do. I consider them as totally
> unreadable: "a multiplied (with?) equal is 2? - What the heck is
> that?" This goes against the data flow. An assignment operation should
> be simple, left side is *where* to assign, right side is *what* to
> assign.
> Today's compilers are smart enough to let you not do such optimization
> constructs and could let you use a clear and readable construct for
> assigning a new value.

Every good C++ programmer knows that "+=" is much more efficient than
"+" for vector/matrix addition because it eliminates the need for
constructing a temporary matrix to hold the sum.

> I love the way Ada does. You want an assignment? - So do that. Not the
> C way: Ok, you can do it *this way* or you can do it *that way*.
> 
> I think the C++-way is wrong, so considering it integrating into an
> Ada-like language would be the totally false way, IMO.
> 
> Sorry, just my opinion. But a lot of my arguments for the more clear
> Ada-syntax simply would vanish in a haze then. :-)
> 
> Vinzent.

Re: status of Ada STL?

[Russ]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<ulm9f0z8p.fsf@wanadoo.fr>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > I really don't understand the objection to my proposal. 
> 
> I've read them all. I see nothing here that will make Ada read better. You
> have 7 rules, all of them are very minor points and in each time your proposal
> seems just more confusing to me.
> 
> I don't know if you have a more extensive description for your changes ? Do
> you have examples ?
> 
> Let's try a simple one :
> 
> Here is the Ada version:
> 
>    procedure Dummy is
> 
>       subtype My_Int is Integer range 1 .. 1_024;
> 
>       procedure Proc (C : out My_Int; A, B : in My_Int := 1) is
>          I : constant Integer := 9;
>       begin
>          if A = 12 then
>             C := A + B + I;
>          end if;
> 
>          C := C * (A + 2 * B);
>       end Proc;
> 
>       R : My_Int;
> 
>    begin
>       Proc (A => 2, B => 8, C => R);
>    end Dummy;
> 
> Here is the Ada-F version :
> 
>    procedure Dummy is
> 
>       subtype My_Int is Integer range 1 : 1_024;
> 
>       procedure Proc (C : out My_Int; A, B = 1 : in My_Int) is
>          I = 9 : constant Integer;
>       begin
>          if A == 12 then
>             C = A + B + I
>          end if;
> 
>          C *= (A + 2 * B)
>       end Proc;
> 
>       R : My_Int;
> 
>    begin
>       Proc (A = 2, B = 8, C = R)
>    end Dummy
> 
> (I have not use rule 1 nor 7)
> 
> Are you still saying that Ada-F is looking better than Ada ?

Yes I am. And thanks for the demo. If you get rid of the semicolons it
will look even better.

> One very nasty effect is "A, B = 1 : in My_Int" it looks like only B is
> set to 1.

That's why I'd say only B should be set to 1. That allows me to set A
to something else.

Re: status of Ada STL?

[Russ]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3D0D4274.6C5E02F9@acm.org>...
> Vinzent Hoefler wrote:
> > 
> > Personally I like ":=" much more than "=". Although in Ada there would
> > be no possibility to do "if (a = b)" vs. "if (a == b)" like in C, I
> > like the slightly mathematically approach of saying "this gives"
> > instead of "this is equal" for assignments definitely more.
> 
> Certainly ":=" is better than "=" for assignment, and replacing "=" with
> "==" for equality is just stupid. But I've thought for decades that the
> assignment symbol should not contain the "=" character at all. "<-"
> would probably be good.

Certainly "=" is better than ":=" for assignment, but if you don't
think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.

HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?

Re: status of Ada STL?

[Dale Stanbrough]

Russ wrote:

> Certainly "=" is better than ":=" for assignment, but if you don't
> think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
> MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.
> 
> HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?

Likelihood of getting this changed?



           0



Dale

Re: status of Ada STL?

[chris.danx]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206162120.3acf4278@posting.google.com...
> Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message
news:<3d0ce154_5@news.bluewin.ch>...
> > 18k11tm001@sneakemail.com (Russ) wrote:
> >
> > >Yes, it IS still essentially Ada, because you can still use standard
> > >Ada compilers. A simple pre-processor could convert the cleaner
> > >dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
> > >STANDARD ADA 95 COULD CONTINUE TO DO SO.
> >
> > Mmh. How do you convert a "/=" construct then?
>
> x /= y -- new syntax
> x := x / y; -- old syntax

  x not equal to y
= x := x / y;

How long have you been programming in Ada?  The '/=' construct should be
known to you if you've been programming for any length of time.

> > And your "anyone who wants..." is no real argument. You then could
> > write a C++ to Ada-Preprocessor to get the same effect. We can going
> > on using Ada and the rest of the world can do their C++. Or do the
> > preprocessor the other way around, it might be easier.
>
> Wrong. Converting from C++ to Ada would be infinitely more complicated
> than going from Ada-F to Ada.
>
> > >I really don't understand the objection to my proposal. Ada advocates
> > >keep telling me they like Ada's syntax and it doesn't need to be
> > >changed.
> >
> > Yup. More or less this is the case. IMO the syntax is well chosen,
> > perhaps not perfect, but very good and clear.
>
> Let me repeat: YOU'S STILL BE ABLE TO USE IT EVEN IF MY PROPOSAL WAS
> ADOPTED.

<What's with all the shouting?>

How would you tell equals from assignment equals in your new mode?  I mean
if you're allowed both they'd need to be mutually exclusive otherwise they'd
confuse the reader and maybe even the compiler.


> > Personally I like ":=" much more than "=". Although in Ada there would
> > be no possibility to do "if (a = b)" vs. "if (a == b)" like in C, I
> > like the slightly mathematically approach of saying "this gives"
> > instead of "this is equal" for assignments definitely more.
>
> I heard that ":=" was originally chosen by some early language
> designer (can't remember who) who actually wanted to use "<=", but his
> ancient ancient keyboard didn't have "<". You've fooled yourself into
> thinking it has some deep meaning. Einstein said, "Everything should
> be made as simple as possible, but not simpler." So Einstein agrees
> with me.

Vincent isn't saying it's got a deeper meaning, he's saying he prefers to
use a mathematical symbol the way it's supposed to be used (and is used) and
have a separate symbol for assignment which is entirely different from
equality (equality is either true or false, assignment is neither).

(Personally I agree with Jeff '<-' is a much nicer symbol for assignment, it
looks like 'take the right and put it into the left' and it's quite
natural).

Also Einstien wouldn't agree with you, you'd still have two symbols (one for
assignment and one for equality), instead would throw his hands up in
disgust at the change in meaning of a well defined mathematical symbol.

btw I don't dislike c symbols, I just dislike ppl who think Ada should look
like C to get a bit of recognition.  It's just plain silly.  The language is
the way it is.

The best way to promote Ada (if that's what you want to do) is to write
software in it, not mess with it's syntax.

Chris

Re: status of Ada STL?

[chris.danx]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206162248.45b6174e@posting.google.com...
> Jeffrey Carter <jrcarter@acm.org> wrote in message
news:<3D0D4274.6C5E02F9@acm.org>...
>
> > Certainly ":=" is better than "=" for assignment, and replacing "=" with
> > "==" for equality is just stupid. But I've thought for decades that the
> > assignment symbol should not contain the "=" character at all. "<-"
> > would probably be good.
>
> Certainly "=" is better than ":=" for assignment,

"=" implies stateful, assignment is stateful hence using "=" for stateful
transitions is confusing if not wrong (let's not go into C and why it has
"=" for assignment, that's done, in the past, over with!  The issue here is
whether Ada should have "=" for assignment).

Try fp for a while and see that "something is something else" is different
from saying "something becomes something else".


> but if you don't
> think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
> MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.
>
> HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?

NOPE COS' YOU'RE SHOUTING AT EVERYONE AND YOUR PROPOSAL HAS NO BENEFITS TO
THE ADA COMMUNITY AS A WHOLE.

As I said before the best way to support Ada is to develop software in it,
and for it.  Adas' biggest problem is ppl moaning that it's not as popular
as this language or that language and thinking up ways of making it more
popular, instead of getting on with writing software and supporting it in
that way.  After all the more software you put out there, the more ppl get
to see what you can do with Ada and see it's benefits.


Chris

Re: status of Ada STL?

[Grein, Christoph]

How would you translate

  B := X = Y;

Before making silly proposals, learn the language!

Re: status of Ada STL?

[Frank J. Lhota]

Personally, my favorite assignment symbol comes from APL: a single character
left arrow. The arrow really signifies what assignment is: placing the value
on the right into the reference on the left. Unfortunately, not many
character sets include arrows, and few languages have taken the APL approach
of defining their own character set. But this is the one area where APL is
arguably more readable than conventional languages.

Also, SNOBOL fans who still have "The SNOBOL Programming Language", Second
Edition (the green book), check out Sample Program 5, where a left arrow is
used for assignments throughout the program.

Re: status of Ada STL?

[Frank J. Lhota]

> And I must say that I am getting tired of people claiming that I want
> to "make Ada look more like C". How does the lack of semicolons
> resemble C?

Actually, it would make Ada look more like Icon, not that that's necessarily
a bad thing...

Re: status of Ada STL?

[Frank J. Lhota]

> But then there is no necessity in having two different symbols for
equality
> and assignment. Make both "="!

If memory serves correctly, that was the PL/1 approach: within a context
where a Boolean expression is expected, "=" tests for equality; outside of
such contexts, "=" was assignment. At the time, PL/1's syntax was criticized
for being confusing for the reader, if not the compiler. We may wish to
exercise caution before adopting context-sensitive interpretation of
operators.

Re: status of Ada STL?

[Ted Dennison]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206162107.5cf737c@posting.google.com>...
> Ted Dennison <dennison@telepath.com> wrote in message news:<3D0D18D5.2020601@telepath.com>...
> >   decisions (eg: not using similar looking operators like "==" and "=") 
> Take a look at how Python handles the "=" vs. "==" "problem". They

Perhaps. But that still does not get around the fact that you are
using "=" for something that isn't equality, and a completely made up
operator for something that *is* equality. Why is it not better to use
"=" in its proper mathematical sense? ("because I'm used to that"
isn't a good answer)

> And I must say that I am getting tired of people claiming that I want
> to "make Ada look more like C". How does the lack of semicolons

Actually, you are exactly right here. I'm sorry for misreading your
spec. Please replace every occurance of "C" in my post with "Python".

> misleading. But I hear it so much that I wonder if some Ada folks
> aren't obsessed with envy over the popularity of C and C++.

Actually, the point is that we *aren't*. I don't really care how C++
or C or Python or Oberon represents equality, any more than most of
those folks care how Ada does it. Languages have different syntaxes.
In Ada's case, most of it was quite thourougly thought out and
discussed, and I seriously doubt you have come up with any startlingly
new option that wasn't available to the original Ada designers. But
either way, its just syntax.

Every year it seems someone comes in here with a great idea to
suddenly make Ada immensley popular by making a dozen minor cosmetic
changes to the syntax so that it matches some other language (that
they happen to be used to). I suspect the *real* goal in such cases is
that said person just got used to the other syntax, and doesn't want
to have to adjust to Ada. So instead of working with the language,
they try to drag the mountain to Mohhamed.

Anyway, go ahead and drag away. But don't expect any help from folks
who are currently happily using the language as it is.

Re: status of Ada STL?

[Marin David Condic]

Libraries are a big deal. Not having one that is at least "Conventional" Ada
(heading towards "Standard" Ada - maybe) does start to make people consider
the leverage they get elsewhere. That's why I've suggested we need to get
*something* that is up and running & generally available and somehow or
other the "Conventional" thing. We can't wait 5 years for that to happen
either - so even a minimal library with some really basic stuff that could
easily be extended would be A Good Start.

Its just real hard to get consensus on what the library should be and with
lack of direction/support from some of the more "Official" interests, its
hard to imagine how this could be speeded up.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206151051.1c25cf1e@posting.google.com...
>
> The main objection is usually that Ada programmers are too hard to
> find. More recently, a top expert (a gcc maintainer) is claiming that
> the STL overcomes many of the objections to C++. If Ada doesn't soon
> have something comparable to STL that is reasonably stable and at
> least on track for standardization, it could be in trouble.
>

Re: status of Ada STL?

[Ted Dennison]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206162248.45b6174e@posting.google.com>...
> Certainly "=" is better than ":=" for assignment, but if you don't

In what way?

Logically, its not better. The symbol comes from math, where it
designates an invariant equality of values, not a moving of values
from one temporary storage place to another. Using it for assigning
just confuses newbies who know algebra. For instance this series of
statements is impossible in algebra, but common in programs:

A = 3
B = 7
...
A = B

This isn't just theory, I've seen it confuse quite a lot of people who
are new to programming.

"=" also had the drawback that is it confusingly similar to the
operator people want to use for true equality (becuase that is what it
*should* be used for, being the most analagous to the mathematical
symbol it comes from).

So what are the advatages that counterbalance these disadvanteges
enough to make it "certianly better"? I've yet to see you name one.

Re: status of Ada STL?

[Marin David Condic]

Syntax is the least of Ada's problems. There have been untold number of
other languages invented that have reached all sorts of levels of popularity
using syntax other than that of C. People can and will adjust to a new
syntax. Most of the objections I've heard from people about Ada never bring
up syntax. They object to things like lack of leverage, lack of programmers,
"complicated" features (tasks, generics, etc...), "inefficiency", "design by
committee", etc. etc. etc. but almost *never* do I hear "The syntax really
sucks so I can't use it."

It would be *very* costly and disruptive to try to adjust Ada's syntax to
look more like that of C's. It would be of *very* dubious value to do so.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"chris.danx" <spamoff.danx@ntlworld.com> wrote in message
news:d%gP8.23130$gm5.4370500@news11-gui.server.ntli.net...
>
> btw I don't dislike c symbols, I just dislike ppl who think Ada should
look
> like C to get a bit of recognition.  It's just plain silly.  The language
is
> the way it is.
>

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> Certainly "=" is better than ":=" for assignment, but if you don't
> think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
> MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.

So it is even worse than I thought since you are proposing to accept different
syntax for the same construct...

> HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?

:)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?

BTW, stop shouting and start building your Ada-F parser, your energie will
be better used this way !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Vinzent Hoefler]

Jeffrey Carter <jrcarter@acm.org> wrote:

>Certainly ":=" is better than "=" for assignment, and replacing "=" with
>"==" for equality is just stupid. But I've thought for decades that the
>assignment symbol should not contain the "=" character at all. "<-"
>would probably be good.

Well. VHDL does it in a similar way to indicate signal assignments:

Bus_Address (7 downto 0) <= "00000000";

But it's still using ":=" for variable assignments. I guess, this has
a reason there...


Vinzent.

Re: status of Ada STL?

[Vinzent Hoefler]

18k11tm001@sneakemail.com (Russ) wrote:

>Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3d0ce154_5@news.bluewin.ch>...
>> 18k11tm001@sneakemail.com (Russ) wrote:
>> 
>> [...]
>> Mmh. How do you convert a "/=" construct then?
>
>x /= y -- new syntax
>x := x / y; -- old syntax

|if (x /= y) then
|
|vs.
|
|x /= y;

No, you don't really want that, do you? And I still consider such
constructs as ugly.

>> Yup. More or less this is the case. IMO the syntax is well chosen,
>> perhaps not perfect, but very good and clear.
>
>Let me repeat: YOU'S STILL BE ABLE TO USE IT EVEN IF MY PROPOSAL WAS
>ADOPTED.

Well, well. Don't shout that loud, I can hear you. My point is this
would lead to different constructs doing the same, making the code
hardly readable.

>> >But the question is not whether CURRENT Ada users like it;
>> >the question is why so few OTHER programmers are showing any interest
>> >in Ada, despite it's superior fundamental design.
>> 
>> Because they are using C-like languages.
>
>Maybe. Maybe not. But so what?

Simply don't let Ada look like C to convince those people. They won't
thank you. The only thing they'd say would be "Fine, looks good for
me, but why? I already have my C++."

>> >Ever heard the old expression, "The first
>> >impression is the most important one."? And no, I am not claiming that
>> >my syntax proposal is the entire answer, but I do believe it would be
>> >a modest step in the right direction.
>> 
>> And the next step would be to replace "begin end" by "{ }"? Well, if I
>> wanted C++, I wouldn't have chosen Ada. :->
>
>I would not go that far.

Even if the people you are probably targeting would say, "The "begin
end" is soooo long, I'd like using my {}, so I won't use Ada."?

>I heard that ":=" was originally chosen by some early language
>designer (can't remember who) who actually wanted to use "<=", but his
>ancient ancient keyboard didn't have "<". You've fooled yourself into
>thinking it has some deep meaning.

Well. Pascal (and its succesors uses it) and I do not think that Wirth
had a such *ancient* keyboard, because he used "<>" instead of "/=".
VHDL uses it, too. And it uses "<=" at the same time for slightly
different things. So there *must* be some deeper meaning. :-)

>Einstein said, "Everything should
>be made as simple as possible, but not simpler." So Einstein agrees
>with me.

Well. So using "=" and "=" for assignments and comparison is more
simple. Brainfuck is very simple, too. The thing is you seemed to miss
the second part: "but not simpler". Although I don't think that your
proposal would actually really lead to something more simple.

>> Today's compilers are smart enough to let you not do such optimization
>> constructs and could let you use a clear and readable construct for
>> assigning a new value.
>
>Every good C++ programmer knows that "+=" is much more efficient than
>"+" for vector/matrix addition because it eliminates the need for
>constructing a temporary matrix to hold the sum.

Every good compiler should see in its data flow analysis that both
statements simply are the same. It *should* not be a matter of how it
is *expressed*. So, what am I missing?


Vinzent.

Re: status of Ada STL?

[Dmitry A.Kazakov]

Russ wrote:

> Take a look at how Python handles the "=" vs. "==" "problem". They
> simply do not allow assignment inside an "if" test. Problem solved.

But then there is no necessity in having two different symbols for equality 
and assignment. Make both "="!

However the single rationale why assignment should be denoted as equality 
and equality as something else, is the gospel from FORTRAN. As we all know, 
God programmed the Universe in FORTRAN-IV. (:-))

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[SteveD]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206151051.1c25cf1e@posting.google.com...
[snip]
>
> I also happen to think that Ada's awkward syntax is part of the
> problem. My proposal for a cleaner Ada syntax option can be found at
> http://RussP.org/Ada.htm
>

I also think there are awkward areas of syntax in Ada, but disagree with ALL
of your examples.  I think it is naive to think that such minor syntax
changes would have any positive impact on the use of Ada.

If the syntax is introduced as an alternate, the result is what I call YABL
(yet another bastard language).

The things I find awkward about Ada syntax...

If you look at blocks of code you have:

  if  condition then
    ...
  end if;

  while condition loop
    ...
  end loop;

If you look at type definitions you have:

  type mytype is
    record
     ...
    end record;

Each of these cases clearly define the scope of a block or type definition.
Now if I move on to tagged types I have:

  package mydemo is

    type mytype is abstract tagged null record;

    procedure MyProc1( value : mytype );

    type anothertype is new mytype with null record;

    procedure MyProc2( value : mytype );

end mydemo;

When I compile this with GNAT 3.14p I get the following:

  mydemo.ads:7:03: warning: no primitive operations for "mytype" after this
  mydemo.ads:9:13: this primitive operation is declared too late

After working with Pascal and C, I was pleased to learn Ada and appreciate
that if, while, case, and for constructs all have an explicit end construct.
I am disappointed that primitive operations, which are really part of a
tagged type construct do not have an explicit end of primititive operations
construct.

I would much prefer:
  type mytype is abstract tagged
    record
       null;
    end record
    methods
      procedure MyProc1( value : mytype );
    end methods;

Or for that matter any notation that explicitly marks the end of primitive
operations on a tagged type declaration.  This kind of ambiguity is what
other languages are good for.  Like C++... hey wait a minute  ;-)

This is one of my few peeves with Ada.  But I can't say that changing this
would have any significant impact on market penetration.

SteveD

Re: status of Ada STL?

[Russ]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<u1yb5n7v3.fsf@wanadoo.fr>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Certainly "=" is better than ":=" for assignment, but if you don't
> > think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
> > MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.
> 
> So it is even worse than I thought since you are proposing to accept different
> syntax for the same construct...

You are just realizing that now? Please see the first paragraph of my
proposal, and let me know what is unclear about it.

Re: status of Ada STL?

[Russ]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message news:<mailman.1024312682.22670.comp.lang.ada@ada.eu.org>...
> How would you translate
> 
>   B := X = Y;

B = X == Y

Gosh, that was a real challenge. I had to think about it for nearly 3 seconds.

> Before making silly proposals, learn the language!

Before asking stupid questions, find out about languages other than Ada.

Re: status of Ada STL?

[Russ]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206170611.260a3951@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206162107.5cf737c@posting.google.com>...
> > Ted Dennison <dennison@telepath.com> wrote in message news:<3D0D18D5.2020601@telepath.com>...
> > >   decisions (eg: not using similar looking operators like "==" and "=") 
> > Take a look at how Python handles the "=" vs. "==" "problem". They
> 
> Perhaps. But that still does not get around the fact that you are
> using "=" for something that isn't equality, and a completely made up
> operator for something that *is* equality. Why is it not better to use
> "=" in its proper mathematical sense? ("because I'm used to that"
> isn't a good answer)

Think about it this way. Immediately after the statement "x=1"
executes, the mathematical statement "x=1" becomes true. The same does
not apply to a statement like "x=x+1", of course, but so what? Anyone
who is actually confused by something like that should either get over
it within one minute or find another profession fast. Besides that, a
much more elegant way of writing it would be "x+=1" anyway. And no, I
don't say that because it "looks like C". I say that because it is a
minimal form (the x need not be repeated, which can be noticibly
simpler in a case like,

my_very_descriptive_variable += 1

Or do you prefer 

my_very_descriptive_variable := my_very_descriptive_variable + 1;

If so, you're beyond reason.

> > And I must say that I am getting tired of people claiming that I want
> > to "make Ada look more like C". How does the lack of semicolons
> 
> Actually, you are exactly right here. I'm sorry for misreading your
> spec. Please replace every occurance of "C" in my post with "Python".

Thanks for recognizing that. In my proposal I specifically referred to
Python and Fortran. I did not refer to C or C++, yet I'll bet a dozen
or so replies accuse me of wanting to "make Ada look more like C"! How
can I help but wonder if these replies are based on something other
than rational thought.

> > misleading. But I hear it so much that I wonder if some Ada folks
> > aren't obsessed with envy over the popularity of C and C++.
> 
> Actually, the point is that we *aren't*. I don't really care how C++
> or C or Python or Oberon represents equality, any more than most of
> those folks care how Ada does it. Languages have different syntaxes.
> In Ada's case, most of it was quite thourougly thought out and
> discussed, and I seriously doubt you have come up with any startlingly
> new option that wasn't available to the original Ada designers. But
> either way, its just syntax.
> 
> Every year it seems someone comes in here with a great idea to
> suddenly make Ada immensley popular by making a dozen minor cosmetic
> changes to the syntax so that it matches some other language (that
> they happen to be used to). I suspect the *real* goal in such cases is
> that said person just got used to the other syntax, and doesn't want
> to have to adjust to Ada. So instead of working with the language,
> they try to drag the mountain to Mohhamed.
> 
> Anyway, go ahead and drag away. But don't expect any help from folks
> who are currently happily using the language as it is.

At that rate, a couple dozen regulars on comp.lang.ada will still be
proudly using Ada after everyone else has forgotten about it -- like
those Japanese soldiers who were discovered still fighting WWII on
some remote island in 1967. And they'll still be swearing that its
perfectly adequate.

Re: status of Ada STL?

[Russ]

"chris.danx" <spamoff.danx@ntlworld.com> wrote in message news:<d%gP8.23130$gm5.4370500@news11-gui.server.ntli.net>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0206162120.3acf4278@posting.google.com...
> > Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message
>  news:<3d0ce154_5@news.bluewin.ch>...
> > > 18k11tm001@sneakemail.com (Russ) wrote:
> > >
> > > >Yes, it IS still essentially Ada, because you can still use standard
> > > >Ada compilers. A simple pre-processor could convert the cleaner
> > > >dialect to standard Ada 95, and ANYONE WHO WANTS TO CONTINUE TO USE
> > > >STANDARD ADA 95 COULD CONTINUE TO DO SO.
> > >
> > > Mmh. How do you convert a "/=" construct then?
> >
> > x /= y -- new syntax
> > x := x / y; -- old syntax
> 
>   x not equal to y
> = x := x / y;
> 
> How long have you been programming in Ada?  The '/=' construct should be
> known to you if you've been programming for any length of time.

I'm an experienced aerospace engineer with good programming
experience, but I am new to Ada. That's why I think I can see some of
the blemishes of Ada more clearly than jaded Ada programmers. Thanks
for pointing out the problem with "/=". I guess I'll have to use "!="
instead. No big deal.

By the way, it's too bad that Ada wasted "/=" on "not equals. It would
be very useful for dividing a matrix by a scalar. For example, the
construct

A := A / 2.0;

is very inefficient because a temporary matrix must be created to
store A/2, then an assignment must be used to put the result back in
A. On the other hand,
the construct

A /= 2.0

is not only much cleaner looking, it is much more efficient because
you can skip the temporary matrix and the assignment. And please don't
argue with me here, because you will only be showing your ignorance.
Good C++ programmers know all about this.

> > > And your "anyone who wants..." is no real argument. You then could
> > > write a C++ to Ada-Preprocessor to get the same effect. We can going
> > > on using Ada and the rest of the world can do their C++. Or do the
> > > preprocessor the other way around, it might be easier.
> >
> > Wrong. Converting from C++ to Ada would be infinitely more complicated
> > than going from Ada-F to Ada.
> >
> > > >I really don't understand the objection to my proposal. Ada advocates
> > > >keep telling me they like Ada's syntax and it doesn't need to be
> > > >changed.
> > >
> > > Yup. More or less this is the case. IMO the syntax is well chosen,
> > > perhaps not perfect, but very good and clear.
> >
> > Let me repeat: YOU'S STILL BE ABLE TO USE IT EVEN IF MY PROPOSAL WAS
> > ADOPTED.
> 
> <What's with all the shouting?>
> 
> How would you tell equals from assignment equals in your new mode?  I mean
> if you're allowed both they'd need to be mutually exclusive otherwise they'd
> confuse the reader and maybe even the compiler.

Thanks to another post, I now realize that I need to use "==" (or
something other than "=") for equality testing. That is exactly what
Python does. No problem at all.

<cut>

> btw I don't dislike c symbols, I just dislike ppl who think Ada should look
> like C to get a bit of recognition.  It's just plain silly.  The language is
> the way it is.

Here we go again. No, I don't want Ada to "look like C", and without
those silly semicolons it definitely won't.

> The best way to promote Ada (if that's what you want to do) is to write
> software in it, not mess with it's syntax.

Good luck.

Re: status of Ada STL?

[Russ]

Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale-B74C15.17040617062002@its-aw-news.its.rmit.edu.au>...
> Russ wrote:
> 
> > Certainly "=" is better than ":=" for assignment, but if you don't
> > think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
> > MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.
> > 
> > HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?
> 
> Likelihood of getting this changed?
> 
> 
> 
>            0
> 
> 
> 
> Dale

Likelihood of getting what "changed"? My proposal does not change the
Ada 95 standard one iota. It only ADDS an alternative dialect. AM I
GETTING THROUGH NOW?

Re: status of Ada STL?

[Russ]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206170753.599fd771@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206162248.45b6174e@posting.google.com>...
> > Certainly "=" is better than ":=" for assignment, but if you don't
> 
> In what way?
> 
> Logically, its not better. The symbol comes from math, where it
> designates an invariant equality of values, not a moving of values
> from one temporary storage place to another. Using it for assigning
> just confuses newbies who know algebra. For instance this series of
> statements is impossible in algebra, but common in programs:
> 
> A = 3
> B = 7
> ...
> A = B
> 
> This isn't just theory, I've seen it confuse quite a lot of people who
> are new to programming.

Anyone who is "confused" by this for long should find another
profession -- like moving furniture.

Immediately after the statement "x=3" executes, it becomes true in the
mathematical sense, which is why it makes sense.

> "=" also had the drawback that is it confusingly similar to the
> operator people want to use for true equality (becuase that is what it
> *should* be used for, being the most analagous to the mathematical
> symbol it comes from).

I agree this is a problem, albeit a very minor one. The rational for
using "=" for assignment rather than equality testing is that
assignment is done far more often than equality testing.

> So what are the advatages that counterbalance these disadvanteges
> enough to make it "certianly better"? I've yet to see you name one.

The "disadvantages" you listed are so minor as to be frivilous in my
view. The advantage that I thought I had made clear is that "=" is
simpler and cleaner than ":=" -- which is why it is used by most
languages for assignment. Simplicity should not be underrated.

You claim that people don't like ":=" because they are not "used to
it." Well, that may be part of it, but I think you are defending it
mainly because you are "used to it." That's your perogative, of
course, and I wouldn't dream of trying to make you change. If you
prefer ":=", then you should certainly not be forced to use "=". All I
am saying is that I prefer "=" and I think many others would too.
Can't we all just get along?

Re: status of Ada STL?

[chris.danx]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206172212.4bc5cc3a@posting.google.com...


> By the way, it's too bad that Ada wasted "/=" on "not equals. It would
> be very useful for dividing a matrix by a scalar. For example, the
> construct
>
> A := A / 2.0;
>
> is very inefficient because a temporary matrix must be created to
> store A/2, then an assignment must be used to put the result back in
> A. On the other hand,
> the construct
>
> A /= 2.0
>
> is not only much cleaner looking, it is much more efficient because
> you can skip the temporary matrix and the assignment. And please don't
> argue with me here, because you will only be showing your ignorance.
> Good C++ programmers know all about this.

I'm not going to argue with you (you've made up your mind and so have I,
what's the point?), I'm just curious as to whether compilers would see A :=
A / 2 and think "that code's dividing the matrix by 2 and assigning it to
itself.  It might be better just to divide it inplace" leading to the same
thing.  But then I'm largely ignorant of compilers.

Chris

Re: status of Ada STL?

[Fraser Wilson]

18k11tm001@sneakemail.com (Russ) writes:

> By the way, it's too bad that Ada wasted "/=" on "not equals. It would
> be very useful for dividing a matrix by a scalar. For example, the
> construct
> 
> A := A / 2.0;
> 
> is very inefficient because a temporary matrix must be created to
> store A/2, then an assignment must be used to put the result back in
> A. On the other hand,
> the construct
> 
> A /= 2.0
> 
> is not only much cleaner looking, it is much more efficient because
> you can skip the temporary matrix and the assignment. And please don't
> argue with me here, because you will only be showing your ignorance.

C++ seems to tie itself in knots over the issue of temporaries, which
is why constructs such as the above have to be used.  Is it because of
the class/constructor/destructor thing?  I don't know, but it's always
seemed odd that programmers of this language get so caught up in it.

In any case, Ada has a different type model, and, even in the case of
matrices, the expression "A := A / 2.0" can, in many situations, be
optimised by the compiler to avoid temporaries.  I'm not saying they
do, but they can, and it's not particularly difficult as optimisations
go.

Look, I'll write some pseudo code: if the assignment expression looks
like "X := X <op> Y", X is of type T, T is big, and T, <op> are
declared in a pure package, put the address of X on the stack and call
the non-temporary version of <op>.  When compiling operators of a big
type in a pure package, create a non-temporary version of each
suitable operator, and have a standard version which calls that.

Alternatively, you could just pragma Inline these things, which will
also eliminate temporaries (I expect).

I'd much rather write my assignments in a natural and readable manner
("A becomes A divided by 2") than worry about arcane compiler
temporary issues.

> Good C++ programmers know all about this.

Ada programmers don't have to!

Fraser.

Re: status of Ada STL?

[Adrian Hoe]

Marin David Condic wrote:

> Libraries are a big deal. Not having one that is at least "Conventional" Ada
> (heading towards "Standard" Ada - maybe) does start to make people consider
> the leverage they get elsewhere. That's why I've suggested we need to get
> *something* that is up and running & generally available and somehow or
> other the "Conventional" thing. We can't wait 5 years for that to happen
> either - so even a minimal library with some really basic stuff that could
> easily be extended would be A Good Start.
> 
> Its just real hard to get consensus on what the library should be and with
> lack of direction/support from some of the more "Official" interests, its
> hard to imagine how this could be speeded up.
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0206151051.1c25cf1e@posting.google.com...
> 
>>The main objection is usually that Ada programmers are too hard to
>>find. More recently, a top expert (a gcc maintainer) is claiming that
>>the STL overcomes many of the objections to C++. If Ada doesn't soon
>>have something comparable to STL that is reasonably stable and at
>>least on track for standardization, it could be in trouble.
>>
>>
> 
> 
> 


There are a lot of (re)usable Ada code (or libraries) out there 
already. Most can be easily extended. The question here is it 
necessary to make a library? And we have many Ada websites. Why not 
have these libraries and download location listed there?

Just my 2cents. ;-)
-- 
Remove *nospam* to email.              -- Adrian Hoe
                                        -- http://adrianhoe.com

Re: status of Ada STL?

[chris.danx]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206172352.3658a885@posting.google.com...
> dennison@telepath.com (Ted Dennison) wrote in message
news:<4519e058.0206170753.599fd771@posting.google.com>...

> > This isn't just theory, I've seen it confuse quite a lot of people who
> > are new to programming.
>
> Anyone who is "confused" by this for long should find another
> profession -- like moving furniture.

Shouting at everyone and insulting ppl?

> Immediately after the statement "x=3" executes, it becomes true in the
> mathematical sense, which is why it makes sense.

No, equalities are invariant on their domains.  This is why the following
works

sumTwo :: Int -> Int -> Int
sumTwo x y = x + y                sumTwo.0

double :: Int -> Int
double x = sumTwo x x             double.0

Using those rules we get

double x = sumTwo x x             using double.0
double x = x + x                  using sumTwo.0

(which is always true!)

and this doesn't

addTwo :: Int -> Int
addTwo x = (y = y + 2)
   where y = x


(it's a bad example and artificial but it's simple).

The functions sumTwo and double make perfect sense to anyone who've done
maths at any level even if they don't know Haskell.  addTwo otoh makes no
sense if you show it to someone who doesn't know that "=" means assignment
and not equality, and most (if not all) ppl who learn programming/computing
science have done maths and will be used to '=' for equality.

Let's evaluate it with '=' as equality

addTwo x = (y = y + 2)
   where y = x

y = y + 2 and y = x

y = x + 2 and y = x

x = x + 2

which isn't true for the definition of addition on the domain of Ints (it
says 0 = 2).

Now for assignment

addTwo x = (y = y + 2)
addTwo x = y + 2
addTwo x = x + 2

it works, but you have to know '=' means assigment and not equality.


> I agree this is a problem, albeit a very minor one. The rational for
> using "=" for assignment rather than equality testing is that
> assignment is done far more often than equality testing.

That's not a good reason.


> You claim that people don't like ":=" because they are not "used to
> it." Well, that may be part of it, but I think you are defending it
> mainly because you are "used to it".

Don't know about Ted, but I'm defending it because it's not confusing and
more mathematically minded for "=" to mean equality.  I also think you're
defending '=' because your used to it and for no other reason.

Anyone want to get back to serious issues, like the STL?


Chris

Re: status of Ada STL?

[Colin Paul Gloster]

In article news:bebbba07.0206151051.1c25cf1e@posting.google.com , Russ
wrote:

"[..]
  
  [..] More recently, a top expert (a gcc maintainer) is claiming that
  the STL overcomes many of the objections to C++. If Ada doesn't soon
  have something comparable to STL that is reasonably stable and at
  least on track for standardization, it could be in trouble.

[..]"

Unless there were major additions to gcc 3, much the same can be said of
GNU C++ which your colleague should be aware of. While GNU C++ has (or at
least fairly recently had) a reputation for good conformance to C++
templates, it has (or had) a reputation for one of the least implemented
STL implementations available. (Note there is a difference between the
language mechanism and the offical standard library which heavily depends
on said mechanism.)

So saying that one should use GNU C++ instead of Ada because the C++ STL
is needed would demand that something other than the GNU STL effort be
used.

Re: status of Ada STL?

[Robert A Duff]

"SteveD" <nospam_steved94@attbi.com> writes:

> If you look at type definitions you have:
> 
>   type mytype is
>     record
>      ...
>     end record;

I wish it were "end My_Type", instead of "end record",
especially when the record contains 10 lines of components,
and 30 lines of comments.

> I would much prefer:
>   type mytype is abstract tagged
>     record
>        null;
>     end record
>     methods
>       procedure MyProc1( value : mytype );
>     end methods;

Not an entirely unreasonable complaint, but I don't think the above
would work very well.  At least it raises questions:  Where would you
put the class-wide ops?  Where would you put the exceptions and generics
that are "related" to mytype but not primitive?

Anyway, the *usual* practise is to have one type (or one "major" type)
per package, so "end Package_Name" serves the purpose well enough.

- Bob

Re: status of Ada STL?

[chris.danx]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccptyozndh.fsf@shell01.TheWorld.com...

> I wish it were "end My_Type", instead of "end record",
> especially when the record contains 10 lines of components,
> and 30 lines of comments.

I've been programming in Ada for 3 years and I still have to stop myself
typing My_Type at the end of a record sometimes.  Silly, eh?


Chris

Re: status of Ada STL?

[Ted Dennison]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206172155.1d50bbac@posting.google.com>...
> Think about it this way. Immediately after the statement "x=1"
> executes, the mathematical statement "x=1" becomes true. The same does
> not apply to a statement like "x=x+1", of course, but so what? Anyone

Thanks. I could not have come up with a better example of why "=" for
assignment is confusing and inappropriate myself.

> At that rate, a couple dozen regulars on comp.lang.ada will still be
> proudly using Ada after everyone else has forgotten about it -- like

The problem with that logic is:

  o Ada use is increasing already (according to the vendors).
  o There is absolutely no evidence that minor syntax differences with
Python is significantly holding Ada back. That might seem
self-obvioius to a big Python fan, but such people are hardly
unbiased. Big Lisp fans would probably say the same about Lisp. Big
Fourth fans would say the same about Forth.
  o There is also no evidence that you won't loose all the big Pascal,
Modula-*, and Oberon fans who are Ada users by doing this (and there
are probably *way* more of those around than interested Python fans).

If you hang out here long enough (or read back through the archives),
I guarantee you will come across all of the following:

   o  Big C fans who think Ada is only being held back by non-C-like
syntax
   o  Big .NET fans who are convinced Ada is only being held back from
huge success by lack of .NET support.
   o  Big Java fans who are convinced Ada is only being held back from
huge success by lack of JVM support (now obsolete and proven wrong).
   o  Big Delphi fans who are convinced Ada is only being held back
due to its lack of a Delphi-like library and interface.
   o  Longtime VisualC++ users who are convinced Ada is only being
held back due to lack of a Visual programming environment.

I've been here long enough to have heard just about every theory there
is. Frankly, I don't think the syntax theories hold any water at all.
The programming environment theories are a smidge better, but no more.

The main reason hordes of people don't switch to Ada is that
programmers are a very conservative lot. Given a choice, they fight
hard to use the language they are most familiar with. Programming
managers are even more so, since they aren't technically involved
enough to have any judgement point other than past use. People comming
here saying that Ada use would take off if only it used syntax items
from their own favorite other language are just further examples of
this principle.

If we look at past successes, what builds language bases isn't
wonderful syntax, but rather heavy marketing campaigns (with hopefully
a germ of truth under all the BS). If we want usage to skyrocket, then
we need to somehow foster the (generally self-fufilling) impression
that Ada is a "hot" language. Its a bit tough to do that with no big
moneybags company like Sun or Microsoft behind us. When someone comes
in here and starts an "Ada's syntax is all wrong" thread, if anything
its counterproductive.

Don't let this stop you from implementing your Pythada preprocessor
though. Just don't expect it to be used by anyone but big Python fans
new to Ada, very few of which are hanging out in this newsgroup to be
recruited. Perhaps you would have more luck getting support from a
Python newsgroup.

Re: status of Ada STL?

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206170753.599fd771@posting.google.com>...
> > 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206162248.45b6174e@posting.google.com>...
> > > Certainly "=" is better than ":=" for assignment, but if you don't
> > 
> > In what way?
> > 
> > Logically, its not better. The symbol comes from math, where it
> > designates an invariant equality of values, not a moving of values
> > from one temporary storage place to another. 

I strongly agree with that sentiment.  Any programming language designer
who throws away hundreds of years of perfectly good maths notation is
being arrogant, obnoxious, rude, and evil.  ;-)

Some languages use "integer" to mean a small subset of the integers, and
"real" to mean an even smaller subset of the real numbers.  That's also
arrogant, etc, in my opinion.  (Ada is guilty of only one of these
sins.)

>...All I
> am saying is that I prefer "=" and I think many others would too.
> Can't we all just get along?

No, we can't.  Programs are for communicating among people.  (If they
were for communicating to machines, we would use machine language!)  If
you use "=" and I use ":=" then we will have a harder time understanding
each other's programs.

- Bob

Re: status of Ada STL?

[Robert A Duff]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> I'm not going to argue with you (you've made up your mind and so have I,
> what's the point?), I'm just curious as to whether compilers would see A :=
> A / 2 and think "that code's dividing the matrix by 2 and assigning it to
> itself.  It might be better just to divide it inplace" leading to the same
> thing.  But then I'm largely ignorant of compilers.

I don't think any Ada compilers are that smart.

- Bob

Re: status of Ada STL?

[Robert A Duff]

Vinzent Hoefler <JeLlyFish.software@gmx.net> writes:

> 18k11tm001@sneakemail.com (Russ) wrote:
> >Every good C++ programmer knows that "+=" is much more efficient than
> >"+" for vector/matrix addition because it eliminates the need for
> >constructing a temporary matrix to hold the sum.
> 
> Every good compiler should see in its data flow analysis that both
> statements simply are the same. It *should* not be a matter of how it
> is *expressed*. So, what am I missing?

I think Russ is right here.

X := F(X, Y);

is *not* equivalent to the code that overwrites X in place,
in the general case.  In the usual case, where the called function
is not inlined, and the compiler doesn't look at its body,
the compiler has no hope of doing this optimization.
Even if it's inlined, the proof is not trivial.

(Whether you call it "+" or F or Add_Vector is irrelevant to the
optimization issue.)

- Bob

Re: status of Ada STL?

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0206180630.b6ef8cd@posting.google.com...
>
> I've been here long enough to have heard just about every theory there
> is. Frankly, I don't think the syntax theories hold any water at all.
> The programming environment theories are a smidge better, but no more.
>
As one of the advocates of better programming environments (libraries, IDEs,
etc.) I'd want to slightly recharacterize the theory as you describe it. My
contention would be that these days, libraries and IDEs are the price of
admission - not a guarantee of success. If you *do* have them, people might
still ignore and dismiss the language for a whole host of other reasons. If
you *don't* have them, you can't come to the table and compete because of
the business case against it - "Ada may be cool and I'd really love to use
it, but I get *sooo* much leverage with this library, IDE, GUI builder, etc.
that I can't afford the cost of going with Ada." (I've known plenty of
people who knew & liked Ada who *did* switch to other languages because of
the leverage.)


> The main reason hordes of people don't switch to Ada is that
> programmers are a very conservative lot. Given a choice, they fight
> hard to use the language they are most familiar with. Programming
> managers are even more so, since they aren't technically involved
> enough to have any judgement point other than past use. People comming
> here saying that Ada use would take off if only it used syntax items
> from their own favorite other language are just further examples of
> this principle.
>
Amen. Once a language gets entrenched in the mind of the programmer or in
the investment of the company, it is going to be *real* hard to change
anything. That's why it is important for the Ada-philes to develop software
or products that use Ada. The more of it that is out there, the more Ada
becomes "entrenched".


> If we look at past successes, what builds language bases isn't
> wonderful syntax, but rather heavy marketing campaigns (with hopefully
> a germ of truth under all the BS). If we want usage to skyrocket, then
> we need to somehow foster the (generally self-fufilling) impression
> that Ada is a "hot" language. Its a bit tough to do that with no big
> moneybags company like Sun or Microsoft behind us. When someone comes
> in here and starts an "Ada's syntax is all wrong" thread, if anything
> its counterproductive.
>
Marketing got people to open their wallets and give up their hard-earned
cash in exchange for a rock in a cardboard box. They did it in great
numbers, too. A strong marketing campaign would do a lot for Ada - but who
would fund it?

That isn't the only reason languages flourish, but it is one of the reasons
it happens in recent years. (I don't recall ATT investing heavily in a "Use
C" campaign - but they did give away an OS that was written in C and had a
compiler come along for the ride.)

But when you get down to it, programmers, managers and institutions do *not*
conduct surveys of the syntax of various languages and decide "I'll stop
using what I already am using to start using this new language because it
has this wonderful, spiffy, scientifically demonstrated to be superior
syntax!!!" They *might* do it if the language (no matter how butt-ugly you
make the syntax) offers them some significant leverage in getting their job
done or offers some significant capabilities they can exploit in producing
better (more marketable) products.

What would convince a number of programmers to learn and use a new language
is if they are being offered a *job* that utilized it. For that to happen,
you need companies to exist that are building their products with Ada
inside. Its not likely that companies with existing products that have "C++
Inside" or "Java Inside" are going to change their products, so the jobs
will have to come from new startups - either internal to our existing
companies or external as entrepreneurial endeavors.

> Don't let this stop you from implementing your Pythada preprocessor
> though. Just don't expect it to be used by anyone but big Python fans
> new to Ada, very few of which are hanging out in this newsgroup to be
> recruited. Perhaps you would have more luck getting support from a
> Python newsgroup.

Its always possible to build a front-end and hook it up to Gnat. If that's
the silver bullet to get Ada adopted by "The Masses", its not that difficult
or expensive to prove that theory out. But I just don't see tinkering with
the syntax as an "Official" change to the language when there is no evidence
that anything is "broke" with it. It would be just way too disruptive (even
if the old syntax still worked) to the whole industry and for what gain?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: status of Ada STL?

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> I heard that ":=" was originally chosen by some early language
> designer (can't remember who) who actually wanted to use "<=", but his
> ancient ancient keyboard didn't have "<".

I believe the language you're thinking of was Algol-60, and I believe
they wanted to use a left-pointing arrow (a single character, not a "<"
followed by an "="), which character sets didn't support, so they
searched for some other notation that indicated the asymmetric nature of
assignment, and came up with ":=".

It's sad that ancient character sets didn't have the proper symbols for
"<=", ">=", and "/=".

>... You've fooled yourself into
> thinking it has some deep meaning.

It *does* have a deep meaning, or at least some meaning more substantial
than the stated rationale for C, which involves number of keystrokes:
assignment is asymmetric (the left-hand side is very different from the
right), and ":=" indicates that reasonably well.  Assignment does not
mean the same thing as equality.

>... Einstein said, "Everything should
> be made as simple as possible, but not simpler." So Einstein agrees
> with me.

Einstein was happy to obey hundreds of years of maths tradition as to
the meaning of "=".  ;-)

Anyway, saying that "=" is simpler than ":=" seems silly to me.
Do we measure simplicity by the length of the symbol?

- Bob

Re: status of Ada STL?

[Hyman Rosen]

Fraser Wilson wrote:
> C++ seems to tie itself in knots over the issue of temporaries, which
> is why constructs such as the above have to be used.

The arithmetic assignment operators all existed in C, some decades
before C++ ever existed. The usual argument is that when you are
operating on a long name, you don't want to say it more than once -

	myArray[10].subfield1.subarray[5].z /= 2;

More likely, it helps with stepping through an array with a
post-incrementing pointer, where you simply cannot repeat the
name of the object -

	while (begin != end) *begin++ /= 2;

As far as temporaries go, it's simply a fact that operating
in place on an object is likely to be more efficient than
making a new one and copying it about. For reasonably complex
objects, it is hopeless to think that the compiler can raeson
this out for you. The usual C++ technique is to write the
infix operators in terms of the assignment ones -

	struct X
	{
		X &operator/=(const X &other)
		{
			/* do something */
			return *this;
		}
		X operator/(const X &other)
		{
			X x = *this;
			return x /= other;
		}
	};

Re: status of Ada STL?

[Pascal Obry]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccptyozndh.fsf@shell01.TheWorld.com...
> 
> > I wish it were "end My_Type", instead of "end record",
> > especially when the record contains 10 lines of components,
> > and 30 lines of comments.
> 
> I've been programming in Ada for 3 years and I still have to stop myself
> typing My_Type at the end of a record sometimes.  Silly, eh?

Same here :) It is too late to remove the "record" but will be nice to be
able to name the record:

   type My_Type is record;
      ...
   end record My_Type;

the My_Type after "end record" being optional.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> "chris.danx" <spamoff.danx@ntlworld.com> writes:
> 
> > I'm not going to argue with you (you've made up your mind and so have I,
> > what's the point?), I'm just curious as to whether compilers would see A :=
> > A / 2 and think "that code's dividing the matrix by 2 and assigning it to
> > itself.  It might be better just to divide it inplace" leading to the same
> > thing.  But then I'm largely ignorant of compilers.
> 
> I don't think any Ada compilers are that smart.

Ok, but that is a compiler issue, I don't see why it should not be possible
and it is not a language issue.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> I really don't understand the objection to my proposal. 

OK, I'll try to explain *my* objections.  (And I will refrain from
accusing you of being a C lover. ;-)  Your proposal clearly states that
your ideas come from Fortran and Python.)  I even agree with some of
what you said.

I understand your point that you can write a preprocessor, so people can
choose whichever notation they like.  I think that's a bad idea,
because it hinders communication among Ada programmers.

Here's your proposal, with my comments:

> A Cleaner Syntax for Ada Programming
> 
> Ada 95 is a great programming language with an excellent fundamental
> design. However, it has an awkward, "klunky" syntax. I propose to
> simplify its syntax by borrowing features from Fortran 95 and Python. I
> will tentatively call the resulting new dialect "Ada-F". Ada-F maintains
> all the safety features of Ada and can be converted into standard Ada 95
> with a simple pre-processor (to be developed). Existing Ada compilers
> can still be used, therefore, and programmers who wish to continue using
> the old syntax can do so. Here are the changes I propose:
> 
> 1. Eliminate semicolons, except for combining multiple statements on a
>    single line, as in Python and Fortran 95, and use "\" (backslash) to
>    continue a statement on the next line when necessary. Semicolons are
>    unnecessary clutter, and they cause many nuisance compilation
>    errors. 

Equating "statement" with "line", and then having a convention like "\"
to mean "I didn't really mean end-of-line; I just ran out of room" seems
kludgy to me.  The ";" seems much cleaner, and I don't find it a
nuisance at all.

There are some languages that eliminate the need for ";" by carefully
designing the syntax to avoid the need.  That seems reasonable,
but the "\" convention is an abomination.

> 2. Use "=" rather than ":=" for assignment. The vast majority of
>    languages use "=" for assignment, which is simpler and perfectly
>    adequate. (Continue to use "=" for equality testing if confusion with
>    assignment can be avoided, otherwise use "==", but never allow
>    assignment within an "if" test.) 

As I said in a different posting, maths tradition ought to trump the
faddish concerns of an industry that's only a few decades old.  ;-)

> 3. Use "=" instead of "=>" for passing arguments by named association,
>    as in Python and Fortran 95. Again, it is simpler and perfectly
>    adequate. 

I don't much like "=>" either, but this is another example of using "="
to mean something other than equality -- see my previous point.

An early version of Ada used ":=", ":=:", and "=:" to indicate 'in',
'in out', and 'out' actual parameters.  This I like, because I think
it's useful to indicate this information at the call site.

> 4. Use ":" instead of ".." to denote a range of numbers, as in Fortran,
>    Python, and Matlab. 

Shrug.  I see no advantage or disadvantage to ":" vs. "..".
So why change?

> 5. Add assignment operators such as "+=", "-=", "*=", and "/=". These
>    operators produce cleaner code. They could also facilitate much more
>    efficient vector/matrix operations if integrated into the core
>    language. 

I agree with you that there should be a notation for these, but given
that I reject number 2, I don't like *these* notations.  And of course,
"/=" already means something else in Ada.  I believe Algol 68 uses
"+:=", which seems OK, but I would actually prefer "Increment" or
"Incr".  The goal is not to make the notation short, but to avoid having
"X" appear twice in things like "X := X + 1;".  X could be a long
expression, and having it appear twice means the reader has to carefully
notice whether it's really the same, and also whether there are side
effects that might occur twice.  I think this:

    Incr(X, By => 2);
    Incr(X); -- By defaults to 1.

is more readable than:

    X := X + 1;

if X is a medium-to-long expression.

So on this point, I partly agree with you.

Your point about efficiency is partly right: If you call a procedure
that updates one of its parameters, that can be more efficient (eg in
the matrix case, as you say).  But this is true whether or not the
notation is built in -- it could just as well be a user-defined

    Matrix_Add(X, Y);

> 6. Allow a more natural declaration/initialization syntax, as
>    illustrated by the following example: 
> 
>    count: integer := 0; -- old syntax
> 
>    count = 0: integer -- new syntax
> 
>    The assignment is to the variable, not the type, and the new syntax
>    shows that. The same applies to default subprogram arguments. 

Shrug.  Maybe I'm just used to it, but it seems perfectly reasonable to
me to have the name of the thing, followed by its type, followed by its
initial value (more important info ... least important info).

> 7. Let "use" imply "with" so files need not be cluttered with both
>    "with" and "use" for the same package. Note that this would not
>    preclude the explicit use of "with" if that is deemed preferable. 

I agree with this point.  Saying "with X; use X;" is useless clutter
when you could just say "use X;".  (With child packages, X is often
quite long, so saying it twice hinders readability.)

> With these relatively minor changes, I believe Ada could gain the
> popularity it deserves.

This is the point I most strongly disagree with.  All of the above
issues are trivial, and even if I agreed with all of them, I don't think
they would have the slightest effect on people's language choices.

>... Yet existing compilers would still work, and
> programmers who prefer the old syntax could continue to use
> it.

This makes it even worse.  It's bad enough that people won't follow the
RM-recommended indentation and capitalization styles.  Now you're saying
they don't have to agree on the spelling of assignment and whatnot!

>... Initially, a pre-processor could be called explicitly to convert
> Ada-F files to standard Ada files, but eventually Ada compilers could do
> the conversions automatically.
> 
> The proposed syntactic changes are minor enough that it might be
> possible to allow both dialects within the same source file, but that
> has yet to be verified. If so, the pre-processor would pass standard Ada
> source lines through unchanged, and would change only lines using the
> new syntax. Another possibility is to denote Ada-F files with a keyword
> such as "Ada-F" in a comment in the first line of the file.

- Bob

Re: status of Ada STL?

[Brian Rogoff]

On Tue, 18 Jun 2002, Robert A Duff wrote:
> 18k11tm001@sneakemail.com (Russ) writes:
>
> > dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206170753.599fd771@posting.google.com>...
> > > 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206162248.45b6174e@posting.google.com>...
> > > > Certainly "=" is better than ":=" for assignment, but if you don't
> > >
> > > In what way?
> > >
> > > Logically, its not better. The symbol comes from math, where it
> > > designates an invariant equality of values, not a moving of values
> > > from one temporary storage place to another.
>
> I strongly agree with that sentiment.  Any programming language designer
> who throws away hundreds of years of perfectly good maths notation is
> being arrogant, obnoxious, rude, and evil.  ;-)
>
> Some languages use "integer" to mean a small subset of the integers, and
> "real" to mean an even smaller subset of the real numbers.  That's also
> arrogant, etc, in my opinion.  (Ada is guilty of only one of these
> sins.)

Ouch! You realize that you're saying that C and C++ got it right, and Ada
didn't? ;-)

BTW, seriously, I agree with this sentiment. int and float are much better
names. Integer, Real, and Complex are not.

I prefer :=, and if I could change C I would change = to := and modify
all of the shorthand operators to look like Icon (:+= and the like).
It is too bad that Ada doesn't have a conditional expression like ? :
in C though...

-- Brian

Re: status of Ada STL?

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> I agree with this point.  Saying "with X; use X;" is useless clutter
> when you could just say "use X;".  (With child packages, X is often
> quite long, so saying it twice hinders readability.)

What about this, the use here is not possible:

package P is
   X : Integer;
end P;

with P;
procedure P2 is

   P : Integer;

   procedure Proc is
      -- use P;            <- this is not possible because P integer
      V : Integer;
   begin
      V := Standard.P.X;   <- and you need full qualified name
   end Proc;

begin
   null;
end P2;

Also all the "with" are in the same places, easy to find, but "use" can be put
in any part of the code. And you certainly don't want to "use" all packages,
right ? All symbols visible ?

I still think that "with" and "use" is ok.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Hyman Rosen]

Pascal Obry wrote:
> Ok, but that is a compiler issue, I don't see why  it
 > should not be possible and it is not a language issue.

Of course it's a language issue. Programming languages,
especially "3rd generation" ones like Ada, C, or C++,
are means of instructing a computer what to do, in
low-level and precise detail. When a language does not
allow you to explicitly describe a certain behavior,
but instead you must hope that the implementation can
reason out what you actually wanted, that is a deficiency
in the language.

Re: status of Ada STL?

[Frank J. Lhota]

> I prefer :=, and if I could change C I would change = to := and modify
> all of the shorthand operators to look like Icon (:+= and the like).

Actually, the Icon augmented assignment operators look like this: "+:=".

I think that the Icon augmented assignment operators would be a worthwhile
addition to Ada, not so much for optimizations but for readability. A smart
compiler could probably optimize

    Whatchama_Callit.Thingy( Here ).Do_Hickey.Count :=
Whatchama_Callit.Thingy( Here ).Do_Hickey.Count  + 1;

but then you're requiring the reader to visually confirm that the expression
on the left of the assignment is the same as the expression on the left of
the "+". Granted, one solution would be to do a "renames" declaration, e.g.

    declare
        DH_Count : Natural renames Whatchama_Callit.Thingy(
Here ).Do_Hickey.Count;
    begin
        DH_Count := DH_Count + 1;
    end;

That's one solution, but wouldn't it be nicer to write this:

    Whatchama_Callit.Thingy( Here ).Do_Hickey.Count +:=
Whatchama_Callit.Thingy( Here ).Do_Hickey.Count;

If we use the Icon notation, then

    X /= Y   means  not ( X = Y )
    X /:= Y  means  X := X / Y

resolving the issue regarding the current use of the "/=" symbol.

Re: status of Ada STL?

[Brian Rogoff]

On Tue, 18 Jun 2002, Frank J. Lhota wrote:
> > I prefer :=, and if I could change C I would change = to := and modify
> > all of the shorthand operators to look like Icon (:+= and the like).
>
> Actually, the Icon augmented assignment operators look like this: "+:=".

You're right, a typo, and no Icon here to check.

> I think that the Icon augmented assignment operators would be a worthwhile
> addition to Ada, not so much for optimizations but for readability. A smart
> compiler could probably optimize

While I agree, the chances for such a change in Ada are infinitesimal.
Better to complain about things that may actually get fixed, like
downward funargs, or a more powerful (C++ like ;) exception system.

-- Brian

Re: status of Ada STL?

[Robert A Duff]

Pascal Obry <p.obry@wanadoo.fr> writes:

> What about this, the use here is not possible:
> 
> package P is
>    X : Integer;
> end P;
> 
> with P;
> procedure P2 is
> 
>    P : Integer;
> 
>    procedure Proc is
>       -- use P;            <- this is not possible because P integer
>       V : Integer;
>    begin
>       V := Standard.P.X;   <- and you need full qualified name
>    end Proc;
> 
> begin
>    null;
> end P2;

I'm not sure what the point of this example is, other than that one can
write obscure code.  You're right that "use P;" would be illegal there
(although "use Standard.P;" would be legal).  So?  The right thing to do
is change the name of one of those P's.

(I would disallow hiding altogether, if I ran the show.)

> Also all the "with" are in the same places, easy to find, but "use"
> can be put in any part of the code. And you certainly don't want to
> "use" all packages, right ? All symbols visible ?

No.  I don't know what Russ meant, but I meant that "use" in a context
clause would imply a "with".  A "use" anywhere else would not (thus
preserving the property that all the imported packages are mentioned at
the top).

- Bob

Re: status of Ada STL?

[Robert A Duff]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> I've been programming in Ada for 3 years and I still have to stop myself
> typing My_Type at the end of a record sometimes.  Silly, eh?

And I keep putting "end for;" at the end of a for loop.  ;-)

- Bob

Re: status of Ada STL?

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> While I agree, the chances for such a change in Ada are infinitesimal.
> Better to complain about things that may actually get fixed, like
> downward funargs, or a more powerful (C++ like ;) exception system.

I think it's fun to argue about the way it ought to be,
even if there is zero chance of fixing it.

Many changes are impossible because they would break existing code,
but are nonetheless fun to talk about.  Maybe in some future
language... 

- Bob

Re: status of Ada STL?

[Robert A Duff]

Pascal Obry <p.obry@wanadoo.fr> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > "chris.danx" <spamoff.danx@ntlworld.com> writes:
> > 
> > > I'm not going to argue with you (you've made up your mind and so have I,
> > > what's the point?), I'm just curious as to whether compilers would see A :=
> > > A / 2 and think "that code's dividing the matrix by 2 and assigning it to
> > > itself.  It might be better just to divide it inplace" leading to the same
> > > thing.  But then I'm largely ignorant of compilers.
> > 
> > I don't think any Ada compilers are that smart.
> 
> Ok, but that is a compiler issue, I don't see why it should not be possible
> and it is not a language issue.

It *is* a language issue.  It would be possible to design a language in
which the above optimization were trivial.  I'm not saying that's a good
idea, just that the language design has a large influence on what
optimizations are feasible.

- Bob

Re: status of Ada STL?

[Frank J. Lhota]

> While I agree, the chances for such a change in Ada are infinitesimal.

Why? Adding augmented assignment operators to Ada would break no existing
program, so it does not seem t be as big a deal as some of these other
proposals.

Re: status of Ada STL?

[Mike Silva]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206151051.1c25cf1e@posting.google.com>...

> The main objection is usually that Ada programmers are too hard to
> find. More recently, a top expert (a gcc maintainer) is claiming that
> the STL overcomes many of the objections to C++.

I wonder which objections the STL overcomes?  Hyman Rosen, care to
help out here?  Doesn't the STL require dynamic allocation (not good
for ATC)?  I could be wrong, but it seems the STL only answers a
couple of objections, not "many".  And, of course, it's voluntary, in
the sense that one can still use the dangerous but legal alternatives
and get a clean compile.

Mike

Re: status of Ada STL?

[Brian Rogoff]

On Tue, 18 Jun 2002, Frank J. Lhota wrote:
> > While I agree, the chances for such a change in Ada are infinitesimal.
>
> Why? Adding augmented assignment operators to Ada would break no existing
> program, so it does not seem t be as big a deal as some of these other
> proposals.

Because you can get the effects you want now using function call notation,
and because so many people (not me) hate this kind of thing that it would
never ever get approved for inclusion in Ada. IMO, of course.

Note that allowing in out mode for functions is also an upward compatible
extension, arguably more useful than shortcut operators, and that still
didn't make it into the language.

-- Brian

Re: status of Ada STL?

[Brian Rogoff]

On Tue, 18 Jun 2002, Robert A Duff wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
>
> > While I agree, the chances for such a change in Ada are infinitesimal.
> > Better to complain about things that may actually get fixed, like
> > downward funargs, or a more powerful (C++ like ;) exception system.
>
> I think it's fun to argue about the way it ought to be,
> even if there is zero chance of fixing it.

I didn't say zero, I said infinitesimal, as in greater than zero but less
than any positive real number. Well, I guess zero is an infinitesimal
too if you define infinitesimals as monad(0)... ;-)

> Many changes are impossible because they would break existing code,
> but are nonetheless fun to talk about.  Maybe in some future
> language...

Of course, but it should be made clear when people are talking about
which. I'm very liberal with changes I'd make in a future Ada like
language, and very conservative about changes I'd want made in an existing
language.

A few months ago lots of people here felt the need to get annoyed by
another attempt at a safe C called Cyclone, but I think that Cyclone is
worthy of study, since it has some features contemplated for the next
generation of Ada (region based memory management, at least if I
understood Tucker Taft correctly) and also some features that would be
great to see in a new language derived from Ada (pattern matching).

http://www.research.att.com/projects/cyclone/

yes, it would have been nicer if they'd started with Ada as a base, but
they're going for widespread applicability so C compatibility is an
important goal.

-- Brian

Re: status of Ada STL?

[Randy Brukardt]

chris.danx wrote in message ...
>
>"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>news:wccptyozndh.fsf@shell01.TheWorld.com...
>
>> I wish it were "end My_Type", instead of "end record",
>> especially when the record contains 10 lines of components,
>> and 30 lines of comments.
>
>I've been programming in Ada for 3 years and I still have to stop
myself
>typing My_Type at the end of a record sometimes.  Silly, eh?


I've been programming in Ada for 21 years, and often compile programs
that end with "end New_Type;" instead of "end record;". It seems obvious
now, but it's also clear from the syntax that the designers thought that
the "type Name is..." part is separate from the "record" part (type
definition vs. type declaration), so the problem is understandable. And
I don't know if it is worth fixing.

             Randy.

Re: status of Ada STL?

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> A few months ago lots of people here felt the need to get annoyed by
> another attempt at a safe C called Cyclone,

I missed that argument -- I wasn't paying attention c.l.a a few months
ago.

>... but I think that Cyclone is
> worthy of study, since it has some features contemplated for the next
> generation of Ada (region based memory management, at least if I
> understood Tucker Taft correctly) and also some features that would be
> great to see in a new language derived from Ada (pattern matching).

I was not impressed by Cyclone's region-based memory management.  At
least for the kinds of programs I write, it seemed that most of the data
would have to end up in the most-global (garbage collected) heap anyway.
Regions are not first-class citizens in Cyclone (they can't be allocated
dynamically, as in "new Region...").  But that restriction is key to
Cyclone's ability to prove stuff about them (no dangling pointers).

Tucker hates garbage collection, and longs for an efficient and safe
alternative to both by-hand memory management and GC.  Me too, but
Cyclone ain't it, IMHO.  As you say, it's worthy of study; Tucker has
mentioned some ideas for making it more powerful.

> http://www.research.att.com/projects/cyclone/
> 
> yes, it would have been nicer if they'd started with Ada as a base, but
> they're going for widespread applicability so C compatibility is an
> important goal.

C compatibility isn't the only thing.  There's also the fact that lots
of people are used to C-like syntax.  Java isn't even close to
compatible with C, but C programmers can feel comfortable with it,
because it sort of looks like C -- I have no proof, but I suspect that's
a big part of the reason Java caught on.

- Bob

Re: status of Ada STL?

[Dmitry A.Kazakov]

Frank J. Lhota wrote:

>> But then there is no necessity in having two different symbols for
> equality
>> and assignment. Make both "="!
> 
> If memory serves correctly, that was the PL/1 approach: within a context
> where a Boolean expression is expected, "=" tests for equality; outside of
> such contexts, "=" was assignment. At the time, PL/1's syntax was
> criticized for being confusing for the reader, if not the compiler. We may
> wish to exercise caution before adopting context-sensitive interpretation
> of operators.

PL/1 was a wonder. You never knew the outcome of any expression you wrote. 
Wasn't something like that the goal of the original poster? (:-)).  So I 
expected that he would immediately embrace my "improvement", and then we 
could go further and replace most of symbols with "="! I thought about ".", 
"=>" etc. So that a valid program would appear sort of white noise to an 
innocent reader. (:-)) I remember in the times of punched cards people used 
all card columns when programmed in PL/1 (it has a free syntax like Ada) to 
reduce the number of cards (one payed per card). The result was like an 
output of UUENCODE. What a fun was to read such programs! 

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Dmitry A.Kazakov]

Russ wrote:

> Immediately after the statement "x=3" executes, it becomes true in the
> mathematical sense, which is why it makes sense.

Nope. Consider C++ having user-defined type conversions. It is very easy to 
write a program in C++ that

SomeClass x;

x=3;
if (x==3) // false

In fact assignment (semantic of) has nothing to do with equality. You may 
have incomparable objects which can be assigned. You may have comparable 
objects that cannot be assigned. You may have objects which have several 
different semantics for assignment (deep/shallow copy/reference) and 
equality (distance/set equality etc).

So this argument does not work for me.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Pascal Obry <p.obry@wanadoo.fr> writes:
> 
> > What about this, the use here is not possible:
> > 
> > package P is
> >    X : Integer;
> > end P;
> > 
> > with P;
> > procedure P2 is
> > 
> >    P : Integer;
> > 
> >    procedure Proc is
> >       -- use P;            <- this is not possible because P integer
> >       V : Integer;
> >    begin
> >       V := Standard.P.X;   <- and you need full qualified name
> >    end Proc;
> > 
> > begin
> >    null;
> > end P2;
> 
> I'm not sure what the point of this example is, other than that one can
> write obscure code.  You're right that "use P;" would be illegal there
> (although "use Standard.P;" would be legal).  So?  The right thing to do
> is change the name of one of those P's.

Right but you are putting more restriction on Ada here. Everything is possible
I won't argue about this...

> No.  I don't know what Russ meant, but I meant that "use" in a context
> clause would imply a "with".  A "use" anywhere else would not (thus
> preserving the property that all the imported packages are mentioned at
> the top).

If "use" has different meaning depending on the position on the source, I
think it is just better to have "with" and "use"...

Or maybe we could also use procedure everywhere, a procedure with a return
value is like a function, and do not use begin/end but the block
command... There is a lot of room to reduce the number of keywords if this is
the game ;)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Vinzent Hoefler]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

>> 18k11tm001@sneakemail.com (Russ) wrote:
>> >Every good C++ programmer knows that "+=" is much more efficient than
>> >"+" for vector/matrix addition because it eliminates the need for
>> >constructing a temporary matrix to hold the sum.

[...]

>I think Russ is right here.
>
>X := F(X, Y);
>
>is *not* equivalent to the code that overwrites X in place,
>in the general case.  In the usual case, where the called function
>is not inlined, and the compiler doesn't look at its body,
>the compiler has no hope of doing this optimization.
>Even if it's inlined, the proof is not trivial.

Hmm, well. Seems I did not take a closer look on what operator
overloading can do. I still thought of simple C. :(

Anyway, I could declare F (X : inout ...; Y); then, to do the
assignment for me. ;-)


Vinzent.

Re: status of Ada STL?

[Vinzent Hoefler]

18k11tm001@sneakemail.com (Russ) wrote:

>don't say that because it "looks like C". I say that because it is a
>minimal form (the x need not be repeated, which can be noticibly
>simpler in a case like,
>
>my_very_descriptive_variable += 1
>
>Or do you prefer 
>
>my_very_descriptive_variable := my_very_descriptive_variable + 1;

What about polish notation?

|(my_very_descriptive_variable, 1) +

Still looks more logical to me. It would be easy to make it read

|Add (my_very_descriptive_variable, 1);

in Ada then. :-) And BTW: shouldn't

|"+"(my_very_descriptive_variable, 1)

work already?


Vinzent.

Re: status of Ada STL?

[Ed Falis]

On Wed, 19 Jun 2002 00:36:21 +0200
Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote:

> 18k11tm001@sneakemail.com (Russ) wrote:

> >my_very_descriptive_variable += 1
> >
> >Or do you prefer 
> >
> >my_very_descriptive_variable := my_very_descriptive_variable + 1;

The question is why such a verbose variable name in the first place? 
Because you use huge subprograms?

- Ed

Re: status of Ada STL?

[Jacob Sparre Andersen]

Hyman Rosen wrote:

> Pascal Obry wrote:
> > Ok, but that is a compiler issue, I don't see why  it
>  > should not be possible and it is not a language issue.

It is certainly possible. IIRC I wrote a description of how
it can be done last time the discussion came up.

> Of course it's a language issue.

B*******.

> Programming languages,
> especially "3rd generation" ones like Ada, C, or C++,
> are means of instructing a computer what to do, in
> low-level and precise detail.

Exactly. _What_ to do, more than _how_ to do it (as opposed
to machine/assembler code).

> When a language does not
> allow you to explicitly describe a certain behavior,
> but instead you must hope that the implementation can
> reason out what you actually wanted, that is a deficiency
> in the language.

Nothing prevents you from explicitly telling the compiler to
do an in-place operation, if you feel that that is important
for you. You can also write in-line assembler code in you
Ada programs, but it is in my experience not all that common
that you need it.

Jacob
-- 
"Those who profess to favor freedom and yet depreciate
 agitation, are people who want crops without ploughing the
 ground; they want rain without thunder and lightning; they
 want the ocean without the roar of its waters."
                                        -- Frederick Douglas

Re: status of Ada STL?

[Brian Rogoff]

On Tue, 18 Jun 2002, Robert A Duff wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
> >... but I think that Cyclone is
> > worthy of study, since it has some features contemplated for the next
> > generation of Ada (region based memory management, at least if I
> > understood Tucker Taft correctly) and also some features that would be
> > great to see in a new language derived from Ada (pattern matching).
>
> I was not impressed by Cyclone's region-based memory management.  At
> least for the kinds of programs I write, it seemed that most of the data
> would have to end up in the most-global (garbage collected) heap anyway.
> Regions are not first-class citizens in Cyclone (they can't be allocated
> dynamically, as in "new Region...").  But that restriction is key to
> Cyclone's ability to prove stuff about them (no dangling pointers).

That's right, Cyclone's implementors are from the ML community, so
being able to prove stuff, as you say, is a high priority.

> Tucker hates garbage collection, and longs for an efficient and safe
> alternative to both by-hand memory management and GC.

I don't know why anyone would hate garbage collection. That seems like a
rather odd sentiment. It also seems that if this is true he'll never be
satisfied, since GC is just the extreme on the automatic end for memory
management; all non-GC mem managers are "by hand" at some level.

In total half baked mode, my gut tells me that future type systems will
include a lot more usage information and compilers will be able to deduce
all sorts of nice things about your program so that even if there is no
"garbage collector" there will be little or no memory management explicit
in the code when you don't need to do it. But this is nothing like what
Ada or C++ or other low level bitdiddling languages are about, you'll need
to look at Clean's uniqueness typings or the effect systems research (by
the same guys who did the original region inference stuff I think).

> Me too, but Cyclone ain't it, IMHO.

Well, it ain't derived from Ada! Anyways, pattern matching, like all
modern functional languages have, would be a worthy addition to an
Ada like language.

> As you say, it's worthy of study; Tucker has mentioned some ideas for
> making it more powerful.

I must have missed this. Did the discussion happen here, or elsewhere?

> > http://www.research.att.com/projects/cyclone/
> >
> > yes, it would have been nicer if they'd started with Ada as a base, but
> > they're going for widespread applicability so C compatibility is an
> > important goal.
>
> C compatibility isn't the only thing.  There's also the fact that lots
> of people are used to C-like syntax.  Java isn't even close to
> compatible with C, but C programmers can feel comfortable with it,
> because it sort of looks like C -- I have no proof, but I suspect that's
> a big part of the reason Java caught on.

I disagree, and I think that there are lots of other reasons that Java
became popular, though I think that it's syntactic similarity to C helped,
I really doubt that was a large part of it. Why did Perl and Python (and
now Ruby?) achieve some popularity? My belief is that there is no great
theory of why languages become popular, and reasons that work in one time
and place won't work at others. It's just luck, or fashion.

-- Brian

Re: status of Ada STL?

[Vinzent Hoefler]

Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote:

a lot of stupid stuff late at night... :-)

>What about polish notation?
>
>|(my_very_descriptive_variable, 1) +
>
>Still looks more logical to me. It would be easy to make it read
>
>|Add (my_very_descriptive_variable, 1);
>
>in Ada then. :-) And BTW: shouldn't
>
>|"+"(my_very_descriptive_variable, 1)
>
>work already?

Well, still it wouldn't assign any value to something.


Looks like I really need a vacation. I'm back on Monday.


Vinzent.

Re: status of Ada STL?

[Vinzent Hoefler]

Ed Falis <efalis@attbi.com> wrote:

>On Wed, 19 Jun 2002 00:36:21 +0200
>Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote:
 ^^^^^^^^^^^^^^^

>> 18k11tm001@sneakemail.com (Russ) wrote:
>
>> >my_very_descriptive_variable += 1
>> >
>> >Or do you prefer 
>> >
>> >my_very_descriptive_variable := my_very_descriptive_variable + 1;
>
>The question is why such a verbose variable name in the first place? 
>Because you use huge subprograms?

Don't ask me. *I* did *not* write this...


Vinzent.

Re: status of Ada STL?

[tmoran]

>I believe the language you're thinking of was Algol-60, and I believe
>they wanted to use a left-pointing arrow (a single character, not a "<"
>followed by an "="), which character sets didn't support, so they
  I learned programming with Neliac (an Algol 58 derivative) on Flexowriters.
They had a right arrow character so you wrote "X+Y->Z" with a single, easily
distinguishable, character instead of "->".  Similarly for single <=,
>=, and /= characters, an upward pointing arrow for exponentiation,
and single And and Or characters (the U and upside down U of symbolic logic).
The punched card was a great leap backwards.

Re: status of Ada STL?

[Dale Stanbrough]

Russ wrote:

> Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message 
> news:<dale-B74C15.17040617062002@its-aw-news.its.rmit.edu.au>...
> > Russ wrote:
> > 
> > > Certainly "=" is better than ":=" for assignment, but if you don't
> > > think so, my proposal WOULD NOT STOP YOU FROM USING :=. LET ME REPEAT:
> > > MY PROPOSAL WOULD NOT STOP YOU FROM USING := FOR ASSINGMENT.
> > > 
> > > HELLO? AM I GETTING THROUGH TO ANYONE OUT THERE?
> > 
> > Likelihood of getting this changed?
> > 
> > 
> > 
> >            0
> > 
> > 
> > 
> > Dale
> 
> Likelihood of getting what "changed"? My proposal does not change the
> Ada 95 standard one iota. It only ADDS an alternative dialect. AM I
> GETTING THROUGH NOW?

PERHAPS! Actually i didn't see your original posting, and thought you
were proposing a language change. My fault for not reading it.

Anyway I still think the chances of it being accepted are 0. Ada is
a marginal (marketplace wise) langauge anyway. Anything that complicates
tool support is unlikely to be adopted. 
Dale

Re: status of Ada STL?

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> I don't know why anyone would hate garbage collection. That seems like a
> rather odd sentiment. It also seems that if this is true he'll never be
> satisfied, since GC is just the extreme on the automatic end for memory
> management; all non-GC mem managers are "by hand" at some level.

By "by hand", I mean the malloc/free or new/Unchecked_Deallocate style
of C, Ada, Pascal, etc.  Cyclone's regions are not "by hand", and can
replace GC safely and efficiently -- if your program matches the
necessary restrictions.

> Well, it ain't derived from Ada!

I meant regions, specifically.

>... Anyways, pattern matching, like all
> modern functional languages have, would be a worthy addition to an
> Ada like language.

Feel free to sketch out your ideas.  I'd be interested.

> > As you say, it's worthy of study; Tucker has mentioned some ideas for
> > making it more powerful.
> 
> I must have missed this. Did the discussion happen here, or elsewhere?

No, sorry, I didn't mean here.  These discussions happened in my
office and Tucker's office.  ;-)

- Bob

Re: status of Ada STL?

[SteveD]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccptyozndh.fsf@shell01.TheWorld.com...
> "SteveD" <nospam_steved94@attbi.com> writes:
>
> > If you look at type definitions you have:
> >
> >   type mytype is
> >     record
> >      ...
> >     end record;
>
> I wish it were "end My_Type", instead of "end record",
> especially when the record contains 10 lines of components,
> and 30 lines of comments.

Me too.  I suppose the language could be changed to permit the name of the
record following end record that is "end record My_Type" and require that
the name of the record match the name at the end if present.

> > I would much prefer:
> >   type mytype is abstract tagged
> >     record
> >        null;
> >     end record
> >     methods
> >       procedure MyProc1( value : mytype );
> >     end methods;
>
> Not an entirely unreasonable complaint, but I don't think the above
> would work very well.  At least it raises questions:  Where would you
> put the class-wide ops?  Where would you put the exceptions and generics
> that are "related" to mytype but not primitive?

I'm sure these details could be worked out.  I wasn't suggesting a specific
syntax, just suggesting that the bounds of the object definition and its
primitives be explicity defined.

> Anyway, the *usual* practise is to have one type (or one "major" type)
> per package, so "end Package_Name" serves the purpose well enough.

Bummer when we have to rely on the compiler to catch simple errors that are
eliminated by a change in syntax.  But at least the compiler will catch the
error (usually).

SteveD

> - Bob

Re: status of Ada STL?

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccbsa8zk7k.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:

> Anyway, saying that "=" is simpler than ":=" seems silly to me.
> Do we measure simplicity by the length of the symbol?

The length of the symbol is one measure of complexity, but what
bothers me even more than its length is that ":=" is just plain ugly.

I'm a pretty good programmer in C++ and Python, and I'm trying to
learn Ada too. I constantly forget to put in the colon and have to go
back and put it in. It's a minor nuisance, yes, but a totally
unnecessary nuisance. Python, on the other hand, is a joy to use (but
it is inappropriate for many applications, of course).

Think about it. Every programmer who is fluent in C, C++, Java,
Python, Perl, Fortran, etc., and who must continue to use those
languages, has to make the mental adjustment from the simple and
straightforward "=" to the goofy ":=" to use Ada. I'll bet that's 95%
of programmers out there. No wonder they are saying "no thanks" in
droves. And no, most of them won't tell you explicitly that ":=" is
what drives them away because they may not even realize it
consciously. It's just the general nuisance factor. Ada is different
from all the other major languages in use today, and it's different
just for the sake of being different. So the programmer has to say to
himself, "Let's see, am I using Ada now, or am I using a language with
standard syntax?"

Re: status of Ada STL?

[Russ]

"chris.danx" <spamoff.danx@ntlworld.com> wrote in message news:<z%BP8.1523$AZ6.154892@news6-win.server.ntlworld.com>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0206172212.4bc5cc3a@posting.google.com...
> 
> 
> > By the way, it's too bad that Ada wasted "/=" on "not equals. It would
> > be very useful for dividing a matrix by a scalar. For example, the
> > construct
> >
> > A := A / 2.0;
> >
> > is very inefficient because a temporary matrix must be created to
> > store A/2, then an assignment must be used to put the result back in
> > A. On the other hand,
> > the construct
> >
> > A /= 2.0
> >
> > is not only much cleaner looking, it is much more efficient because
> > you can skip the temporary matrix and the assignment. And please don't
> > argue with me here, because you will only be showing your ignorance.
> > Good C++ programmers know all about this.
> 
> I'm not going to argue with you (you've made up your mind and so have I,
> what's the point?), I'm just curious as to whether compilers would see A :=
> A / 2 and think "that code's dividing the matrix by 2 and assigning it to
> itself.  It might be better just to divide it inplace" leading to the same
> thing.  But then I'm largely ignorant of compilers.

The short answer is no. It cannot be done by the compiler. (If you
don't believe me, go ahead and chase your tail for a while.) However,
it could be done by a specialized pre-processor. There was talk of
adding something like that to C++ a while back, just so that people
could write more elegant code, such as

A = B + C

and have it automatically converted to the less attractive but more
efficient form

A  = B
A += C

I don't know if it ever went anywhere, but it does show that C++
programmers are well aware of these issues.

Re: status of Ada STL?

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc8z5czi89.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > I really don't understand the objection to my proposal. 
> 
> OK, I'll try to explain *my* objections.  (And I will refrain from
> accusing you of being a C lover. ;-)  Your proposal clearly states that
> your ideas come from Fortran and Python.)  I even agree with some of
> what you said.

Thanks for your thoughtful reply. I have a few rebuttals below.

> I understand your point that you can write a preprocessor, so people can
> choose whichever notation they like.  I think that's a bad idea,
> because it hinders communication among Ada programmers.
> 
> Here's your proposal, with my comments:
> 
> > A Cleaner Syntax for Ada Programming
> > 
> > Ada 95 is a great programming language with an excellent fundamental
> > design. However, it has an awkward, "klunky" syntax. I propose to
> > simplify its syntax by borrowing features from Fortran 95 and Python. I
> > will tentatively call the resulting new dialect "Ada-F". Ada-F maintains
> > all the safety features of Ada and can be converted into standard Ada 95
> > with a simple pre-processor (to be developed). Existing Ada compilers
> > can still be used, therefore, and programmers who wish to continue using
> > the old syntax can do so. Here are the changes I propose:
> > 
> > 1. Eliminate semicolons, except for combining multiple statements on a
> >    single line, as in Python and Fortran 95, and use "\" (backslash) to
> >    continue a statement on the next line when necessary. Semicolons are
> >    unnecessary clutter, and they cause many nuisance compilation
> >    errors. 
> 
> Equating "statement" with "line", and then having a convention like "\"
> to mean "I didn't really mean end-of-line; I just ran out of room" seems
> kludgy to me.  The ";" seems much cleaner, and I don't find it a
> nuisance at all.
> 
> There are some languages that eliminate the need for ";" by carefully
> designing the syntax to avoid the need.  That seems reasonable,
> but the "\" convention is an abomination.

I'm open to suggestions. Actually, if an open "(" has yet to be
closed, you don't need any line-continuation symbol. That takes care
of most multi-line statements right there, perhaps.

Also, I do not see why "\" is so bad. Fortran uses "&", which is
preferable, but that symbol is already used in Ada. The backslash is
used in many scripting languages, so it seems appropriate to me.

> > 2. Use "=" rather than ":=" for assignment. The vast majority of
> >    languages use "=" for assignment, which is simpler and perfectly
> >    adequate. (Continue to use "=" for equality testing if confusion with
> >    assignment can be avoided, otherwise use "==", but never allow
> >    assignment within an "if" test.) 
> 
> As I said in a different posting, maths tradition ought to trump the
> faddish concerns of an industry that's only a few decades old.  ;-)

Consider the major languages in widespread use today, such as C, C++,
Java, Perl, Python, and Fortran. They all use "=" for assignment. It's
virtually a standard, and it makes it easier for programmers to become
fluent in several languages. But Ada is the oddball. A programmer who
wants to be multi-lingual will therefore constantly have annoying
compilation errors when using Ada. The life of a programmer is filled
with enough annoyances already without stupid ones like that.

> > 3. Use "=" instead of "=>" for passing arguments by named association,
> >    as in Python and Fortran 95. Again, it is simpler and perfectly
> >    adequate. 
> 
> I don't much like "=>" either, but this is another example of using "="
> to mean something other than equality -- see my previous point.

The other thing that bothers me about "=>" used this way is that it is
backwards. It should really be "<=", but of course that's already
taken. If you Ada folks were consistent, you would use "=>" for
assignment too:

x => 3;

How does that grab you?

> An early version of Ada used ":=", ":=:", and "=:" to indicate 'in',
> 'in out', and 'out' actual parameters.  This I like, because I think
> it's useful to indicate this information at the call site.
> 
> > 4. Use ":" instead of ".." to denote a range of numbers, as in Fortran,
> >    Python, and Matlab. 
> 
> Shrug.  I see no advantage or disadvantage to ":" vs. "..".
> So why change?

It's not a big deal, but ":" is more consistent with other languages,
such as Python, Fortran, and Matlab. Also, it does use one less
character, and it looks better without spaces, for example: (1:3) vs
(1..3). In the latter case, the first dot looks like a decimal point.

> > 5. Add assignment operators such as "+=", "-=", "*=", and "/=". These
> >    operators produce cleaner code. They could also facilitate much more
> >    efficient vector/matrix operations if integrated into the core
> >    language. 
> 
> I agree with you that there should be a notation for these, but given
> that I reject number 2, I don't like *these* notations.  And of course,
> "/=" already means something else in Ada.  I believe Algol 68 uses
> "+:=", which seems OK, but I would actually prefer "Increment" or
> "Incr".  The goal is not to make the notation short, but to avoid having
> "X" appear twice in things like "X := X + 1;".  X could be a long
> expression, and having it appear twice means the reader has to carefully
> notice whether it's really the same, and also whether there are side
> effects that might occur twice.  I think this:
> 
>     Incr(X, By => 2);
>     Incr(X); -- By defaults to 1.
> 
> is more readable than:
> 
>     X := X + 1;
> 
> if X is a medium-to-long expression.
> 
> So on this point, I partly agree with you.
> 
> Your point about efficiency is partly right: If you call a procedure
> that updates one of its parameters, that can be more efficient (eg in
> the matrix case, as you say).  But this is true whether or not the
> notation is built in -- it could just as well be a user-defined
> 
>     Matrix_Add(X, Y);

Yes, but the name of your Matrix_Add function above does not make it
clear what is happening. Does it return the sum or add them in place?
The advantage of "+=" is that it is clear what is happening (assuming
it is implemented properly, of course). That was the original idea
behind operator overloading in the first place, wasn't it?

> > 6. Allow a more natural declaration/initialization syntax, as
> >    illustrated by the following example: 
> > 
> >    count: integer := 0; -- old syntax
> > 
> >    count = 0: integer -- new syntax
> > 
> >    The assignment is to the variable, not the type, and the new syntax
> >    shows that. The same applies to default subprogram arguments. 
> 
> Shrug.  Maybe I'm just used to it, but it seems perfectly reasonable to
> me to have the name of the thing, followed by its type, followed by its
> initial value (more important info ... least important info).

Sorry, but I don't see how it makes sense to assign the value to the
type. Also, my syntax is consistent with an assignment statement, and
that's aesthetically pleasing to me.

> > 7. Let "use" imply "with" so files need not be cluttered with both
> >    "with" and "use" for the same package. Note that this would not
> >    preclude the explicit use of "with" if that is deemed preferable. 
> 
> I agree with this point.  Saying "with X; use X;" is useless clutter
> when you could just say "use X;".  (With child packages, X is often
> quite long, so saying it twice hinders readability.)

Some people seem to think I want to eliminate "with" altogether. Not
so. But all those duplicated "with" and "use" statements are enough to
drive a beginner away from Ada, particularly when they are for nothing
but basic I/O formatting.

> > With these relatively minor changes, I believe Ada could gain the
> > popularity it deserves.
> 
> This is the point I most strongly disagree with.  All of the above
> issues are trivial, and even if I agreed with all of them, I don't think
> they would have the slightest effect on people's language choices.

And here I though I was making progress! You Ada guys never cease to
baffle me. On the one hand, my proposed changes are "trivial," and on
the other hand, implementing them will be like "moving a mountain."

> >... Yet existing compilers would still work, and
> > programmers who prefer the old syntax could continue to use
> > it.
> 
> This makes it even worse.  It's bad enough that people won't follow the
> RM-recommended indentation and capitalization styles.  Now you're saying
> they don't have to agree on the spelling of assignment and whatnot!

If you really want them to follow indentation conventions, you could
always force the issue, as Python does. But even I wouldn't go that
far.

You Ada guys are so worried about having two slightly different
dialects of Ada, but a much bigger problem for Ada is that it uses
basic syntax that is inconsistent with all the other major languages
in widespread use today, as I explained above. Unless you guys wake up
to that fact, I'm afraid Ada is on the way out -- and that's a shame.

Re: status of Ada STL?

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcchek0xpiv.fsf@shell01.TheWorld.com>...

> C compatibility isn't the only thing.  There's also the fact that lots
> of people are used to C-like syntax.  Java isn't even close to
> compatible with C, but C programmers can feel comfortable with it,
> because it sort of looks like C -- I have no proof, but I suspect that's
> a big part of the reason Java caught on.

WOW! I can't believe I actually read that! Give that man the biggest
frickin' cigar even rolled!

By the way, it ain't just compatibility with C that's important. It's
compatibility with every major language in use today, such as C, C++,
Java, Perl, Python, and even Fortran. Not a one of them uses ":="!
Every last one of them uses "=" for assignment. WAKE UP, FOLKS!

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> The length of the symbol is one measure of complexity, but what
> bothers me even more than its length is that ":=" is just plain ugly.

Only because you aren't used to looking at it yet (and *are* used to 
looking at "="). To me, and probably most other Ada programmers, "=" in 
assignments looks ugly (which is one of the reasons why you are getting 
such an unexpected negative reaction).


> I'm a pretty good programmer in C++ and Python, and I'm trying to
> learn Ada too. I constantly forget to put in the colon and have to go
> back and put it in. It's a minor nuisance, yes, but a totally

And I have the same problem with C++, until I get my mind fully switched 
over. So what?


> himself, "Let's see, am I using Ada now, or am I using a language with
> standard syntax?"

{guffaw}

There is no such thing as "standard syntax" for programming languages. 
Fortran doesn't use either "=" or "==" for equality. Cobol, which is by 
far the most widely used language in existence, doesn't use symbols at 
all. Algol, Pascal, Modula-2, Modula-3, Eiffel, VHDL, Oberon, and 
Oberon-2 all use very similar notations to Ada. APL I believe uses an 
arrow for assignment, while J (an ASCII version of APL) uses "=:" and 
"=.". Lisp uses "set" for assignment and uses "=" only for numeric 
comparisons.

When learning a new programming language, you have to learn the syntax. 
Insisting its syntax is bad simply because it doesn't match one or two 
other languages you are used to using is the height of parrochialism.

Re: status of Ada STL?

[Russ]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aemvpd$8dojl$1@ID-77047.news.dfncis.de>...
> Russ wrote:
> 
> > Immediately after the statement "x=3" executes, it becomes true in the
> > mathematical sense, which is why it makes sense.
> 
> Nope. Consider C++ having user-defined type conversions. It is very easy to 
> write a program in C++ that
> 
> SomeClass x;
> 
> x=3;
> if (x==3) // false

I should have been more specific. For any instance x of a built-in
numerical type, the statement "x=3" becomes true in a mathematical
sense immediately after it executes. (If I am wrong, please provide a
counter-example.)

> In fact assignment (semantic of) has nothing to do with equality. You may 
> have incomparable objects which can be assigned. You may have comparable 
> objects that cannot be assigned. You may have objects which have several 
> different semantics for assignment (deep/shallow copy/reference) and 
> equality (distance/set equality etc).

That's really all irrelevant to the main point here. If you have two
different objects A and B of the SAME type, then

someclass A, B;
A = B;
if ( A == B ) ... // better be true!

If this doesn't evaluate to true, you have goofy code. Yes, I realize
that asignment can be overloaded in C++ in all kinds of ways, but
that's really a distraction. Your claim that "assignment has nothing
to do with equality" is just plain wrong. Nothing to do with it? Give
me a break!

Re: status of Ada STL?

[Russ]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206180630.b6ef8cd@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206172155.1d50bbac@posting.google.com>...
> > Think about it this way. Immediately after the statement "x=1"
> > executes, the mathematical statement "x=1" becomes true. The same does
> > not apply to a statement like "x=x+1", of course, but so what? Anyone
> 
> Thanks. I could not have come up with a better example of why "=" for
> assignment is confusing and inappropriate myself.
> 
> > At that rate, a couple dozen regulars on comp.lang.ada will still be
> > proudly using Ada after everyone else has forgotten about it -- like
> 
> The problem with that logic is:
> 
>   o Ada use is increasing already (according to the vendors).
>   o There is absolutely no evidence that minor syntax differences with
> Python is significantly holding Ada back. That might seem
> self-obvioius to a big Python fan, but such people are hardly
> unbiased. Big Lisp fans would probably say the same about Lisp. Big
> Fourth fans would say the same about Forth.
>   o There is also no evidence that you won't loose all the big Pascal,
> Modula-*, and Oberon fans who are Ada users by doing this (and there
> are probably *way* more of those around than interested Python fans).

You are good at constructing a straw man and then knocking it down.
The problem is not that Ada is not like Python or even C or C++. The
problem (or, rather, one of the problems) with Ada is that it uses
non-standard syntax compared to ALL of the major languages in use in
industry today. That includes C, C++, Java, Perl, Python, and perhaps
even Fortran. Every one of those languages uses "=" for assignment,
for example. And Pascal, Modula*, Lisp, and Forth are hardly major
industrial languages.

> If you hang out here long enough (or read back through the archives),
> I guarantee you will come across all of the following:
> 
>    o  Big C fans who think Ada is only being held back by non-C-like
> syntax
>    o  Big .NET fans who are convinced Ada is only being held back from
> huge success by lack of .NET support.
>    o  Big Java fans who are convinced Ada is only being held back from
> huge success by lack of JVM support (now obsolete and proven wrong).
>    o  Big Delphi fans who are convinced Ada is only being held back
> due to its lack of a Delphi-like library and interface.
>    o  Longtime VisualC++ users who are convinced Ada is only being
> held back due to lack of a Visual programming environment.
> 
> I've been here long enough to have heard just about every theory there
> is. Frankly, I don't think the syntax theories hold any water at all.
> The programming environment theories are a smidge better, but no more.
> 
> The main reason hordes of people don't switch to Ada is that
> programmers are a very conservative lot. Given a choice, they fight
> hard to use the language they are most familiar with. Programming
> managers are even more so, since they aren't technically involved
> enough to have any judgement point other than past use. People comming
> here saying that Ada use would take off if only it used syntax items
> from their own favorite other language are just further examples of
> this principle.

And if Ada was a bit more like the other major industrial languages,
perhaps many more programmers would be willing to give it a try -- and
less likely to get frustrated by all those "missing :=" nuisance
messages.

> If we look at past successes, what builds language bases isn't
> wonderful syntax, but rather heavy marketing campaigns (with hopefully
> a germ of truth under all the BS). If we want usage to skyrocket, then
> we need to somehow foster the (generally self-fufilling) impression
> that Ada is a "hot" language. Its a bit tough to do that with no big
> moneybags company like Sun or Microsoft behind us. When someone comes
> in here and starts an "Ada's syntax is all wrong" thread, if anything
> its counterproductive.

I think you're guess is no better than mine on that point. Actually,
what motivated me to make my proposal is the desire for a programming
that is both fundamentally solid AND with a clean, syntax that is
consistent with all the other major industrial languages. I think your
theory that languages get popular only through cynical marketing is
basically wrong. Java's initial hype was due more to the promise of
platform independence and neutralizing Microsoft than some advertizing
campaign by Sun.

And by the way, why do you suppose that Java adopted C++ syntax? To be
as consistent as possible with the rest of the programming world. And
no, I am not suggesting that C++ is the best model for syntax, but at
least it uses "=" for assignment!

> Don't let this stop you from implementing your Pythada preprocessor
> though. Just don't expect it to be used by anyone but big Python fans
> new to Ada, very few of which are hanging out in this newsgroup to be
> recruited. Perhaps you would have more luck getting support from a
> Python newsgroup.

I may just give it a try one of these days when I have some free time,
though it's cetainly not my specialty. I would write it in Python, and
eventually perhaps port it to Ada.

Re: status of Ada STL?

[Ole-Hjalmar Kristensen]

Adrian Hoe <mailbox@*nospam*adrianhoe.com> writes:

<snip>

> 
> There are a lot of (re)usable Ada code (or libraries) out there
> already. Most can be easily extended. The question here is it
> necessary to make a library? And we have many Ada websites. Why not
> have these libraries and download location listed there?
> 
> Just my 2cents. ;-)
> -- 
> Remove *nospam* to email.              -- Adrian Hoe
>                                         -- http://adrianhoe.com

Yes, there are reusable libraries, but you miss the point.  The STL is
well thought out, it works, and it's part of the *standard*.  The
situation in C++ was the same as Ada for many years, lot of reusable
libraries, but no standard, and it really hurt development of portable
programs. You may argue that Ada libraries are more portable, but you
still have to download it, compile it for your platform, maybe run
some tests to make sure that it works, learn how to use it
efficiently, etc. Very often you end up rolling you own
problem-specific library.  Certainly not a problem for a large
software project which can enforce standards, but for most application
development, it's very nice to have a standard library you can depend
on.

Re: status of Ada STL?

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> It *is* a language issue.  It would be possible to design a language in

Yes I got it now. 

   A := A + 1           <- do the addition, copy back to A

is not equivalent to

   A += 1               <- in-place addition

I have never thought about that :(

Now, a compiler can trivially optimize this if A is a scalar. In the case of
complex types (like matrix) it is quite harder as the compiler must be sure
that each value in A will be use only once. For matrix this is fine for +=
and -= only though...

Anyway I agree that this is a notation that help compiler optimize the code. I
still think that this should not be added to Ada.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> Think about it. Every programmer who is fluent in C, C++, Java,
> Python, Perl, Fortran, etc., and who must continue to use those
> languages, has to make the mental adjustment from the simple and
> straightforward "=" to the goofy ":=" to use Ada.

I'm not sure if you are serious or not. But if the programmer can't do
mental adjustment for ":=" instead of "=" I'm not sure he will be able
to develop in C, C++, Java, Python, Perl, Fortran, Ada, SmallTalk, Eiffel
at the same time anyway. The most important mental adjustment is about
the design and the way to use the language, structure the code, certainly not
in changing ":=" by "="...

But maybe you see Eiffel and Python as so close that you don't need
mental adjustment ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> Also, I do not see why "\" is so bad. Fortran uses "&", which is

Let me show you (have you ever tried you syntax proposal yourself ????):

     My_Function_Call
        (First_Parameter  => 1,
         Second_Parameter => "whatever",
         Third_Parameter  => (1, 8, 9 10, 2, 0),
         Last_One         => 12.89);

vs.

     My_Function_Call \
        (First_Parameter  => 1, \
         Second_Parameter => "whatever", \
         Third_Parameter  => (1, 8, 9 10, 2, 0), \
         Last_One         => 12.89)

So you have removed one ";" and added four "\" !!!!!

> preferable, but that symbol is already used in Ada. The backslash is
> used in many scripting languages, so it seems appropriate to me.

Do you have a Ada-F parser ? If so start using it, put it on your web page
along with some nice examples.

> You Ada guys are so worried about having two slightly different
> dialects of Ada, but a much bigger problem for Ada is that it uses
> basic syntax that is inconsistent with all the other major languages
> in widespread use today, as I explained above. Unless you guys wake up
> to that fact, I'm afraid Ada is on the way out -- and that's a shame.

You Russ, you are trying to push a new syntax based on some "dreams" and you
have actually never used it :) You seem to have not even taken the time to
write some simple Ada-F sources... credibility ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Dmitry A. Kazakov]

On 18 Jun 2002 22:32:12 -0700, 18k11tm001@sneakemail.com (Russ) wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aemvpd$8dojl$1@ID-77047.news.dfncis.de>...
>> Russ wrote:
>> 
>> > Immediately after the statement "x=3" executes, it becomes true in the
>> > mathematical sense, which is why it makes sense.
>> 
>> Nope. Consider C++ having user-defined type conversions. It is very easy to 
>> write a program in C++ that
>> 
>> SomeClass x;
>> 
>> x=3;
>> if (x==3) // false
>
>I should have been more specific. For any instance x of a built-in
>numerical type, the statement "x=3" becomes true in a mathematical
>sense immediately after it executes. (If I am wrong, please provide a
>counter-example.)

1. From ADT point of view there is no difference between numerical,
built-in or whatsoever types and other types. There are good reasons
why it should be so.

2. Try [C is a funny language!]:

   int x;

   x=1.5;
   if (x == 1.5) // false
--------------------------------
   float x;

   x = 1.00000001;
   if (x != 1.00000001) printf ("oops!\n");

>> In fact assignment (semantic of) has nothing to do with equality. You may 
>> have incomparable objects which can be assigned. You may have comparable 
>> objects that cannot be assigned. You may have objects which have several 
>> different semantics for assignment (deep/shallow copy/reference) and 
>> equality (distance/set equality etc).
>
>That's really all irrelevant to the main point here. If you have two
>different objects A and B of the SAME type,

What is for two types to be SAME? It is not an easy question as one
might think.

> then
>
>someclass A, B;
>A = B;
>if ( A == B ) ... // better be true!

But then if you would insist that it should be so in strict
mathematical set-theoretic sense, I would derive from that, that also

A'Address = B'Address -- better be true!

If A and B are SAME then there should be no way to distingush them.
From programming point of view it has in most cases no sense [however,
see LSP]. "==" is not equality it only models one of many possible.

>If this doesn't evaluate to true, you have goofy code. Yes, I realize
>that asignment can be overloaded in C++ in all kinds of ways, but
>that's really a distraction. Your claim that "assignment has nothing
>to do with equality" is just plain wrong. Nothing to do with it? Give
>me a break!

You can start to define what is equality of two fuzzy sets. What is
equality of two floating-point numbers. What is equality of two remote
servers. What is equality of two people. Go on.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Dmitry A. Kazakov]

On Wed, 19 Jun 2002 00:36:20 +0200, Vinzent Hoefler
<JeLlyFish.software@gmx.net> wrote:

>Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>
>>> 18k11tm001@sneakemail.com (Russ) wrote:
>>> >Every good C++ programmer knows that "+=" is much more efficient than
>>> >"+" for vector/matrix addition because it eliminates the need for
>>> >constructing a temporary matrix to hold the sum.
>
>[...]
>
>>I think Russ is right here.
>>
>>X := F(X, Y);
>>
>>is *not* equivalent to the code that overwrites X in place,
>>in the general case.  In the usual case, where the called function
>>is not inlined, and the compiler doesn't look at its body,
>>the compiler has no hope of doing this optimization.
>>Even if it's inlined, the proof is not trivial.
>
>Hmm, well. Seems I did not take a closer look on what operator
>overloading can do. I still thought of simple C. :(
>
>Anyway, I could declare F (X : inout ...; Y); then, to do the
>assignment for me. ;-)

Yes, but it would be nice to have an operator equivalent for that:

procedure "+:=" (Accum : inout A; Argument : A);

I think it would be relatively easy to add some extra keywords like
"+:=", "-:=" etc. They should have no priorities and one need not
predefine them for any type. 

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Dmitry A. Kazakov]

On Tue, 18 Jun 2002 18:56:43 GMT, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>(I would disallow hiding altogether, if I ran the show.)

I almost agree with that. But I am not sure that there would be no
problems with it. Did somebody investigated the case?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Marin David Condic]

I have no objection to adopting an existing library and declaring it to be
"The Ada Answer". The problem is that if all you have is "Somewhere out on
the net you can download this piece and that piece and some other piece...."
you don't really have an integrated answer that gives Ada some additional
leverage. How does someone write a textbook about Ada and show the student
how to do things with a library if there is no "Conventional" library to
rely on? How does an Ada programmer used to using library X start looking at
code written with library Y quickly understand and exploit it? If there were
only three libraries out there, it might not be so bad, but there are dozens
of them and you can't even count on one that comes with some specific
development environment - like MSVC++ comes with MFC. (Not "standard", but
at least a developer who used MSVC++ in one job will recognize what's going
on with it in another job.)

Unless some collection of stuff gets declared to be The Ada Answer in some
semi-official or conventional/customary way, someone with a more integrated
answer (such as C++ & STL or Java and all its class libraries) is always
going to have a hard-to-overcome competitive advantage. All the
protestations of "But you can download one of a dozen...." or "You can bind
to ...." or "You can go cobble together tools from these dozen...." won't
overcome the one-stop-shopping and integrated advantage of some competing
languages.

Like I said elsewhere - its the price of admission these days, not a
guarantee of success.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Adrian Hoe" <mailbox@*nospam*adrianhoe.com> wrote in message
news:3d0f0c40_1@news.tm.net.my...
>
>
> There are a lot of (re)usable Ada code (or libraries) out there
> already. Most can be easily extended. The question here is it
> necessary to make a library? And we have many Ada websites. Why not
> have these libraries and download location listed there?
>

Re: status of Ada STL?

[Marin David Condic]

Exactly! And lots of other good reasons too! (Or should that be
"Megadittos++" :-)

I think Ada will get there. Eventually, there will be a "Standard Library"
in some manner. The question is, will it be too little too late?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote in message
news:7vvg8f4s48.fsf@vlinux.voxelvision.no...
>
> Yes, there are reusable libraries, but you miss the point.  The STL is
> well thought out, it works, and it's part of the *standard*.  The
> situation in C++ was the same as Ada for many years, lot of reusable
> libraries, but no standard, and it really hurt development of portable
> programs. You may argue that Ada libraries are more portable, but you
> still have to download it, compile it for your platform, maybe run
> some tests to make sure that it works, learn how to use it
> efficiently, etc. Very often you end up rolling you own
> problem-specific library.  Certainly not a problem for a large
> software project which can enforce standards, but for most application
> development, it's very nice to have a standard library you can depend
> on.
>
>
>

Re: status of Ada STL?

[Marin David Condic]

There are a lot of "Might Have Been's" out there, but at the end of the day,
Ada syntax is just not that badly broken that it needs to be fixed. If a
change could be made in Ada0x that is not disruptive of existing code and
just makes everything a little bit prettier, then O.K. But I don't think
there is anything here that is so bad that one can argue that programmers
out there will change their religion if only we tinker with the syntax. If
there were any bad "syntax traps" (such as C and some other languages have
with if statements), I'd say they should be fixed - but there just isn't
anything that bad in the language. It is what it is and we ought to be
content to basically leave it alone.

Maybe if we said:

type X is record
    --blah blah blah
end record X ;

That would create something that is mildly prettier and maybe a little more
natural feeling and it wouldn't disrupt existing code and (probably)
wouldn't badly disturb the compilers out there. But I just wouldn't want to
create any hardship over something that only makes Ada slightly prettier
than she already is. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:ugv46kfald9f83@corp.supernews.com...
>
> I've been programming in Ada for 21 years, and often compile programs
> that end with "end New_Type;" instead of "end record;". It seems obvious
> now, but it's also clear from the syntax that the designers thought that
> the "type Name is..." part is separate from the "record" part (type
> definition vs. type declaration), so the problem is understandable. And
> I don't know if it is worth fixing.
>
>              Randy.
>
>
>

Re: status of Ada STL?

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aenioj$rdu$1@nh.pace.co.uk>...
> contention would be that these days, libraries and IDEs are the price of
> admission - not a guarantee of success. If you *do* have them, people might

Personally, I'm not sure I believe that. However, I happen to like
them a lot myself. So if some people having this attitude gets more
Ada libraries and development tools made, who am I to complain? :-)

> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0206180630.b6ef8cd@posting.google.com...
> > If we look at past successes, what builds language bases isn't
> > wonderful syntax, but rather heavy marketing campaigns (with hopefully
> >
> Marketing got people to open their wallets and give up their hard-earned
> cash in exchange for a rock in a cardboard box. They did it in great
> numbers, too. A strong marketing campaign would do a lot for Ada - but who
> would fund it?
>
> That isn't the only reason languages flourish, but it is one of the reasons
> it happens in recent years. (I don't recall ATT investing heavily in a "Use
> C" campaign - but they did give away an OS that was written in C and had a
> compiler come along for the ride.)

Sort of. There was such a campaign, but it was largely user evangelism
driven. What also worked to C's benifit was that it rode the Unix
wave. Unix *was* heavily pushed by a lot of different hardware vendors
(Sun again being one). If you got Unix, you got C. Other compilers had
to be purchased (or built). This is very similar to the mechanisim
that Microsoft today uses to push things like IE and Windows Media
Player.

Re: status of Ada STL?

[Ted Dennison]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206182158.3cfaecdc@posting.google.com>...
> The problem is not that Ada is not like Python or even C or C++. The
> problem (or, rather, one of the problems) with Ada is that it uses
> non-standard syntax compared to ALL of the major languages in use in
> industry today. That includes C, C++, Java, Perl, Python, and perhaps

Baloney. The majority of all software in use right now is Cobol. Cobol
doesn't use "=" at all. On the strength of Cobol alone, "=" assignment
is in the minority. Add to that all the code in Delphi (heavily used
in application development), Lisp-based funtional langauges (almost
universal in AI applications), Modula-based languages (heavily used in
the auto industry), VHDL (heavily used in the chip design biz), and
APL (a sentimental favorite of mathematicians). Perhaps then you will
begin to see that you are just looking at one niche in the software
industry who's main claim to fame is that you happen to live in it.

Re: status of Ada STL?

[Marin David Condic]

I've seen these suggested in this thread and others. I guess I don't like
the way it looks and I think there is a problem with it. In C, the "="
operator is a function call with side effects. In Ada the ":=" operator is
*not* a function - its a primitive operation of the language. Creating
things like "+:=" and "-:=" (and next we'll need some flavor of the "z = (a
> b) ? a : b;" operation? :-) starts confusing the concept of assignment as
a primitive operation and (possibly user definable) functions.

People here have posted wishing Ada would allow them to define a function
":=" just like they can define "=", but it falls apart because ":=" isn't a
function. Wouldn't it also fall apart if we started including "+:="?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:ltu0huchrmmjkabapv55qjrrv1firg9gpi@4ax.com...
>
> I think it would be relatively easy to add some extra keywords like
> "+:=", "-:=" etc. They should have no priorities and one need not
> predefine them for any type.
>

Re: status of Ada STL?

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> I'm a pretty good programmer in C++ and Python, and I'm trying to
> learn Ada too. I constantly forget to put in the colon and have to go
> back and put it in. It's a minor nuisance, yes, but a totally
> unnecessary nuisance. 

To make it even more minor, use my 'gnat-fix-error.el', available from
http://users.erols.com/leakstan/Stephe/emacs/index.html. It recognizes
many syntax-type errors reported by gnat, and can automatically fix
them (including this one). Requires Emacs.

Productivity does depend on proper tools. Emacs is one, Ada is
another.
-- 
-- Stephe

Re: status of Ada STL?

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0206190619.1ee07e80@posting.google.com...
>
> Personally, I'm not sure I believe that. However, I happen to like
> them a lot myself. So if some people having this attitude gets more
> Ada libraries and development tools made, who am I to complain? :-)
>
Well, not *every* customer is driven by spiffy IDE's and libraries. It
depends a lot on your target environment and applications. But certainly
*lots* of developers are driven by it. (Difficult to prove or disprove, but
if the market is any indication - look how many Microsoft has sold?)

And I agree that if saying "its important" gets more/better tools built,
then I'm willing to say it. :-)


>
> Sort of. There was such a campaign, but it was largely user evangelism
> driven. What also worked to C's benifit was that it rode the Unix
> wave. Unix *was* heavily pushed by a lot of different hardware vendors
> (Sun again being one). If you got Unix, you got C. Other compilers had
> to be purchased (or built). This is very similar to the mechanisim
> that Microsoft today uses to push things like IE and Windows Media
> Player.

Well, O.K. It was maybe not a well organized media extravaganza, ala
Sun/Java or Microsoft/Win95, but it was a kind of marketing campaign. And it
may not have been all that deliberate on the part of AT&T - by the time Sun
got to it, Unix/C was already a well entrenched thing.

Not all languages had a campaign such as this. How did Fortran or Cobol
catch on? Demand was there and the product just showed up - no real effort
necessary.

But just because languages caught on without media campaigns isn't to say
that a marketing campaign isn't a good idea. The problem is finding someone
to fund it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: status of Ada STL?

[Brian Rogoff]

On Wed, 19 Jun 2002, Robert A Duff wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
>
> > I don't know why anyone would hate garbage collection. That seems like a
> > rather odd sentiment. It also seems that if this is true he'll never be
> > satisfied, since GC is just the extreme on the automatic end for memory
> > management; all non-GC mem managers are "by hand" at some level.
>
> By "by hand", I mean the malloc/free or new/Unchecked_Deallocate style
> of C, Ada, Pascal, etc.  Cyclone's regions are not "by hand", and can
> replace GC safely and efficiently -- if your program matches the
> necessary restrictions.

Well, I think that there will always (as long as I live, say ;) be places
where doing everything "by hand" will be cost effective, so there will
always be a place for a language which facilitates this. And I agree that
Cyclone currently does not provide all of the forms of memort management
one could reasonably need. It's a research project.

> > Well, it ain't derived from Ada!
>
> I meant regions, specifically.

Got it, my misinterpretation. For anyone reading who is unaware, regions
are roughly what some people call arenas, with some extensions.

> >... Anyways, pattern matching, like all
> > modern functional languages have, would be a worthy addition to an
> > Ada like language.
>
> Feel free to sketch out your ideas.  I'd be interested.

I believe the Cyclone work could be extended directly to an Ada like
language. Conceptually, we want to add let (like destructuring-bind for
you Lispers) and enhance Ada's case statement with pattern matching forms.
In Cyclone, they add a "$" to the C syntax to handle this, and uses
C's && for pattern guards. We'd use "and".

Probably it would be more interesting if such a syntax could be entirely
upward compatible with Ada 95, but I'm not sure how important that is.

I'll put together some examples, and post them under a more relevant
subject line.

Just so everyone knows where I'm coming from, rather than being some
disgruntled C programmer  who wants to make Ada look like C, I'm a
disgruntled ML programmer who'd like to see an Ada like language (meaning
low level) with some MLish features. As far as high level languages go,
I think some ML variant (strict FPL with imperative features, modules)
extended with support for overloading is about right for me. Even the
current MLs are better than the amazingly bad gunk (like Java) that gets
foisted on the programming community.

> > > As you say, it's worthy of study; Tucker has mentioned some ideas for
> > > making it more powerful.
> >
> > I must have missed this. Did the discussion happen here, or elsewhere?
>
> No, sorry, I didn't mean here.  These discussions happened in my
> office and Tucker's office.  ;-)

Are you preparing a paper on it?

-- Brian

Re: status of Ada STL?

[Hyman Rosen]

Russ wrote:
> The short answer is no. It cannot be done by the compiler. (If you
> don't believe me, go ahead and chase your tail for a while.) However,
> it could be done by a specialized pre-processor. There was talk of
> adding something like that to C++ a while back, just so that people
> could write more elegant code, such as
> 
> A = B + C
> 
> and have it automatically converted to the less attractive but more
> efficient form
> 
> A  = B
> A += C
> 
> I don't know if it ever went anywhere, but it does show that C++
> programmers are well aware of these issues.

Not only has it gone somewhere, it went there on steroids.
And it's all doable using existing C++ (albeit to its full
extent), so it doesn't require language changes. See
<http://www.oonumerics.org/blitz/whatis.html>.

Check out <http://www.boost.org/libs/lambda/doc/index.html>
while you're at it.

Automatic template instanciation and partial specialization of
templates form an incredibly useful and powerful tool. (It's
actually Turing-complete!) It's my favorite aspect of C++.

Re: status of Ada STL?

[Robert I. Eachus]

18k11tm001@sneakemail.com (Russ) writes:
 
>By the way, it's too bad that Ada wasted "/=" on "not equals. It would
>be very useful for dividing a matrix by a scalar. For example, the
>construct
>
>A := A / 2.0;
>
>is very inefficient because a temporary matrix must be created to
>store A/2, then an assignment must be used to put the result back in
>A. On the other hand,
>the construct
>
>A /= 2.0
>
>is not only much cleaner looking, it is much more efficient because
>you can skip the temporary matrix and the assignment. And please don't
>argue with me here, because you will only be showing your ignorance.
 

Okay, I'll show my ignorance.  Let's say that your hypothetical Ada 0Y 
compiler generated code without temporaries for the matrix operation A 
/= 2.0;  Would it do the same for A /= 0.2?  If it did, what would 
happen if one element resulted in an overflow?

On the other hand, if you choose to have the compiler use non-signalling 
infinities for such overflows, then it is easy enough for the compiler 
to do the inlining for all matrix op scalar combinations.

So as I see it, the issue here is not syntax, it is the Ada rule that an 
exception on the right hand side of an assignment statement does not 
destroy the target of the assignment.  If you are willing to dispense 
with that, you don't have Ada.  If you are proposing to add a syntax 
(such as Foo++;) for such operations, go ahead.  Most of us will be 
content with Inc(Foo); for cases where exceptions are not an issue. 
Personally, I do define Inc for modular types, and I even have some code 
which defines both:

procedure Inc(X: in out Modular);

and

function Inc(X: in Modular) return Modular;

I should probably lose some sleep over the potential confusion to the 
reader, but it has never bothered me. ;-)

Re: status of Ada STL?

[Brian Rogoff]

On Wed, 19 Jun 2002, Hyman Rosen wrote:
> Not only has it gone somewhere, it went there on steroids.
> And it's all doable using existing C++ (albeit to its full
> extent), so it doesn't require language changes. See
> <http://www.oonumerics.org/blitz/whatis.html>.
>
> Check out <http://www.boost.org/libs/lambda/doc/index.html>
> while you're at it.
>
> Automatic template instanciation and partial specialization of
> templates form an incredibly useful and powerful tool. (It's
> actually Turing-complete!) It's my favorite aspect of C++.

I believe you are mistaken, though I haven't looked at C++ in a long time.
I was told that template instantiation is now limited by some arbitrary
constant (17?) so as to avoid the problem with non-halting compilation.
Is that true?

For those of you who care about such stuff, a similar approach is used
in type inference approaches that support polymorphic recursion (a la
Mycroft and O'Keefe) to prevent nonterminating compilation.

-- Brian

Re: status of Ada STL?

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> Well, I think that there will always (as long as I live, say ;) be places
> where doing everything "by hand" will be cost effective, so there will
> always be a place for a language which facilitates this.

Yes, of course.  If nothing else, you have to write the GC (or whatever)
in some lower level language.

> Got it, my misinterpretation. For anyone reading who is unaware, regions
> are roughly what some people call arenas, with some extensions.

And to bring this a little closer to the topic of Ada:
regions have something in common with a "for T'Storage_Size use ..."
clause.

> I'll put together some examples, and post them under a more relevant
> subject line.

Excellent.  One thing I don't like about the pattern matching of ML and
the like, and that I *do* like about Ada's case statement is the full
coverage rules.  I think a huge benefit of Ada is that you can write a
case statement without an "others", and you get a set of mutually
exclusive choices, and the compiler lets you know when you need to add
more (e.g. because you added an enumeration literal to a type).
(Too bad case statements are so restrictive.)

The pattern matching features I've seen are more like "elsif" chains.

> Are you preparing a paper on it?

Not yet -- just tossing ideas around.

- Bob

Re: status of Ada STL?

[Robert A Duff]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> 18k11tm001@sneakemail.com (Russ) writes:
>  
> >By the way, it's too bad that Ada wasted "/=" on "not equals. It would
> >be very useful for dividing a matrix by a scalar. For example, the
> >construct
> >
> >A := A / 2.0;
> >
> >is very inefficient because a temporary matrix must be created to
> >store A/2, then an assignment must be used to put the result back in
> >A. On the other hand,
> >the construct
> >
> >A /= 2.0
> >
> >is not only much cleaner looking, it is much more efficient because
> >you can skip the temporary matrix and the assignment. And please don't
> >argue with me here, because you will only be showing your ignorance.
>  
> 
> Okay, I'll show my ignorance.  Let's say that your hypothetical Ada 0Y 
> compiler generated code without temporaries for the matrix operation A 
> /= 2.0;  Would it do the same for A /= 0.2?  If it did, what would 
> happen if one element resulted in an overflow?
> 
> On the other hand, if you choose to have the compiler use non-signalling 
> infinities for such overflows, then it is easy enough for the compiler 
> to do the inlining for all matrix op scalar combinations.
> 
> So as I see it, the issue here is not syntax, it is the Ada rule that an 
> exception on the right hand side of an assignment statement does not 
> destroy the target of the assignment.

That was true in Ada 83, but the rules in Ada 95 are much more lax.
As I read 11.6(6), if you have this:

    X := Matrix_Multiply(Y, Z);

if some operation inside Matrix_Multiply overflows, then X can indeed be
destroyed.  In RM terms, X can become "abnormal", which means merely
looking at it can cause you to turn into stone.

In fact, if you say:

    A := 1.0;
    X := Matrix_Multiply(Y, Z);
    B := 2.0;

then A and B can be destroyed, too.

11.6 is very subtle, and I'm not sure I fully understand it, and I'm
sure I don't like it.  ;-)  I think the moral of the 11.6 story is,
"don't handle predefined exceptions".

The changes to 11.6 were deliberate.  The purpose was to allow more
optimizations, e.g. on some modern machines where exceptions don't
get noticed until long after they have occurred.

Turning "X := X + Y;" into "X +:= Y;" is still not a trivial
optimization, because you have to worry about the aliasing.

>...  If you are willing to dispense 
> with that, you don't have Ada.  If you are proposing to add a syntax 
> (such as Foo++;) for such operations, go ahead.  Most of us will be 
> content with Inc(Foo); for cases where exceptions are not an issue. 
> Personally, I do define Inc for modular types, and I even have some code 
> which defines both:
> 
> procedure Inc(X: in out Modular);
> 
> and
> 
> function Inc(X: in Modular) return Modular;
> 
> I should probably lose some sleep over the potential confusion to the 
> reader, but it has never bothered me. ;-)

Sounds perfectly reasonable.  I like the above.  But C programmers will
want:

  function Inc(X: in out Modular) return Modular;

which is evil in my opinion.  (And happens to be illegal in Ada.)

What I really want to be able to do is:

  procedure Inc(X: in out Root_Modular'Class);

which is of course impossible to write in Ada.

- Bob

Re: status of Ada STL?

[Brian Rogoff]

On Wed, 19 Jun 2002, Robert A Duff wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
> > I'll put together some examples, and post them under a more relevant
> > subject line.
>
> Excellent.  One thing I don't like about the pattern matching of ML and
> the like, and that I *do* like about Ada's case statement is the full
> coverage rules.  I think a huge benefit of Ada is that you can write a
> case statement without an "others", and you get a set of mutually
> exclusive choices, and the compiler lets you know when you need to add
> more (e.g. because you added an enumeration literal to a type).
> (Too bad case statements are so restrictive.)

Not sure I get you here.

bpr@granite[bpr]$ ledit ocaml
        Objective Caml version 3.04

# type foo = Foo | Bar | Baz;;
type foo = Foo | Bar | Baz
# let f = function Foo -> "foo" | Bar -> "bar";;
Warning: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
Baz
val f : foo -> string = <fun>
#let f1 = function Foo -> "foo" | _ -> "Non foo";;
val f1 : foo -> string = <fun>

Isn't that the behavior you want?

> The pattern matching features I've seen are more like "elsif" chains.

They are far more powerful than elsif chains, since they do matching and
binding. They're certainly a feature for programming in the small, but
they have the IMO wonderful property of being readable and very succinct.

> > Are you preparing a paper on it?
>
> Not yet -- just tossing ideas around.

Hey, toss them around here too!

-- Brian

Re: status of Ada STL?

[SteveD]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206181855.5a80b2fd@posting.google.com...
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:<wccbsa8zk7k.fsf@shell01.TheWorld.com>...
> > 18k11tm001@sneakemail.com (Russ) writes:
>
> > Anyway, saying that "=" is simpler than ":=" seems silly to me.
> > Do we measure simplicity by the length of the symbol?
>
> The length of the symbol is one measure of complexity, but what
> bothers me even more than its length is that ":=" is just plain ugly.
>
I fully disagree.

> just for the sake of being different. So the programmer has to say to
> himself, "Let's see, am I using Ada now, or am I using a language with
> standard syntax?"

Wow!  When did any language have "standard syntax".  If it were standard
syntax they would all look like Ada :-)   After all Ada has been a
"standard" longer than C (unless you want to talk about de-facto standards,
but then who uses K&R C anymore?).

Rather than try to change the language, how about producing an IDE with a
programming language sensitive spell checker?  Actually GNAT already does
some of what is required since it often suggests that the variable you
selected is perhaps some other variable misspelled.

Personally I do most of my work in Ada and Delphi.  They both use ":=" for
assignment.  I also do a significant amount of work in C.

Sure I have to shift gears a bit when switching between languages, but whats
new?
I do find that when I go back to work on C I have to switch into "super
careful" mode because typo's are often accepted and produce the wrong
result.

SteveD

Re: status of Ada STL?

[Ted Dennison]

SteveD wrote:
> programming language sensitive spell checker?  Actually GNAT already does
> some of what is required since it often suggests that the variable you
> selected is perhaps some other variable misspelled.

I love that. Compare this with VisualC++, which reports a missing } on 
the end of a class as an error somewhere in the next header file.

Re: status of Ada STL?

[Russ]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<ibt0hu4fdr9ql5duvgogp9iv6vf57kqgr7@4ax.com>...
> On 18 Jun 2002 22:32:12 -0700, 18k11tm001@sneakemail.com (Russ) wrote:
> 
> >Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aemvpd$8dojl$1@ID-77047.news.dfncis.de>...
> >> Russ wrote:
> >> 
> >> > Immediately after the statement "x=3" executes, it becomes true in the
> >> > mathematical sense, which is why it makes sense.
> >> 
> >> Nope. Consider C++ having user-defined type conversions. It is very easy to 
> >> write a program in C++ that
> >> 
> >> SomeClass x;
> >> 
> >> x=3;
> >> if (x==3) // false
> >
> >I should have been more specific. For any instance x of a built-in
> >numerical type, the statement "x=3" becomes true in a mathematical
> >sense immediately after it executes. (If I am wrong, please provide a
> >counter-example.)
> 
> 1. From ADT point of view there is no difference between numerical,
> built-in or whatsoever types and other types. There are good reasons
> why it should be so.
> 
> 2. Try [C is a funny language!]:
> 
>    int x;
> 
>    x=1.5;
>    if (x == 1.5) // false
> --------------------------------
>    float x;
> 
>    x = 1.00000001;
>    if (x != 1.00000001) printf ("oops!\n");

All you've shown here is that assignment does not always work as
expected in C. I agree that a non-integer shouldn't simply be
converted an integer with no warning, but that's a completely separate
issue from the semantics of assignment. Had those assignments worked
as the programmer presumably intended them to, the tests would have
evaluated to true.

Let me postulate a rule of good programming practice, and you can let
me know if you agree with it or not. If I define an assignment
operation for a particular type or between any two types, and if I
also define an equality test between them, then immediately after the
assignment is executed for instances of those two types, the equality
test should evaluate to true. For example:

type1 A;
type2 B;
...
A = B;
if ( A == B ) ... // true or you goofed somewhere, dude!

Note that it will not always make sense to define the assignment
operator and/or the equality test operator for every possible
combination of types, and my rule applies only when they are both
defined. Unless you disagree with this rule, you must agree that there
is indeed a very close relationship between assignment and equality
testing, and your earlier claim that they have "nothing to do" with
each other is nonsense. And so is the notion that "=" should not be
used for assignment.

> >> In fact assignment (semantic of) has nothing to do with equality. You may 
> >> have incomparable objects which can be assigned. You may have comparable 
> >> objects that cannot be assigned. You may have objects which have several 
> >> different semantics for assignment (deep/shallow copy/reference) and 
> >> equality (distance/set equality etc).
> >
> >That's really all irrelevant to the main point here. If you have two
> >different objects A and B of the SAME type,
> 
> What is for two types to be SAME? It is not an easy question as one
> might think.
> 
> > then
> >
> >someclass A, B;
> >A = B;
> >if ( A == B ) ... // better be true!
> 
> But then if you would insist that it should be so in strict
> mathematical set-theoretic sense, I would derive from that, that also
> 
> A'Address = B'Address -- better be true!

In C++ you can define the "==" operator for any two types any way you
wish. Your particular definition depends on the problem you are trying
to solve, of course. But in most cases you probably would not be
testing whether the two objects are actually one and the same object.

> If A and B are SAME then there should be no way to distingush them.
> From programming point of view it has in most cases no sense [however,
> see LSP]. "==" is not equality it only models one of many possible.

But I contend it should at least be consistent with your assignment
operator for the type or types it applies to.

> >If this doesn't evaluate to true, you have goofy code. Yes, I realize
> >that asignment can be overloaded in C++ in all kinds of ways, but
> >that's really a distraction. Your claim that "assignment has nothing
> >to do with equality" is just plain wrong. Nothing to do with it? Give
> >me a break!
> 
> You can start to define what is equality of two fuzzy sets. What is
> equality of two floating-point numbers. What is equality of two remote
> servers. What is equality of two people. Go on.

As I'm sure you well know, good programmers rarely test for exact
equality of two floating point numbers. And if you can test for exact
equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am
missing your point here. Do you have one?

Re: status of Ada STL?

[Russ]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206190635.48fe03a5@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206182158.3cfaecdc@posting.google.com>...
> > The problem is not that Ada is not like Python or even C or C++. The
> > problem (or, rather, one of the problems) with Ada is that it uses
> > non-standard syntax compared to ALL of the major languages in use in
> > industry today. That includes C, C++, Java, Perl, Python, and perhaps
> 
> Baloney. The majority of all software in use right now is Cobol. Cobol
> doesn't use "=" at all. On the strength of Cobol alone, "=" assignment
> is in the minority. Add to that all the code in Delphi (heavily used
> in application development), Lisp-based funtional langauges (almost
> universal in AI applications), Modula-based languages (heavily used in
> the auto industry), VHDL (heavily used in the chip design biz), and
> APL (a sentimental favorite of mathematicians). Perhaps then you will
> begin to see that you are just looking at one niche in the software
> industry who's main claim to fame is that you happen to live in it.

You have a lots of knifty tricks, don't you. By talking about
"software in use", you can pretend that dying languages are still
thriving. By the same trick, I suppose I could tell my boss that I
don't need to show up for work tomorrow because I have a program
running that is working for me.

The issue is not which languages are "in use right now" in the sense
of 30-year-old legacy code that is still executing. The issue is which
languages are being used on a large scale for new software
development. I'm hardly an expert on that, but I hope to heck that
Cobol isn't one of them. And if you think that Lisp is still going
strong, you must live in an ivory tower somewhere. Modula I don't know
about, but I certainly don't hear much about it. If it is still
"heavily used" in the auto industry, then I'm darn glad I bolted from
Michigan after I graduated.

Re: status of Ada STL?

[Dmitry A.Kazakov]

Robert A Duff wrote:

> What I really want to be able to do is:
> 
>   procedure Inc(X: in out Root_Modular'Class);
> 
> which is of course impossible to write in Ada.

What for? I vote with both hands for:

procedure Inc(X: in out Modular'Class);

but to have a common ancestor for all modular types. what for? And what to 
do with:

type Digital_Outs is new Unsigned_16;

It is bad enough that type cloning was lost for tagged types.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Russ]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uofe7k6ut.fsf@wanadoo.fr>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Also, I do not see why "\" is so bad. Fortran uses "&", which is
> 
> Let me show you (have you ever tried you syntax proposal yourself ????):
> 
>      My_Function_Call
>         (First_Parameter  => 1,
>          Second_Parameter => "whatever",
>          Third_Parameter  => (1, 8, 9 10, 2, 0),
>          Last_One         => 12.89);
> 
> vs.
> 
>      My_Function_Call \
>         (First_Parameter  => 1, \
>          Second_Parameter => "whatever", \
>          Third_Parameter  => (1, 8, 9 10, 2, 0), \
>          Last_One         => 12.89)
> 
> So you have removed one ";" and added four "\" !!!!!

Actually, you don't need ANY backslashes in your example (if you put
the open "(" on the first line of the function call). If a "(" is
unanswered by a ")", the compiler knows that the statement must
continue on the next line.

> > preferable, but that symbol is already used in Ada. The backslash is
> > used in many scripting languages, so it seems appropriate to me.
> 
> Do you have a Ada-F parser ? If so start using it, put it on your web page
> along with some nice examples.

Good idea.

> > You Ada guys are so worried about having two slightly different
> > dialects of Ada, but a much bigger problem for Ada is that it uses
> > basic syntax that is inconsistent with all the other major languages
> > in widespread use today, as I explained above. Unless you guys wake up
> > to that fact, I'm afraid Ada is on the way out -- and that's a shame.
> 
> You Russ, you are trying to push a new syntax based on some "dreams" and you
> have actually never used it :) You seem to have not even taken the time to
> write some simple Ada-F sources... credibility ?

You have a point.

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> But I contend it should at least be consistent with your assignment
> operator for the type or types it applies to.

One thing you are going to have to get used to in Ada is that assignment 
is *not* an operator. There are ways to indirectly change what it does 
for some user-defined types (hopefully Ada200X will change that to 
"all"), and you can disable it by making your type limited, but you 
can't overload it or do anything else with it directly.

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> You have a lots of knifty tricks, don't you. By talking about

The truth is often inconvienent, isn't it?

> "software in use", you can pretend that dying languages are still
> thriving. By the same trick, I suppose I could tell my boss that I

In what way is Cobol "dying"? Last I heard, there was more new Cobol 
being written every year that there probabaly is Python code in existence.

I'll try this once again: Just because you don't use it and don't come 
across it much yourself, doesn't mean a language isn't quite healthy.


> strong, you must live in an ivory tower somewhere. Modula I don't know
> about, but I certainly don't hear much about it. If it is still

That's the exact problem isn't it? You can't just assume that anything 
you don't hear about in your work must not be thriving or important.

Re: status of Ada STL?

[Colin Paul Gloster]

In article news:slrnagu71l.eei.Colin_Paul_Gloster@camac.dcu.ie , overly
harsh words such as

"[..] While GNU C++ has (or at least fairly recently had) a reputation for good
conformance to C++ templates, it has (or had) a reputation for one of the least
implemented STL implementations available. [..]"

What I really should have said is that it has a reputation for poor
performance.

Re: status of Ada STL?

[Russ]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aes7nh$9ar7i$1@ID-77047.news.dfncis.de>...
> Russ wrote:

> > Let me postulate a rule of good programming practice, and you can let
> > me know if you agree with it or not. If I define an assignment
> > operation for a particular type or between any two types, and if I
> > also define an equality test between them, then immediately after the
> > assignment is executed for instances of those two types, the equality
> > test should evaluate to true. For example:
> > 
> > type1 A;
> > type2 B;
> > ...
> > A = B;
> > if ( A == B ) ... // true or you goofed somewhere, dude!
> 
> It is a good rule for 80% cases. Unfortunately it is not always possible to 
> follow it. The real-world is more complicated than one might think. A pair 
> examples:
> 
> 1. A refers a hardware register. So A = 2, initiates I/O (read from A/D 
> converter port Base + 2) and as a result A becomes 123!
> 
> 2. A is a fuzzy set, then A==B is a pair of confidence factors, which 
> cannot be tested in "if".
> 
> and so on and so far.

If my rule doesn't apply, then I don't think that assignment and/or
equality test operators should be used. Appropriate functions should
be defined instead.

> >> You can start to define what is equality of two fuzzy sets. What is
> >> equality of two floating-point numbers. What is equality of two remote
> >> servers. What is equality of two people. Go on.
> > 
> > As I'm sure you well know, good programmers rarely test for exact
> > equality of two floating point numbers. And if you can test for exact
> > equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am
> > missing your point here. Do you have one?
> 
> The point is that though a set-theoretic equality might be defined, for 
> some types it might appear unusable for them, like for floating-points or 
> fuzzy sets. For other things it cannot be defined at all, yet alternative 
> equality definitions might have sense for them. So there are situations 
> when reasonable defined assignment and equality are not conformant with 
> your proposition.

Again, I contend that if my rule (requiring consistency of assignment
and equality testing) does not apply, then those operators are
inappropriate anyway. You shouldn't use "==" (or whatever your symbol
is) for comparing two "fuzzy" sets unless you are testing for exact
equality. Is you are merely testing for similarity, than you should
write a function called "areSimilar" or some such thing. Otherwise,
YOU are the one abusing mathematical notation.

So were back to the original point. Assignment and equality testing
are very tightly related, and using "=" for assignment is perfectly
reasonable.

Re: status of Ada STL?

[Russ]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aes7nh$9ar7i$1@ID-77047.news.dfncis.de>...
> Russ wrote:

> > Let me postulate a rule of good programming practice, and you can let
> > me know if you agree with it or not. If I define an assignment
> > operation for a particular type or between any two types, and if I
> > also define an equality test between them, then immediately after the
> > assignment is executed for instances of those two types, the equality
> > test should evaluate to true. For example:
> > 
> > type1 A;
> > type2 B;
> > ...
> > A = B;
> > if ( A == B ) ... // true or you goofed somewhere, dude!
> 
> It is a good rule for 80% cases. Unfortunately it is not always possible to 
> follow it. The real-world is more complicated than one might think. A pair 
> examples:
> 
> 1. A refers a hardware register. So A = 2, initiates I/O (read from A/D 
> converter port Base + 2) and as a result A becomes 123!
> 
> 2. A is a fuzzy set, then A==B is a pair of confidence factors, which 
> cannot be tested in "if".
> 
> and so on and so far.

If my rule doesn't apply, then I don't think that assignment and/or
equality test operators should be used. Appropriate functions should
be defined instead.

> >> You can start to define what is equality of two fuzzy sets. What is
> >> equality of two floating-point numbers. What is equality of two remote
> >> servers. What is equality of two people. Go on.
> > 
> > As I'm sure you well know, good programmers rarely test for exact
> > equality of two floating point numbers. And if you can test for exact
> > equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am
> > missing your point here. Do you have one?
> 
> The point is that though a set-theoretic equality might be defined, for 
> some types it might appear unusable for them, like for floating-points or 
> fuzzy sets. For other things it cannot be defined at all, yet alternative 
> equality definitions might have sense for them. So there are situations 
> when reasonable defined assignment and equality are not conformant with 
> your proposition.

Again, I contend that if my rule (requiring consistency of assignment
and equality testing) does not apply, then those operators are
inappropriate anyway. You shouldn't use "==" (or whatever your symbol
is) for comparing two "fuzzy" sets unless you are testing for exact
equality. Is you are merely testing for similarity, than you should
write a function called "areSimilar" or some such thing. Otherwise,
YOU are the one abusing mathematical notation.

So were back to the original point. Assignment and equality testing
are very tightly related, and using "=" for assignment is perfectly
reasonable.

Re: status of Ada STL?

[Russ]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aes7nh$9ar7i$1@ID-77047.news.dfncis.de>...
> Russ wrote:

> > Let me postulate a rule of good programming practice, and you can let
> > me know if you agree with it or not. If I define an assignment
> > operation for a particular type or between any two types, and if I
> > also define an equality test between them, then immediately after the
> > assignment is executed for instances of those two types, the equality
> > test should evaluate to true. For example:
> > 
> > type1 A;
> > type2 B;
> > ...
> > A = B;
> > if ( A == B ) ... // true or you goofed somewhere, dude!
> 
> It is a good rule for 80% cases. Unfortunately it is not always possible to 
> follow it. The real-world is more complicated than one might think. A pair 
> examples:
> 
> 1. A refers a hardware register. So A = 2, initiates I/O (read from A/D 
> converter port Base + 2) and as a result A becomes 123!
> 
> 2. A is a fuzzy set, then A==B is a pair of confidence factors, which 
> cannot be tested in "if".
> 
> and so on and so far.

If my rule doesn't apply, then I don't think that assignment and/or
equality test operators should be used. Appropriate functions should
be defined instead.

> >> You can start to define what is equality of two fuzzy sets. What is
> >> equality of two floating-point numbers. What is equality of two remote
> >> servers. What is equality of two people. Go on.
> > 
> > As I'm sure you well know, good programmers rarely test for exact
> > equality of two floating point numbers. And if you can test for exact
> > equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am
> > missing your point here. Do you have one?
> 
> The point is that though a set-theoretic equality might be defined, for 
> some types it might appear unusable for them, like for floating-points or 
> fuzzy sets. For other things it cannot be defined at all, yet alternative 
> equality definitions might have sense for them. So there are situations 
> when reasonable defined assignment and equality are not conformant with 
> your proposition.

Again, I contend that if my rule (requiring consistency of assignment
and equality testing) does not apply, then those operators are
inappropriate anyway. You shouldn't use "==" (or whatever your symbol
is) for comparing two "fuzzy" sets unless you are testing for exact
equality. Is you are merely testing for similarity, than you should
write a function called "areSimilar" or some such thing. Otherwise,
YOU are the one abusing mathematical notation.

So were back to the original point. Assignment and equality testing
are mirror images (or should be), and using "=" for assignment is
perfectly reasonable.

Re: status of Ada STL?

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uofe7k6ut.fsf@wanadoo.f> >      My_Function_Call \
> >         (First_Parameter  => 1, \
> >          Second_Parameter => "whatever", \
> >          Third_Parameter  => (1, 8, 9 10, 2, 0), \
> >          Last_One         => 12.89)
> > 
> > So you have removed one ";" and added four "\" !!!!!
> 
> Actually, you don't need ANY backslashes in your example (if you put
> the open "(" on the first line of the function call). If a "(" is
> unanswered by a ")", the compiler knows that the statement must
> continue on the next line.

Ok, and with this one:

        package My_New_Package is \
           new My_Package.My_Child_Generic_Package \
                (Name = ...,
                 Xyz  = ...);

You need 2 backslashes, then because you have '(' you don't need them
anymore... Consistency ??

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: status of Ada STL?

[Dmitry A.Kazakov]

Russ wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message
> news:<ibt0hu4fdr9ql5duvgogp9iv6vf57kqgr7@4ax.com>...
>> On 18 Jun 2002 22:32:12 -0700, 18k11tm001@sneakemail.com (Russ) wrote:
>> 
>> >Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message
>> >news:<aemvpd$8dojl$1@ID-77047.news.dfncis.de>...
>> >> Russ wrote:
>> >> 
>> >> > Immediately after the statement "x=3" executes, it becomes true in
>> >> > the mathematical sense, which is why it makes sense.
>> >> 
>> >> Nope. Consider C++ having user-defined type conversions. It is very
>> >> easy to write a program in C++ that
>> >> 
>> >> SomeClass x;
>> >> 
>> >> x=3;
>> >> if (x==3) // false
>> >
>> >I should have been more specific. For any instance x of a built-in
>> >numerical type, the statement "x=3" becomes true in a mathematical
>> >sense immediately after it executes. (If I am wrong, please provide a
>> >counter-example.)
>> 
>> 1. From ADT point of view there is no difference between numerical,
>> built-in or whatsoever types and other types. There are good reasons
>> why it should be so.
>> 
>> 2. Try [C is a funny language!]:
>> 
>>    int x;
>> 
>>    x=1.5;
>>    if (x == 1.5) // false
>> --------------------------------
>>    float x;
>> 
>>    x = 1.00000001;
>>    if (x != 1.00000001) printf ("oops!\n");
> 
> All you've shown here is that assignment does not always work as
> expected in C. I agree that a non-integer shouldn't simply be
> converted an integer with no warning, but that's a completely separate
> issue from the semantics of assignment. Had those assignments worked
> as the programmer presumably intended them to, the tests would have
> evaluated to true.

I just gave you counter-examples. They show that even with primitive 
numerical types it is not so easy defend your point, because even they are 
not mathematical entities, but only inprecise models of those. Three 
involved types int, float and double model in the examples real numbers and 
oops, here you are. With user-defined types it becomes far worse.

Aside, you are trying to tie one langauge level the semantics of one 
operator with the semantics of another. This is a wrong way, which makes 
things more complicated for a programmer. It is wrong because SEMANTICS is 
a property of a program and not of the language the program is written in.
Interestingly is that Ada's design is on your side here, sigh. For 
instance, Ada tries to deduce inequality operator user-defined equality. It 
also tries to deduce assignment (":=") from copy-constructor (bitwise copy 
+ user-defined Adjust), etc. In my opinion it is a wrong way to do things.

> Let me postulate a rule of good programming practice, and you can let
> me know if you agree with it or not. If I define an assignment
> operation for a particular type or between any two types, and if I
> also define an equality test between them, then immediately after the
> assignment is executed for instances of those two types, the equality
> test should evaluate to true. For example:
> 
> type1 A;
> type2 B;
> ...
> A = B;
> if ( A == B ) ... // true or you goofed somewhere, dude!

It is a good rule for 80% cases. Unfortunately it is not always possible to 
follow it. The real-world is more complicated than one might think. A pair 
examples:

1. A refers a hardware register. So A = 2, initiates I/O (read from A/D 
converter port Base + 2) and as a result A becomes 123!

2. A is a fuzzy set, then A==B is a pair of confidence factors, which 
cannot be tested in "if".

and so on and so far.

> Note that it will not always make sense to define the assignment
> operator and/or the equality test operator for every possible
> combination of types, and my rule applies only when they are both
> defined. Unless you disagree with this rule,

> you must agree that there
> is indeed a very close relationship between assignment and equality
> testing, and your earlier claim that they have "nothing to do" with
> each other is nonsense. And so is the notion that "=" should not be
> used for assignment.

The above is a wrong logic. Surely there is a very tight relation between 
"+" and "-" for some types, should then "+" be denoted as "-"? "Related" 
does not mean "same". I didn't claimed that assignment and equality have 
nothing to do with each other, I claimed that their semantcis does.

>> >> In fact assignment (semantic of) has nothing to do with equality. You
>> >> may have incomparable objects which can be assigned. You may have
>> >> comparable objects that cannot be assigned. You may have objects which
>> >> have several different semantics for assignment (deep/shallow
>> >> copy/reference) and equality (distance/set equality etc).
>> >
>> >That's really all irrelevant to the main point here. If you have two
>> >different objects A and B of the SAME type,
>> 
>> What is for two types to be SAME? It is not an easy question as one
>> might think.
>> 
>> > then
>> >
>> >someclass A, B;
>> >A = B;
>> >if ( A == B ) ... // better be true!
>> 
>> But then if you would insist that it should be so in strict
>> mathematical set-theoretic sense, I would derive from that, that also
>> 
>> A'Address = B'Address -- better be true!
> 
> In C++ you can define the "==" operator for any two types any way you
> wish. Your particular definition depends on the problem you are trying
> to solve, of course. But in most cases you probably would not be
> testing whether the two objects are actually one and the same object.

Sometimes I will. Consider UNIX-like processes. A meaningful assignment 
would kill the target and replace it with a clone of the source. A 
meaningfull equality would test if both processes are the same process.

>> If A and B are SAME then there should be no way to distingush them.
>> From programming point of view it has in most cases no sense [however,
>> see LSP]. "==" is not equality it only models one of many possible.
> 
> But I contend it should at least be consistent with your assignment
> operator for the type or types it applies to.

It is a good practice. But agian, "*" should be [when possible] consistent 
with "+", which by no means forces us to use the same symbol for both.

>> >If this doesn't evaluate to true, you have goofy code. Yes, I realize
>> >that asignment can be overloaded in C++ in all kinds of ways, but
>> >that's really a distraction. Your claim that "assignment has nothing
>> >to do with equality" is just plain wrong. Nothing to do with it? Give
>> >me a break!
>> 
>> You can start to define what is equality of two fuzzy sets. What is
>> equality of two floating-point numbers. What is equality of two remote
>> servers. What is equality of two people. Go on.
> 
> As I'm sure you well know, good programmers rarely test for exact
> equality of two floating point numbers. And if you can test for exact
> equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am
> missing your point here. Do you have one?

The point is that though a set-theoretic equality might be defined, for 
some types it might appear unusable for them, like for floating-points or 
fuzzy sets. For other things it cannot be defined at all, yet alternative 
equality definitions might have sense for them. So there are situations 
when reasonable defined assignment and equality are not conformant with 
your proposition.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Russ]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0206180630.b6ef8cd@posting.google.com>...

> If we look at past successes, what builds language bases isn't
> wonderful syntax, but rather heavy marketing campaigns (with hopefully
> a germ of truth under all the BS). If we want usage to skyrocket, then
> we need to somehow foster the (generally self-fufilling) impression
> that Ada is a "hot" language. Its a bit tough to do that with no big
> moneybags company like Sun or Microsoft behind us. When someone comes
> in here and starts an "Ada's syntax is all wrong" thread, if anything
> its counterproductive.

Oh, so Ada needs "moneybags" like Sun or Microsoft behind it, eh?

Let's see, the DoD annual budget has been around $200,000,000,000 to
$300,000,000,000 for the past couple of decades, and it MANDATED Ada
for much of that time.

So we agree that Ada is a technically superior language -- and it had
the mother of all "moneybags" solidly behind it in the form of a
mandate. I wonder why it isn't as popular as C, C++, and Java. Could
the klunky syntax be a part of the problem?

Oh, I'm sure you will come with another excuse.

Re: status of Ada STL?

[Russ]

Ted Dennison <dennison@telepath.com> wrote in message news:<3D11C9ED.4010709@telepath.com>...
> Russ wrote:
> > You have a lots of knifty tricks, don't you. By talking about
> 
> The truth is often inconvienent, isn't it?

Yes it is, as you are about to find out.

> > "software in use", you can pretend that dying languages are still
> > thriving. By the same trick, I suppose I could tell my boss that I
> 
> In what way is Cobol "dying"? Last I heard, there was more new Cobol 
> being written every year that there probabaly is Python code in existence.

Interesting. I did a little web search, and I discovered, to my
amazement, that Cobol is indeed still thriving. You were right about
that. But I also did a little check on Cobol syntax, and I found that
it actually uses "=" for assignment (in its "COMPUTE" statement). So
thanks for solidifying my argument. You're wrong on the main point
even though you're right on a subordinate point.

Let's see, what are the most widely used languages today? How about
Cobol, C, C++, Java, Fortran, Perl, and Ada. And lo and behold, every
one of them except Ada uses "=" for assignment (come to think of it,
doesn't BASIC use "=" too?).

Somebody ought to do a study. It seems that you can almost predict the
popularity of a language based on whether or not it uses "=" for
assignment. It seems that all the major languages use "=", and all the
minor languages use something else.

Consider the four major scripting languages: Basic, Perl, Python, and
Tcl/Tk. I haven't checked on Basic, but I think it uses "=" for
assignment, as do Perl and Python. They are all wildly popular, with
Python growing radidly. Tcl was once consider a rising star, but now
it seems to be fading away (though it still has a devoted group of
core users). I personally happen to be a good Tcl programmer and I
think it is the best language around for straight GUIs, so I am
certainly not biased against it. But guess what? Tcl does not use "="
for assignment, and it is dwindling in popularity. Coincidence? You
decide.

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> Oh, so Ada needs "moneybags" like Sun or Microsoft behind it, eh?

No, I never said that, and I don't believe it does. It doesn't really 
matter either way though, because it doesn't have one and isn't likely 
to get one in the near future. We have to find a way to make do with 
less financial resources to purchase glowing media coverage.


> Let's see, the DoD annual budget has been around $200,000,000,000 to
> $300,000,000,000 for the past couple of decades, and it MANDATED Ada
> for much of that time.

:-)
You could make this number even larger by using the US tax rolls for 
those years. After all, the DoD is part of the US government. Actually, 
you could even trump that by using the US GDP, on the basis that the 
government is owned by the people.

If you want to be realistic about it though, you'd have to compare the 
money spend on marketing Ada by the AJPO to comparable amounts spent by 
Sun's marketing department on Java. It would be much more interesting to 
see that comparison.

A lot of the stuff they did do (like the mandate) was at least partially 
counterproductive. The mandate served its purpose for the DoD quite 
well, but it didn't help Ada out all that much. The point of the mandate 
was not to promote Ada, it was to lessen the tremendous amount of 
different languages that were being used on DoD jobs. With the mandate 
in place, it made it a bit tougher to use one of the little niche 
languages, like CMS-2. However, the effect on Ada was roughly the same 
as the effect on the popularity of classics like Shakespeare among high 
school students when they are forced to read it for a class.

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> that. But I also did a little check on Cobol syntax, and I found that
> it actually uses "=" for assignment (in its "COMPUTE" statement). So

:-)
Yikes! You're right. I looked for it by doing a search through a lot of 
source code, and never found it. I guess that was a bad method. :-(

> assignment, as do Perl and Python. They are all wildly popular, with

I'd really like to see hard numbers on just how "wildly popular" and 
"rapidly growing" Python is. I've yet to personally bump into any Python 
code "in the wild", but of course that doesn't mean anything. Still, I'd 
be suprised if we didn't find orders of magnitude more Ada code out 
there, and a larger absolote growth for Ada as well (although probably 
less of a growth rate). Perhaps that's wrong too, but I think I'd need 
to see numbers on it before believing some absolute statement like that 
(particularly one comming from someone who thought Cobol was dead).


> Python growing radidly. Tcl was once consider a rising star, but now
> it seems to be fading away (though it still has a devoted group of
> core users). I personally happen to be a good Tcl programmer and I
> think it is the best language around for straight GUIs, so I am

I used to use TCL/TK quite a bit myself. It was really cool to be able 
to build GUI's interactively at the command line. What I eventually 
discovered was that I couldn't read and modify my own TCL code after 
about 6 months of not looking at it.

I don't know why anyone else quit using TCL, but for me its only big 
attraction was the portable GUI (TK). Once GTK+ came along, I had no 
further use for it. But in general, I think it was just a fad language. 
I have yet to be convinced that all of the other "scripting languages" 
aren't in that category too (although you could probably make a good 
case for Perl).

Re: status of Ada STL?

[Russ]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<u7kktk7tq.fsf@wanadoo.fr>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uofe7k6ut.fsf@wanadoo.f> >      My_Function_Call \
> > >         (First_Parameter  => 1, \
> > >          Second_Parameter => "whatever", \
> > >          Third_Parameter  => (1, 8, 9 10, 2, 0), \
> > >          Last_One         => 12.89)
> > > 
> > > So you have removed one ";" and added four "\" !!!!!
> > 
> > Actually, you don't need ANY backslashes in your example (if you put
> > the open "(" on the first line of the function call). If a "(" is
> > unanswered by a ")", the compiler knows that the statement must
> > continue on the next line.
> 
> Ok, and with this one:
> 
>         package My_New_Package is \
>            new My_Package.My_Child_Generic_Package \
>                 (Name = ...,
>                  Xyz  = ...);
> 
> You need 2 backslashes, then because you have '(' you don't need them
> anymore... Consistency ??

I don't think you need the "\" after the is, and if you move the
opening "(" up to the same line as "new ...", you won't need that "\"
either. I think it looks better that way anyway. Here's how I'd write
it:

    package My_New_Package is
        new My_Package.My_Child_Generic_Package (
            Name = ...,
            Xyz  = ...
            )

No backslash line continuations are needed in this example either. And
they would rarely be needed in general if good formatting is used.
Long statements can usually be broken up AND made more readable by the
use of intermediate variables anyway.

Re: status of Ada STL?

[Ian Wild]

Russ wrote:
> 
>...
> Somebody ought to do a study. It seems that you can almost predict the
> popularity of a language based on whether or not it uses "=" for
> assignment. It seems that all the major languages use "=", and all the
> minor languages use something else.

Hence the massive popularity of PL/I, Rexx, and Snobol these days,
compared to rarely-used languages like Postscript, Emacs lisp, and Forth.

Re: status of Ada STL?

[Dmitry A. Kazakov]

On 20 Jun 2002 11:20:44 -0700, 18k11tm001@sneakemail.com (Russ) wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aes7nh$9ar7i$1@ID-77047.news.dfncis.de>...
>> Russ wrote:
>
>> The point is that though a set-theoretic equality might be defined, for 
>> some types it might appear unusable for them, like for floating-points or 
>> fuzzy sets. For other things it cannot be defined at all, yet alternative 
>> equality definitions might have sense for them. So there are situations 
>> when reasonable defined assignment and equality are not conformant with 
>> your proposition.
>
>Again, I contend that if my rule (requiring consistency of assignment
>and equality testing) does not apply, then those operators are
>inappropriate anyway. You shouldn't use "==" (or whatever your symbol
>is) for comparing two "fuzzy" sets unless you are testing for exact
>equality. Is you are merely testing for similarity, than you should
>write a function called "areSimilar" or some such thing. Otherwise,
>YOU are the one abusing mathematical notation.

For a fuzzy inference engine equality defined as a function having
fuzzy boolean result is perfectly reasonable in both mathematical and
practical sense. It is not an abuse.

>So were back to the original point. Assignment and equality testing
>are very tightly related, and using "=" for assignment is perfectly
>reasonable.

I can only repeat that 'to be related' is not 'to be same'. Your idea
(when applied consequently) is to replace statements with their
postconditions, i.e. instead of saying "what to do" one says "what he
wants to have". It is nothing new, but it was nothing to do with
languages like Ada.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Dmitry A. Kazakov]

On Wed, 19 Jun 2002 10:35:18 -0400, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>I've seen these suggested in this thread and others. I guess I don't like
>the way it looks and I think there is a problem with it. In C, the "="
>operator is a function call with side effects. In Ada the ":=" operator is
>*not* a function - its a primitive operation of the language. Creating
>things like "+:=" and "-:=" (and next we'll need some flavor of the "z = (a
>> b) ? a : b;" operation? :-)

?: is another story, but do not blame C for it. Ada has "and then" and
"or else", which are not much better from a puristic point view. [ It
is of course not so, that I liked Ada have ?: (:-)) ]

>starts confusing the concept of assignment as
>a primitive operation and (possibly user definable) functions.

There is nothing wrong with that. A function could be a primitive
operation. But assignment should be a procedure, not a function. We
already have operations (+, -, *, / etc) implemented by functions.

Why not to have operators (+:=, -:=, etc) implemented by procedures or
entry points?

>People here have posted wishing Ada would allow them to define a function
>":=" just like they can define "=", but it falls apart because ":=" isn't a
>function.

What's wrong with:

procedure '':=" (Target : in out A; Source : A); -- (*)

Note I do not demand that the copy constructor would be derived from
":=". It is IMO a wrong idea to attempt to derive one from another.
C++ does it simplier. What is actually wrong in C++ is that the result
of "=" is not void.

>Wouldn't it also fall apart if we started including "+:="?

No, they should be just user-defined procedures. Whether they are
primitive or not should only depend on the freezing rules and whether
particular parameters are class-wide.

(*)  There is a minor problem with unconstrained subtypes passed as
inout and that discriminants cannot be changed.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Marin David Condic]

To most Ada users, the syntax is not "klunky" and it is the least of their
concerns. Ada may shrivel up and die - but it won't be because of the
syntax. It may die because programmers don't like the rigid structure -
prefering to be "free spirits". It may die because programmers don't like
its type safety or its tasking model or its method of supporting OO
Programming or a dozen other more "global" and "serious" concerns. But it
won't die because the syntax for assignment is ":=" instead of "=". I've got
to believe that most programmers are more "grown up " than that and can get
over their personal preferences for this style or that style of syntactic
notation to look at the much more significant issues of how well the
language does the work that they want to do.

Try researching the criticisms that have been leveled against Ada in various
newsgroups, websites, articles, etc. You'll easily find a lot of them. You
won't find much reference to "klunky" syntax among the criticisms.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206201447.7d70511d@posting.google.com...
>
> So we agree that Ada is a technically superior language -- and it had
> the mother of all "moneybags" solidly behind it in the form of a
> mandate. I wonder why it isn't as popular as C, C++, and Java. Could
> the klunky syntax be a part of the problem?

Re: status of Ada STL?

[Mark Biggar]

"Dmitry A. Kazakov" wrote:
> 
> procedure '':=" (Target : in out A; Source : A); -- (*)
> 
> Note I do not demand that the copy constructor would be derived from
> ":=". It is IMO a wrong idea to attempt to derive one from another.
> C++ does it simplier. What is actually wrong in C++ is that the result
> of "=" is not void.
> 
> >Wouldn't it also fall apart if we started including "+:="?
> 
> No, they should be just user-defined procedures. Whether they are
> primitive or not should only depend on the freezing rules and whether
> particular parameters are class-wide.
> 
> (*)  There is a minor problem with unconstrained subtypes passed as
> inout and that discriminants cannot be changed.

There are other problems as well.  This was looked at in detail during
the Ada95 revision.  Allowing users to redefine ":=" using a procedure
definition like that above was determine to be way too course grained.
Do you expect your new assignment operation to compose for record or 
array types? What about variable initialization?  Or, the assign out
during procedure exit for out parameters?

This is way ada95 controlled types are tagged and break the assignment
process down into finer parts with Initialize, Adjust and Finalize
as user definable hooks into a larger assignment process.  This way
use defines the type specific parts of data movement and the compiler
is free to use them in various ways to move data around in ways the 
guarantees that the type's data abstractions are preserved. 

--
Mark Biggar
mark.a.biggar@attbi.com

Re: status of Ada STL?

[Russ]

Ted Dennison <dennison@telepath.com> wrote in message news:<3D127686.5030400@telepath.com>...

> A lot of the stuff they did do (like the mandate) was at least partially 
> counterproductive. The mandate served its purpose for the DoD quite 
> well, but it didn't help Ada out all that much. The point of the mandate 
> was not to promote Ada, it was to lessen the tremendous amount of 
> different languages that were being used on DoD jobs. With the mandate 
> in place, it made it a bit tougher to use one of the little niche 
> languages, like CMS-2. However, the effect on Ada was roughly the same 
> as the effect on the popularity of classics like Shakespeare among high 
> school students when they are forced to read it for a class.

The mandate also forced many people to learn Ada and apply it. No
doubt many resented that, but many others who were forced to use Ada
must have realized that it is a good language and spread the word.
Having an 800-pound (or $300 billion) gorilla on your side has some
advantages.

Re: status of Ada STL?

[Russ]

Ted Dennison <dennison@telepath.com> wrote in message news:<3D128874.4060304@telepath.com>...

> I'd really like to see hard numbers on just how "wildly popular" and 
> "rapidly growing" Python is. I've yet to personally bump into any Python 
> code "in the wild", but of course that doesn't mean anything. Still, I'd 
> be suprised if we didn't find orders of magnitude more Ada code out 
> there, and a larger absolote growth for Ada as well (although probably 
> less of a growth rate). Perhaps that's wrong too, but I think I'd need 
> to see numbers on it before believing some absolute statement like that 
> (particularly one comming from someone who thought Cobol was dead).

Last I heard Python was well behind Perl but catching up. I've never
used Perl myself, but it seems to have a reputation for being hard to
read. Someone once referred to Perl as a "write-only" language. For
that reason, it apparently doesn't scale up to larger projects very
well. Python, on the other hand, has exactly the opposite reputation:
it reads clearly and scales up fairly well. It will never replace C++
or Ada, but it beats them for rapid prototyping. I've been using it
recently to generate input test data for large C/C++ programs (and
perhaps eventually Ada programs, if I can successfully sell Ada here).


> 
> > Python growing radidly. Tcl was once consider a rising star, but now
> > it seems to be fading away (though it still has a devoted group of
> > core users). I personally happen to be a good Tcl programmer and I
> > think it is the best language around for straight GUIs, so I am
> 
> I used to use TCL/TK quite a bit myself. It was really cool to be able 
> to build GUI's interactively at the command line. What I eventually 
> discovered was that I couldn't read and modify my own TCL code after 
> about 6 months of not looking at it.
> 
> I don't know why anyone else quit using TCL, but for me its only big 
> attraction was the portable GUI (TK). Once GTK+ came along, I had no 
> further use for it. But in general, I think it was just a fad language. 
> I have yet to be convinced that all of the other "scripting languages" 
> aren't in that category too (although you could probably make a good 
> case for Perl).

Scripting languages are by no means a fad. They dramatically increase
programmer productivity for small to medium size non-critical
programs. They are great for rapid prototyping, data analysis, and
test drivers, for example. I think you'll hear a lot more about Python
in the future.

Re: status of Ada STL?

[Russ]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206201522.f00b81@posting.google.com>...

> Let's see, what are the most widely used languages today? How about
> Cobol, C, C++, Java, Fortran, Perl, and Ada. And lo and behold, every
> one of them except Ada uses "=" for assignment (come to think of it,
> doesn't BASIC use "=" too?).
> 
> Somebody ought to do a study. It seems that you can almost predict the
> popularity of a language based on whether or not it uses "=" for
> assignment. It seems that all the major languages use "=", and all the
> minor languages use something else.

I would like to update this post. In addition to Cobol, Basic, C, C++,
Java, Fortran, Perl, and Python, I've also found a couple of other
significant languages that use "=" for assignment: Matlab and
Mathematica.

Matlab is widely used by engineers for vector/matrix computations,
control system design, and lots of other stuff. Mathematica is a very
sophisticated symbolic math system. Actually, Mathematica uses a
combination of ":=" and "=", but basic variable assignment is done
with "=".

Why is that significant? Well, suffice it to say that the authors of
Mathematica know a thing or two about Math. And the fact that they
used "=" for assignment puts to rest the notion that such usage
somehow violates basic mathematical conventions. It is the final nail
in the coffin of the notion that ":=" is somehow more appropriate. If
"=" is "good enough" for Mathematica, it's good enough for Ada too!

Re: status of Ada STL?

[Jano]

Russ ha escrito esto previamente:

> The mandate also forced many people to learn Ada and apply it. No
> doubt many resented that, but many others who were forced to use Ada
> must have realized that it is a good language and spread the word.
> Having an 800-pound (or $300 billion) gorilla on your side has some
> advantages.

Sometimes I think that with programming languages occurs the same that 
with TV: the general feeling is that the major part of TV time is crap. 
Of course, all say also that they see the minor part that isn't. But 
later, the big budgets always go to the crappiest programs because "the 
mass" likes that (or that think the money owners). 

Personally I think that Ada is like documentals in TV: considered best, 
*really* best, but not appropriate for the masses, which are happy with 
C, C++, Java or what trends dictamine.

Another analogy that comes to my mind sometimes is fast food and sane 
food. Everyone likes fast food, but knows the advantages of a more decent 
diet. But it requires more effort, or more discipline, or more time.

My particular oppinion is Ada will never hit the fame outside elitist 
environments, because it's too good for the ordinary man. 

Never. It's in its nature.

;-)

-- 
-------------------------
Jano
402450[at]cepsz.unizar.es
-------------------------

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> Scripting languages are by no means a fad. They dramatically increase
> programmer productivity for small to medium size non-critical
> programs. They are great for rapid prototyping, data analysis, and
> test drivers, for example. I think you'll hear a lot more about Python
> in the future.

In general, I agree that scripting languages are always going to be 
around. However, I think the individual languages themselves tend to be 
fads. I can remember when REXX was the hot new scripting language.

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> The mandate also forced many people to learn Ada and apply it. No
> doubt many resented that, but many others who were forced to use Ada
> must have realized that it is a good language and spread the word.


No doubt forcing to high school students to read Shakespeare or Dickens 
created a fan or two as well. But the overall net effect is that a lot 
of people grew to dislike them.

Re: status of Ada STL?

[Robert I. Eachus]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccfzzj5bez.fsf@shell01.TheWorld.com>...
> That was true in Ada 83, but the rules in Ada 95 are much more lax.
> As I read 11.6(6), if you have this:
> 
>     X := Matrix_Multiply(Y, Z);
> 
> if some operation inside Matrix_Multiply overflows, then X can indeed be
> destroyed.  In RM terms, X can become "abnormal", which means merely
> looking at it can cause you to turn into stone.

The wording is very subtle, look at it again.  But the real meaning is
simple.  The call to Matrix_Multiply(Y,Z) is not allowed to destroy X,
unless Matrix_Multiply is declared with pragma Inline, and does not
include an exception handler.  The handler doesn't need to do anything
really, it is a signal that the code from the inlined call cannot be
mixed with the surrounding code.  IF the call to Matrix_Multiply is
not safe in this way, you can write:
 
     A := 1.0;
     begin
       X := Matrix_Multiply(Y, Z);
     exception when others => raise; end;
     B := 2.0;

   to protect A and B.  If you want to protect X from an exception
during the call as well, what do you write?

     A := 1.0;
     declare
       Temp: Matrix := X;
     begin
       begin
         Temp := Matrix_Multiply(Y, Z);
       exception when others => raise; end;
     end;
     B := 2.0;

And you have made the requirement for a temporary variable explicit. 
Of course, in practice you would either declare a "wrapper" function
for Matrix_Multiply or fix the original in-lined version if this was a
problem.

> 11.6 is very subtle, and I'm not sure I fully understand it, and I'm
> sure I don't like it.  ;-)  I think the moral of the 11.6 story is,
> "don't handle predefined exceptions".
> 
> The changes to 11.6 were deliberate.  The purpose was to allow more
> optimizations, e.g. on some modern machines where exceptions don't
> get noticed until long after they have occurred.

I can assure that everyone on the ARG agrees on the don't like it
part.  In fact the section number was carefully preserved so that we
could continue to use 11.6 as a swear word.  (Or is that swear
number?)

As for normal programmers, there are only three rules to remember:

If you have an Constraint_Error handler, it should make no assumptions
about variable that may have been assigned to within the direct scope
of the handler.

If you write a library, any inlined operations should have local
exception handlers if Constraint_Error within the subprogram is a
concern.

Use 'Valid to avoid problems when validating input data.

Re: status of Ada STL?

[Dmitry A.Kazakov]

Mark Biggar wrote:

> "Dmitry A. Kazakov" wrote:
>> 
>> procedure '':=" (Target : in out A; Source : A); -- (*)
>> 
>> Note I do not demand that the copy constructor would be derived from
>> ":=". It is IMO a wrong idea to attempt to derive one from another.
>> C++ does it simplier. What is actually wrong in C++ is that the result
>> of "=" is not void.
>> 
>> >Wouldn't it also fall apart if we started including "+:="?
>> 
>> No, they should be just user-defined procedures. Whether they are
>> primitive or not should only depend on the freezing rules and whether
>> particular parameters are class-wide.
>> 
>> (*)  There is a minor problem with unconstrained subtypes passed as
>> inout and that discriminants cannot be changed.
> 
> There are other problems as well.  This was looked at in detail during
> the Ada95 revision.  Allowing users to redefine ":=" using a procedure
> definition like that above was determine to be way too course grained.
> Do you expect your new assignment operation to compose for record or
> array types? What about variable initialization? 

This should be performed by a copy-constructor. The user may influence it 
by overriding Adjust which is a part of it. Compiler should never use ":=" 
implicitly.

> Or, the assign out
> during procedure exit for out parameters?

Out parameters are now allowed to be read, so it is no more a problem. A 
similar problem (though with all predefined operations) is that people 
might want to get rid of predefined ":=" and have

procedure '':=" (Target : in out A; Source : A'Class);

This is unsolvable, because there is no way to disallow a primitive 
operation in Ada.

> This is way ada95 controlled types are tagged and break the assignment
> process down into finer parts with Initialize, Adjust and Finalize
> as user definable hooks into a larger assignment process.  This way
> use defines the type specific parts of data movement and the compiler
> is free to use them in various ways to move data around in ways the
> guarantees that the type's data abstractions are preserved.

This is IMO bad. Assignment should be just a user-defined procedure. It 
could be well defined as Finalize + Copy-constructor, but no longer user 
overrides it.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of Ada STL?

[Russ]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aev8n2$bkl$1@nh.pace.co.uk>...
> To most Ada users, the syntax is not "klunky" and it is the least of their
> concerns.

You just don't get it, do you. The point is not what Ada USERS think,
but rather what POTENTIAL Ada users think.

> Ada may shrivel up and die - but it won't be because of the
> syntax. It may die because programmers don't like the rigid structure -
> prefering to be "free spirits". It may die because programmers don't like
> its type safety or its tasking model or its method of supporting OO
> Programming or a dozen other more "global" and "serious" concerns. But it
> won't die because the syntax for assignment is ":=" instead of "=". I've got
> to believe that most programmers are more "grown up " than that and can get
> over their personal preferences for this style or that style of syntactic
> notation to look at the much more significant issues of how well the
> language does the work that they want to do.
> 
> Try researching the criticisms that have been leveled against Ada in various
> newsgroups, websites, articles, etc. You'll easily find a lot of them. You
> won't find much reference to "klunky" syntax among the criticisms.

First of all, the root cause of a problem is not always obvious to
everyone or even to a few. Why do you suppose people need counseling
and psychotherapy for months or years to discover the underlying cause
of their problems? Perhaps Ada syntax just grates on many people
unconsciously. It's possible. And perhaps it's just a minor impediment
that constantly tips the balance against Ada. One person on this
thread told me that Ada will become more popular if more people write
software with it. Isn't that brilliant reasoning! So the way to make
Ada more popular is to first get more people to use it! Why didn't I
think of that?!

Secondly, I do not appreciate your patronzing tone. No, I am not an
Ada expert. But if you take a look at the title of this thread, you
might recall that it started out with my asking about the status of an
Ada version of the C++ STL. The lack of a STANDARD Ada version of STL
seems to me to be a pretty serious problem with Ada at the current
time. The lack of "+=", "-=", "*=", and "/=" (the correct version of
"/=", that is), which I also brought up in this thread, is also a
significant problem for efficient vector/matrix (and other)
operations.

I work in air traffic management/control. A few years ago the FAA
mandated that decision support systems for controllers be written in
Ada. Now I have to practically beg to get anyone to even consider
using Ada. World-class software experts tell me to use C++ or Java
because Ada programmers are on the endangered species list. Perhaps
the situation is not as serious elsewhere, but if my environment is
representative, Ada could be in trouble. And if Ada stalwarts are
unwilling to even consider an optional cosmetic makeover, I think you
might eventually be sorry. But have it your way.

> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0206201447.7d70511d@posting.google.com...
> >
> > So we agree that Ada is a technically superior language -- and it had
> > the mother of all "moneybags" solidly behind it in the form of a
> > mandate. I wonder why it isn't as popular as C, C++, and Java. Could
> > the klunky syntax be a part of the problem?

Re: status of Ada STL?

[Chad R. Meiners]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206240029.53032b15@posting.google.com...
>> using Ada. World-class software experts tell me to use C++ or Java
              ----------------------------
                           ^
                           |
                           |

Ah!  Here is the problem!  People with titles like this are most often
charlatans.  I fear that the problems caused by charlatans are unlikely to
be solved by changing Ada. ;-)

-CRM

RE: status of Ada STL?

[Steven Deller]

One more voice for some notation that shows the result of an assignment
is the same as the first item in the expression.  This is NOT a "do it
like C" or "do it like Icon" vote, but an "express what I mean in a
readable fashion" vote.

+:=   -:=   *:=   /:=   
would be fine

Since we have the ":" to work with, we could also put the operation on
the proper side of the start of the assignment.  How about 
:+   :-   :*   :/

That keeps the syntactical look-ahead to two symbols and also, once you
get used to it, seems (to me) to be more readable than either the C or
Icon notation, where the operator seems to be misplaced.

x :+ 1 ; -- x is x with one added
y :- 1 ; -- y is y with one subtracted
z :/ 2 ; -- z is z divided by 2
a :* (z+2)/3 ; -- y is y multiplied by (z+2)/3

Anyway, this one particular syntax changes does seem to have numerous
people in favor of it as a way of SIMPLIFYING the expression of a
program. (I personally DON'T care about the "temporararies" argument).

Why isn't this a valid Ada 0X proposal?

I also agree about the record notation of
   type X is record ...
   end record ;
being the subject of continual error, both in writing and in reading.

I guess the argument is that "end record" is parallel in concept to "end
if", but "record" occurs in a declaration, not a statement.  As a
result, "end X" always seems more reasonable to me, being parallel to
"package X is ... end X".  

When reading code, it is much more difficult to match up "record" with
the right "is record ..." than it would be to match "end X" with the one
and only "type X".

Why can't Ada 0X include "end X" and even "end record X" as alternatives
to "end record".  

The syntactical burden on compilers would seem to be small, and the
improved readability would be in keeping with the intentions of Ada.
(Plus there would be a lot less recompiles by me simply because I have
to change "end X" back to "end record" every time I define a record :-)
).

Regards,
Steve

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org 
> [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Frank J. Lhota
> Sent: Tuesday, June 18, 2002 12:13 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: status of Ada STL?
> ...
> I think that the Icon augmented assignment operators would be 
> a worthwhile addition to Ada, not so much for optimizations 
> but for readability. A smart compiler could probably optimize
> 
>     Whatchama_Callit.Thingy( Here ).Do_Hickey.Count := 
> Whatchama_Callit.Thingy( Here ).Do_Hickey.Count  + 1;

Yet another assignment variation (was Re: status of Ada STL?)

[Dale Stanbrough]

Steven Deller <deller@smsail.com> wrote:

> One more voice for some notation that shows the result of an assignment
> is the same as the first item in the expression.  This is NOT a "do it
> like C" or "do it like Icon" vote, but an "express what I mean in a
> readable fashion" vote.
> 
> +:=   -:=   *:=   /:=   
> would be fine
> 
> Since we have the ":" to work with, we could also put the operation on
> the proper side of the start of the assignment.  How about 
> :+   :-   :*   :/
> 
> That keeps the syntactical look-ahead to two symbols and also, once you
> get used to it, seems (to me) to be more readable than either the C or
> Icon notation, where the operator seems to be misplaced.
> 
> x :+ 1 ; -- x is x with one added
> y :- 1 ; -- y is y with one subtracted
> z :/ 2 ; -- z is z divided by 2
> a :* (z+2)/3 ; -- y is y multiplied by (z+2)/3


How well would this apply to multi character operators?

   a :** y;

   X : Boolean;

   X :/= Y;
   X :or z;
   x :rem z;


Sounds tricky to me (and i'm not sure it looks readable - maybe it would
require getting used to).


Perhaps instead we could come up with smiley assignments...

   x :-) y; -- happily overwrite x

   x :-/ y; -- unsure assignment...
            -- good for 1st year students


Dale

Re: Yet another assignment variation (was Re: status of Ada STL?)

[Frank J. Lhota]

> Perhaps instead we could come up with smiley assignments...
>
>    x :-) y; -- happily overwrite x
>
>    x :-/ y; -- unsure assignment...
>             -- good for 1st year students

LOL! Funniest post I've seen here in ages.

Re: status of Ada STL?

[Kevin Cline]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0206151051.1c25cf1e@posting.google.com>...
> "Ehud Lamm" <mslamm@huji.ac.il> wrote in message news:<aedgoc$to7$1@news.iucc.ac.il>...
> > There were attempts by Musser and Stepanov using Ada IIRC, but the current
> > design of the STL uses many C++ specific "tricks".
> 
> If only someone could get them interested again.

IIRC, Stepanov abandoned Ada for C++ because he found Ada generics
unwieldy, particularly the need to explicitly instantiate each
generic before use.  A single line of C++ code like this:

  for_each(myMap.begin(), myMap.end(), mem_fun(myType::action))

would require a dozen lines of Ada code just to instantiate the
for_each and mem_fun generic functions.  That would eliminate
much of the benefit provided by the STL.

Re: Yet another assignment variation (was Re: status of Ada STL?)

[Georg Bauhaus]

Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
: How well would this apply to multi character operators?
Look at J :-)

Re: Yet another assignment variation (was Re: status of Ada STL?)

[Robert A Duff]

Dale Stanbrough <dale@cs.rmit.edu.au> writes:

> Perhaps instead we could come up with smiley assignments...
> 
>    x :-) y; -- happily overwrite x
> 
>    x :-/ y; -- unsure assignment...
>             -- good for 1st year students

Reminds me of an idea I heard from somebody who said "or else" is
nice, but the syntax should be more like this:

    X := Y, or else;

meaning, "you better do it!".

;-)

- Bob

RE: status of Ada STL?

[Grein, Christoph]

> I also agree about the record notation of
>    type X is record ...
>    end record ;
> being the subject of continual error, both in writing and in reading.
> 
[snip]
> 
> When reading code, it is much more difficult to match up "record" with
> the right "is record ..." than it would be to match "end X" with the one
> and only "type X".

I see the point in having "end record X;", but I do not buy that it's difficult to match it with "type X" since records cannot be nested.

Re: status of Ada STL?

[David Thompson]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
> I've seen [+= etc.] suggested in this thread and others. I guess I don't like
> the way it looks and I think there is a problem with it. In C, the "="
> operator is a function call with side effects. In Ada the ":=" operator is
> *not* a function - its a primitive operation of the language. ...

Um, in C = assignment is the builtin operator, as is == equality.
Presumably you mean C++ where they can be user-defined
(overloaded) but only where at least one operand is of user-defined
i.e. class (including struct and union) or enum type.

--
- David.Thompson 1 now at worldnet.att.net

Re: status of Ada STL?

[Marin David Condic]

O.K. that's probably more accurate. My point was that the whole "vision" of
the "=" operator is different from what Ada does. In C and C++ you can write
an expression like: "X = Y = Z = 0 ;" because the "=" is viewed as a kind of
binary function with side effects. (First you call "Z = 0" which has side
effects on Z, then "Y = Z" which has side effects on Y, etc...) Whereas in
Ada, the whole concept of an expression such as "X := Y := Z := 0;" would be
foreign and incomprehensible, because it isn't viewed as a function with
side effects, but as a fundamental statement of the language - "object gets
the value of an expression".

So what falls to the right of ":=" has to be an "expression" and the only
way for that to be an expression is for ":=" to be a binary function which
starts redefining what it means to be a function because of side effects and
then of course you've got the leftmost ":=" which can't any longer be
"object gets expression" because now ":=" is a function and that means you
need to allow function calls where the return value is discarded and.....
(deep breath) Pretty soon, you're thoroughly hosed - and for what? So that
some ex C/C++ programmers don't have to go through the change of life
necessary to get comfortable with "X := X + 1;"? (Suggestion: Get Over It!
:-)

I'd think that tinkering with something this fundamental in the language to
change it into a function with side effects would have such profound
implications, that it would either "break" Ada or Ada would start to take on
the characteristics of "organically grown"* (rather than "designed") that I
consider to be the style of C/C++. It would be A Bad Thing.

*(IMHO, C++ shows all the signs of following the Harley Davidson Design
Methodology - "If it breaks, make it bigger. If it sticks out, chrome it."
:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"David Thompson" <david.thompson1@worldnet.att.net> wrote in message
news:_cvS8.63267$UT.4317265@bgtnsc05-news.ops.worldnet.att.net...
>
> Um, in C = assignment is the builtin operator, as is == equality.
> Presumably you mean C++ where they can be user-defined
> (overloaded) but only where at least one operand is of user-defined
> i.e. class (including struct and union) or enum type.
>

Re: status of Ada STL?

[Russ]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<afhoob$j1u$1@nh.pace.co.uk>...
> O.K. that's probably more accurate. My point was that the whole "vision" of
> the "=" operator is different from what Ada does. In C and C++ you can write
> an expression like: "X = Y = Z = 0 ;" because the "=" is viewed as a kind of
> binary function with side effects. (First you call "Z = 0" which has side
> effects on Z, then "Y = Z" which has side effects on Y, etc...) Whereas in
> Ada, the whole concept of an expression such as "X := Y := Z := 0;" would be
> foreign and incomprehensible, because it isn't viewed as a function with
> side effects, but as a fundamental statement of the language - "object gets
> the value of an expression".

Perhaps I am missing something here, but when you say the expression
"Z = 0" has a "side-effect" on Z you lose me. I don't see how
assignment can be considered a "side effect".

I confess I don't know didly about assignment in Ada, but I can tell
you that assignment in C++ for user defined types is a member
function. It does whatever the implementer of the class tells it to
do. And it is considered good form to have it return a reference to
"*this" so that assignment can be cascaded, as in "A = B = C = D".

If a C++ class does not explicitly define an assignment operator, the
compiler will define one by default. The default assignment operator
is often perfectly good. In fact, the only time the class should
define its own assignment operator is when the it contains a pointer
to data on the heap that needs to be copied in the assignment
operation. Otherwise, you are much better off with the default. The
same applies to copy constructors, by the way. Newbies often
misunderstand this and write their own unnecessarily, which can only
cause unnecessary bugs.

> So what falls to the right of ":=" has to be an "expression" and the only
> way for that to be an expression is for ":=" to be a binary function which
> starts redefining what it means to be a function because of side effects and
> then of course you've got the leftmost ":=" which can't any longer be
> "object gets expression" because now ":=" is a function and that means you
> need to allow function calls where the return value is discarded and.....
> (deep breath) Pretty soon, you're thoroughly hosed - and for what? So that
> some ex C/C++ programmers don't have to go through the change of life
> necessary to get comfortable with "X := X + 1;"? (Suggestion: Get Over It!
> :-)

Ya, and what about Cobol, Basic, Fortran, Java, Perl, Python, Matlab,
and Mathematica programmers? Should they all just get lost too?

As I said, I have no idea how assignment works in Ada, but it would be
nice if it worked as well as it does in C++.

> I'd think that tinkering with something this fundamental in the language to
> change it into a function with side effects would have such profound
> implications, that it would either "break" Ada or Ada would start to take on
> the characteristics of "organically grown"* (rather than "designed") that I
> consider to be the style of C/C++. It would be A Bad Thing.
> 
> *(IMHO, C++ shows all the signs of following the Harley Davidson Design
> Methodology - "If it breaks, make it bigger. If it sticks out, chrome it."
> :-)

I'll bet you wouldn't say that at a gathering of Hell's Angels. ;^)

Re: status of Ada STL?

[Ted Dennison]

Russ wrote:
> Perhaps I am missing something here, but when you say the expression
> "Z = 0" has a "side-effect" on Z you lose me. I don't see how
> assignment can be considered a "side effect".

The main job of a function is supposed to be to calculate and return a 
value based on its parameters/operands. If it has any other lasting 
effect, we call that a "side effect".

If we were to look at C's "=" as a function (which C kind of does), then 
the "effect" of the function is to return is the value of the right 
operand, and the "side-effect" is that this value also gets placed into 
the storage location of the left operand.

The reason this is confusing of course is that the whole point of 
assignment in C is almost always the side-effect, and the effect is 
rarely used. The blame for this confusion should lie with the C 
designers for putting confusing features in the language solely for 
their hack value.

> If a C++ class does not explicitly define an assignment operator, the
> compiler will define one by default. The default assignment operator
> is often perfectly good. In fact, the only time the class should
> define its own assignment operator is when the it contains a pointer
> to data on the heap that needs to be copied in the assignment
> operation. Otherwise, you are much better off with the default. The

Not quite true. You *have* to define your own assignment function if 
your class contains any const members (which most of mine seem to).

Re: status of Ada STL?

[Marin David Condic]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0206292005.45ad915a@posting.google.com...
>
> Perhaps I am missing something here, but when you say the expression
> "Z = 0" has a "side-effect" on Z you lose me. I don't see how
> assignment can be considered a "side effect".
>
Think of the user definable Ada function:

function "=" (Left, Right : in Some_Type) return Boolean ;

You can call it as: "="(L,R) or as: L = R and in either case it returns a
Boolean. But note that the formals Left and Right are *in* parameters - they
cannot be changed. If Assignment were to be a "function" instead of a
primitive statement then you'd have to be able to make Left be an *in out*
parameter - which is illegal in Ada. Changing "Left" in a function call is a
"side effect" which C/C++ allows, but Ada does not.


> I confess I don't know didly about assignment in Ada, but I can tell
> you that assignment in C++ for user defined types is a member
> function. It does whatever the implementer of the class tells it to
> do. And it is considered good form to have it return a reference to
> "*this" so that assignment can be cascaded, as in "A = B = C = D".
>
Sure, but in Ada the way assignment is defined it is *not* a function so it
just doesn't behave in the same way as what it does in C/C++. Trying to make
it so would probably break the language because it has implications all over
the place with respect to the way other things in the language work.


> If a C++ class does not explicitly define an assignment operator, the
> compiler will define one by default. The default assignment operator
> is often perfectly good. In fact, the only time the class should
> define its own assignment operator is when the it contains a pointer
> to data on the heap that needs to be copied in the assignment
> operation. Otherwise, you are much better off with the default. The
> same applies to copy constructors, by the way. Newbies often
> misunderstand this and write their own unnecessarily, which can only
> cause unnecessary bugs.
>
You have the same capability in Ada. Yoy get assignment for free and if you
need to change the behavior, you derive from Controlled and define your own
Initialize, Adjust and Finalize subprograms. It actually works much cleaner
than Constructors and Destructors in C++ - especially where parameter
passing is concerned. The important thing is that you can acomplish the same
thing in Ada that you can in C++ - you just can't do it in exactly the same
syntactic/semantic manner.


>
> Ya, and what about Cobol, Basic, Fortran, Java, Perl, Python, Matlab,
> and Mathematica programmers? Should they all just get lost too?
>
If you want to program in Ada - program in Ada. If you want to program in
Cobol - program in Cobol. Changing Ada to make it look and act like Cobol is
just going to a) not work well and b) urinate-off existing Ada users. Get
lost? No. Just get comfortable with what Ada *is* and don't insist it be
something it isn't. Attempting to please everyone isn't going to work
anyway - Cobol programmers aren't going to switch to Ada if only Ada starts
supporting "Add X to Y Giving Z" syntax and semantics for assignment, so why
make the compiler writers and existing users go through agony to try to
persuade some Cobol guys to jump the fence?

The important thing about Ada is that it provides all the capabilities you
get with other languages and additional capabilities you don't get with
other languages. It doesn't do it identically - but a solution does exist.
You *can* achieve the same results and you get extra things on top of it. If
you want all those capabilities, then you work within the framework of what
Ada is and does. Asking Ada to look like and act like C++, Java, Fortran,
Cobol, Perl, etc. in order to make users of those languages more comfortable
is just a hopeless task.


> As I said, I have no idea how assignment works in Ada, but it would be
> nice if it worked as well as it does in C++.
>
It works just fine. It works (IMHO) better than it does in C++. Its far less
of a cobbled together hack that requires all sorts of "I before E except
after C or when sounded as A as in Neighbor and Weigh..." kinds of
exceptional rules. It just doesn't work *identically* to assignment in C++,
so one needs to learn how to work with The Ada Way. Trying to force Ada to
do assignment in an identical way to that of C++ is like trying to teach a
pig to dance. The results won't be very pretty or successful and it will
only annoy the pig.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: status of Ada STL?

[Robert A Duff]

I like Ada too, and I don't want C or COBOL syntax for assignment in
Ada, but MDC goes a bit too far here.  Let me throw in some anti-Ada
rhetoric, just for fun.  (Sorry, Marin.)

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0206292005.45ad915a@posting.google.com...
> >
> > Perhaps I am missing something here, but when you say the expression
> > "Z = 0" has a "side-effect" on Z you lose me. I don't see how
> > assignment can be considered a "side effect".
> >
> Think of the user definable Ada function:
> 
> function "=" (Left, Right : in Some_Type) return Boolean ;
> 
> You can call it as: "="(L,R) or as: L = R and in either case it returns a
> Boolean. But note that the formals Left and Right are *in* parameters - they
> cannot be changed. If Assignment were to be a "function" instead of a
> primitive statement then you'd have to be able to make Left be an *in out*
> parameter - which is illegal in Ada. Changing "Left" in a function call is a
> "side effect" which C/C++ allows, but Ada does not.

As Robert Dewar likes to point out, Ada functions can have side effects
so long as you make that fact unclear (by not passing them as
parameters, but by writing upon global variables).

Anyway, the "obvious" solution is to make ":=" a procedure rather than a
function.  Unfortunately, this solution doesn't work, which is why we
didn't choose it.  The reason is explained in the AARM (I'm too lazy to
look up the reference right now), but it doesn't exactly make Ada look
good.

> You have the same capability in Ada. Yoy get assignment for free and if you
> need to change the behavior, you derive from Controlled and define your own
> Initialize, Adjust and Finalize subprograms. It actually works much cleaner
> than Constructors and Destructors in C++ - especially where parameter
> passing is concerned. The important thing is that you can acomplish the same
> thing in Ada that you can in C++ ...

Not quite.  A serious limitation is that Adjust can't get its hands on
the left-hand side.

>... - you just can't do it in exactly the same
> syntactic/semantic manner.

> If you want to program in Ada - program in Ada. If you want to program in
> Cobol - program in Cobol.

What it you are not completely satisfied with either one (or any of the
others)?  What if you want to think about language design (rather than
programming in existing languages)?

> The important thing about Ada is that it provides all the capabilities you
> get with other languages and additional capabilities you don't get with
> other languages.

Oh, come on!  That's complete nonsense.  If you can't name 100
capabilities off the top of your head that are not present in Ada (but
are present in some other language), then you don't know enough about
other languages to compare.

>.... It doesn't do it identically - but a solution does exist.
> You *can* achieve the same results and you get extra things on top of it. If
> you want all those capabilities, then you work within the framework of what
> Ada is and does. Asking Ada to look like and act like C++, Java, Fortran,
> Cobol, Perl, etc. in order to make users of those languages more comfortable
> is just a hopeless task.
> 
> 
> > As I said, I have no idea how assignment works in Ada, but it would be
> > nice if it worked as well as it does in C++.
> >
> It works just fine. It works (IMHO) better than it does in C++. Its far less
> of a cobbled together hack that requires all sorts of "I before E except
> after C or when sounded as A as in Neighbor and Weigh..." kinds of
> exceptional rules. It just doesn't work *identically* to assignment in C++,
> so one needs to learn how to work with The Ada Way.

I hate that phrase ("The Ada Way").  Makes Ada folks sound like a bunch
of unreasoning zealots.

>... Trying to force Ada to
> do assignment in an identical way to that of C++ is like trying to teach a
> pig to dance. The results won't be very pretty or successful and it will
> only annoy the pig.

I've heard analogies made between Ada and pigs before, but never as an
argument in *favor* of Ada.  ;-)

- Bob

Re: status of Ada STL?

[Pat Rogers]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc4rfhj43l.fsf@shell01.TheWorld.com...
<snip>
> Anyway, the "obvious" solution is to make ":=" a procedure rather than a
> function.  Unfortunately, this solution doesn't work, which is why we
> didn't choose it.  The reason is explained in the AARM (I'm too lazy to
> look up the reference right now), but it doesn't exactly make Ada look
> good.

Paul Hilfinger's 1983 PhD dissertation on this very subject was most
interesting:

Title: Abstraction Mechanisms and Language Design
Series Title: ACM Distinguished Dissertations
Publisher: MIT Press
ISBN: 0-262-08134-2

but good luck finding it.

 > > You have the same capability in Ada. Yoy get assignment for free and if you
> > need to change the behavior, you derive from Controlled and define your own
> > Initialize, Adjust and Finalize subprograms. It actually works much cleaner
> > than Constructors and Destructors in C++ - especially where parameter
> > passing is concerned. The important thing is that you can acomplish the same
> > thing in Ada that you can in C++ ...
>
> Not quite.  A serious limitation is that Adjust can't get its hands on
> the left-hand side.

The issue I ran into was that I wanted a non-limited type for the sake of
assignment but I wanted values of the type to have unique "identity", ie,
components that did not change during assignment.  Because the entire LHS is
overwritten with the bit-wise copy, that's not easy to maintain like it is in
C++.  (This was for an incremental recovery cache, in which assignment only
stores the value if necessary.)  One approach was to have the identity info in a
separate object and hash on the address of the assignable object (and hope the
address doesn't change!).  Another was to have the identity info referenced via
an access discriminant -- since assignment could not actually change the value
of the discriminant (other Constraint_Error), the (indirect) identity was
maintained.  Still, very ugly compared to user-defined operator "=" in C++.

When asked, I tell people that when I cannot write in Ada I often choose C++ for
this kind of transparent extension, and by the same reasoning see Java as
comparatively underpowered.

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

Re: status of Ada STL?

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:aeq2as$l0m$1@nh.pace.co.uk...
>
> Unless some collection of stuff gets declared to be The Ada Answer in some
> semi-official or conventional/customary way, someone with a more
integrated
> answer (such as C++ & STL or Java and all its class libraries) is always
> going to have a hard-to-overcome competitive advantage. All the
> protestations of "But you can download one of a dozen...." or "You can
bind
> to ...." or "You can go cobble together tools from these dozen...." won't
> overcome the one-stop-shopping and integrated advantage of some competing
> languages.

I have written a library, called Charles, modeled on the C++ STL, which has
all the container types in that library (vectors, deques, lists, sets,
multisets, maps, and multimaps).

http://home.earthlink.net/~matthewjheaney/charles-20020918.zip

Both active and passive iteration is supported.

Re: status of Ada STL?

[Marin David Condic]

Its an admirable effort. The question would be "Will everyone agree that
this is now The Ada Answer?" or is it going to be one more among many
available container libraries? Maybe I'm just cynical about it. :-) We've
got lots of libraries. We've got libraries coming out of our ears. We've got
libraries of every conceivable flavor, color or design philosophy. What we
need is to get some semi-official recognition of ONE library (for at least
the given problem domain of containers - other libraries for things like
math, etc are also good ideas) that will be what Ada provides as the default
product with all conforming compilers.

To be cynical about it, the last time there was an effort in this area,
nobody "official" popped up with tons of enthusiasm to declare something to
be the right answer. To be hopeful about it, at least I've seen comments in
Ada Letters and elsewhere that seem to indicate that there is some official
recognition of the need to have *some* kind of library(ies). To go back to
being cynical, I imagine it will take another 10 years before we see any
usable response to the problem, by which time C++++ will have included some
kind of mind-reading compiler functionality to include the "Do What I Mean"
instruction set. :-) Ada needs some mechanism for defining "Official"
responses to users needs that takes something less than ten years to react.

Maybe I just need more coffee this morning. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Matthew Heaney <mheaney@on2.com> wrote in message
news:uoh6j2rak72b5b@corp.supernews.com...
>
>
> I have written a library, called Charles, modeled on the C++ STL, which
has
> all the container types in that library (vectors, deques, lists, sets,
> multisets, maps, and multimaps).
>
> http://home.earthlink.net/~matthewjheaney/charles-20020918.zip
>
> Both active and passive iteration is supported.
>
>
>
>

Re: status of Ada STL?

[Hyman Rosen]

Marin David Condic wrote:
>  I imagine it will take another 10 years before we see any
> usable response to the problem, by which time C++++ will
 > have included

You clearly haven't been reading comp.std.c++ :-)
The C++ standard bearers are no quicker at this
than are the Ada ones.

Re: status of Ada STL?

[Randy Brukardt]

Marin David Condic wrote in message ...
>To be cynical about it, the last time there was an effort in this area,
>nobody "official" popped up with tons of enthusiasm to declare
something to
>be the right answer. To be hopeful about it, at least I've seen
comments in
>Ada Letters and elsewhere that seem to indicate that there is some
official
>recognition of the need to have *some* kind of library(ies).

There is an open AI for container libraries for Ada 200Y. The problem
is, everyone is willing to write an interesting library, but there is
much less enthusism for the hard work it takes to make something
suitable for standardization. (Compare the documentation for the typical
library with the RM for Ada.Strings.Fixed, and you'll see what I mean).
Then, compound that with getting everyone to agree on the requirements
and the solution...

>Ada needs some mechanism for defining "Official"
>responses to users needs that takes something less than ten years to
react.

That is being studied. Of course, the study may take the ten years. :-)

>Maybe I just need more coffee this morning. :-)


Yes, I think so. :-)

          Randy Brukardt

Re: status of Ada STL?

[Marin David Condic]

Oh, once something gets big enough, bureaucratic and institutional inertia
begins to take over. Perhaps C++ is no better off than Ada with respect to
standardization, but I think there's a cultural difference that lets
practical results happen a bit faster. My impression is that the C++
community is a bit more willing to accept something as a de facto standard
without first getting it past ISO. (One vendor might put something out that
is useful and it gets copied by others plus or minus some implementation
variance, the users get a generally useful feature without upgrading the
standard.) With Ada, we come from a viewpoint of strict compliance to the
standard to get the advantage of portability, but that slows the process
down for getting new features into the language in some manner.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Hyman Rosen <hyrosen@mail.com> wrote in message
news:1032444677.850496@master.nyc.kbcfp.com...
>
> You clearly haven't been reading comp.std.c++ :-)
> The C++ standard bearers are no quicker at this
> than are the Ada ones.
>

Re: status of Ada STL?

[Marin David Condic]

Yes, I understand that. I just think that so long as the reigning notion is
that it has to be part of the ARM in order to be part of Ada, it will always
take ten years to get something new and useful into the language.

OTOH, if there was some body of vendors, academics, SIGAda people, major
users and gadflies that were willing to declare "This reference
implementation of linked lists is what will come with all compilers as of
next week..." then we'd have a linked list library. Would it be 100%
portable? Would it be 100% flawless? Would it be 100% well specified in its
behavior? No, no and no. But it would *exist* and I think thats a big deal.

If it was done by "Reference Implementation" and made available on easy
terms for distribution by the vendors, it doesn't particularly even
hamstring anyone long term by tying them to some "bad idea". You issue a new
reference implementation to fix bad ideas and anyone with legacy code just
keeps using the legacy library. So long as its all in source and under easy
terms (public domain?) nobody gets hurt. What you get as an improvement over
the existing situation (roll-your-own or download your favorite flavor) is
some consistency across compilers and the ability to say "This is the
standard way you make a dynamic array in Ada...." or "This is how you
multiply two matrices in one line of Ada code..." when it comes up on
newsgroups. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:uoka2alhr78538@corp.supernews.com...
>
> There is an open AI for container libraries for Ada 200Y. The problem
> is, everyone is willing to write an interesting library, but there is
> much less enthusism for the hard work it takes to make something
> suitable for standardization. (Compare the documentation for the typical
> library with the RM for Ada.Strings.Fixed, and you'll see what I mean).
> Then, compound that with getting everyone to agree on the requirements
> and the solution...
>

Re: status of Ada STL?

[Kevin Cline]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<amf43s$8ih$1@slb7.atl.mindspring.net>...
> Oh, once something gets big enough, bureaucratic and institutional inertia
> begins to take over. Perhaps C++ is no better off than Ada with respect to
> standardization, but I think there's a cultural difference that lets
> practical results happen a bit faster. My impression is that the C++
> community is a bit more willing to accept something as a de facto standard
> without first getting it past ISO. 

This is true.  There are good public domain libraries that are used
today in commercial applications.  The boost library
(http://www.boost.org) is probably the most prominent example.  It's
not an ISO standard, but the
software is reviewed before being accepted into the library, and the
code is of high quality and is generally useful.

Re: status of Ada STL?

[Hyman Rosen]

Kevin Cline wrote:
 > The boost library (http://www.boost.org)

In fact, many of the people involved in the C++ Standard are
also involved in Boost. It's becoming something of a testbed
for proposed library features.

Re: status of Ada STL?

[Michael Bode]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> OTOH, if there was some body of vendors, academics, SIGAda people, major
> users and gadflies that were willing to declare "This reference
> implementation of linked lists is what will come with all compilers as of
> next week..." then we'd have a linked list library. Would it be 100%
> portable? Would it be 100% flawless? Would it be 100% well specified in its
> behavior? No, no and no. But it would *exist* and I think thats a big deal.

Until that happens, what would be the semi-official reference
implementation of c.l.a? Any votes?

Re: status of Ada STL?

[Pat Rogers]

"Michael Bode" <m.g.bode@web.de> wrote in message
news:m3y99nnn7i.fsf@jupiter.solar.system...
> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>
> > OTOH, if there was some body of vendors, academics, SIGAda people,
major
> > users and gadflies that were willing to declare "This reference
> > implementation of linked lists is what will come with all
compilers as of
> > next week..." then we'd have a linked list library. Would it be
100%
> > portable? Would it be 100% flawless? Would it be 100% well
specified in its
> > behavior? No, no and no. But it would *exist* and I think thats a
big deal.
>
>
> Until that happens, what would be the semi-official reference
> implementation of c.l.a? Any votes?


The Ada 95 Booch Components.

Re: status of Ada STL?

[Marin David Condic]

Be careful what you wish for. You just may get it. :-)

What I think is far more important is some kind of indication of willingness
to adopt something on the part of the vendors. If they won't pack it up with
their compilers and ship it, then it isn't an unofficial standard. (Can we
call this  a "Convention"?) They obviously want to wait until some
sufficient number of their paying customers start asking for something.
(Hint: If you are a paying customer, send an e-mail to your sales or
customer support weenies indicating what you would prefer.) If the compiler
vendors aren't on board with something then it doesn't matter - download
Booch or PragmARC or any of the other spiffy libraries out there and use
what suits you best.

Getting a consensus of CLA posters isn't going to make it any more universal
or conventional - those who don't like Booch or PragmARC or Grace will use
whatever they do like because there isn't much incentive not to. If it comes
with the compiler, then you're spitting into the wind to use something else
and you'd be fighting portability if you did. Why would someone go with a
CLA consensus - especially since it will likely be anything but definitive -
except to be one of The 'In' Crowd? There's not much incentive to cause it
to be a Convention.

Otherwise, we can wait for Ada0x since I'm sure something will be in it by
then. In the mean time, people starting new projects can always go use C++
where they get the STL to help them leverage their efforts. :-)

MDC

--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Pat Rogers <progers@classwide.com> wrote in message
news:JI4l9.38421$Co1.462744722@newssvr30.news.prodigy.com...
>
>
> The Ada 95 Booch Components.
>
>

Re: status of Ada STL?

[Pat Rogers]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:an4alu$dtq$1@nntp9.atl.mindspring.net...
> Be careful what you wish for. You just may get it. :-)

That would be a Good Thing, IMHO.  Not necessarily that it was the
BC's that became a "standard", but that any good one did.  Obviously I
think they qualify.

> What I think is far more important is some kind of indication of
willingness
> to adopt something on the part of the vendors. If they won't pack it
up with
> their compilers and ship it, then it isn't an unofficial standard.
(Can we
> call this  a "Convention"?) They obviously want to wait until some
> sufficient number of their paying customers start asking for
something.

Just so, as we've discussed before, because supplying it means they
have to support it.

> (Hint: If you are a paying customer, send an e-mail to your sales or
> customer support weenies indicating what you would prefer.)

Good idea.  I think it is the only way it will happen.

> Otherwise, we can wait for Ada0x since I'm sure something will be in
it by
> then.

Is there reason to think so? :-(

Re: status of Ada STL?

[Martin Dowie]

"Pat Rogers" <progers@classwide.com> wrote in message
news:Mmjl9.38563$jw6.533609596@newssvr30.news.prodigy.com...
> > Otherwise, we can wait for Ada0x since I'm sure something will be in
> it by
> > then.
>
> Is there reason to think so? :-(

Well, there is definitely the ASCL Working Group set up (see Matt's message
near the start of this thread for a link to the work he has been doing on
this).

Re: status of Ada STL?

[Richard Riehle]

Randy Brukardt wrote:

> There is an open AI for container libraries for Ada 200Y. The problem
> is, everyone is willing to write an interesting library, but there is
> much less enthusism for the hard work it takes to make something
> suitable for standardization. (Compare the documentation for the typical
> library with the RM for Ada.Strings.Fixed, and you'll see what I mean).
> Then, compound that with getting everyone to agree on the requirements
> and the solution...

I seem to recall that George Bernard Shaw wrote, "If you layed all the
economists in the world end-to-end, you will wouldn't reach a conclusion."

I think the same is true if you lay all the programmers end-to-end,
especially
when trying to get agreement on something as subject to variation of
intepretation as standard libraries.

Perhaps, before commiting anything to code, in any language, we should be
discussing the underlying architecture for this kind of standard library.
Yes,
I realize that language structure is an important consideration, and that
linguistic continuity is largely influenced by programming language
structure.
However,  there may be enough architectural issues to permit discussion of
this
at a slightly higher level of abstraction.

This suggestion is not meant to deprecate the work that has already been
represented in source code.  In fact, that work is an important contribution

to raising the discussion to the next higher level of abstraction.

Richard Riehle

Re: status of Ada STL?

[Marin David Condic]

Pat Rogers <progers@classwide.com> wrote in message
news:Mmjl9.38563$jw6.533609596@newssvr30.news.prodigy.com...
>
> Just so, as we've discussed before, because supplying it means they
> have to support it.
>
I understand that aspect - they don't want to increase the level of effort
to maintain something unless there is some demand out there. It seems though
that perhaps instead of waiting for a groundswell of demand it might be
wiser to actually try to drive it from in front. Get a preliminary agreement
between the interested parties that some specific thing *might* be the right
answer, then go out and try to sell it. "We vendors kind of agree that a
library sort of like this might be a good idea. Is that worth something to
you if we made it a priority? What would you give up in exchange for making
it a priority?"

Given the traffic on this subject here in the past, I don't find it
difficult to believe that there is a significant demand for *some* library
to exist - the problem seems to be one of who is going to say what that
library is.


> > (Hint: If you are a paying customer, send an e-mail to your sales or
> > customer support weenies indicating what you would prefer.)
>
> Good idea.  I think it is the only way it will happen.
>
If demand is perceived, they'll make something happen. So for those with
contracts and an interest in libraries, start creating the demand.


> > Otherwise, we can wait for Ada0x since I'm sure something will be in
> it by
> > then.
>
> Is there reason to think so? :-(
>
I think there is a good likelihood that Ada0x will have some kind of library
in it. I don't know that waiting for something to get in the standard is a
good thing. First off, whatever eventually *does* end up in the standard, it
will most likely be very limited in scope. Its just too darned hard to get
any truly extensive thing into the standard given the need for validation,
etc. So maybe you'll see some limited containers in there and maybe some
support for OS interfacing. But consider that most of the folks driving the
standard really want stability and lack of new required effort on their
part, so they've got an incentive to exclude as much as they can from
getting in there. That's why it would be better to have some mechanism to
get a reference implementation built & give it to the vendors. A reference
implementation of something can get as big and glorious as it wants and it
requires much less from the vendors than sticking something into the
standard. They can provide it with all sorts of disclaimers "Use at your own
risk." "No vendor serviceable parts inside." "If you want to complain - send
a note to SIGAda-Library-Working-Group or someone who might actually care."
If all the vendors have the same reference implementation, it doesn't change
competitiveness much, but it dramatically increases the value of Ada to
those not using it as of yet.

Its quite all right if the Ada community wants to wait until Ada0x to
include some libraries for containers and whatnot. After all, the Ada
community waited until Ada95 to provide sqrt and log functions and the folks
who had to do numeric programming between 83 and 95 had a workaround - use
Fortran, C or C++. (Oh, but you can always bind to those libraries! :-) If
the Ada community doesn't want to create libraries to help developers
leverage their effort, I'm sure the folks starting new developments can just
as easily get those started in Java or C++ where they *do* already have
extensive libraries. Ada can continue to provide too little, too late and
the computing world can continue to adopt technologies that give them more
leverage. Darwin won't shed any tears. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: status of Ada STL?

[Jeffrey Carter]

It appears that there will only be a common data-structures library 
supported by most vendors if the ARG receives an API proposal for one. 
That's a lot of work someone will have to do to get it into the form of 
ARM sections.

If the ARG receives only one such proposal, that will by default form 
the basis of the standard library. The best thing for Ada would be for 
people to prepare such proposals. With multiple proposals we are more 
likely to get a decent standard library. Debating societies such as we 
have seen here have yet to accomplish anything useful.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus

Re: status of Ada STL?

[Marin David Condic]

I agree that endless debate is not going to move the mission forward, but
would take some exception to the ARG approach to getting a library. With no
intent to slight the ARG, it just by nature is going to be slow in arriving
at anything and will likely go for a much more limited approach than could
be done through some other means. Its just way too hard to get something
like this into an ISO standard or do it with any speed and rapid response to
changing demands. It would likely be far better to get something less formal
through some other mechanism - such as SIGAda. The question is what sort of
mechanism might be blessed by ARG, the vendors and the community at large as
being an acceptable alternative?1

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Jeffrey Carter <jrcarter@acm.org> wrote in message
news:3D974E8E.5050302@acm.org...
> It appears that there will only be a common data-structures library
> supported by most vendors if the ARG receives an API proposal for one.
> That's a lot of work someone will have to do to get it into the form of
> ARM sections.
>
> If the ARG receives only one such proposal, that will by default form
> the basis of the standard library. The best thing for Ada would be for
> people to prepare such proposals. With multiple proposals we are more
> likely to get a decent standard library. Debating societies such as we
> have seen here have yet to accomplish anything useful.
>

Re: status of Ada STL?

[Marin David Condic]

I'm curious about what you're looking for archtecturally? Some sort of
breakdown of library domains? (e.g., "Containers", "Mathematics", "OS
Services", etc.) A breakdown of implementation concepts? (Dynamic vs Static,
Generic vs Object Oriented, etc.) Or just a breakdown of desired
functionality? ("A list container will have the following types, operations,
etc.")

In my mind, I could see adopting an existing container library and not
trying to get it into the standard. Just a library that is a reference
implementation and is deemed to be suitable for most practical purposes.
Something the vendors would package with their compilers on an "As Is" basis
with the only promise being that most/all implementations of Ada come with
this library and the only guarantee is the package spec - behavior may vary
some. This isn't far afield from what other languages have done in the past
and continue to do - maybe it eventually makes it into a standard, but who
cares so long as it exists in all implementations and the behavior is at
least mostly the same everywhere. In a perfect world, I'd like to see a lot
more than just containers supported since anything Ada does to give the
developer leverage makes Ada more attractive. Why *not* have a big math
library and make Ada more attractive for the numeric types of projects? Why
*not* have a communications suite that provided network interfaces and made
Ada more attractive to distributed computing projects? Why *not* have a
business library that provided facilities for common business computations
and make Ada more attractive to data processing applications?

I've known people who have been big fans of Ada but have taken their
projects to other languages with the story always being the same: "I really
like Ada, but I can get my job done so much faster by utilizing what comes
with <insert compiler product here>" Ada can provide the same leverage and
might even do it better, but not if it waits until a perfect answer is
found.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Richard Riehle <richard@adaworks.com> wrote in message
news:3D95E5F7.CE1669E9@adaworks.com...
>
> I seem to recall that George Bernard Shaw wrote, "If you layed all the
> economists in the world end-to-end, you will wouldn't reach a conclusion."
>
> I think the same is true if you lay all the programmers end-to-end,
> especially
> when trying to get agreement on something as subject to variation of
> intepretation as standard libraries.
>
> Perhaps, before commiting anything to code, in any language, we should be
> discussing the underlying architecture for this kind of standard library.
> Yes,
> I realize that language structure is an important consideration, and that
> linguistic continuity is largely influenced by programming language
> structure.
> However,  there may be enough architectural issues to permit discussion of
> this
> at a slightly higher level of abstraction.
>
> This suggestion is not meant to deprecate the work that has already been
> represented in source code.  In fact, that work is an important
contribution
>
> to raising the discussion to the next higher level of abstraction.
>
> Richard Riehle
>

Re: status of Ada STL?

[Randy Brukardt]

Marin David Condic wrote in message ...
>I'm curious about what you're looking for archtecturally? Some sort of
>breakdown of library domains? (e.g., "Containers", "Mathematics", "OS
>Services", etc.) A breakdown of implementation concepts? (Dynamic vs
Static,
>Generic vs Object Oriented, etc.) Or just a breakdown of desired
>functionality? ("A list container will have the following types,
operations,
>etc.")

Speaking for myself (not for the ARG!), I'd like to see an agreed on
list of requirements for the library. That would make it easier to
evaluate proposals/existing libraries.

For example, my number one requirement is ease-of-use. I expect the
primary use of these containers would be in prototypes and non-critical
code, and also by programmers relatively new to Ada. For those uses,
ease of use is more important than expressive power or top shelf
performance. After all, if it is harder to use the components than it is
to roll-your-own, no one will use them. (That is my objection to the
original Booch components - haven't looked at them recently).
Ada.Strings.Unbounded is designed that way, so it would be consistent to
do that with libraries as well.

>..
>Something the vendors would package with their compilers on an "As Is"
basis
>with the only promise being that most/all implementations of Ada come
with
>this library and the only guarantee is the package spec - behavior may
vary
>some.

That is not going to happen. Speaking for RR Software, if we provide it,
we're going to support it. If you want something else, get it from
AdaPower. We're not going to provide an "as-is" code. Period.

Moreover, I doubt that anything that doesn't have defined behavior is
going to be portable in any practical way. You're better off downloading
the code from AdaPower, because then you'll have the code, and it can be
ported (hopefully) without changes.

>This isn't far afield from what other languages have done in the past
>and continue to do ...

The best suggestion I've seen here is to provide a semi-official library
of code similar to Java's. This keeps the vendors out of it (beyond
making sure that the code compiles). And the user is not mislead about
the status of the code. The main question with this idea is who is going
to sponser it and fund it? That's being actively studied -- hopefully a
solution will be found.

                Randy Brukardt

Re: status of Ada STL?

[Jean-Pierre Rosen]

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


"Randy Brukardt" <randy@rrsoftware.com> a �crit dans le message news:
upjr96ggnr4mb2@corp.supernews.com...
> For example, my number one requirement is ease-of-use. I expect the
> primary use of these containers would be in prototypes and non-critical
> code, and also by programmers relatively new to Ada. For those uses,
> ease of use is more important than expressive power or top shelf
> performance. After all, if it is harder to use the components than it is
> to roll-your-own, no one will use them.
I strongly support that statement.
I *do* keep rewriting data structure packages, when I have some specialized
requirements.
After all, that's my job, and not a big deal if you know how to write them.
Predefined libraries are for the casual user, under not-demanding conditions

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: status of Ada STL?

[Marin David Condic]

So perhaps an alternative to having the vendors bundle some library up with
their compilers would be to have some one single library declared "The
Library" and vendors, academics, industrial users, newsgroups, and other
gadflies can all point to that and say "This is what everyone uses". That
certainly separates it from the language standard which I think can only
produce something very static and limited. But there's still a problem with
somehow or other giving it some aura of officialdom. Also, there's the
problem of if it isn't just sitting there when you get your Ada compiler
installed, its awful rough to, say, write a textbook about Ada that presumes
the student can just include XYZ and have it work. Not having it come with
the compiler risks having it be just one more of many available libraries of
stuff and that's not quite the same thing as what C++ and Java have right
now.

Still, it might be a way to *start*. Get a semi-official library going that
is at first independent of the compiler or standard and perhaps later if it
seems to be working well, it starts getting bundled with compilers (on
customer demand?) and might one day find its way into the standard, should
it be sufficiently well specified. Isn't this kind of how ASIS got built? (I
don't see why it couldn't perhaps start with some existing library and be
grown from there so long as the existing library was sound and met whatever
requirements were established.)

You're absolutely right about who is going to sponsor and fund it. It needs
to be driven by *someone* with some semi-official status or its just one
more library built by one more enthusiast. Assuming the vendors were at
least on board to the extent that they were willing to bless some effort as
"The Library" and were willing to drive the requirements somewhat, then the
rest is a problem of finding some organization to be the caretaker of the
project and some way of paying for it. SIGAda might be a reasonable
mechanism for being the caretaker and might even find some volunteer labor
for some of the work. (The problem with all-volunteer labor is, of course,
you can't count on getting anything done.) Universities might be other
candidates. As for funding, if it was written up properly, it might be
possible to get some government research money thrown at it. I think that if
there is a willingness on the part of the vendors and/or other major
stakeholders to push for something, it might just happen. Without that, it
will lack focus and never get done.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:upjr96ggnr4mb2@corp.supernews.com...
>
> The best suggestion I've seen here is to provide a semi-official library
> of code similar to Java's. This keeps the vendors out of it (beyond
> making sure that the code compiles). And the user is not mislead about
> the status of the code. The main question with this idea is who is going
> to sponser it and fund it? That's being actively studied -- hopefully a
> solution will be found.
>

Re: status of Ada STL?

[Marin David Condic]

Well, I wouldn't necessarily characterize it as the "casual user". What's
the point of having a library if its only for someone who is just tinkering
around and not doing serious development? Perhaps this perspective helps:
For a serious Ada user who may not have stringent performance criteria, a
standard library is better than a roll-your-own library if he can quickly
and easily get his job done using it. In the handful of cases where there
might be a need to do something very complex or with tough requirements, the
Ada programmer may still need to roll his own because *no* standard library
can possibly meet every conceivable need.

When I was doing C++ work with MSVC++, they gave me lists and maps as
freebies. They may not have been the most sophisticated classes imaginable,
but they sure made it quick to put together many parts of a serious
application without having to do lots of drudge work making yet another
custom data structure. Of course, in this instance there was no issue of
realtime or safety critical performance that might have warranted a very
careful look at possibly creating more optimal classes, but that's kind of
rare in comparison to most programming jobs.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Jean-Pierre Rosen <rosen@adalog.fr> wrote in message
news:aneb7v$81m$1@s1.read.news.oleane.net...
>
> I strongly support that statement.
> I *do* keep rewriting data structure packages, when I have some
specialized
> requirements.
> After all, that's my job, and not a big deal if you know how to write
them.
> Predefined libraries are for the casual user, under not-demanding
conditions
>

Re: status of Ada STL?

[Jean-Pierre Rosen]

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


"Marin David Condic" <mcondic.auntie.spam@acm.org> a �crit dans le message
news: anepmc$631$1@slb7.atl.mindspring.net...
> Well, I wouldn't necessarily characterize it as the "casual user". What's
> the point of having a library if its only for someone who is just
tinkering
> around and not doing serious development? Perhaps this perspective helps:
> For a serious Ada user who may not have stringent performance criteria, a
> standard library is better than a roll-your-own library if he can quickly
> and easily get his job done using it. In the handful of cases where there
> might be a need to do something very complex or with tough requirements,
the
> Ada programmer may still need to roll his own because *no* standard
library
> can possibly meet every conceivable need.
>
I think you simply defined better what I called a "casual" user. Anyway, we
are in agreement.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: status of Ada STL?

[Matthew Heaney]

"Michael Bode" <m.g.bode@web.de> wrote in message
news:m3y99nnn7i.fsf@jupiter.solar.system...
>
> Until that happens, what would be the semi-official reference
> implementation of c.l.a? Any votes?

If you're interested in an Ada95 port of the C++ STL, then you can try the
Charles container library:

http://home.earthlink.net/~matthewjheaney/charles/index.html