Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

As promised in the Ada popularity thread, I have taken one of the
Charles examples and reimplemented it in C++.  I used only the
standard C++ language and libraries.  The Ada/CHARLES main program
body is 118 (non-blank) lines of code, plus an additional 40 lines of
instantiations in eight other specification files, for a total of 158
lines and 9 files.  The C++ implementation is 76 (non-blank) lines of
code in a single file.  For grins, I also wrote the program in Perl. 
That took 14 lines.

Summary:

Ada/Charles 158 lines, 9 files
C++         76 lines
Perl        14 lines

You can compare the implementations at
http://www.geocities.com/kc0a/wordcount.html

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Pylinius]

Kevin Cline wrote:
> As promised in the Ada popularity thread, I have taken one of the
> Charles examples and reimplemented it in C++.  I used only the
> standard C++ language and libraries.  The Ada/CHARLES main program
> body is 118 (non-blank) lines of code, plus an additional 40 lines of
> instantiations in eight other specification files, for a total of 158
> lines and 9 files.  The C++ implementation is 76 (non-blank) lines of
> code in a single file.  For grins, I also wrote the program in Perl. 
> That took 14 lines.
> 
> Summary:
> 
> Ada/Charles 158 lines, 9 files
> C++         76 lines
> Perl        14 lines
> 
> You can compare the implementations at
> http://www.geocities.com/kc0a/wordcount.html
> 


-- 11 lines + 1 comment line, which is the one you are reading, duh
with Gnat.Problems_For_High_Schoolers;
with Text_IO; use Text_IO;
procedure Main is
begin
   loop
     Put_Line(Gnat.Problems_For_High_Schoolers.Word_Count_Concordance);
   end loop;
exception
   when Gnat.Problems_For_High_Schoolers.End_Error =>
     null;
end;

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Björn Persson]

Kevin Cline wrote:

> Ada/Charles 158 lines, 9 files
> C++         76 lines
> Perl        14 lines

Neat. Now let's take three identical persons who haven't seen this 
program before, give them one version each, and see how long it takes 
them to understand it.

In other words: What matters is how easy the program is to read and 
maintain. The line count is interesting only to the extent that it 
affects the readability.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Benjamin Ketcham]

Bj?rn Persson <spam-away@nowhere.nil> wrote:
> Kevin Cline wrote:
> 
>> Ada/Charles 158 lines, 9 files
>> C++         76 lines
>> Perl        14 lines
> 
> Neat. Now let's take three identical persons who haven't seen this 
> program before, give them one version each, and see how long it takes 
> them to understand it.
> 
> In other words: What matters is how easy the program is to read and 
> maintain. The line count is interesting only to the extent that it 
> affects the readability.

Well, the line count affects readability rather profoundly, in
this example!  Not being an expert in any of the languages
concerned, I can take a more objective view of readability
perhaps; and I can say that if I had to figure out and maintain
any of these programs, the one that easily fits in entirety
on an 80x24 screen wins my approval.  I.e., this
might not scale to larger projects: I'm not at all sure I'd
rather read a 1400-line Perl program than a 7600-line C++
program or a 15800-line Ada program.  Actually, "none of the
above" sounds most appealing.

OTOH, it does not appear that the three programs actually
implement the same spec.  E.g., error messages are different
(and missing in the Perl version), and if I'm not mistaken
the Perl version reads input from stdin, the other two take
a file argument -- or is while(<>) in Perl smart/twisted enough
to read from a filename in argv[] if present, else stdin?  I
certainly recall that it has extensively overloaded behaviour.
Anyway, this is not even a vaguely fair test until all three
actually have the same behaviour in detail.

--Benjamin

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Hyman Rosen]

Benjamin Ketcham wrote:
 > or is while(<>) in Perl smart/twisted enough
> to read from a filename in argv[] if present, else stdin?

Yes. In fact, it reads all the files specified on the command
line and stdin if there are none.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Cesar Rabak]

Benjamin Ketcham escreveu:
> Bj?rn Persson <spam-away@nowhere.nil> wrote:
> 
>>Kevin Cline wrote:
>>
>>
>>>Ada/Charles 158 lines, 9 files
>>>C++         76 lines
>>>Perl        14 lines
>>
>>Neat. Now let's take three identical persons who haven't seen this 
>>program before, give them one version each, and see how long it takes 
>>them to understand it.
>>
>>In other words: What matters is how easy the program is to read and 
>>maintain. The line count is interesting only to the extent that it 
>>affects the readability.
> 
> 
> Well, the line count affects readability rather profoundly, in
> this example!  Not being an expert in any of the languages
> concerned, I can take a more objective view of readability
> perhaps; and I can say that if I had to figure out and maintain
> any of these programs, the one that easily fits in entirety
> on an 80x24 screen wins my approval.  I.e., this
> might not scale to larger projects: I'm not at all sure I'd
> rather read a 1400-line Perl program than a 7600-line C++
> program or a 15800-line Ada program.  Actually, "none of the
> above" sounds most appealing.

I was wondering this. Thanks for this report Benjamin!

> 
> OTOH, it does not appear that the three programs actually
> implement the same spec.  E.g., error messages are different
> (and missing in the Perl version), and if I'm not mistaken
> the Perl version reads input from stdin, the other two take
> a file argument -- or is while(<>) in Perl smart/twisted enough
> to read from a filename in argv[] if present, else stdin?  I
> certainly recall that it has extensively overloaded behaviour.
> Anyway, this is not even a vaguely fair test until all three
> actually have the same behaviour in detail.

I second this. And for a quick and dirty comparison we have to figure 
out some (unique for all implementations) test suite, so we can check 
the overall behaviour (not only performance).

--
Cesar Rabak

> 
> --Benjamin
> 

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[James Alan Farrell]

On 21 Sep 2004 17:21:38 -0700, kevin.cline@gmail.com (Kevin Cline)
wrote:

>As promised in the Ada popularity thread, I have taken one of the
>Charles examples and reimplemented it in C++.  I used only the
>standard C++ language and libraries.  The Ada/CHARLES main program
>body is 118 (non-blank) lines of code, plus an additional 40 lines of
>instantiations in eight other specification files, for a total of 158
>lines and 9 files.  The C++ implementation is 76 (non-blank) lines of
>code in a single file.  For grins, I also wrote the program in Perl. 
>That took 14 lines.
>
>Summary:
>
>Ada/Charles 158 lines, 9 files
>C++         76 lines
>Perl        14 lines
>
>You can compare the implementations at
>http://www.geocities.com/kc0a/wordcount.html

Just have to put my $0.02 in on this:

Does this prove that perl is the best language?  If so, perhaps we
should all switch our avionics projects over to perl.  Must be it will
be easier to code and maintain, safer to fly, and run just as fast.

The things that make a language a "good" language are many and
complex, and are different in different circumstances.  If I need a
small utility that compares lines in different text files, I find perl
much easier than Ada.  On the other hand, if I have a very large
project that must always perform "correctly", I've not found a
language that can beat Ada.

But then I've never used Eiffel.

James Alan Farrell

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: 
: Summary:
: 
: Ada/Charles 158 lines, 9 files

If you want, you can place all units in one file. The compilers
can handle this.
Will the compilation process profit from splitting
C++ sources into files, in general?


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Simon Wright]

James Alan Farrell <anonymous@anonymous.com> writes:

> The things that make a language a "good" language are many and
> complex, and are different in different circumstances.  If I need a
> small utility that compares lines in different text files, I find
> perl much easier than Ada.  On the other hand, if I have a very
> large project that must always perform "correctly", I've not found a
> language that can beat Ada.

Even I would accept that Ada may just not be the best language in the
world for text processing!

We needed a program to remove the private part of a package spec; the
winner was the one-line sed script you can select off the Wiki and
paste into an xterm.

And there's the Ada line counter (which includes semicolons in
comments and strings but is still useful):

  $ tr -cd ';' <bcwords.ada | wc -c

(by the way, that shows that the Booch Components version of the word
counter comes in at 123 lines).

As you say, there's a boundary somewhere between those and the missile
guidance system where the choices change.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Brian May]

>>>>> "Simon" == Simon Wright <simon@pushface.org> writes:

    Simon> James Alan Farrell <anonymous@anonymous.com> writes:
    >> The things that make a language a "good" language are many and
    >> complex, and are different in different circumstances.  If I
    >> need a small utility that compares lines in different text
    >> files, I find perl much easier than Ada.  On the other hand, if
    >> I have a very large project that must always perform
    >> "correctly", I've not found a language that can beat Ada.

    Simon> Even I would accept that Ada may just not be the best
    Simon> language in the world for text processing!

Perl has high level primitive for:

* <> operator

* built in $hash{$index}

* split function

C++

* doesn't have the <> operator so the files have to be opened manually.

* uses std::map instead of $hash{$index} which is more verbose for extra
  type checking.

* requires both word_list (std::list) and word_map (std::map), I am
  guessing this is because it is not possible to have an ordered
  std::map. (as distinct from the perl solution).

* doesn't have the split operator, so needs a get_word function.

ADA

* doesn't have the <> operator so files have to be opened manually.

* the insert function seems complicated, not convinced this is
  required (maybe it is).

* has a find_token function which somewhat simplifies the C++ code for
  get_word, but not quite as simple as the perl code.

* has more overhead because of increased type checking.


In the Ada case, putting almost everything in one big huge, ugly,
function doesn't help readability (maybe this is a bit extreme, but
one of my university lecturers insisted that no
function/procedure/subroutine/whatever-you-call-it should be longer
then a page). I would say this is a good example of why programming in
Ada does not necessarily mean excellent code. If I were writing this,
I would try splitting along similar lines as the perl code, e.g.:

(disclaimer: not tested; syntax may not be exactly correct; still you
should get the general idea).


with Input;
with Word;
with Word_Map;
with Ada.Text_IO.

procedure Wordcount is
          Line : String;
          Word : String;
          n : Integer := 0;
begin        
        while Input.More do
              Word.Set_Line(Input.Get_Line);

              while Word.More do
                    Word_Map.Add_Word(Word.Get_Word);
                    Word.Next;
              end while;

              Input.Next;
        end while;

        Word_Map.sort;

        while Word_Map.More and n <= 10 then
              Put(Word_Map.Get_Word);
              Put(' ');
              Put(Word_Map.Get_Count, Width => 0);
              New_Line;

              Word_Map.Next;
              n := n + 1;
        end;                            
end Wordcount;
        

I think something like this could be just as readable as the perl code
(you might argue that it is more readable), even though there are
extra packages required that I haven't considered, and the total line
count is likely to be higher.

Sure, some of the packages could also be more generic and/or task safe
(e.g. no objects or iterators used), but a generic solution wasn't
required so I didn't bother.

Also it is perhaps worth noting that while the perl code seems simple
now, if the specifications were to incrementally change, the resultant
code may not be so simple.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Jeffrey Carter]

Simon Wright wrote:
> 
> And there's the Ada line counter (which includes semicolons in
> comments and strings but is still useful):
> 
>   $ tr -cd ';' <bcwords.ada | wc -c

I always used

grep \; <file> | wc -l

IIRC

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0409211621.6f3d3723@posting.google.com>...
> 
> You can compare the implementations at
> http://www.geocities.com/kc0a/wordcount.html

See also the latest version of the wordcount example, that compiles
against the Madison release of the AI-302 API:

http://charles.tigris.org/source/browse/charles/src/ai302/examples/wordcount/

This should give you some idea of how things will work in Ada 2005.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Simon Wright wrote:

> James Alan Farrell <anonymous@anonymous.com> writes:
>   $ tr -cd ';' <bcwords.ada | wc -c
> 
> (by the way, that shows that the Booch Components version of the word
> counter comes in at 123 lines).

Which shows that the "1 instantiation only"  argument of Charles and
Ada.Containers is misguided. So think I stick with the Booch Components
even after Ada 2005.

When we at it: I still have the "indefinite extension" within AdaCL.
Howabout joining them?

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Benjamin Ketcham <bketcham@drizzle.com> wrote in message news:<1095860313.176522@yasure>...
> Bj?rn Persson <spam-away@nowhere.nil> wrote:
> > Kevin Cline wrote:
> > 
> >> Ada/Charles 158 lines, 9 files
> >> C++         76 lines
> >> Perl        14 lines
> > 
> > Neat. Now let's take three identical persons who haven't seen this 
> > program before, give them one version each, and see how long it takes 
> > them to understand it.
> > 
> > In other words: What matters is how easy the program is to read and 
> > maintain. The line count is interesting only to the extent that it 
> > affects the readability.
> 
> Well, the line count affects readability rather profoundly, in
> this example!  Not being an expert in any of the languages
> concerned, I can take a more objective view of readability
> perhaps; and I can say that if I had to figure out and maintain
> any of these programs, the one that easily fits in entirety
> on an 80x24 screen wins my approval.  I.e., this
> might not scale to larger projects: I'm not at all sure I'd
> rather read a 1400-line Perl program than a 7600-line C++
> program or a 15800-line Ada program.  Actually, "none of the
> above" sounds most appealing.
> 
> OTOH, it does not appear that the three programs actually
> implement the same spec.  E.g., error messages are different
> (and missing in the Perl version), and if I'm not mistaken
> the Perl version reads input from stdin, the other two take
> a file argument -- or is while(<>) in Perl smart/twisted enough
> to read from a filename in argv[] if present, else stdin?  I
> certainly recall that it has extensively overloaded behaviour.
> Anyway, this is not even a vaguely fair test until all three
> actually have the same behaviour in detail.

I didn't actually run the Ada program, but I did run the C++ and Perl
code.  As I mentioned in the message, the Perl program does not give
the same error messages, but in some sense it is more powerful than
the Ada and C++ programs, because it works like a standard Unix
filter, either reading from standard input or from the files specified
on the command line.  A more serious effort would take another few
lines to at least handle the -h switch.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<11b4d.3849$d5.30042@newsb.telia.net>...
> Kevin Cline wrote:
> 
> > Ada/Charles 158 lines, 9 files
> > C++         76 lines
> > Perl        14 lines
> 
> Neat. Now let's take three identical persons who haven't seen this 
> program before, give them one version each, and see how long it takes 
> them to understand it.
> In other words: What matters is how easy the program is to read and 
> maintain. 

I quite agree, and on that score the Perl code wins hands down. 
Anyone with a couple of months of Perl experience could understand the
Perl program in about two minutes, and a halfway decent Perl
programmer should be able to write that code in about ten minutes.  It
took me a bit longer because I had forgotten how to call sort and had
to look it up.
  
It's pretty hard to make the case that this Ada code:

  procedure Insert (Word : String) is 
    I : Wordcount_Maps.Iterator_Type; 
    B : Boolean; 
    type Element_Access is access all Wordcount_Maps.Element_Subtype;

    for Element_Access'Storage_Size use 0;

    function To_Access is new Wordcount_Maps.Generic_Element
(Element_Access);
  
  begin -- Insert 
    Insert (Map, To_Lower (Word), 0, I, B); 
    declare E : Wordcount_Maps.Element_Subtype renames To_Access
(I).all;
    begin 
      E := E + 1; 
    end; 
  end Insert;

is easier to understand than the corresponding C++ code:
  ++concordance[word];

or the corresponding Perl code:
  ++$count{$word};

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

James Alan Farrell <anonymous@anonymous.com> wrote in message news:<g563l0llm9trvjcn9n9ao4vit704b43kqm@4ax.com>...
> On 21 Sep 2004 17:21:38 -0700, kevin.cline@gmail.com (Kevin Cline)
> wrote:
> 
> >As promised in the Ada popularity thread, I have taken one of the
> >Charles examples and reimplemented it in C++.  I used only the
> >standard C++ language and libraries.  The Ada/CHARLES main program
> >body is 118 (non-blank) lines of code, plus an additional 40 lines of
> >instantiations in eight other specification files, for a total of 158
> >lines and 9 files.  The C++ implementation is 76 (non-blank) lines of
> >code in a single file.  For grins, I also wrote the program in Perl. 
> >That took 14 lines.
> >
> >Summary:
> >
> >Ada/Charles 158 lines, 9 files
> >C++         76 lines
> >Perl        14 lines
> >
> >You can compare the implementations at
> >http://www.geocities.com/kc0a/wordcount.html
> 
> Just have to put my $0.02 in on this:
> 
> Does this prove that perl is the best language?  If so, perhaps we
> should all switch our avionics projects over to perl.  Must be it will
> be easier to code and maintain, safer to fly, and run just as fast.

It doesn't prove that Perl is the best language for every job.  But
the original thread was about Ada popularity.  Relatively few people
write avionics code, or any safety-critical software.  I do think that
a lot of projects currently being written in C++, Java, or C# could be
done much more cheaply and effectively in Perl or a similar language.

> 
> The things that make a language a "good" language are many and
> complex, and are different in different circumstances.  If I need a
> small utility that compares lines in different text files, I find perl
> much easier than Ada.  On the other hand, if I have a very large
> project that must always perform "correctly", I've not found a
> language that can beat Ada.

But large projects in Ada or C++ or Java or C# might be small or
medium-sized projects in a higher-level language.

If you have a project that must always perform "correctly", then you
better prove it correct.  Strong typing can help, but is not
absolutely necessary to that effort.

For the rest of us, the most important thing is to get tested code
done quickly.  I don't know about you, but I can write and test 14
lines of code a whole lot faster than I can write and test 80 or 160.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Brian May <bam@snoopy.apana.org.au> wrote in message news:<sa41xgtam2g.fsf@snoopy.apana.org.au>...
> >>>>> "Simon" == Simon Wright <simon@pushface.org> writes:
> 
>     Simon> James Alan Farrell <anonymous@anonymous.com> writes:
>     >> The things that make a language a "good" language are many and
>     >> complex, and are different in different circumstances.  If I
>     >> need a small utility that compares lines in different text
>     >> files, I find perl much easier than Ada.  On the other hand, if
>     >> I have a very large project that must always perform
>     >> "correctly", I've not found a language that can beat Ada.
> 
>     Simon> Even I would accept that Ada may just not be the best
>     Simon> language in the world for text processing!
> 
> Perl has high level primitive for:
> 
> * <> operator
> 
> * built in $hash{$index}
> 
> * split function
> 
> C++
> 
> * doesn't have the <> operator so the files have to be opened manually.
> 
> * uses std::map instead of $hash{$index} which is more verbose for extra
>   type checking.

The map has to be declared, but then you can simply say map[key].

> 
> * requires both word_list (std::list) and word_map (std::map), I am
>   guessing this is because it is not possible to have an ordered
>   std::map. (as distinct from the perl solution).

Actually, the map keys are ordered, but the program prints the words
in order from most to least frequent, so you need to resort on the map
values.
> 
> * doesn't have the split operator, so needs a get_word function.

That was the most painful part.  I spent a while trying to figure out
if it could be done using the >> operator by modifying the definition
of whitespace, but gave up.  That part of the library could be
improved.  Alternatively, I could have used boost::regex and saved a
dozen lines or so.

> ADA
> 
> * doesn't have the <> operator so files have to be opened manually.
> 
> * the insert function seems complicated, not convinced this is
>   required (maybe it is).
> 
> * has a find_token function which somewhat simplifies the C++ code for
>   get_word, but not quite as simple as the perl code.

No, because strings are manipulated as arrays instead of simple types.
 Instead of simply returning a string, find_token returns indices into
a character array.  Handling strings as array slices is extremely
awkward.  It's hard to write, and hard to read.  And it's error-prone.
 Ada will protect you from buffer overruns, but it can't protect you
from off-by-one errors that misplace a character.
String handling in Ada is only a slight improvement over C's
strcpy/strcat mess.

> 
> * has more overhead because of increased type checking.
> 
> 
> In the Ada case, putting almost everything in one big huge, ugly,
> function doesn't help readability (maybe this is a bit extreme, but
> one of my university lecturers insisted that no
> function/procedure/subroutine/whatever-you-call-it should be longer
> then a page). 

He's right, and I think even a page is much too long.  I generally try
to keep mine at about ten lines or less.  When they get bigger than
that, I split them into smaller routines.  Do this and you will
generally find that the total line count will decrease, because those
small functions get reused more than you might intially expect.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cisper$e5u$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> : 
> : Summary:
> : 
> : Ada/Charles 158 lines, 9 files
> 
> If you want, you can place all units in one file. The compilers
> can handle this.

I was pretty sure that all those instantiations could go into the
body.

> Will the compilation process profit from splitting
> C++ sources into files, in general?

No, it will get slower, in general, because opening files is about the
slowest part of compilation.  The only reason to split code into
multiple files is to ease maintenance.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Anders Wirzenius]

Benjamin Ketcham <bketcham@drizzle.com> writes:
> 
> Well, the line count affects readability rather profoundly, in
> this example!  Not being an expert in any of the languages
> concerned, I can take a more objective view of readability
> perhaps; and I can say that if I had to figure out and maintain
> any of these programs, the one that easily fits in entirety
> on an 80x24 screen wins my approval.  I.e., this
> might not scale to larger projects: I'm not at all sure I'd
> rather read a 1400-line Perl program than a 7600-line C++
> program or a 15800-line Ada program.  Actually, "none of the
> above" sounds most appealing.
> 

Anyone else than I missing the good old days with printouts 
from line printers with continuous paper?

Anders

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[stephane richard]

"Anders Wirzenius" <anders@no.email.thanks.invalid> wrote in message 
news:uu0tpi7em.fsf@no.email.thanks.invalid...
> Benjamin Ketcham <bketcham@drizzle.com> writes:
>>
>> Well, the line count affects readability rather profoundly, in
>> this example!  Not being an expert in any of the languages
>> concerned, I can take a more objective view of readability
>> perhaps; and I can say that if I had to figure out and maintain
>> any of these programs, the one that easily fits in entirety
>> on an 80x24 screen wins my approval.  I.e., this
>> might not scale to larger projects: I'm not at all sure I'd
>> rather read a 1400-line Perl program than a 7600-line C++
>> program or a 15800-line Ada program.  Actually, "none of the
>> above" sounds most appealing.
>>
>
> Anyone else than I missing the good old days with printouts
> from line printers with continuous paper?
>
> Anders

Yep, I miss that :-).  Along with green and amber monochrome monitors that 
when turned on, you could shut down the heating in the house and open the 
your windows...in January no less ;-).

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
:  begin -- Insert 
:    Insert (Map, To_Lower (Word), 0, I, B); 
:    declare E : Wordcount_Maps.Element_Subtype renames To_Access
: (I).all;
:    begin 
:      E := E + 1; 
:    end; 
:  end Insert;

Is the intention to first store a 0 with word, and then
to increment the value stored at word?

: is easier to understand than the corresponding C++ code:
:  ++concordance[word];

Although this will require that you know how to separate the
queries and commands in this abbreviation. If you are not used
to how ++ and [] work in the context of maps, will this still be
easy to understand?  AFAIK, [] does more than one thing behind
the scenes.  ++ is known to be difficult to understand in that it
is not clear what ++ is referring to. Here, it is not incrementing
the concordance, although the operator is placed immediately before
the identifier. IIRC, the K&R book talks about (), ++, *, -> at
length. I guess there is a reaseon.

For me this is similar to saying the APL is easy to read, which
is true if you know APL.

-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:
:> 
:>   $ tr -cd ';' <bcwords.ada | wc -c
: 
: I always used
: 
: grep \; <file> | wc -l

I use

grep -c \; <file>


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Jean-Pierre Rosen]

Anders Wirzenius a écrit :

  > Anyone else than I missing the good old days with printouts
> from line printers with continuous paper?
> 
When you were allowed only one compilation run a day?
Then, you had to be careful about missing semi-colons :-)

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Jeff C r e e.m]

"Matthew Heaney" <mheaney@on2.com> wrote in message 
news:1ec946d1.0409222224.6d86e038@posting.google.com...
> kevin.cline@gmail.com (Kevin Cline) wrote in message 
> news:<e749549b.0409211621.6f3d3723@posting.google.com>...
>>
>> You can compare the implementations at
>> http://www.geocities.com/kc0a/wordcount.html
>
> See also the latest version of the wordcount example, that compiles
> against the Madison release of the AI-302 API:
>
> http://charles.tigris.org/source/browse/charles/src/ai302/examples/wordcount/
>
> This should give you some idea of how things will work in Ada 2005.
>
> -Matt


I took a quick look. What possible reason is there to procedeed all of those 
nested subprogram bodies by the specifications

For example. (See inline comment below)



   Populate_Vector :
   declare
      --
      -- As written, this line as absolutely no purpose
      --
      procedure Append_To_V (C : Wordcount_Maps.Cursor);

      procedure Append_To_V (C : Wordcount_Maps.Cursor) is
      begin
         Append (V, C);
      end Append_To_V;

      N : constant Count_Type := Length (M);
   begin
      if Capacity (V) < N then
         Ensure_Capacity (V, N);
      end if;

      Iterate (M, Append_To_V'Access);
   end Populate_Vector;

In the complete example that style represents 5 lines of code that add 
nothing to the program semantics or
to the program readability.

Of course it is early in the morning so perhaps I am missing something 
obvious.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Ole-Hjalmar Kristensen]

>>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes:

<snip>

    >> 
    >> Does this prove that perl is the best language?  If so, perhaps we
    >> should all switch our avionics projects over to perl.  Must be it will
    >> be easier to code and maintain, safer to fly, and run just as fast.

    KC> It doesn't prove that Perl is the best language for every job.  But
    KC> the original thread was about Ada popularity.  Relatively few people
    KC> write avionics code, or any safety-critical software.  I do think that
    KC> a lot of projects currently being written in C++, Java, or C# could be
    KC> done much more cheaply and effectively in Perl or a similar language.

    >> 
    >> The things that make a language a "good" language are many and
    >> complex, and are different in different circumstances.  If I need a
    >> small utility that compares lines in different text files, I find perl
    >> much easier than Ada.  On the other hand, if I have a very large
    >> project that must always perform "correctly", I've not found a
    >> language that can beat Ada.

    KC> But large projects in Ada or C++ or Java or C# might be small or
    KC> medium-sized projects in a higher-level language.

Maybe. It depends on how large the projcet is, and how good you are to
create reusable components/abstractions within the project, and how
good a fit your problem is to the facilites provided by the
"higher-level" language.

    KC> If you have a project that must always perform "correctly", then you
    KC> better prove it correct.  Strong typing can help, but is not
    KC> absolutely necessary to that effort.

    KC> For the rest of us, the most important thing is to get tested code
    KC> done quickly.  I don't know about you, but I can write and test 14
    KC> lines of code a whole lot faster than I can write and test 80 or 160.

I usually find that my ability to create programs is limited by my
thought process, not my typing speed :-)

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Jeff C r e e.m <jcreem@yahoo.com> wrote:
: 
:   Populate_Vector :
:   declare
:      --
:      -- As written, this line as absolutely no purpose
:      --
:      procedure Append_To_V (C : Wordcount_Maps.Cursor);

I find these lines useful as head lines. You can place a short
comment below them. Then the implementation, which follows
the commenting paragraph, is less disrupted.

:      procedure Append_To_V (C : Wordcount_Maps.Cursor) is
:      begin
:         Append (V, C);
:      end Append_To_V;
: 
:      N : constant Count_Type := Length (M);
:   begin
:      if Capacity (V) < N then
:         Ensure_Capacity (V, N);
:      end if;
: 
:      Iterate (M, Append_To_V'Access);
:   end Populate_Vector;

-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Marius Amado Alves]

> Anyone else than I missing the good old days with printouts 
> from line printers with continuous paper?

This interests me, because I'm researching knowledge media, how the 
medium constraints influence habits and effectivness of reading, what 
levels of knowledge organization are influenced by technology... You 
mean the "page principle" (fit a function inside a page or less) is 
totally technology-driven (and hence not a principle)? Not a rough 
measure of some cognitive absolute? Thanks.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Anders Wirzenius]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> > Anyone else than I missing the good old days with printouts from
> > line printers with continuous paper?
> 
> This interests me, because I'm researching knowledge media, how the
> medium constraints influence habits and effectivness of reading, what
> levels of knowledge organization are influenced by technology... You
> mean the "page principle" (fit a function inside a page or less) is
> totally technology-driven (and hence not a principle)? Not a rough
> measure of some cognitive absolute? Thanks.

I mean the easiness to "turn pages" using a finger under the left
edge of the paper strip. My English is not good enough to explain
that more detailed. I think everyone who have experienced the
line printer paper strips knows what I mean. 
Back in the "good old days" I worked on a system with hundreds of 
code (Fortran subroutine) files up to some thousand lines.
We kept all code as a library of printed paper strips and it was 
very fast to go to the files and find whatever information you 
might have needed from the code. That even if we had the excellent
editor (don't remember the name anymore) on our VAX machines.

Perhaps you may obtain something similar using a text editor 
with bookmarks, but I have never reached that level of usage.

I have compared the screen_scrolling versus flip_through_paper to
a situation where you read your newspaper (at least A3 size) 
looking at the text through a frame of size A5 (or smaller).
You are not allowed to move your eyes outside the frame.
If you don't want to jump to another place in the text by 
moving the frame and your eyes simultaneously,
jumping to a new place is done in three steps:
First step one or two steps back (scroll out), 
then move your frame to a new place (move cursor), 
and then step back closer (scroll in). 
After which you may continue to read (through the frame, of course).

Yes, I think it is technology driven.  
Why are printed newspapers still popular even if a lot of 
people have a permanent, uninterrupted Internet connection 
and are able to rapidly move even between several 
electronic newspapers?

I remember having read somewhere that 2 or 3 centuries back
many writing desks had an inclination which made the
reader look at the text perpendicular to the paper.
Later the desks have been tilted so that we read the text 
from an angle less than 90 degrees. And feel obviously
more comfortable with it.
Now our computer screens are tilted to the 90 degrees. :)

Anders

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ciuadu$t8o$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> :  begin -- Insert 
> :    Insert (Map, To_Lower (Word), 0, I, B); 
> :    declare E : Wordcount_Maps.Element_Subtype renames To_Access
> : (I).all;
> :    begin 
> :      E := E + 1; 
> :    end; 
> :  end Insert;
> 
> Is the intention to first store a 0 with word, and then
> to increment the value stored at word?

Yes.  That's exactly how the index operator works in C++ (which is
deliberate).  This is the most efficient technique, since the search
is performed only one time.

Note that in the AI-302 API, you use a slightly different technique:

declare
   procedure Increment_Count (W : in String; N : in out Natural) is
   begin
      N := N + 1;
   end;
begin
   Update_Element (C, Increment_Count'Access);
end;

See the link in my previous post to the Ada 2005 version of
wordcount.adb at the tigris site.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1777528.JKnUEYTOM6@linux1.krischik.com>...
> 
> Which shows that the "1 instantiation only"  argument of Charles and
> Ada.Containers is misguided. So think I stick with the Booch Components
> even after Ada 2005.

I haven't seen Simon's wordcount code in a while (probably not since
Simon and I met in Vienna), but I suspect we're comparing apples and
oranges here.

Simon probably used the BC set, which stores each element with a
count.  In Charles and AI-302, the container model is a little
different, and you would use a map instead, with the word as the map
key and the frequency count as the map element.

So it would not surprise me if the wordcount problem has slightly
fewer lines of code using the BC set than using the AI-302 map, since
in the former case you're using what is essentially a special purpose
container.

Someone needs to make a feature-by-feature comparison of Simon's BC
solution and the AI-302 solution I just posted.  (I don't have time
right now since I'm too busy incorporating the Madison changes.)  Note
that the example I posted does a lot of extra stuff to illustrate API
features, extra stuff that isn't strictly necessary to solve the
wordcount problem.  If the unnecessary stuff were removed, then the
comparison between BC and AI-302 solutions would be more realistic.


> When we at it: I still have the "indefinite extension" within AdaCL.
> Howabout joining them?

All the containers in AI-302 have variants that support indefinite
keys and indefinite elements.  (All of the containers are now publicly
taggged, too.)

If AI-302 doesn't meet your needs, then you need to let us know. 
Please peruse the a-c*.ad[sb] sources at the tigris website.  (Note
that I'm still incorporating changes from the most recent ARG
meeting.)

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ciuadu$t8o$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> :  begin -- Insert 
> :    Insert (Map, To_Lower (Word), 0, I, B); 
> :    declare E : Wordcount_Maps.Element_Subtype renames To_Access
> : (I).all;
> :    begin 
> :      E := E + 1; 
> :    end; 
> :  end Insert;
> 
> Is the intention to first store a 0 with word, and then
> to increment the value stored at word?

My understanding is that Insert will insert a new key/value pair into
the map if no entry exists for the given key, and outputs the iterator
I pointing to the key/value pair for the given key.

> 
> : is easier to understand than the corresponding C++ code:
> :  ++concordance[word];
> 
> Although this will require that you know how to separate the
> queries and commands in this abbreviation. If you are not used
> to how ++ and [] work in the context of maps, will this still be
> easy to understand?

The only question is whether the [] operator will create an entry 
if none exists.  Thirty seconds with the reference will confirm that
it does, and I would expect a professional programmer to be able to
remember that.
  
> AFAIK, [] does more than one thing behind the scenes.  
> ++ is known to be difficult to understand in that it
> is not clear what ++ is referring to. 

Now are you claiming that C++ is hard to read because one has to learn
the operator precedence rules?

> Here, it is not incrementing
> the concordance, although the operator is placed immediately before
> the identifier. IIRC, the K&R book talks about (), ++, *, -> at
> length. I guess there is a reaseon.
> 
> For me this is similar to saying the APL is easy to read, which
> is true if you know APL.

Presumably anyone undertaking to program in APL will at some point
come to know APL.  You seem to be arguing that a tool is poor because
it's use is not immediately obvious to the untrained.  The
effectiveness of a tool has to be judged by comparing the productivity
of workers skilled with that tool.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Warren W. Gay VE3WWG]

Anders Wirzenius wrote:
> Marius Amado Alves <amado.alves@netcabo.pt> writes:
>>>Anyone else than I missing the good old days with printouts from
>>>line printers with continuous paper?
>>
>>This interests me, because I'm researching knowledge media, how the
>>medium constraints influence habits and effectivness of reading, what
>>levels of knowledge organization are influenced by technology... You
>>mean the "page principle" (fit a function inside a page or less) is
>>totally technology-driven (and hence not a principle)? Not a rough
>>measure of some cognitive absolute? Thanks.
> 
> I mean the easiness to "turn pages" using a finger under the left
> edge of the paper strip. My English is not good enough to explain
> that more detailed. I think everyone who have experienced the
> line printer paper strips knows what I mean. 

Another reason that "method" worked so well, was
that it supported the high resolution pen graphics (pencil
or pen, even highliters). Notes and scribbles, even doodles
often helped the thought process in more complicated
cases.

If you went further, and kept prior listings in a filing
cabinet (as one place I worked at did), then you had
the benefits of other notes, scribbles and alas, even
sometimes diagrams!

People usually won't make the same effort in electronic
forms -- so this is lacking today.

> Perhaps you may obtain something similar using a text editor 
> with bookmarks, but I have never reached that level of usage.

They don't support the "high resolution graphics" and
diagrams ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Warren W. Gay VE3WWG]

Kevin Cline wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cisper$e5u$1@a1-hrz.uni-duisburg.de>...
>>Kevin Cline <kevin.cline@gmail.com> wrote:
...
>>Will the compilation process profit from splitting
>>C++ sources into files, in general?
> 
> No, it will get slower, in general, because opening files is about the
> slowest part of compilation.  The only reason to split code into
> multiple files is to ease maintenance.

Not just open overhead, but each separate compile
requires re-digesting all the #include files
that must be repeated for each unit.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Pascal Obry]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Jeff C r e e.m <jcreem@yahoo.com> wrote:
> : 
> :   Populate_Vector :
> :   declare
> :      --
> :      -- As written, this line as absolutely no purpose
> :      --
> :      procedure Append_To_V (C : Wordcount_Maps.Cursor);
> 
> I find these lines useful as head lines. You can place a short
> comment below them. Then the implementation, which follows
> the commenting paragraph, is less disrupted.

Exactly and this is the GNAT style (and can be checked using -gnatys). It
ensures that all routines that are only in the body have a spec and this is
the best place to put a set of comments for this routine.

Pascal.

-- 

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

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Pascal Obry]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> I find these lines useful as head lines. You can place a short
> comment below them. Then the implementation, which follows
> the commenting paragraph, is less disrupted.

BTW, this is also the style used for AWS.

Pascal.

-- 

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

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dan Andreatta]

kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0409211621.6f3d3723@posting.google.com>...
> As promised in the Ada popularity thread, I have taken one of the
> Charles examples and reimplemented it in C++.  I used only the
> standard C++ language and libraries.  The Ada/CHARLES main program
> body is 118 (non-blank) lines of code, plus an additional 40 lines of
> instantiations in eight other specification files, for a total of 158
> lines and 9 files.  The C++ implementation is 76 (non-blank) lines of
> code in a single file.  For grins, I also wrote the program in Perl. 
> That took 14 lines.
> 
> Summary:
> 
> Ada/Charles 158 lines, 9 files
> C++         76 lines
> Perl        14 lines
> 
> You can compare the implementations at
> http://www.geocities.com/kc0a/wordcount.html

And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries.

module Main where

import Data.FiniteMap
import Data.List
import System
import Char

count_words :: [String] -> [(String, Integer)]
count_words ws = sortBy comp $ fmToList $ addListToFM_C (+) emptyFM  ws'
    where
    comp (_,n) (_,m) = compare m n
    ws' = zip ws [1,1..]

main = do
       args <- getArgs
       f <- readFile (args!!0)
       putStr $ show $ take 10 $ count_words (map (map toLower) $ words f)

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Cesar Rabak]

Marius Amado Alves escreveu:
>> Anyone else than I missing the good old days with printouts from line 
>> printers with continuous paper?
> 
> 
> This interests me, because I'm researching knowledge media, how the 
> medium constraints influence habits and effectivness of reading, what 
> levels of knowledge organization are influenced by technology... You 
> mean the "page principle" (fit a function inside a page or less) is 
> totally technology-driven (and hence not a principle)? Not a rough 
> measure of some cognitive absolute? Thanks.
> 

Probably. For other realms, a 'comfortable' size would be an A3 or A2 
sheet with some graphical representation, or a maquette with no more 
than (say) one square meter.

You probably will pass at in your research why the distance we find 
comfortable for talking to other persons has to be no less than a meter 
so we can see the whole face of the other person.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Pascal Obry]

andreatta@mail.chem.sc.edu (Dan Andreatta) writes:

> And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries.

And it is just unreadable ! I just can't understand how this is supposed
to work!

Pascal.

-- 

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

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

mheaney@on2.com (Matthew Heaney) wrote in message news:<1ec946d1.0409222224.6d86e038@posting.google.com>...
> kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0409211621.6f3d3723@posting.google.com>...
> > 
> > You can compare the implementations at
> > http://www.geocities.com/kc0a/wordcount.html
> 
> See also the latest version of the wordcount example, that compiles
> against the Madison release of the AI-302 API:
> 
> http://charles.tigris.org/source/browse/charles/src/ai302/examples/wordcount/
> 
> This should give you some idea of how things will work in Ada 2005.

Ok, but the new code is longer than the old code.  There are 150
non-blank lines in the main body, and an additional 19 lines of code
in two instantiation specifications, for a total of 179 lines of code.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Jeff C r e e.m" <jcreem@yahoo.com> wrote in message news:<Kmy4d.243234$mD.161573@attbi_s02>...
>
> I took a quick look. What possible reason is there to procedeed all of those 
> nested subprogram bodies by the specifications
[snip]
 
> Of course it is early in the morning so perhaps I am missing something 
> obvious.


They add nothing.  I was using the -gnatg option, and -gnatg requires
forward declarations of all subprograms.

That was a mistake.  I only need to use -gnatg to compile the ada.*
units, not wordcount.adb.

I'll fix that tonight.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Anders Wirzenius <anders@no.email.thanks.invalid> wrote in message news:<upt4dhzxu.fsf@no.email.thanks.invalid>...
 
> Why are printed newspapers still popular even if a lot of 
> people have a permanent, uninterrupted Internet connection 
> and are able to rapidly move even between several 
> electronic newspapers?

Because a newspaper is a set of unrelated articles, and we read the
articles from beginning to end.  And we don't have to edit the
newspaper, just read it.  Newspaper writers and editors universally do
their work on a computer screen.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Marius Amado Alves]

>>Why are printed newspapers still popular even if a lot of 
>>people have a permanent, uninterrupted Internet connection 
>>and are able to rapidly move even between several 
>>electronic newspapers?
> 
> Because a newspaper is a set of unrelated articles, and we read the
> articles from beginning to end.  And we don't have to edit the
> newspaper, just read it.  Newspaper writers and editors universally do
> their work on a computer screen.

I don't understand this explanation.

My answer would be along these lines. On a big paper sheet there are 
different content items, or different parts of some content. You have to 
locate a part, focus on it, to read it. Same goes for the whole 
(printed) newspaper. On a small screen only one part fits. The others 
are away. So what is different is how the user locates parts. With a 
printed paper you only have to turn your eyes or head to look at a 
different part. And you can even move a sheet up/down/left/right so the 
part under inspection stays more aligned with the eyes. You cannot do 
that with a small screen. Maybe with an eyetracking system you can 
simulate that, but I doubt it will work as well.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[jayessay]

kevin.cline@gmail.com (Kevin Cline) writes:

> Bj�rn Persson <spam-away@nowhere.nil>
> > Kevin Cline wrote:
> > 
> > > Ada/Charles 158 lines, 9 files
> > > C++         76 lines
> > > Perl        14 lines
> > 
> > Neat. Now let's take three identical persons who haven't seen this 
> > program before, give them one version each, and see how long it takes 
> > them to understand it.
> > In other words: What matters is how easy the program is to read and 
> > maintain. 

Here is a quick hack Common Lisp version.  It is 11 "lines".  You
could get rid of a couple more 

(defun word-count (file-spec &key (wordpat (compile-pattern "[A-Za-z]+")))
  (let ((words->count (make-hash-table :test #'equal :size 10007)))
    (with-open-file (in file-spec :direction :input)
      (loop for line = (read-line in nil nil)
	    while line
	    do (replace-match
		:source line :target wordpat :every-occurance t
		:replacement #'(lambda (word)
				 (incf (gethash word words->count 0)) ""))))
    (format t "~{~A~^~%~}"
      (subseq (sort (all (w c) :in words->count) #'> :key #'second) 0 10))))

This also does all the checking of the C++ and Ada versions as well.


> I quite agree, and on that score the Perl code wins hands down. 

I don't much like Perl (too much line noise), but I still think you
are right here.  It took just a glance at the Perl to know what the
basic "spec" was (including just printing the top ten).  OTOH, I think
the above Lisp is significantly more readable than any of them as it
is both short and very descriptive.


> It's pretty hard to make the case that this Ada code:
> 
>   procedure Insert (Word : String) is 
>     I : Wordcount_Maps.Iterator_Type; 
>     B : Boolean; 
>     type Element_Access is access all Wordcount_Maps.Element_Subtype;
> 
>     for Element_Access'Storage_Size use 0;
> 
>     function To_Access is new Wordcount_Maps.Generic_Element
> (Element_Access);
>   
>   begin -- Insert 
>     Insert (Map, To_Lower (Word), 0, I, B); 
>     declare E : Wordcount_Maps.Element_Subtype renames To_Access
> (I).all;
>     begin 
>       E := E + 1; 
>     end; 
>   end Insert;
> 
> is easier to understand than the corresponding C++ code:
>   ++concordance[word];
> 
> or the corresponding Perl code:
>   ++$count{$word};

Or the non library, out of the box Lisp:

(incf (gethash word words->count 0))

What's more, it will be at least as fast as the C++ or Ada.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbrd60dusx0.fsf@sun.com>...
> >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes:
> 
> <snip>
> 
>     >> 
>     >> Does this prove that perl is the best language?  If so, perhaps we
>     >> should all switch our avionics projects over to perl.  Must be it will
>     >> be easier to code and maintain, safer to fly, and run just as fast.
> 
>     KC> It doesn't prove that Perl is the best language for every job.  But
>     KC> the original thread was about Ada popularity.  Relatively few people
>     KC> write avionics code, or any safety-critical software.  I do think that
>     KC> a lot of projects currently being written in C++, Java, or C# could be
>     KC> done much more cheaply and effectively in Perl or a similar language.
> 
>     >> 
>     >> The things that make a language a "good" language are many and
>     >> complex, and are different in different circumstances.  If I need a
>     >> small utility that compares lines in different text files, I find perl
>     >> much easier than Ada.  On the other hand, if I have a very large
>     >> project that must always perform "correctly", I've not found a
>     >> language that can beat Ada.
> 
>     KC> But large projects in Ada or C++ or Java or C# might be small or
>     KC> medium-sized projects in a higher-level language.
> 
> Maybe. It depends on how large the projcet is, and how good you are to
> create reusable components/abstractions within the project, and how
> good a fit your problem is to the facilites provided by the
> "higher-level" language.
> 
>     KC> If you have a project that must always perform "correctly", then you
>     KC> better prove it correct.  Strong typing can help, but is not
>     KC> absolutely necessary to that effort.
> 
>     KC> For the rest of us, the most important thing is to get tested code
>     KC> done quickly.  I don't know about you, but I can write and test 14
>     KC> lines of code a whole lot faster than I can write and test 80 or 160.
> 
> I usually find that my ability to create programs is limited by my
> thought process, not my typing speed :-

Mine too.  For the Perl program, the thought process was limited to
this:

  read input: while (<>)

  split into sequences of alphabetic characters: 
     foreach my $word (split (/[a-zA-Z]+/))

  count words: ++$count{$word}

  sort words by frequency: sort { $map{$a} <=> $map{$b} ) keys %count

  print first 10: $n = 0; foreach ( ... ) { print ...; last if ++$n >=
10; }

The only bits that required much thought at all were figuring out the
right comparison function for sorting (I looked at an example), and
getting the loop exit right.  The rest was written nearly
instantaneously.

Are you really claiming that you can think of:

  procedure Insert (Word : in String) is

      procedure Increment_Count
        (K : in     String;
         N : in out Natural) is

         pragma Warnings (Off, K);
      begin
         N := N + 1;
      end Increment_Count;

      C : Wordcount_Maps.Cursor;
      B : Boolean;

   begin -- Insert
      Insert (M, Word, 0, C, B);
      Update_Element (C, Increment_Count'Access);
   end Insert;

As quickly as I can think of: 
  ++concordance[word] 
or
  ++$count{$word} ?

Multiply this 1000 times for a medium to large program and I think Ada
really suffer from unnecessary verbosity.

It's reasonable to claim that Ada is better than C++ for
safety-critical embedded programming, but if you really want to
understand why Ada is not more popular for desktop applications I
think the evidence is here.  The real question I have is why Perl and
similar high-level languages are not more popular.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Eric Jacoboni]

Pascal Obry <pascal@obry.org> writes:

> And it is just unreadable ! I just can't understand how this is supposed
> to work!

Agree... 

What about Ruby ? Much more readable than perl/python, imho. Its
inventor claims to be inspired by Ada and Eiffel syntaxes. (i've don't
find the equivalent of the perl <> construct, hence the opening of
files given at the command line). I've don't managed to reduce the
number of lines (it could be done...).

count = Hash.new(0)

ARGV.each do |a_filename|                    # for each filename given as argument..
  File::open(a_filename) do |lines|          # open it
    lines.each_line do |line|                # for each of its lines...
      for word in line.split (/[^A-Za-z]+/)  # get each word
         count[word.downcase] += 1           # update this word count
      end # for
    end # lines.each_line
  end # File::open
end # ARGV.each

sorted_count = count.sort do |pair_1, pair_2|  # for each (key,value) pair
  pair_2[1] <=> pair_1[1]                      # compare their values
end

nb = 0

sorted_count.each do |word, nb_occ|           # print the first 10 results
  print word, ' -> ', nb_occ, "\n"
  nb += 1
  break if nb >= 10 
end # count.each

-- 
�ric Jacoboni, n� il y a 1399410646 secondes

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Simon Wright]

mheaney@on2.com (Matthew Heaney) writes:

> Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1777528.JKnUEYTOM6@linux1.krischik.com>...
> > 
> > Which shows that the "1 instantiation only"  argument of Charles and
> > Ada.Containers is misguided. So think I stick with the Booch Components
> > even after Ada 2005.
> 
> I haven't seen Simon's wordcount code in a while (probably not since
> Simon and I met in Vienna), but I suspect we're comparing apples and
> oranges here.
> 
> Simon probably used the BC set, which stores each element with a
> count.  In Charles and AI-302, the container model is a little
> different, and you would use a map instead, with the word as the map
> key and the frequency count as the map element.

Bag, actually; designed precisely for counting things (that compare
"="). Not (IME) a solution to any problems I actually have in real
life!

If you didn't have Bags, the Map scheme is just as good (and is how
the BC bag is implemented under the hood).

> So it would not surprise me if the wordcount problem has slightly
> fewer lines of code using the BC set than using the AI-302 map, since
> in the former case you're using what is essentially a special purpose
> container.
> 
> Someone needs to make a feature-by-feature comparison of Simon's BC
> solution and the AI-302 solution I just posted.

Only if they really care!

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Eric Jacoboni]

Pascal Obry <pascal@obry.org> writes:

> And it is just unreadable ! I just can't understand how this is supposed
> to work!

Agree... 

What about Ruby ? Much more readable than perl/python, imho. Its
inventor claims to be inspired by Ada and Eiffel syntaxes. (i've not
find the equivalent of the perl <> construct, hence the opening of
files given at the command line). I've not managed to reduce the
number of lines (it could be done...).

count = Hash.new(0)

ARGV.each do |a_filename|                    # for each filename given as argument..
  File::open(a_filename) do |lines|          # open it
    lines.each_line do |line|                # for each of its lines...
      for word in line.split (/[^A-Za-z]+/)  # get each word
         count[word.downcase] += 1           # update this word count
      end # for
    end # lines.each_line
  end # File::open
end # ARGV.each

sorted_count = count.sort do |pair_1, pair_2|  # for each (key,value) pair
  pair_2[1] <=> pair_1[1]                      # compare their values
end

nb = 0

sorted_count.each do |word, nb_occ|           # print the first 10 results
  print word, ' -> ', nb_occ, "\n"
  nb += 1
  break if nb >= 10 
end # count.each

-- 
�ric Jacoboni, n� il y a 1399410646 secondes

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[jayessay]

Ole-Hjalmar Kristensen 

> >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes:
> 
> <snip>
> 
>     >> 
>     >> Does this prove that perl is the best language?  If so, perhaps we
>     >> should all switch our avionics projects over to perl.  Must be it will
>     >> be easier to code and maintain, safer to fly, and run just as fast.
> 
>   KC> It doesn't prove that Perl is the best language for every job.  But
>   KC> the original thread was about Ada popularity.  Relatively few people
>   KC> write avionics code, or any safety-critical software.  I do think that
>   KC> a lot of projects currently being written in C++, Java, or C# could be
>   KC> done much more cheaply and effectively in Perl or a similar language.
> 
>     >> 
>     >> The things that make a language a "good" language are many and
>     >> complex, and are different in different circumstances.  If I need a
>     >> small utility that compares lines in different text files, I find perl
>     >> much easier than Ada.  On the other hand, if I have a very large
>     >> project that must always perform "correctly", I've not found a
>     >> language that can beat Ada.
> 
>     KC> But large projects in Ada or C++ or Java or C# might be small or
>     KC> medium-sized projects in a higher-level language.

I have found this to be _very_ true.


> Maybe. It depends on how large the projcet is, and how good you are
> to create reusable components/abstractions within the project,

Not really, as that should be true no matter what language you use.


> and how good a fit your problem is to the facilites provided by the
> "higher-level" language.

This is key.  The robustness, maintainability, evolvability, and
"correctness" of a program is directly and closely related to how
close its expression is to the language of the problem domain.

In the case of Lisp, this is where the "Lisp is a programmable
programming language" comes in.  You can always create a (possibly
hierarchical set of) domain specific language that directly supports
the most natural, clean, and direct means of expressing the
definitions and process within the domain.  People often talk of
"hoisting the language up to the level of the domain".

It used to be (and I suppose in many places still is the case) that
people thought this sort of thing could be done with components and
component libraries.  But this is an error.  No library (no matter how
good it is - and most are very poor) will ever have the level of
expressiveness as even a decent (let alone good) domain specific
language.


>     KC> If you have a project that must always perform "correctly", then you
>     KC> better prove it correct.  Strong typing can help, but is not
>     KC> absolutely necessary to that effort.
> 
>     KC> For the rest of us, the most important thing is to get tested code
>     KC> done quickly.  I don't know about you, but I can write and test 14
>     KC> lines of code a whole lot faster than I can write and test 80 or 160.
> 
> I usually find that my ability to create programs is limited by my
> thought process, not my typing speed :-)

He's not refering to the same limitation, and he's right.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Simon Wright]

mheaney@on2.com (Matthew Heaney) writes:

> "Jeff C r e e.m" <jcreem@yahoo.com> wrote in message news:<Kmy4d.243234$mD.161573@attbi_s02>...
> >
> > I took a quick look. What possible reason is there to procedeed
> > all of those nested subprogram bodies by the specifications
>  
> > Of course it is early in the morning so perhaps I am missing something 
> > obvious.
> 
> 
> They add nothing.  I was using the -gnatg option, and -gnatg requires
> forward declarations of all subprograms.
> 
> That was a mistake.  I only need to use -gnatg to compile the ada.*
> units, not wordcount.adb.

I find that GNAT's style checking helps me a lot; and it's much easier
to say -gnaty than -gnaty3abcefhiklmprt, which is the standard set
less -gnats (check separate specs). A shame that you can't say -gnatyS
to turn the feature off, as in -gnatw ...

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Ed Falis]

On Thu, 23 Sep 2004 21:21:06 +0200, Eric Jacoboni <jaco@neottia.net> wrote:

> What about Ruby ?

A lot easier to follow than the perl version (or the lisp version).

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Eric Jacoboni]

"Ed Falis" <falis@verizon.net> writes:

> A lot easier to follow than the perl version (or the lisp version).

And that's why i use it instead of Perl ;)
-- 
�ric Jacoboni, n� il y a 1399412243 secondes

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Alexander E. Kopilovich]

Kevin Cline wrote:

>  But the original thread was about Ada popularity.

Implicitly, among programmers/software engineers and perhaps software-related
managers, I suppose. But this isn't the only possible audience for popularity,
even for programming languages.

>  Relatively few people write avionics code,

Just as relatively few people fly airplanes as airline or military pilots or
pilots for other services. But quite enough people depend on that flying and
its safety and effectiveness.

Even in avaiation world there are different kinds of popularity - for example,
both Boeing and Cessna are certainly quite popular. And probably much more
people fly Cessnas, but does it mean that Cessna is generally more popular
than Boeing?

> But large projects in Ada or C++ or Java or C# might be small or
> medium-sized projects in a higher-level language.

Don't you know that a plane cannot fly before the weight of its documentation
exceeds its own weight? -:)




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Alexander E. Kopilovich]

Kevin Cline wrote:

> The real question I have is why Perl and
> similar high-level languages are not more popular.
Perl has its own great competitor - Visual Basic (and to some degree Delphi
and some others, which also provide nice buttons and other GUI components)
- just as Ada has C++ and to some degree Java.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Adam Ruth]

In article <m365647qdv.fsf@rigel.goldenthreadtech.com>,
 jayessay <nospam@foo.com> wrote:

> kevin.cline@gmail.com (Kevin Cline) writes:

> 
> Here is a quick hack Common Lisp version.  It is 11 "lines".  You
> could get rid of a couple more 
> 
> (defun word-count (file-spec &key (wordpat (compile-pattern "[A-Za-z]+")))
>   (let ((words->count (make-hash-table :test #'equal :size 10007)))
>     (with-open-file (in file-spec :direction :input)
>       (loop for line = (read-line in nil nil)
> 	    while line
> 	    do (replace-match
> 		:source line :target wordpat :every-occurance t
> 		:replacement #'(lambda (word)
> 				 (incf (gethash word words->count 0)) ""))))
>     (format t "~{~A~^~%~}"
>       (subseq (sort (all (w c) :in words->count) #'> :key #'second) 0 10))))
> 

I've come to this thread late, so I'm not completely sure about the 
exact specs of the code, but here's my take on a Python version.  It 
comes in at a svelt 10 lines, and I think it's quite readable.  I'm sure 
I'm missing something though.

import sys

words = {}
for line in sys.stdin.readlines():
    for word in line.split():
        words[word] = words.get(word, 0) + 1

words = [[x[1], x[0]] for x in words.items()]
words.sort()
words.reverse()

for word in words[:10]:
   print word[0], word[1]

-- 
Adam Ruth
adamruth at mac dot com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Eric Jacoboni]

Eric Jacoboni <jaco@neottia.net> writes:

> What about Ruby ? Much more readable than perl/python, imho. Its
> inventor claims to be inspired by Ada and Eiffel syntaxes. (i've not
> find the equivalent of the perl <> construct, hence the opening of
> files given at the command line). 

Ok, i've finally found the equivalent of while (<>) construct in Ruby,
so the initialisation of the hash is now more concise. By using 'for'
instead of iterators, the code is more Ada-ish :

for a_file in ARGF do
  for a_line in a_file do
    for a_word in a_line.split(/[^A-Za-z]+/) do
        count[a_word.downcase] += 1
    end # for a_word 
  end # for a_line
end # for a_file

-- 
�ric Jacoboni, n� il y a 1399418449 secondes

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Eric Jacoboni]

kevin.cline@gmail.com (Kevin Cline) writes:
I
> The real question I have is why Perl and similar high-level
> languages are not more popular.

But Perl /is/ very popular... Ask a sys or a network admin, for
example.

That's only a matter of programming domain
-- 
�ric Jacoboni, n� il y a 1399419904 secondes

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Anders Gidenstam]

In article <u6564dfge.fsf@obry.org>,
	Pascal Obry <pascal@obry.org> writes:
> 
> andreatta@mail.chem.sc.edu (Dan Andreatta) writes:
> 
>> And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries.
> 
> And it is just unreadable ! I just can't understand how this is supposed
> to work!

It is not all that horrible once you realize that $ is function
application, for example

  putStr $ show $ take 10 $ count_words (map (map toLower) $ words f)

can also be written

  putStr (show (take 10 (count_words (map (map toLower) (words f)))))

Still, I'm not sure Dan's version behaves as expected since it sometimes
treats non-alphabetic characters as words.

Here is another Haskell version and this time in pure Haskell 98 at the
expense of one more line. Enjoy! 

module Main where

import System
import List
import Char

count_words :: [String] -> [(Int, String)]
count_words xs = sortBy comp $ init $ foldr count_same [(0, "")] $ sort xs
  where count_same w1 (y1@(c, w2):ys) = if (w1 == w2)
					then (c + 1, w1):ys else (1,w1):y1:ys 
        comp (c1, _) (c2, _) = compare c2 c1

main = do args <- getArgs
	  f <- readFile (args!!0)
          putStr $ concat $ map prettyShow $ take 10 $ count_words $ wordify f
       where wordify xs       = words $ map toLower $ map onlyAlpha xs
	     onlyAlpha x      = if isAlpha x then x else ' '
	     prettyShow (c,w) = w ++ " " ++ show c ++ "\n"


Well, I think it is nifty even if you don't :)

/Anders
-- 
"Luck is my middle name," said Rincewind, indistinctly. "Mind you,
 my first name is Bad." 
   -- (Terry Pratchett, Interesting Times) 

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Randy Brukardt]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409211621.6f3d3723@posting.google.com...
> As promised in the Ada popularity thread, I have taken one of the
> Charles examples and reimplemented it in C++.  I used only the
> standard C++ language and libraries.  The Ada/CHARLES main program
> body is 118 (non-blank) lines of code, plus an additional 40 lines of
> instantiations in eight other specification files, for a total of 158
> lines and 9 files.

Why were all of the files needed? For a program of this size, I would have
nested the specifications in the body. (One possible reason was the old
restriction on nesting of tagged type extensions. Ada 2005 has eliminated
this restriction, so that particular issue will go away soon.)

                             Randy.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Brian May]

>>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes:
  
    Kevin> It's pretty hard to make the case that this Ada code:

    Kevin> procedure Insert (Word : String) is 
    Kevin> I : Wordcount_Maps.Iterator_Type; 
    Kevin> B : Boolean; 
    Kevin> type Element_Access is access all Wordcount_Maps.Element_Subtype;

    Kevin> for Element_Access'Storage_Size use 0;

    Kevin> function To_Access is new Wordcount_Maps.Generic_Element
    Kevin> (Element_Access);
  
    Kevin> begin -- Insert 
    Kevin> Insert (Map, To_Lower (Word), 0, I, B); 
    Kevin> declare E : Wordcount_Maps.Element_Subtype renames To_Access
    Kevin> (I).all;
    Kevin> begin 
    Kevin> E := E + 1; 
    Kevin> end; 
    Kevin> end Insert;

The following code (or something like it), I believe (not tested),
should reduce the line count (and complexity) of the above:

procedure Insert (Word : String) is 
   I : Wordcount_Maps.Iterator_Type; 
   B : Boolean; 
  
begin -- Insert 
   Insert (Map, To_Lower (Word), 0, I, B); 
   Replace_Element(I, Element(I) + 1);
end Insert;
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dale Stanbrough]

In article <AMqdnUutfbXY0s7cRVn-vA@megapath.net>,
 "Randy Brukardt" <randy@rrsoftware.com> wrote:

> Why were all of the files needed? For a program of this size, I would have
> nested the specifications in the body. (One possible reason was the old
> restriction on nesting of tagged type extensions. Ada 2005 has eliminated
> this restriction, so that particular issue will go away soon.)
> 
>                              Randy.

Talking about removing restrictions - will Ada 2005 allow for downward 
closures (I read that the one reason for it's exclusion was a compiler
which is no longer with us).

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> I find that GNAT's style checking helps me a lot; and it's much easier
> to say -gnaty than -gnaty3abcefhiklmprt, which is the standard set
> less -gnats (check separate specs). A shame that you can't say -gnatyS
> to turn the feature off, as in -gnatw ...

I also use GNAT's style checking, but I don't like the default -gnaty
(80 columns is too small, for one thing). So I have a standard project
file that specifies the options I like:

-- Standard settings for all of Stephe's Ada projects.
project Standard_Common is
  for Source_Dirs use ();

  type GNAT_Version_Type is ("5.02a1", "5.02a", "5.01a", "3.16a1", "3.15p");

  GNAT_Version : GNAT_Version_Type := External ("GNAT_VERSION");

  type OS_Version_Type is ("Windows_XP", "Windows_98", "Windows_2000", "Lynx_4.0");

  OS_Version : OS_Version_Type := External ("OS_VERSION");

  package Compiler is
     System_Case_Style_Checks := "n";
     Space_Style_Checks       := "t";
     Base_Style_Checks        := "-gnaty3abefhiklM120pr";
     Style_Checks             := Base_Style_Checks & System_Case_Style_Checks & Space_Style_Checks;
     Non_Spacing_Style_Checks := Base_Style_Checks & System_Case_Style_Checks;

     --  For GNAT 3.15, don't warn about elaboration order (gnatwL,
     --  off by default in 3.16).
     --
     --  -gnatVa causes some inline procedures to be non-inlineable;
     --  suppress that warning with -gnatwP.
     Base_Debug_Switches :=
       --  Switches we always use
       ("-g",
        "-O0",
        "-gnatf",
        "-gnato",
        "-gnatwa",
        "-gnatwL",
        "-gnatVa",
        "-gnatwP",
        "-fstack-check");
     Debug_Switches      := Base_Debug_Switches &
       --  Switches we need to suppress sometimes
       ("-gnata",
        "-gnatwe");

     Release_Switches := ("-g", "-O3", "-gnatn", "-gnatf", "-gnatwa", "-gnatwL");

     --  The project file syntax does not let us set a variable in a
     --  case statement. So we set the Default_Switches attribute to
     --  contain the version-dependent switches. This is then
     --  accessible in child project files via 'Default_Switches.
     case GNAT_Version is
     when "5.01a" =>
        --  WORKAROUND: GNAT 5.01a optimization bug;
        --  -fno-strict-aliasing avoids it. However,
        --  -fno-strict-aliasing is not defined in earlier GNAT
        --  versions. This switch is only needed for release builds
        --  (when optimization is enabled), but does not hurt in
        --  debug/test builds. Specifying it in both avoids splitting
        --  this file in two.
        for Default_Switches ("Ada") use ("-fno-strict-aliasing");

     when "5.02a1" | "5.02a" | "3.16a1" | "3.15p" =>

     end case;

  end Compiler;

  --  In project files, normally use this:
  --  package Compiler is
  --  for Default_Switches ("Ada") use Standard_Common.Compiler'Default_Switches ("Ada") &
  --     Standard_Common.Compiler.Base_Release_Switches &
  --     Standard_Common.Compiler.Style_Checks;
  --  end Compiler;

  package Binder is
     case OS_Version is
     when "Windows_98" =>


     when "Windows_2000" | "Lynx_4.0" | "Windows_XP" =>
        for Default_Switches ("Ada") use ("-E");
     end case;

     Debug_Configuration_Pragmas := "Normalize_Scalars";
  end Binder;

  --  In project files, normally use this:
  --  package Binder is
  --     for Default_Switches ("Ada") use Standard_Common.Binder'Default_Switches ("Ada");
  --  end Binder;

end Standard_Common;


Hmm. That file is bigger than I remembered :). But it holds everything
I've learned about running gnatmake.

-- 
-- Stephe

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Stephen Leake]

kevin.cline@gmail.com (Kevin Cline) writes:

> It's pretty hard to make the case that this Ada code:
> 
>   procedure Insert (Word : String) is 
>     I : Wordcount_Maps.Iterator_Type; 
>     B : Boolean; 
>     type Element_Access is access all Wordcount_Maps.Element_Subtype;
> 
>     for Element_Access'Storage_Size use 0;
> 
>     function To_Access is new Wordcount_Maps.Generic_Element
> (Element_Access);
>   
>   begin -- Insert 
>     Insert (Map, To_Lower (Word), 0, I, B); 
>     declare E : Wordcount_Maps.Element_Subtype renames To_Access
> (I).all;
>     begin 
>       E := E + 1; 
>     end; 
>   end Insert;
> 
> is easier to understand than the corresponding C++ code:
>   ++concordance[word];
> 
> or the corresponding Perl code:
>   ++$count{$word};

You're kidding, right? All I need to do for the Ada code is add:

procedure "+" (Word : in String) renames Insert;

and the final user code is:

+Word;

-- 
-- Stephe

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Jeffrey Carter]

Randy Brukardt wrote:

> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0409211621.6f3d3723@posting.google.com...
> 
>>As promised in the Ada popularity thread, I have taken one of the
>>Charles examples and reimplemented it in C++.  I used only the
>>standard C++ language and libraries.  The Ada/CHARLES main program
>>body is 118 (non-blank) lines of code, plus an additional 40 lines of
>>instantiations in eight other specification files, for a total of 158
>>lines and 9 files.
> 
> Why were all of the files needed? For a program of this size, I would have
> nested the specifications in the body. (One possible reason was the old
> restriction on nesting of tagged type extensions. Ada 2005 has eliminated
> this restriction, so that particular issue will go away soon.)

I have implemented a word counting program in Ada that requires 64 
statements in 3 files (the extra files are needed because of the current 
rules about extending tagged types). This is possible because of the 
existence of PragmARC.Word_Input.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Why were all of the files needed? For a program of this size, I would
> have nested the specifications in the body. (One possible reason was
> the old restriction on nesting of tagged type extensions. Ada 2005 has
> eliminated this restriction, so that particular issue will go away
> soon.)

Yes, the map instantiation was done at library level.

However, Kevin's file count appears to include all of the files in the
closure of the program, which means he's counting all the stuff in
ada.containers.*.  This isn't really fair, since he didn't count all the
myriad files in the STL.

Once the AI about nested instantiations gets approved, then the actual,
correct file count should only be 1.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes:

> Talking about removing restrictions - will Ada 2005 allow for downward
> closures (I read that the one reason for it's exclusion was a compiler
> which is no longer with us).

Yes.  The only caveat is that the procedure pointer cannot be copied.

AI-302 depends on this new feature.  For example, the passive iterator
looks like this:

procedure Iterate
  (Container : in CT;
   Process   : not null access procedure (Position : in Cursor));

There are procedures for querying and modifying the element at a
position, that look like this:

procedure Query_Element
  (Position : in Cursor;
   Process  : not null access procedure (Element : in Element_Type));

procedure Update_Element
  (Position : in Cursor;
   Process  : not null access procedure (Element : in out Element_Type));

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> > Is the intention to first store a 0 with word, and then
> > to increment the value stored at word?
> 
> My understanding is that Insert will insert a new key/value pair into
> the map if no entry exists for the given key, and outputs the iterator
> I pointing to the key/value pair for the given key.

Yes.  This behavior is identical to the C++ statements:

   typedef std::map<std::string, int> wcmap_t;

   wcmap_t wcmap;

   typedef wcmap_t::iterator iter_t;
   typedef std::pair<iter_t, bool> status_t;

   const status_t status = wcmap.insert(std::make_pair(word, 0));
   const iter_t i = status.first;
   ++i->second;
   

> > Although this will require that you know how to separate the queries
> > and commands in this abbreviation. If you are not used to how ++ and
> > [] work in the context of maps, will this still be easy to
> > understand?
> 
> The only question is whether the [] operator will create an entry if
> none exists.  Thirty seconds with the reference will confirm that it
> does, and I would expect a professional programmer to be able to
> remember that.

Yes, the index operator creates an element with its default value, if
the requested key isn't already in the map.

Note, however, that the index operator isn't completely benign.  In
fact, the index operator for map gets its own entry in Effective STL.

One thing programmers sometimes do is:

   some_map[some_key] = x;

The issue here is that the element associated with some_key gets
constructed using its default ctor, and then the object is immediately
assigned the value of x.  But it's more efficient to use the copy ctor,
but to do that you need to use the insert member function as above.

The other issue with the index operator is that if you use a (string)
literal as the key, then it's possible to misspell the value, and create
a new key accidently.

That being said, for this particular problem, the index operator is very
convenient, and entirely appropriate.

   
> > AFAIK, [] does more than one thing behind the scenes.  
> > ++ is known to be difficult to understand in that it
> > is not clear what ++ is referring to. 
> 
> Now are you claiming that C++ is hard to read because one has to learn
> the operator precedence rules?

The rule in C and C++ is that postfix operators have a higher precedence
than prefix operators.  This is the only rule that makes sense, for
example:

   struct S { int i; };

   S s = { 0 };

   ++s.i;

In this case, the operator is the "dot" operator (which isn't
user-definable).

Actually, I would have used a pointer instead:

   S* ps = &s;
   ++ps->i;

The arrow operator is postfix, so it has higher precedence than ++
(which is prefix), so the expression above increments i, not ps.

In the statement:

  ++wcmap[word];

the index operator is postfix, so that happens first.  It either returns
the element whose key is "word", or constructs a new element using the
default ctor for the type, which in this case (type int) initializes the
element to the value 0.

That last bit might be confusing, since you don't normally think of
built-in types as having a constructor.  However, type int does have a
ctor, so for example:
 
   int i;  //garbage
   int j = int::int();  //0

The existence of a default ctor for type int is why the index operator
works safely.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Brian May <bam@snoopy.apana.org.au> writes:

> The following code (or something like it), I believe (not tested),
> should reduce the line count (and complexity) of the above:
> 
> procedure Insert (Word : String) is 
>    I : Wordcount_Maps.Iterator_Type; 
>    B : Boolean; 
>   
> begin -- Insert 
>    Insert (Map, To_Lower (Word), 0, I, B); 
>    Replace_Element(I, Element(I) + 1);
> end Insert;

Yes, that's true, but the point of the original example was to show how
to modify the element in-place, as you do for C++.  

Clearly, in the case of an object of type Integer, you don't really need
to modify the object in place, and your solution above is perfectly
adequate (and simpler too).

Support for in-place modification is really provided for composition of
containers.  So for example, if you have a container whose elements are
another container, then you need in-place modification to manipulate the
(container) element.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Randy Brukardt]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4ekks60xf.fsf@snoopy.apana.org.au...
...
> The following code (or something like it), I believe (not tested),
> should reduce the line count (and complexity) of the above:
>
> procedure Insert (Word : String) is
>    I : Wordcount_Maps.Iterator_Type;
>    B : Boolean;
>
> begin -- Insert
>    Insert (Map, To_Lower (Word), 0, I, B);
>    Replace_Element(I, Element(I) + 1);
> end Insert;

I was going to post something similar, as update-in-place is a premature
optimization in this case.

As far as I can tell, all this thread proves is that it would be nice if Ada
allowed redefinition of some of the operations (as opposed to operators)
like "in" and "()". And that the overriding concern for safety in Ada makes
code a bit longer. The latter is why there aren't implicit instantiations,
and why there isn't a routine like:

    function Modify_Element (Item : in Cursor) return access Element_Type;

(Humm, the other reason was that 3.6(11) caused trouble -- but that's been
repealed. I wonder if that decision should be revisited??)

                      Randy.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I was going to post something similar, as update-in-place is a
> premature optimization in this case.

Actually, I just finished the indefinite ordered maps, and realized that
Replace_Element deallocates the old element and reallocates a new
element.  So you could make a good case that Update_Element is the
better choice here.

[OT]Screen ergonomics, was Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Anders Wirzenius]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> >> Why are printed newspapers still popular even if a lot of people
> >> have a permanent, uninterrupted Internet connection and are able to
> >> rapidly move even between several electronic newspapers?
> > Because a newspaper is a set of unrelated articles, and we read the
> > articles from beginning to end.  And we don't have to edit the
> > newspaper, just read it.  Newspaper writers and editors universally do
> > their work on a computer screen.
> 
> I don't understand this explanation.
> 
> My answer would be along these lines. On a big paper sheet there are
> different content items, or different parts of some content. You have
> to locate a part, focus on it, to read it. Same goes for the whole
> (printed) newspaper. On a small screen only one part fits. The others
> are away. So what is different is how the user locates parts. With a
> printed paper you only have to turn your eyes or head to look at a
> different part. And you can even move a sheet up/down/left/right so
> the part under inspection stays more aligned with the eyes. You cannot
> do that with a small screen. Maybe with an eyetracking system you can
> simulate that, but I doubt it will work as well.

This is exactly what I tried to explain in the metaphor about 
the reading a newspaper through a frame.

Anders

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dale Stanbrough]

Matthew Heaney wrote:

> Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes:
> 
> > Talking about removing restrictions - will Ada 2005 allow for downward
> > closures (I read that the one reason for it's exclusion was a compiler
> > which is no longer with us).
> 
> Yes.  The only caveat is that the procedure pointer cannot be copied.

How is this enforced?

> AI-302 depends on this new feature.  For example, the passive iterator
> looks like this:
> 
> procedure Iterate
>   (Container : in CT;
>    Process   : not null access procedure (Position : in Cursor));


Can you specify a type for the procedure pointer?
e.g.

   type Proc_Ptr is access procedure (Position : in Cursor);
   procedure Iterate
     (Container : in CT;
     Process    : not null Proc_Ptr);


Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Matthew Heaney wrote:

> If AI-302 doesn't meet your needs, then you need to let us know.
> Please peruse the a-c*.ad[sb] sources at the tigris website.ￜￜ(Note
> that I'm still incorporating changes from the most recent ARG
> meeting.)

I have got my most important baby (indefinite types). And I don't want to
confuse the ARG. I fully agree that we need a container library inside the
standart.

However it would be sad if Ada.Containers would kill off all other container
libraries. Just like the STL did. Im am sill looking at IBM OCL thinking
how much more practical it was. std::string might me academicly correct but
IString was a lot more usefull in day to day live with all the asInt (),
asUnsigned (), asAnythingYouEverNeed() methods.

Somtimes I am toying with the idea of recreating IString - in Ada with
exports for C and C++ so I have handy in any language I use. 

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Ole-Hjalmar Kristensen]

Pascal Obry <pascal@obry.org> writes:

> andreatta@mail.chem.sc.edu (Dan Andreatta) writes:
> 
> > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries.
> 
> And it is just unreadable ! I just can't understand how this is supposed
> to work!
> 
> Pascal.
> 

Which just shows that any sufficiently advanced technology is
indistinguishable from magic :-)

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

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Ole-Hjalmar Kristensen]

Awk/shell version, snipped from Emacs info pages:

     # Print list of word frequencies
     {
         $0 = tolower($0)    # remove case distinctions
         gsub(/[^a-z0-9_ \t]/, "", $0)  # remove punctuation
         for (i = 1; i <= NF; i++)
             freq[$i]++
     }
     
     END {
         sort = "sort +1 -nr"
         for (word in freq)
             printf "%s\t%d\n", word, freq[word] | sort
         close(sort)
     }

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Ole-Hjalmar Kristensen]

kevin.cline@gmail.com (Kevin Cline) writes:

> Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbrd60dusx0.fsf@sun.com>...
> > >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes:
> > 

<snip>

> > I usually find that my ability to create programs is limited by my
> > thought process, not my typing speed :-
> 
> Mine too.  For the Perl program, the thought process was limited to
> this:
> 
>   read input: while (<>)
> 
>   split into sequences of alphabetic characters: 
>      foreach my $word (split (/[a-zA-Z]+/))
> 
>   count words: ++$count{$word}
> 
>   sort words by frequency: sort { $map{$a} <=> $map{$b} ) keys %count
> 
>   print first 10: $n = 0; foreach ( ... ) { print ...; last if ++$n >=
> 10; }
> 
> The only bits that required much thought at all were figuring out the
> right comparison function for sorting (I looked at an example), and
> getting the loop exit right.  The rest was written nearly
> instantaneously.
> 
> Are you really claiming that you can think of:
> 
>   procedure Insert (Word : in String) is
> 
>       procedure Increment_Count
>         (K : in     String;
>          N : in out Natural) is
> 
>          pragma Warnings (Off, K);
>       begin
>          N := N + 1;
>       end Increment_Count;
> 
>       C : Wordcount_Maps.Cursor;
>       B : Boolean;
> 
>    begin -- Insert
>       Insert (M, Word, 0, C, B);
>       Update_Element (C, Increment_Count'Access);
>    end Insert;
> 
> As quickly as I can think of: 
>   ++concordance[word] 
> or
>   ++$count{$word} ?
> 

No, not at all. But I usually write programs where the logic tends to
be a bit more complicated, and where the instantiation of
templates/generics and similar boiler plate is not dominating.

> Multiply this 1000 times for a medium to large program and I think Ada
> really suffer from unnecessary verbosity.
> 
> It's reasonable to claim that Ada is better than C++ for
> safety-critical embedded programming, but if you really want to
> understand why Ada is not more popular for desktop applications I
> think the evidence is here.  The real question I have is why Perl and
> similar high-level languages are not more popular.

If I wanted something more high-level I would use Lisp, not Perl.  

Now consider the following implementation of a polygon clipper (an old
test program I had lying around to test the relative speed of a
recursive and non-recursive version of essentially the same polygon
clipper)

Do you really believe this program had been any more readable or easy
to program in C++ or Perl?

with Vector; use Vector; -- Contains basic vector and plane stuff

-- Pipelined Sutherland-Hodgson type polygon clipper
-- Pipeline implemented by recursive calls

procedure Sutherland is

   -- Polygon container
   type Vertex_Array is array(Integer range <>) of Vector3;

   -- Stage in pipeline
   type Stage is record
      Pl : Plane;    -- Clipping plane
      S : Vector3;   -- Start point
      F : Boolean := true;   -- First visit?
      Closing : Vector3; -- Closing point
   end record;

   -- 6 planes for frustum clipping
   Stages : array(1..6) of Stage;

   procedure Reset_Stages is
   begin
      for I in Stages'Range loop
         Stages(I).F := True;
      end loop;
   end Reset_Stages;

   -- Test if vertex is inside plane
   function Inside(Test_Vertex : Vector3; clip : Integer) return Boolean is
   begin
      return Inside(Test_Vertex, Stages(Clip).Pl);
   end Inside;

   -- Return intersect of vector from S to P with plane
   function Intersect(S : Vector3;
                      P : Vector3;
                      Clip : Integer ) return Vector3 is
   begin
      return Intersect(S,P,Stages(Clip).Pl);
   end Intersect;

   -- Output vertex to next stage of clipper
   procedure Output_Point(Clip_Stage : Integer; P : Vector3);

   -- Clip vertex to plane given by Clip_Stage
   procedure Clip_Vertex(Clip_Stage : Integer; P : Vector3) is
      Clipped_P : Vector3;
   begin
      -- Initialize start if first time
      if Stages(Clip_Stage).F then
         Stages(Clip_Stage).S := P;
         Stages(Clip_Stage).Closing := P;
         Stages(Clip_Stage).F := False;
      else
         if Inside(P,Clip_Stage) then
            if Inside(Stages(Clip_Stage).S,Clip_Stage) then
               Output_Point(Clip_Stage,P);
            else
               Clipped_P := Intersect(Stages(Clip_Stage).S,P,Clip_Stage);
               Output_Point(Clip_Stage,Clipped_P);
               Output_Point(Clip_Stage,P);
            end if;
         else
            if Inside(Stages(Clip_Stage).S,Clip_Stage) then
               Clipped_P := Intersect(Stages(Clip_Stage).S,P,Clip_Stage);
               Output_Point(Clip_Stage,Clipped_P);
            end if;
         end if;
         Stages(Clip_Stage).S := P;
      end if;
   end Clip_Vertex;

   -- Output vertex to next stage of clipper
   procedure Output_Point(Clip_Stage : Integer; P : Vector3) is
   begin
      if Clip_Stage >= Stages'Last then
         null; 
      else
         Clip_Vertex(Clip_Stage + 1, P);
      end if;
   end Output_Point;

   procedure Empty_Pipeline is
   begin
      for I in Stages'Range loop
         if not Stages(I).F then
            Clip_Vertex(I,Stages(I).Closing);
         end if;
      end loop;
   end Empty_Pipeline;

   -- Clip polygon by clipping each vertex in turn
   procedure Clip_Poly(In_Poly : Vertex_Array) Is
   begin
      for I in In_Poly'Range loop
         Clip_Vertex(Stages'First,In_Poly(I));
      end loop;
      Empty_Pipeline;
   end Clip_Poly;

   procedure Init_Stages is
   begin
      Reset_Stages;
      -- Front
      Stages(1).Pl := Create_Plane((0.0,0.0,0.0),
                                   (100.0,0.0,0.0),
                                   (100.0,0.0,100.0));
      -- Back
      Stages(2).Pl := Create_Plane((100.0,100.0,0.0),
                                   (0.0,100.0,0.0),
                                   (0.0,100.0,100.0));
      -- Left
      Stages(3).Pl := Create_Plane((0.0,100.0,0.0),
                                   (0.0,0.0,0.0),
                                   (0.0,0.0,100.0));
      -- Right
      Stages(4).Pl := Create_Plane((100.0,0.0,0.0),
                                   (100.0,100.0,0.0),
                                   (100.0,100.0,100.0));
      -- Bottom
      Stages(5).Pl := Create_Plane((0.0,0.0,0.0),
                                   (0.0,100.0,0.0),
                                   (100.0,100.0,0.0));
      -- Top
      Stages(6).Pl := Create_Plane((0.0,0.0,100.0),
                                   (100.0,0.0,100.0),
                                   (100.0,100.0,100.0));

   end Init_Stages;

   Test_Poly : Vertex_Array(1..3) := ((0.0,0.0,1.0),
                                      (150.0,200.0,1.0),
                                      (200.0,150.0,1.0));

begin
   Init_Stages;
   for I in 1..100000 loop
      Clip_Poly(Test_Poly);
      Reset_Stages;
   end loop;
end Sutherland;


-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
: Are you really claiming that you can think of:
: 
:  procedure Insert (Word : in String) is
: 
:      procedure Increment_Count
:        (K : in     String;
:         N : in out Natural) is
: 
:         pragma Warnings (Off, K);
:      begin
:         N := N + 1;
:      end Increment_Count;
: 
:      C : Wordcount_Maps.Cursor;
:      B : Boolean;
: 
:   begin -- Insert
:      Insert (M, Word, 0, C, B);
:      Update_Element (C, Increment_Count'Access);
:   end Insert;
: 
: As quickly as I can think of: 
:  ++concordance[word] 
: or
:  ++$count{$word} ?

Isn't the comparison at different levels? AI 302 is to be minimal, I think, 
in that every convenient operation can be built from thingies present in
Ada.Containers.

 
: Multiply this 1000 times for a medium to large program and I think Ada
: really suffer from unnecessary verbosity.

Are you saying that Ada programmers automatically don't make reusable
procudures and instead will repeat a procedure with the effect of ++ all
over the place?


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Hyman Rosen]

Matthew Heaney wrote:
> Note, however, that the index operator isn't completely benign.  In
> fact, the index operator for map gets its own entry in Effective STL.

One of the really annoying features of this operator is that due to
its behavior of creating the element if not already present, there is
no const version of the operator, and so you cannot use the natural
indexing syntax on a const map.

There have been many requests for a const version that throws an
exception if the element is not present, but you know how language
standardization committees are.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Kevin Cline <kevin.cline@gmail.com> wrote:
[body of Insert snipped]
> :  ++concordance[word] 
> : or
> :  ++$count{$word} ?
> 
> Isn't the comparison at different levels? AI 302 is to be minimal, I
> think, in that every convenient operation can be built from thingies
> present in Ada.Containers.

Yes, that's exactly right.  Which is why the comparison above should
really be:

  Insert (Word);
or
  ++concordance[word] 
or
  ++$count{$word}

Comparing the one-line C++ and Perl statements to the body of the Insert
subprogram defeats the purpose of writing the subprogam!

And the reason why we have to write the subpgram is because Ada doesn't
give you any direct way of returning a reference to variable view from a
function, as C++ does.  But even so, in Ada you can modify objets in
place (in AI-302 by using a downward closure -- which C++ doesn't have).
That's what really matters, not the syntax.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote:

> And the reason why we have to write the subpgram is because Ada doesn't
> give you any direct way of returning a reference to variable view from a
> function, as C++ does.  But even so, in Ada you can modify objets in
> place (in AI-302 by using a downward closure -- which C++ doesn't have).
> That's what really matters, not the syntax.

Syntax does not matter. What matters is an ability to express an idea in
the syntax you want. To me, the most natural syntax for modifying an array
element is A(I) := B;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Cesar Rabak]

Stephen Leake escreveu:
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> 
>>It's pretty hard to make the case that this Ada code:
>>
>>  procedure Insert (Word : String) is 
>>    I : Wordcount_Maps.Iterator_Type; 
>>    B : Boolean; 
>>    type Element_Access is access all Wordcount_Maps.Element_Subtype;
>>
>>    for Element_Access'Storage_Size use 0;
>>
>>    function To_Access is new Wordcount_Maps.Generic_Element
>>(Element_Access);
>>  
>>  begin -- Insert 
>>    Insert (Map, To_Lower (Word), 0, I, B); 
>>    declare E : Wordcount_Maps.Element_Subtype renames To_Access
>>(I).all;
>>    begin 
>>      E := E + 1; 
>>    end; 
>>  end Insert;
>>
>>is easier to understand than the corresponding C++ code:
>>  ++concordance[word];
>>
>>or the corresponding Perl code:
>>  ++$count{$word};
> 
> 
> You're kidding, right? All I need to do for the Ada code is add:
> 
> procedure "+" (Word : in String) renames Insert;
> 
> and the final user code is:
> 
> +Word;
> 
Stephen,

I think the point Kevin is trying to make� is that "++$count{$word};" is 
already built in the Perl language, whereas "procedure "+" (Word : in 
String) renames Insert;" requires we _implement_ Insert as above.

--
Cesar Rabak

[1] I'm not completely agreeing, but would like to put that in another 
thread.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cj0qlt$qkh$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> : Are you really claiming that you can think of:
> : 
> :  procedure Insert (Word : in String) is
> : 
> :      procedure Increment_Count
> :        (K : in     String;
> :         N : in out Natural) is
> : 
> :         pragma Warnings (Off, K);
> :      begin
> :         N := N + 1;
> :      end Increment_Count;
> : 
> :      C : Wordcount_Maps.Cursor;
> :      B : Boolean;
> : 
> :   begin -- Insert
> :      Insert (M, Word, 0, C, B);
> :      Update_Element (C, Increment_Count'Access);
> :   end Insert;
> : 
> : As quickly as I can think of: 
> :  ++concordance[word] 
> : or
> :  ++$count{$word} ?
> 
> Isn't the comparison at different levels? AI 302 is to be minimal, I think, 
> in that every convenient operation can be built from thingies present in
> Ada.Containers.
> 
>  
> : Multiply this 1000 times for a medium to large program and I think Ada
> : really suffer from unnecessary verbosity.
> 
> Are you saying that Ada programmers automatically don't make reusable
> procudures and instead will repeat a procedure with the effect of ++ all
> over the place?

The insert procedure is not reusable.  It is specific to
Wordcount_Maps.
To be reusable it would have to be made generic, and then it would
have to be instantiated before it could be used.

In C++ you can write ++concordance[word] because of two features
present in C++ that are missing in Ada.  C++ allows the indexing
operator [] to be overridden, so that concordance[key] can be assigned
a meaning.  Also, C++ has reference types, so that concordance[key]
can return a modifiable reference to the value, which can be
incremented.  Together, these functions allow user-defined types in
C++ to be as convenient to use as the built-in array type.

I think I made a fair comparison.  A claim was made that Ada/CHARLES
was essentially equivalent to the C++ STL.  I took an example program
written by the author of Ada/CHARLES and rewrote it in C++ and Perl. 
The C++ code was less than half as long, and the Perl code one-tenth
as long.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:3673998.bj16mkkOu2@linux1.krischik.com...
>
> I have got my most important baby (indefinite types). And I don't want to
> confuse the ARG. I fully agree that we need a container library inside the
> standard.

Well, we might be slow but we don't confuse that easily.  8^)

Seriously, if you have a comment on the API, it would be helpful to let us
know.  We have added most of the features people have asked for.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dan Andreatta]

Pascal Obry <pascal@obry.org> wrote in message news:<u6564dfge.fsf@obry.org>...
> andreatta@mail.chem.sc.edu (Dan Andreatta) writes:
> 
> > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries.
> 
> And it is just unreadable ! I just can't understand how this is supposed
> to work!
> 
> Pascal.

I understand. Functional languages require a change in prospective.
But also I made unreadable to have a less lines :-). Hope now you find
it more readable.

Here is slightly rewritten:

module Main where

import Data.FiniteMap
import Data.List
import System
import Char

count_words :: [String] -> [(String, Integer)]
count_words ws = wc
    where
    comp (_,n) (_,m) = compare m n -- used in sortBy to sort 
                                   -- the values, not keys
    ws' = zip ws [1,1..] -- creates a list [("word",1),("word",1)...]
    -- In functional languages the hash table is substituted with a
    -- finite map
    -- emptyFM creates an empty finite map
    -- addToFM adds an element in the form (key, value) to a
    --   finite map. If the element already exists,
    --   it is replaced by the new one.
    -- addListToFM adds a list of elements, 
    --   [(key, value), (key, value)...]
    -- addListToFM_C instead applies an operation (e.g. +) between 
    --   the values of the old and new elements with the same key.
    --   Since every key has value 1,
    --   we count the number of keys in the list.
    fm  = addListToFM_C (+) emptyFM  ws'
    list = fmToList fm -- Creates a list from the finite map in the
                       -- form [(key,value)], with the keys ordered.
    wc = sortBy comp list -- sort the list in ascending order
                          -- of the values.

-- this to take care of alphanumeric symbols.
-- Replace them with spaces.
removeSymbol x = if isAlphaNum x then x else ' '
 
main = do
       args <- getArgs   -- get the command line arguments as
                         -- a list of strings.
       f <- readFile (args!!0) -- the first one is the one we want. 
                               -- And read the whole file and
                               -- return a String
       let f1 = map (removeSymbol.toLower) f 
                       -- convert to lowercase and substitue spaces
                       -- for symbols. For every character, convert
                       -- it to lowercase and remove it if a symbol
       let f2 = words f1 -- divide the string in a list of strings
       let wc = count_words f2
       let wc10 = take 10 wc -- take only the first ten elements
       putStrLn ( show wc10 ) -- and print them

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dan Andreatta]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbr1xgsnl2u.fsf@ellex06.Norway.Sun.COM>...
> Pascal Obry <pascal@obry.org> writes:
> 
> > andreatta@mail.chem.sc.edu (Dan Andreatta) writes:
> > 
> > > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries.
> > 
> > And it is just unreadable ! I just can't understand how this is supposed
> > to work!
> > 
> > Pascal.
> > 
> 
> Which just shows that any sufficiently advanced technology is
> indistinguishable from magic :-)
> 

Can I take that as a compliment? ;-)
(When I was a kid I wanted to be a magician)

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
:> Are you saying that Ada programmers automatically don't make reusable
:> procudures and instead will repeat a procedure with the effect of ++ all
:> over the place?
: 
: The insert procedure is not reusable.  It is specific to
: Wordcount_Maps.

OK. But Insert is not the effect of ++, which is what is had been
thinking about.

: I took an example program
: written by the author of Ada/CHARLES and rewrote it in C++ and Perl. 
: The C++ code was less than half as long, and the Perl code one-tenth
: as long.

Well, if it besides the reference issue all boils down to "shorter
code is better", Ada is verbose, then I think I can stay with some
verbosity. There are far too many neat idioms to remember once I have
to use more than one or two languages every other day.


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Mark Lorenzen]

Hyman Rosen <hyrosen@mail.com> writes:

> Matthew Heaney wrote:
> > Note, however, that the index operator isn't completely benign.  In
> > fact, the index operator for map gets its own entry in Effective STL.
> 
> One of the really annoying features of this operator is that due to
> its behavior of creating the element if not already present, there is
> no const version of the operator, and so you cannot use the natural
> indexing syntax on a const map.

Absolutely. I actually just learned this today while reading the STL
reference manual a bit more carefully than just browsing it, and I was
surprised about this fact.

> 
> There have been many requests for a const version that throws an
> exception if the element is not present, but you know how language
> standardization committees are.

Which is why I am a bit worried that AI 302 only defines the minimal
set of operations.

Regards,
- Mark Lorenzen

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message
news:m3acvfblun.fsf@0x50a5b1a2.boanxx18.adsl-dhcp.tele.dk...
> Hyman Rosen <hyrosen@mail.com> writes:
>
> > There have been many requests for a const version that throws an
> > exception if the element is not present, but you know how language
> > standardization committees are.
>
> Which is why I am a bit worried that AI 302 only defines the minimal
> set of operations.

Hmmm... There is no direct equivalent to the index operator in the STL map
in AI-302, so it's not as if AI-302 is "missing" the const version of that
operator, since it doesn't have that operator at all.  (The 5-parameter
Insert operation provides the same functionality, but not the same syntax,
as the index operator.)

What operations would you like AI-302 to provide, that you think are
missing?  It would help the designers of that library if you could be more
specific.  Otherwise we can't help you.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Pascal Obry]

andreatta@mail.chem.sc.edu (Dan Andreatta) writes:

> I understand. Functional languages require a change in prospective.
> But also I made unreadable to have a less lines :-). Hope now you find
> it more readable.

Let's say a very little bit more :)

Pascal.

-- 

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

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<mOednXIrZJxIBM7cRVn-uQ@megapath.net>...
> "Brian May" <bam@snoopy.apana.org.au> wrote in message
> news:sa4ekks60xf.fsf@snoopy.apana.org.au...
> ...
> > The following code (or something like it), I believe (not tested),
> > should reduce the line count (and complexity) of the above:
> >
> > procedure Insert (Word : String) is
> >    I : Wordcount_Maps.Iterator_Type;
> >    B : Boolean;
> >
> > begin -- Insert
> >    Insert (Map, To_Lower (Word), 0, I, B);
> >    Replace_Element(I, Element(I) + 1);
> > end Insert;
> 
> I was going to post something similar, as update-in-place is a premature
> optimization in this case.
> 
> As far as I can tell, all this thread proves is that it would be nice if Ada
> allowed redefinition of some of the operations (as opposed to operators)
> like "in" and "()". And that the overriding concern for safety in Ada makes
> code a bit longer.  

Again, the original question was "Why isn't Ada more popular?"  

The answer I am giving is that most programmers don't have such an
overriding concern for safety that they are willing to write twice as
much code to get the additional safety.

> The latter is why there aren't implicit instantiations,
> and why there isn't a routine like:
> 
>     function Modify_Element (Item : in Cursor) return access Element_Type;

Ok, although it's not readily apparent to me why implicit
instantiations are inherently unsafe.  Nor do I believe reference
expressions like
   concordance[word] 
are inherently unsafe.  Storing the reference in a variable that may
outlive the referent is unsafe, but I don't see why this is different
from Ada access types.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<3673998.bj16mkkOu2@linux1.krischik.com>...
> Matthew Heaney wrote:
> 
> > If AI-302 doesn't meet your needs, then you need to let us know.
> > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note
> > that I'm still incorporating changes from the most recent ARG
> > meeting.)
> 
> I have got my most important baby (indefinite types). And I don't want to
> confuse the ARG. I fully agree that we need a container library inside the
> standart.
> 
> However it would be sad if Ada.Containers would kill off all other container
> libraries. Just like the STL did. 

I think the STL killed off all the other container libraries because
the STL container/algorithm separation is an extremely powerful design
that dominates all older container library designs.  Certainly STL
programming is much cleaner and easeir than programming with the once
popular RogueWave containers.  The STL also has the advantage that it
is relatively easy to write new containers that will work with the STL
algorithms, so that even though new containers are written, they all
look like STL containers.
 
> Im am sill looking at IBM OCL thinking
> how much more practical it was. std::string might me academicly correct but
> IString was a lot more usefull in day to day live with all the asInt (),
> asUnsigned (), asAnythingYouEverNeed() methods.

The problem with that design is that it isn't readily extensible to
accomodate user-defined types, and it makes generic programming very
difficult.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Eric Jacoboni <jaco@neottia.net> wrote in message news:<m2ekkspza5.fsf@mac.scrogneugneu.org>...
> Pascal Obry <pascal@obry.org> writes:
> 
> > And it is just unreadable ! I just can't understand how this is supposed
> > to work!
> 
> Agree... 
> 
> What about Ruby ? Much more readable than perl/python, imho. 

The Ruby implementation lines up with the Perl code almost token for
token,
except that I used the Perl <> operator, and I didn't bother storing
the sort result in a variable.

I agree that Ruby is slightly more readable than Perl, but I don't
know about MUCH more readable.  I think the use of %, @, and $ in Perl
is not obvious, and the <> operator is pretty magical, but the rest of
the code seems straightforward.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Frank J. Lhota]

"Matthew Heaney" <mheaney@on2.com> wrote in message 
news:41547dae$0$91007$39cecf19@news.twtelecom.net...
> Note that (as Randy alluded to) there's still a chance the ARG will add
> something like reference types to Ada.  It would be declared something 
> like:
>
>   function Update_Element
>     (Container : in Map;
>      Key         : in  Key_Type) return access Element_Type;
>
> Then you could say:
>
>   Update_Element (M, K).all := 42;

I still like the idea of adding "()" and "():=" operators to Ada. Then you 
could say:

    M(K) := 42;

This is clearer, and it makes absolutely no assertions as to how containers 
represent their elements.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409240828.53001e66@posting.google.com...
>
> In C++ you can write ++concordance[word] because of two features
> present in C++ that are missing in Ada.  C++ allows the indexing
> operator [] to be overridden, so that concordance[key] can be assigned
> a meaning.  Also, C++ has reference types, so that concordance[key]
> can return a modifiable reference to the value, which can be
> incremented.  Together, these functions allow user-defined types in
> C++ to be as convenient to use as the built-in array type.

Note that (as Randy alluded to) there's still a chance the ARG will add
something like reference types to Ada.  It would be declared something like:

   function Update_Element
     (Container : in Map;
      Key         : in  Key_Type) return access Element_Type;

Then you could say:

   Update_Element (M, K).all := 42;

In our wordcount example you'd have to say:

declare
   N : Natural renames Update_Element (M, K).all;
begin
   N := N + 1;
end;

Note that it would possible to get the automatic insertion behavior too, by
passing the container as an access parameter:

   function Update_Element
    (Container : access Map;
     Key         : in Key_Type) return access Element_Type;

and then say:

declare
   N : Natural renames Update_Element (M'Access, K).all;
begin
   N := N + 1;
end;

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uu0tob9on.fsf@earthlink.net>...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
> > Why were all of the files needed? For a program of this size, I would
> > have nested the specifications in the body. (One possible reason was
> > the old restriction on nesting of tagged type extensions. Ada 2005 has
> > eliminated this restriction, so that particular issue will go away
> > soon.)
> 
> Yes, the map instantiation was done at library level.
> 
> However, Kevin's file count appears to include all of the files in the
> closure of the program, which means he's counting all the stuff in
> ada.containers.*.  This isn't really fair, since he didn't count all the
> myriad files in the STL.

I only counted the files in examples/wordcount_vector.  The first
version I saw had a main body and eight specification files.  The
current version has a main body and two specification files.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Randy Brukardt]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409241112.44f4bc85@posting.google.com...
...
> Ok, although it's not readily apparent to me why implicit
> instantiations are inherently unsafe.  Nor do I believe reference
> expressions like
>    concordance[word]
> are inherently unsafe.  Storing the reference in a variable that may
> outlive the referent is unsafe, but I don't see why this is different
> from Ada access types.

It isn't different than Ada access types, that's the point. Access types are
inherently unsafe and should be avoided when possible. (But not to go
overboard, of course.)

That's an important design issue when designing reusable libraries. My
personal rule is that such libraries should not contain access types of any
kind in their specification unless they are doing something that requires
dynamic management of objects. (That's rather rare.) In Ada, there is no
need to use access types to get OOP or to get objects sized at runtime --
those uses are common in other languages.

Ada goes to fairly great lengths to try to avoid dangling pointers (the
dreaded accessibility rules), so access types in Ada are a bit safer than
those in some other languages. But that doesn't make them safe by any means.

In this particular case, the access would have roughly the same erroneous
use rules as a cursor does, which wouldn't be that awful. But it wouldn't be
a very good example of Ada design, because the library would return an
access to a data structure that is managed by other code -- which cannot
know whether any accesses remain -- so it would be impossible to be safe.
(I'm intending an implementation of the containers library that will try to
detect dangling cursors, so there will be little chance of building buggy
code with it.)

                                 Randy.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Randy Brukardt]

"Dale Stanbrough" <MrNoSpam@bigpoop.net.au> wrote in message
news:MrNoSpam-4FAA69.16322324092004@news-server.bigpond.net.au...
> Matthew Heaney wrote:
>
> > Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes:
> >
> > > Talking about removing restrictions - will Ada 2005 allow for downward
> > > closures (I read that the one reason for it's exclusion was a compiler
> > > which is no longer with us).
> >
> > Yes.  The only caveat is that the procedure pointer cannot be copied.
>
> How is this enforced?

Via accessibility. The accessibility of an anonymous access-to-subprogram
used as a parameter is infinite, so you can put anything into it (of
course), but you are not allowed to convert to another type (unless it too
is anonymous access-to-subprogram used as a parameter).

> > AI-302 depends on this new feature.  For example, the passive iterator
> > looks like this:
> >
> > procedure Iterate
> >   (Container : in CT;
> >    Process   : not null access procedure (Position : in Cursor));
>
>
> Can you specify a type for the procedure pointer?
> e.g.
>
>    type Proc_Ptr is access procedure (Position : in Cursor);
>    procedure Iterate
>      (Container : in CT;
>      Process    : not null Proc_Ptr);

You can do that, but you get the Ada 95 accessibility rules. That's
necessary as access-to-subprogram is often used to interface to C or other
foreign code, and thus those types must be implementable as thin pointers
(just a subprogram address for most targets). An anonymous
access-to-subprogram used as a parameter will need to be some sort of fat
structure including a display or static link (and, for Janus/Ada and other
generic sharing implementations, a generic instance descriptor) along with
the subprogram address. You can go from thin to fat by creating the needed
structures based on the type, but you can't go the other way (because you
can't call a nested routine without all the stuff in the structure).

("not null" is optional of course; if you want to be able to pass null for
some meaning. I use this sort of structure for debugging logging routines in
my spam filter; I pass null to mean "don't log anything". So I'd omit the
"not null" in that case.)

                     Randy.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:sOudnSKh7rXbFMncRVn-jg@megapath.net...
>
> (I'm intending an implementation of the containers library that will try
to
> detect dangling cursors, so there will be little chance of building buggy
> code with it.)

Actually, I had wanted to build something similar for AI-302, once the work
on the reference implementation settles down.  There are after-market STLs
like that, and it wouldn't be hard to build a debug-version of AI-302 for
Ada.

All you'd need to do to detect dangling cursors is to implement type Cursor
as a private derivation from Controlled, and then add a reference count to
the internal storage node.  If that element (node) is deleted, then you
could inspect the reference count to see if it's non-zero.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Eric Jacoboni]

kevin.cline@gmail.com (Kevin Cline) writes:


> The Ruby implementation lines up with the Perl code almost token for
> token, except that I used the Perl <> operator, and I didn't bother
> storing the sort result in a variable.

Of course, as Ruby is a language of the same high level as Perl. The
Perl/Ruby code sticks with the "natural" algorithm to count
words... There's no much ways to achieve this problem. The most natural
could be "Hey, count the different word of these files" but,
unfortunately, it could be done like that (when it will be possible,
well, we have to choose another job).

> I agree that Ruby is slightly more readable than Perl, but I don't
> know about MUCH more readable.  I think the use of %, @, and $ in Perl
> is not obvious, and the <> operator is pretty magical, but the rest of
> the code seems straightforward.

For what i know, Ruby code is /always/ more readable than Perl code,
for the same level of abstraction. If you can see the difference in
this simple example, imagine for scripts of hundred and hundred
lines... Readibility, that's my point.

Back to Ada, i'm agree with you, your Ada code is not very readable :
it's to "heavy", but perhaps because Charles is not adequate here ? I
wonder if using such "small" packages as gnat.htable could be more
appropriate for this particular example. I'm not fond of always using
the same libs for different things. But i admit i don't know Charles
very well.
-- 
�ric Jacoboni, n� il y a 1399514759 secondes

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Simon Wright]

Wow! That will take some time to digest ..

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Kevin Cline wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote in message
> news:<3673998.bj16mkkOu2@linux1.krischik.com>...
>> Matthew Heaney wrote:
>> 
>> > If AI-302 doesn't meet your needs, then you need to let us know.
>> > Please peruse the a-c*.ad[sb] sources at the tigris website.ￜￜ(Note
>> > that I'm still incorporating changes from the most recent ARG
>> > meeting.)
>> 
>> I have got my most important baby (indefinite types). And I don't want to
>> confuse the ARG. I fully agree that we need a container library inside
>> the standart.
>> 
>> However it would be sad if Ada.Containers would kill off all other
>> container libraries. Just like the STL did.
> 
> I think the STL killed off all the other container libraries because
> the STL container/algorithm separation is an extremely powerful design
> that dominates all older container library designs. Certainly STL 
> programming is much cleaner and easeir than programming with the once
> popular RogueWave containers.  The STL also has the advantage that it
> is relatively easy to write new containers that will work with the STL
> algorithms, so that even though new containers are written, they all
> look like STL containers.

No Library is perfect, but the "I which I had" list for the STL is much
larger then for container out of IBM's OCL. The OCL was not designed for
academic correctness bit but for usability.

>> Im am sill looking at IBM OCL thinking
>> how much more practical it was. std::string might me academicly correct
>> but IString was a lot more usefull in day to day live with all the asInt
>> (), asUnsigned (), asAnythingYouEverNeed() methods.
> 
> The problem with that design is that it isn't readily extensible to
> accomodate user-defined types, and it makes generic programming very
> difficult.

In 99.99% of all cases I don't need strings on user defined types. I need
base_string<char>. I can see that I one day might need
base_string<wchar_t>, but I have not until now. They made all that funky
design which I just never need. And for that:

int
string::asInt();
  throw (bad_value);

and 

explicit
string::string (int value)
   throw();

are missing. Two functions I am missing on daily basis. Sure, I am an
experienced programmer, I can do that myself - but a proper library should
have all the function one need on a daily basis.

And they could have had both:

class string:
public: base_string<char>
  {
  public:

  int
  string::asInt()
    throw (bad_value);

  explicit
  string (int value)
     throw();
  }

Would have been so easy, so usefull but it would not have been a template.
The "all is template" religion got in there way.

And just for the record: atio is a C function - you need the overhead of
convertion the std::string into a char* and std::strstream seem quite heavy
weight for just a simple task of convertion a string from and to an int.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Hyman Rosen wrote:

> Matthew Heaney wrote:
>> Note, however, that the index operator isn't completely benign.  In
>> fact, the index operator for map gets its own entry in Effective STL.
> 
> One of the really annoying features of this operator is that due to
> its behavior of creating the element if not already present, there is
> no const version of the operator, and so you cannot use the natural
> indexing syntax on a const map.

But the other option is just as bad: the operator [] from std::vector does
not create new objects, hence you can't use operator [] to fill a vector.

I just change from std::vector <...> to a std::map<int,...> for that very
reason.

So more I work with the STL so more I bloody hate it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote:
> 
>> And the reason why we have to write the subpgram is because Ada doesn't
>> give you any direct way of returning a reference to variable view from a
>> function, as C++ does.  But even so, in Ada you can modify objets in
>> place (in AI-302 by using a downward closure -- which C++ doesn't have).
>> That's what really matters, not the syntax.
> 
> Syntax does not matter. What matters is an ability to express an idea in
> the syntax you want. To me, the most natural syntax for modifying an array
> element is A(I) := B;

True. But only if it works. I just had some fun reading the fineprint from
std::vector::operator [] (can not insert new elements - and at least the MS
version crashes deep inside library code when you try) and
std::map::operator [] (no const version). If it does not work as expected I
rather live without and use an Insert () which then does work as expected.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cj0qlt$qkh$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> : Are you really claiming that you can think of:
> : 
> :  procedure Insert (Word : in String) is
> : 
> :      procedure Increment_Count
> :        (K : in     String;
> :         N : in out Natural) is
> : 
> :         pragma Warnings (Off, K);
> :      begin
> :         N := N + 1;
> :      end Increment_Count;
> : 
> :      C : Wordcount_Maps.Cursor;
> :      B : Boolean;
> : 
> :   begin -- Insert
> :      Insert (M, Word, 0, C, B);
> :      Update_Element (C, Increment_Count'Access);
> :   end Insert;
> : 
> : As quickly as I can think of: 
> :  ++concordance[word] 
> : or
> :  ++$count{$word} ?
> 
> Isn't the comparison at different levels? AI 302 is to be minimal, I think, 
> in that every convenient operation can be built from thingies present in
> Ada.Containers.

> 
>  
> : Multiply this 1000 times for a medium to large program and I think Ada
> : really suffer from unnecessary verbosity.
> 
> Are you saying that Ada programmers automatically don't make reusable
> procudures and instead will repeat a procedure with the effect of ++ all
> over the place?

Well, if C++ had no operator++ it would be easy enough to write:
    template <class T> T preincrement(T& value)
    {
       value = value + 1;
       return value;
    }

You could write a generic function in Ada, except that it couldn't
return a value, and you would have to instantiate it for every type
you wanted to increment.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Eric Jacoboni <jaco@neottia.net> wrote in message news:<m2llezjj4t.fsf@mac.scrogneugneu.org>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> 
> > The Ruby implementation lines up with the Perl code almost token for
> > token, except that I used the Perl <> operator, and I didn't bother
> > storing the sort result in a variable.
> 
> Of course, as Ruby is a language of the same high level as Perl. The
> Perl/Ruby code sticks with the "natural" algorithm to count
> words... There's no much ways to achieve this problem. The most natural
> could be "Hey, count the different word of these files" but,
> unfortunately, it could be done like that (when it will be possible,
> well, we have to choose another job).
> 
> > I agree that Ruby is slightly more readable than Perl, but I don't
> > know about MUCH more readable.  I think the use of %, @, and $ in Perl
> > is not obvious, and the <> operator is pretty magical, but the rest of
> > the code seems straightforward.
> 
> For what i know, Ruby code is /always/ more readable than Perl code,
> for the same level of abstraction. If you can see the difference in
> this simple example, imagine for scripts of hundred and hundred
> lines... Readibility, that's my point.

I don't think it's all that important for code to be readable by
someone with little experience in the language.  It's nice if nothing
else is sacrificed, but  programmers don't remain novices for long. 
That said, I'm not arguing that Perl is better than Ruby.

> 
> Back to Ada, i'm agree with you, your Ada code is not very readable :

I'm not the author.  The Ada code was written by Matthew Heaney, the
author of Charles.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message news:<mailman.76.1095975168.390.comp.lang.ada@ada-france.org>...
> Kevin Cline wrote:
> 
> > The real question I have is why Perl and
> > similar high-level languages are not more popular.
> Perl has its own great competitor - Visual Basic (and to some degree Delphi
> and some others, which also provide nice buttons and other GUI components)

I have written a lot of Perl and some Visual Basic, and Visual Basic
is not much of a competitor to Perl.  Perl is fully reflexive and
quite extensible, although some of the extension mechanisms are a bit
arcane.  By comparison with Perl, Visual Basic is completely
inextensible.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uk6ukb74c.fsf@earthlink.net>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> > > Is the intention to first store a 0 with word, and then
> > > to increment the value stored at word?
> > 
> > My understanding is that Insert will insert a new key/value pair into
> > the map if no entry exists for the given key, and outputs the iterator
> > I pointing to the key/value pair for the given key.
> 
> Yes.  This behavior is identical to the C++ statements:
> 
>    typedef std::map<std::string, int> wcmap_t;
> 
>    wcmap_t wcmap;
> 
>    typedef wcmap_t::iterator iter_t;
>    typedef std::pair<iter_t, bool> status_t;
> 
>    const status_t status = wcmap.insert(std::make_pair(word, 0));
>    const iter_t i = status.first;
>    ++i->second;
>    
> 
> > > Although this will require that you know how to separate the queries
> > > and commands in this abbreviation. If you are not used to how ++ and
> > > [] work in the context of maps, will this still be easy to
> > > understand?
> > 
> > The only question is whether the [] operator will create an entry if
> > none exists.  Thirty seconds with the reference will confirm that it
> > does, and I would expect a professional programmer to be able to
> > remember that.
> 
> Yes, the index operator creates an element with its default value, if
> the requested key isn't already in the map.
> 
> Note, however, that the index operator isn't completely benign.  In
> fact, the index operator for map gets its own entry in Effective STL.
> 
> One thing programmers sometimes do is:
> 
>    some_map[some_key] = x;
> 
> The issue here is that the element associated with some_key gets
> constructed using its default ctor, and then the object is immediately
> assigned the value of x.  But it's more efficient to use the copy ctor,
> but to do that you need to use the insert member function as above.
> 
> The other issue with the index operator is that if you use a (string)
> literal as the key, then it's possible to misspell the value, and create
> a new key accidently.
> 
> That being said, for this particular problem, the index operator is very
> convenient, and entirely appropriate.
> 
>    
> > > AFAIK, [] does more than one thing behind the scenes.  
> > > ++ is known to be difficult to understand in that it
> > > is not clear what ++ is referring to. 
> > 
> > Now are you claiming that C++ is hard to read because one has to learn
> > the operator precedence rules?
> 
> The rule in C and C++ is that postfix operators have a higher precedence
> than prefix operators.  This is the only rule that makes sense, for
> example:
> 
>    struct S { int i; };
> 
>    S s = { 0 };
> 
>    ++s.i;
> 
> In this case, the operator is the "dot" operator (which isn't
> user-definable).
> 
> Actually, I would have used a pointer instead:
> 
>    S* ps = &s;
>    ++ps->i;

Most C++ programmers would not.  Modern practice is to avoid naked
pointers when possible, which for me is almost all the time.  Pointers
are needed only for low -level programming, like building a new type
of container.  The rest of the time you can use auto_ptr or some other
smart pointer type.

Anyway, the arrow and dot operators have the same precedence, so I
don't see why you would prefer ++ps->i to ++s.i.  I find ++ps->i to be
more confusing, since a pointer can be incremented, so it would be
possible to read (++ps)->i.  A reference can not be incremented, so
there is only one reasonable interpretation of ++s.i.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Matthew Heaney" <mheaney@on2.com> wrote in message news:<41547dae$0$91007$39cecf19@news.twtelecom.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0409240828.53001e66@posting.google.com...
> >
> > In C++ you can write ++concordance[word] because of two features
> > present in C++ that are missing in Ada.  C++ allows the indexing
> > operator [] to be overridden, so that concordance[key] can be assigned
> > a meaning.  Also, C++ has reference types, so that concordance[key]
> > can return a modifiable reference to the value, which can be
> > incremented.  Together, these functions allow user-defined types in
> > C++ to be as convenient to use as the built-in array type.
> 
> Note that (as Randy alluded to) there's still a chance the ARG will add
> something like reference types to Ada.  It would be declared something like:
> 
>    function Update_Element
>      (Container : in Map;
>       Key         : in  Key_Type) return access Element_Type;
> 
> Then you could say:
> 
>    Update_Element (M, K).all := 42;
> 
> In our wordcount example you'd have to say:
> 
> declare
>    N : Natural renames Update_Element (M, K).all;
> begin
>    N := N + 1;
> end;
> 
> Note that it would possible to get the automatic insertion behavior too, by
> passing the container as an access parameter:
> 
>    function Update_Element
>     (Container : access Map;
>      Key         : in Key_Type) return access Element_Type;
> 
> and then say:
> 
> declare
>    N : Natural renames Update_Element (M'Access, K).all;
> begin
>    N := N + 1;
> end;

One of the most frustrating things I found in Ada programming was the
inability to make user-defined types work like the built-in types. 
Given

  A: array (1..10) of integer;

then the expression A(5) is a modifiable reference to the fifth
element of A.

After experience with C++ it was amazingly frustrating to learn that
there was no way I could define My_Container so that I could write:

  C: My_Container ;

  C(5) := 7;

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<13bv1aau5q9ht.1fr6ixcdql72.dlg@40tude.net>...
> On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote:
> 
> > And the reason why we have to write the subpgram is because Ada doesn't
> > give you any direct way of returning a reference to variable view from a
> > function, as C++ does.  But even so, in Ada you can modify objets in
> > place (in AI-302 by using a downward closure -- which C++ doesn't have).
> > That's what really matters, not the syntax.
> 
> Syntax does not matter. What matters is an ability to express an idea in
> the syntax you want. To me, the most natural syntax for modifying an array
> element is A(I) := B;

This is how I develop C++ code.  I start programming at a high-level,
writing code in the syntax I want to use.  Then I write the code to
support the syntax.  This works pretty well until I want to do
something like overload ".".  So far I haven't thought of doing that,
but after messing with boost::lambda, I can see why one would.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Marius Amado Alves <amado.alves@netcabo.pt> wrote in message news:<mailman.73.1095966095.390.comp.lang.ada@ada-france.org>...
> >>Why are printed newspapers still popular even if a lot of 
> >>people have a permanent, uninterrupted Internet connection 
> >>and are able to rapidly move even between several 
> >>electronic newspapers?
> > 
> > Because a newspaper is a set of unrelated articles, and we read the
> > articles from beginning to end.  And we don't have to edit the
> > newspaper, just read it.  Newspaper writers and editors universally do
> > their work on a computer screen.
> 
> I don't understand this explanation.
> 
> My answer would be along these lines. On a big paper sheet there are 
> different content items, or different parts of some content. You have to 
> locate a part, focus on it, to read it. Same goes for the whole 
> (printed) newspaper. On a small screen only one part fits. The others 
> are away. So what is different is how the user locates parts. With a 
> printed paper you only have to turn your eyes or head to look at a 
> different part. And you can even move a sheet up/down/left/right so the 
> part under inspection stays more aligned with the eyes. You cannot do 
> that with a small screen. Maybe with an eyetracking system you can 
> simulate that, but I doubt it will work as well.

That explains why it's easier to read linear text from a printed page.
 Programs aren't linear text -- they have a complex structure, and
aren't read from beginning to end.  That is why most programmers
prefer to work with code via a screen editor.  It's been a long time
since I've seen a programmer work from listings.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi!

(Sorry for mixing quotations of your post, it was easier for me to respond
this way).

> In 99.99% of all cases I don't need strings on user defined types. I need
> base_string<char>. I can see that I one day might need
> base_string<wchar_t>, but I have not until now. They made all that funky
> design which I just never need.

    And the best thing is that if you don't need it, you don't have to use
it. Yet still there is this 0.01% of cases when this approach is extremely
useful because of its flexibility. E.g. when you want a class of
case-insensitive strings - you just reuse the basic string template like
this:

//class defining character traits
class my_char_traits: public std::char_traits<char>
{
  //here you just redefine simple comparison
  //functions like eq() to be case-insensitive
};

//case-insensitive string class
typedef std::basic_string<char, my_char_traits> cis_string;

> Would have been so easy, so usefull but it would not have been a template.
> The "all is template" religion got in there way.

    Actually you might not even know that std::string is a typedef of
template instantiation and still use it as if nothing had happened.
    And compare this example to creating completely new string class just
because you want this small difference in behaviour - and you have an
explanation for making everything a template. :-) Similar results could be
achieved using polymorphysm, but the "template religion" has got one great
advantage - all the binding is done during compilation, and moreover many
functions are inlined (!) - this allows a performance during runtime other
approaches couldn't have...

> And for that:
>
> int
> string::asInt();
>  throw (bad_value);
>
> and
>
> explicit
> string::string (int value)
>   throw();
>
> are missing. Two functions I am missing on daily basis. Sure, I am an
> experienced programmer, I can do that myself - but a proper library should
> have all the function one need on a daily basis.

    std::string doesn't have int conversion functions, because it's not its
job to do this. Maybe you don't see the whole idea of the design of C++
standard library. It's goal is to divide responsibility for diffrent
features between separate parts of library - that's where it's flexibility
and extensibility comes from.

> And just for the record: atio is a C function - you need the overhead of
> convertion the std::string into a char* and std::strstream seem quite
> heavy
> weight for just a simple task of convertion a string from and to an int.

    Actually, the overhead of conversion is virtually none (at least in
Stlport implementation). You just call std::string::c_str() which just
returns a pointer to the data, and which is also inlined.

    If you need string-to-int conversion and vice-versa, then it's the job
of std::stringstream (std::strstream is obsolete...) - there's a very easy
way to do this:

/********************************************/

#include <string>
using std::string;

#include <sstream>
typedef std::ostringstream oss;
typedef std::istringstream iss;

int i = 4;
string MyString("2");



//step-by-step:

void f() {

  //instead of std::string::fromInt(int)
  oss MyOutputStream;
  MyOutputStream << i;
  MyString = MyOutputStream.str();

  //instead of std::string::toInt()
  iss MyInputStream;
  MyInputStream.str(MyString);
  MyInputStream >> i;

} //f()



//same things as one-liners:

void g() {

  MyString = static_cast<oss &>(oss() << i).str();
  iss(MyString) >> i;

} //g()



//you may also define two simple functions to do this for you:

inline string ToString(int i)
{
  return static_cast<oss &>(oss() << i).str();
} //ToString()

inline int ToInt(const string & s)
{
  int i;
  iss(s) >> i;
  return i;
} //ToInt()

void h() {

  //couldn't be simplier ;-)
  MyString = ToString(i);
  i = ToInt(MyString);

} //h()

/********************************************/

    Most compilers will optimise away the initialisations etc., so in this
case you don't have to worry about the overhead.
    But if you really can't live without this ability in the string class,
then nothing stands on a way to extend std::string with these two functions
using inheritance (note, however, that you will also have to re-implement
constructors you want to use. Constructor inheritance is not a part of
standard C++ yet).

    C++ is not that evil, you just have to switch your mind to a different
way of thinking to understand it well... ;-) It *is* difficult, but once you
feel it, it gives you a lot of abilities. Please don't understand me wrong -
I don't claim I'm some kind of C++ guru, and the following is just my
general opinion, not an answer for your particular post. Why I think many
people think of C++ as so dangerous and letting you easily shoot your foot
is that unfortunately not many people know it as well as they should to use
it properly. I mean C++ is not a "toy language" - if you want something
easy, use Java. But be prepared for many limitations and restrictions (which
are there for your own good, but if you exactly know what you are doing,
they are inconvenient).
    I also don't say C++ is better than Ada - it depends on how a programmer 
is familiar with those languages and how effectively can write good, safe 
programs using them. Of course C++ forces to learn more to write such 
programs, but in turn provides you with much more flexibility and 
usefulness.

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Jacob Sparre Andersen]

Kevin Cline wrote:

> As promised in the Ada popularity thread, I have taken one of the
> Charles examples and reimplemented it in C++.  I used only the
> standard C++ language and libraries.  The Ada/CHARLES main program
> body is 118 (non-blank) lines of code, plus an additional 40 lines
> of instantiations in eight other specification files, for a total of
> 158 lines and 9 files.  The C++ implementation is 76 (non-blank)
> lines of code in a single file.  For grins, I also wrote the program
> in Perl.  That took 14 lines.
> 
> Summary:
> 
> Ada/Charles 158 lines, 9 files
> C++         76 lines
> Perl        14 lines

If we really have to compete about the shortest implementation, then
Bash with GNU tools beats all these languages:

   tr -c 'A-Za-z' '\n' | grep -v '^$' | sort | uniq -c | sort -nr | head

And I suppose that anybody with a minimum of knowledge of Bash and the
GNU tools will understand this immediately.

But does that tell us that Bash is an excellent tool for controlling
nuclear reactors, medical equipment, or just plain bioinformatics
software?

At most it tells us that if you just want to count words, Bash is
probably a better implementation language than Ada, C++ or Perl.

Jacob

PS: The Bash version is also rather easy to internationalize.  Just
    substitute 'A-Za-z' with '[[:lower:][:upper:]]'.
-- 
LDraw.org Parts Tracker FAQ:
               http://www.ldraw.org/library/tracker/ref/faq/

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Jacob Sparre Andersen]

Eric Jacoboni wrote:

> for a_file in ARGF do
>   for a_line in a_file do
>     for a_word in a_line.split(/[^A-Za-z]+/) do
>         count[a_word.downcase] += 1
>     end # for a_word 
>   end # for a_line
> end # for a_file

That's reasonably readable.  Probably easier to read than the Bash
one-liner that I usually use for this purpose.  Maybe it is worthwhile
to look a bit at Ruby for text processing.

Jacob
-- 
"Any newsgroup where software developers hang out is
 an Emacs newsgroup."

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> > Back to Ada, i'm agree with you, your Ada code is not very readable :
> 
> I'm not the author.  The Ada code was written by Matthew Heaney, the
> author of Charles.

The ARG is bandying about the idea of allowing functions to return an
anonymous access type, something like:

   function Element (C : Cursor)
      return not null access Element_Type;

This would allow that part of the program that increments the word count
to be written like this:

   declare
      C : Cursor;
      B : Boolean;
   begin
      Insert (M, Word, 0, C, B);

      declare
         N : Natural renames Element (C).all;
      begin
         N := N + 1;
      end;
   end;

Still not as concise as the C++ index and increment operators, but it's
less verbose the original example.

If we were to write the C++ example using insert(), it would look
something like:

   typedef map_t::iterator iter_t;
   typedef pair<iter_t, bool> status_t;
  
   const status_t status = m.insert(make_pair(word, 0));

   const iter_t& iter = status.first;

   int& n = iter->second;

   ++n;

So now they don't look that much different.  In fact, the 5-parameter
Insert operation in the AI-302 API is modeled directly on the C++ code
fragment above.

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> Well, if C++ had no operator++ it would be easy enough to write:
>     template <class T> T preincrement(T& value)
>     {
>        value = value + 1;
>        return value;
>     }

Shouldn't preincrement return T&, not T?

   template <class T> T& preincrement(T& value)
   {
      value = value + 1;
      return value;
   }

As you wrote it, the function will invoke the copy ctor for T, and
return a copy of value.  (But maybe that's what you wanted.)

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message
> news:<uk6ukb74c.fsf@earthlink.net>...
> > 
> > Actually, I would have used a pointer instead:
> > 
> >    S* ps = &s;
> >    ++ps->i;
> 
> Most C++ programmers would not. 

That was a typo.  I meant "could" not "would", and meant to say:

"As another example of precedence rules, I could have used a pointer
instead of a dot."

You obviously wouldn't want to declare a pointer to a locally declared
struct just to increment one of its members...

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> 
> One of the most frustrating things I found in Ada programming was the
> inability to make user-defined types work like the built-in types. 
> Given
> 
>   A: array (1..10) of integer;
> 
> then the expression A(5) is a modifiable reference to the fifth
> element of A.
> 
> After experience with C++ it was amazingly frustrating to learn that
> there was no way I could define My_Container so that I could write:
> 
>   C: My_Container ;
> 
>   C(5) := 7;


Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have to say:

   Replace_Element (C, Index => 5, By => 7);

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Alexander E. Kopilovich]

Kevin Cline wrote:

> > > The real question I have is why Perl and
> > > similar high-level languages are not more popular.
> > Perl has its own great competitor - Visual Basic (and to some degree Delphi
> > and some others, which also provide nice buttons and other GUI components)
>
> I have written a lot of Perl and some Visual Basic, and Visual Basic
> is not much of a competitor to Perl.

Well, Visual Basic is not much a competitor to Perl for you - according to
your tasks/skills/tastes, but for too many software developers the situation
is opposite.

>  Perl is fully reflexive and
> quite extensible, although some of the extension mechanisms are a bit
> arcane.  By comparison with Perl, Visual Basic is completely
> inextensible.

You are certainly either joking or confusing a software development tool with
its verbal language core. Unlike Perl, Visual Basic is designed for dealing
with end-user behaviour, not just with data streams. And in this direction
it is much more extensible than Perl. You may note, that even an early Visual
Basic VBX stands for Visual Basic eXtension (although it must be programmed
in C/C++) and now ActiveX can be easily created with Visual Basic itself).
And there is a sea of various VBX/OCX/ActiveX for public use - commercial,
shareware and freeware.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Hi,

Robert Kawulak wrote:

> 
>> In 99.99% of all cases I don't need strings on user defined types. I need
>> base_string<char>. I can see that I one day might need
>> base_string<wchar_t>, but I have not until now. They made all that funky
>> design which I just never need.
> 
>     And the best thing is that if you don't need it, you don't have to use
> it. Yet still there is this 0.01% of cases when this approach is extremely
> useful because of its flexibility. E.g. when you want a class of
> case-insensitive strings - you just reuse the basic string template like
> this:
 
> //class defining character traits
> class my_char_traits: public std::char_traits<char>
> {
>   //here you just redefine simple comparison
>   //functions like eq() to be case-insensitive
> };
> 
> //case-insensitive string class
> typedef std::basic_string<char, my_char_traits> cis_string;
> 
>> Would have been so easy, so usefull but it would not have been a
>> template. The "all is template" religion got in there way.
> 
>     Actually you might not even know that std::string is a typedef of
> template instantiation and still use it as if nothing had happened.

I know that. And I was wondering why.

>> And just for the record: atio is a C function - you need the overhead of
>> convertion the std::string into a char* and std::strstream seem quite
>> heavy
>> weight for just a simple task of convertion a string from and to an int.
> 
>     Actually, the overhead of conversion is virtually none (at least in
> Stlport implementation). You just call std::string::c_str() which just
> returns a pointer to the data, and which is also inlined.

From what I read about std::string strings do not need to be '\0' terminated
and std::string::c_str() will add a terminator if needed. Thats unlike
std::string::data() which does not add a '\0'. Well on the other side
std::string::c_str() is const.

This all leaves me wonder how actually works. And if I ever need to work
again if I had a Euro for every call where std::string::data() and
std::string::c_str() have been mixed up.
 
>     If you need string-to-int conversion and vice-versa, then it's the job
> of std::stringstream (std::strstream is obsolete...) - there's a very easy
> way to do this:

Interesting. I did not know that. Well tomorrow I look if Microsoft does
know as well.

> /********************************************/
> 
> #include <string>
> using std::string;
> 
> #include <sstream>
> typedef std::ostringstream oss;
> typedef std::istringstream iss;
> 
> int i = 4;
> string MyString("2");
> 
> 
> 
> //step-by-step:
> 
> void f() {
> 
>   //instead of std::string::fromInt(int)
>   oss MyOutputStream;
>   MyOutputStream << i;
>   MyString = MyOutputStream.str();
> 
>   //instead of std::string::toInt()
>   iss MyInputStream;
>   MyInputStream.str(MyString);
>   MyInputStream >> i;
> 
> } //f()

Well, nice. But are you shure you don't leak memory here. I remember there
was something about ownership and the str() function. 

> //same things as one-liners:

Please DON'T. This is comp.lang.ada after all. Three liners are quite OK.

>     C++ is not that evil, you just have to switch your mind to a different
> way of thinking to understand it well... ;-) It *is* difficult, but once 
> you feel it, it gives you a lot of abilities. Please don't understand me 
> wrong - I don't claim I'm some kind of C++ guru, and the following is just
> my general opinion, not an answer for your particular post. Why I think
> many people think of C++ as so dangerous and letting you easily shoot your
> foot is that unfortunately not many people know it as well as they should
> to use it properly.

Well I use C++ for 15 years now. And now I am here at c.l.a. Don't you think
there is a reason for that? I think I never ever get use to the fact that
the following one liner is not an error - and usually only reported at
highest warning level.

static unsigned Wrong = -1;

Not only that you can shoot yourself in the foot with C++ (You can do that
with Ada as well) but the weapon is allways loaded (that is, cannot be
unloaded), has no safety lever, and the trigger is allwas taut. And of
corse it is a snipers hair trigger going off at the slightest touch.

So no matter how experienced you are, you are allways in danger of shooting
your food of.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[jayessay]

Eric Jacoboni <jaco@neottia.net> writes:

> Eric Jacoboni <jaco@neottia.net> writes:
>
> > What about Ruby ? Much more readable than perl/python, imho. Its
> > inventor claims to be inspired by Ada and Eiffel syntaxes.

Actually, Ruby is closer to Lisp than either of those.


> Ok, i've finally found the equivalent of while (<>) construct in Ruby,
> so the initialisation of the hash is now more concise. By using 'for'
> instead of iterators, the code is more Ada-ish :
>
> for a_file in ARGF do
>   for a_line in a_file do
>     for a_word in a_line.split(/[^A-Za-z]+/) do
>         count[a_word.downcase] += 1
>     end # for a_word
>   end # for a_line
> end # for a_file

(defun word-count-2 (file-spec &key (wordpat (compile-pattern "[A-Za-z]+")))
  (let ((count (make-hash-table :test #'equal)))
    (with-open-file (the-file file-spec :direction :input)
      (for-each line :in the-file
        (for-each word :in (split-string wordpat line)
          (incf (gethash (string-downcase word) count 0)))))
    (let ((topten (subseq (sort (all (w c) :in count) #'> :key 'second) 0 10)))
      (for-each pair :in topten (print pair)))))

Just curious, do people who had "trouble" with the first version find
this one as "clear" as the Ruby?  Note: the part that is the same as
the above Ruby is just:

(with-open-file (the-file file-spec :direction :input)
  (for-each line :in the-file
    (for-each word :in (split-string wordpat line)
      (incf (gethash (string-downcase word) count 0)))))


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[jayessay]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> As far as I can tell, all this thread proves is that it would be nice if Ada
> allowed redefinition of some of the operations (as opposed to operators)
> like "in" and "()". And that the overriding concern for safety in Ada makes
> code a bit longer.

I don't think this thread "proves" anything.  Also there is nothing in
this thread to indicate in any sense that an "overiding concern for
safety" should make code longer.  Certainly there is nothing in any of
the Ada given that is more checked or "safe" than in the Lisp examples.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

jayessay <nospam@foo.com> wrote:
 
: I don't think this thread "proves" anything.  Also there is nothing in
: this thread to indicate in any sense that an "overiding concern for
: safety" should make code longer.  Certainly there is nothing in any of
: the Ada given that is more checked or "safe" than in the Lisp examples.

I also don't think that this thread "proves" anything. Certainly it
doesn't "prove" that static type checking doesn't add to safety.


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Keith H Duggar]

> I've come to this thread late, so I'm not completely sure about the 
> exact specs of the code, but here's my take on a Python version.  It 
> comes in at a svelt 10 lines, and I think it's quite readable.  I'm sure 
> I'm missing something though.
> 
> import sys
> 
> words = {}
> for line in sys.stdin.readlines():
>     for word in line.split():
>         words[word] = words.get(word, 0) + 1
> 
> words = [[x[1], x[0]] for x in words.items()]
> words.sort()
> words.reverse()
> 
> for word in words[:10]:
>    print word[0], word[1]

Sweet. Python get's my vote for most readable in this case.
The "for ... in ..." construct is very nice. It saves a lot
of time and a lot of error prone indexing code. Thanks for
posting it.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Sat, 25 Sep 2004 16:17:34 +0200, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote:
>> 
>>> And the reason why we have to write the subpgram is because Ada doesn't
>>> give you any direct way of returning a reference to variable view from a
>>> function, as C++ does.  But even so, in Ada you can modify objets in
>>> place (in AI-302 by using a downward closure -- which C++ doesn't have).
>>> That's what really matters, not the syntax.
>> 
>> Syntax does not matter. What matters is an ability to express an idea in
>> the syntax you want. To me, the most natural syntax for modifying an array
>> element is A(I) := B;
> 
> True. But only if it works. I just had some fun reading the fineprint from
> std::vector::operator [] (can not insert new elements - and at least the MS
> version crashes deep inside library code when you try) and
> std::map::operator [] (no const version). If it does not work as expected I
> rather live without and use an Insert () which then does work as expected.

Insert is another story. Whether array indexing should be used for
inserting new elements is questionable. Anyway, Ada lacks abstract arrays,
abstract indices and many other things, including an ability to return a
safe referential cursor as Matthew has pointed, essential for building a
safe, intuitive container library. Also in my deep opinion that library
should not be generic.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On 26 Sep 2004 00:17:13 -0700, Kevin Cline wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<13bv1aau5q9ht.1fr6ixcdql72.dlg@40tude.net>...
>> On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote:
>> 
>>> And the reason why we have to write the subpgram is because Ada doesn't
>>> give you any direct way of returning a reference to variable view from a
>>> function, as C++ does.  But even so, in Ada you can modify objets in
>>> place (in AI-302 by using a downward closure -- which C++ doesn't have).
>>> That's what really matters, not the syntax.
>> 
>> Syntax does not matter. What matters is an ability to express an idea in
>> the syntax you want. To me, the most natural syntax for modifying an array
>> element is A(I) := B;
> 
> This is how I develop C++ code.  I start programming at a high-level,
> writing code in the syntax I want to use.  Then I write the code to
> support the syntax.  This works pretty well until I want to do
> something like overload ".".

I wished Ada had abstract record types. In some sense it has an embryo of
that for protected types:

protected type Object is
   function Member return A_Type;
end Object;

But it cannot be abstract, it is read-only etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Fri, 24 Sep 2004 20:10:36 GMT, Frank J. Lhota wrote:

> "Matthew Heaney" <mheaney@on2.com> wrote in message 
> news:41547dae$0$91007$39cecf19@news.twtelecom.net...
>> Note that (as Randy alluded to) there's still a chance the ARG will add
>> something like reference types to Ada.  It would be declared something 
>> like:
>>
>>   function Update_Element
>>     (Container : in Map;
>>      Key         : in  Key_Type) return access Element_Type;
>>
>> Then you could say:
>>
>>   Update_Element (M, K).all := 42;
> 
> I still like the idea of adding "()" and "():=" operators to Ada.

"():=" could be problematic in Y(I).Foo(Baz):=Bar. I think it should better
be an in-place "()" and ":=".

> Then you could say:
> 
>     M(K) := 42;
> 
> This is clearer, and it makes absolutely no assertions as to how containers 
> represent their elements.

Yes. And I agree with Randy Brukardt, that a library should avoid using
access types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Insert is another story. Whether array indexing should be used for
: inserting new elements is questionable. Anyway, Ada lacks abstract arrays,
: abstract indices and many other things,

In this sense Ada doesn't have anything abstract, does it?

-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

: I wished Ada had abstract record types.

Perhaps you could use a word like meta-types or type classes,
or type types.
Ada does have abstract record types in any Ada sense, I'm sure
you know this well.

-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Chris Humphries]

Kevin Cline wrote:
> 
> Again, the original question was "Why isn't Ada more popular?"  
> 
> The answer I am giving is that most programmers don't have such an
> overriding concern for safety that they are willing to write twice as
> much code to get the additional safety.
> 

(whoa, what a thread this has become!)

Thanks, and good answer. Since then asking that question, I have
learned a lot more about Ada. John Barnes' book, "Programming in
Ada 96, 2nd Edition" helped tremendously. A very good book. It is
now nice to understand just what Ada _is_, and not just another
programming language, but more an attempting at progressing software
engineering.

I also think I understand why Ada is not more popular. Though I
am very thankful for open source, and feel very strongly about about
it, something bad has grown out of it: bad programmers and programs.
Most open source projects seem to have no formal software development
process. There is more an attitude of "shut up and hack", which
typically goes by whatever they get features to do from, which may
be from whatever they want, if there is a TODO list, then you are
lucky. There is usually no goals or anything actually defined, no
use cases (I would put money on most do not even know what one is,
and if they did, what they would use it for), no unit tests or any
automated framework for making sure the code does as designed (which
brings me to my next one), no design documentation or even a design
process.

Many young/inexperienced programmers do not even see why this is
important, as their code works, and generally they are done with it
then and there. In the real world, and in my job, most of the time
is spend updating code. Good times are when I get to design something
new, most the time is spent doing grunt work.

In a time when most programs are written by having a 1-2 thought
process of 1) i want my program to do this and 2) type-type-run-repeat,
such languages that allow you to do this easier are more popular, such
as php and perl.

Granted, I do code perl for some of the legacy projects here (no I am
not a web developer, heh), and if standards are in place, perl code can
be very readable and understandable. Coding standards are nice, yet
seem to be rarely used.

Again, sorry to start a thread that went off on a 400+ post tangent,
yet now I understand.

If anyone new to Ada, yet not to programming is reading this, I strongly
recommend getting "Programming in Ada 95, 2nd Edition" by John Barnes.

Thanks c.l.ada!

-Chris

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Chris Humphries]

I apologize, first thing in the morning on a monday without any
caffeine :) Type-o's exist in places, heh.

Chris Humphries wrote:
> Kevin Cline wrote:
> 
>>
>> Again, the original question was "Why isn't Ada more popular?" 
>> The answer I am giving is that most programmers don't have such an
>> overriding concern for safety that they are willing to write twice as
>> much code to get the additional safety.
>>
> 
> (whoa, what a thread this has become!)
> 
> Thanks, and good answer. Since then asking that question, I have
> learned a lot more about Ada. John Barnes' book, "Programming in
> Ada 96, 2nd Edition" helped tremendously. A very good book. It is
> now nice to understand just what Ada _is_, and not just another
> programming language, but more an attempting at progressing software
> engineering.
> 
> I also think I understand why Ada is not more popular. Though I
> am very thankful for open source, and feel very strongly about about
> it, something bad has grown out of it: bad programmers and programs.
> Most open source projects seem to have no formal software development
> process. There is more an attitude of "shut up and hack", which
> typically goes by whatever they get features to do from, which may
> be from whatever they want, if there is a TODO list, then you are
> lucky. There is usually no goals or anything actually defined, no
> use cases (I would put money on most do not even know what one is,
> and if they did, what they would use it for), no unit tests or any
> automated framework for making sure the code does as designed (which
> brings me to my next one), no design documentation or even a design
> process.
> 
> Many young/inexperienced programmers do not even see why this is
> important, as their code works, and generally they are done with it
> then and there. In the real world, and in my job, most of the time
> is spend updating code. Good times are when I get to design something
> new, most the time is spent doing grunt work.
> 
> In a time when most programs are written by having a 1-2 thought
> process of 1) i want my program to do this and 2) type-type-run-repeat,
> such languages that allow you to do this easier are more popular, such
> as php and perl.
> 
> Granted, I do code perl for some of the legacy projects here (no I am
> not a web developer, heh), and if standards are in place, perl code can
> be very readable and understandable. Coding standards are nice, yet
> seem to be rarely used.
> 
> Again, sorry to start a thread that went off on a 400+ post tangent,
> yet now I understand.
> 
> If anyone new to Ada, yet not to programming is reading this, I strongly
> recommend getting "Programming in Ada 95, 2nd Edition" by John Barnes.
> 
> Thanks c.l.ada!
> 
> -Chris

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Björn Persson]

Jacob Sparre Andersen wrote:

> But does that tell us that Bash is an excellent tool for controlling
> nuclear reactors, medical equipment, or just plain bioinformatics
> software?

Of course not, but maybe for less life critical applications, 
particularly text processing applications. ;-) An IDE written in Bash, 
anyone? ;-)

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Mon, 27 Sep 2004 12:59:02 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: Insert is another story. Whether array indexing should be used for
>: inserting new elements is questionable. Anyway, Ada lacks abstract arrays,
>: abstract indices and many other things,
> 
> In this sense Ada doesn't have anything abstract, does it?

You cannot:

package Foo is
   type String is array (Integer range <>) of Character is private;
   ...
private
   type String is new Ada.Finalization.Controlled with ...

An abstract array is something that can be indexed. It means that it has a
definite set of abstract primitive operations like "()", ":=", 'First,
'Last etc to be implemented. The way an implementation does it is no
matter, so in my hypothetical example, a string is implemented by a
controlled type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Mon, 27 Sep 2004 13:03:11 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>: I wished Ada had abstract record types.
> 
> Perhaps you could use a word like meta-types or type classes,
> or type types.

Maybe

> Ada does have abstract record types in any Ada sense, I'm sure
> you know this well.

Yes, you mean an abstract type which is occasionally a record type. What I
meant was records as abstract interfaces.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Adam Ruth]

In article <b47de02.0409261812.659a923b@posting.google.com>,
 duggar@mit.edu (Keith H Duggar) wrote:

> > I've come to this thread late, so I'm not completely sure about the 
> > exact specs of the code, but here's my take on a Python version.  It 
> > comes in at a svelt 10 lines, and I think it's quite readable.  I'm sure 
> > I'm missing something though.
> > 
> > import sys
> > 
> > words = {}
> > for line in sys.stdin.readlines():
> >     for word in line.split():
> >         words[word] = words.get(word, 0) + 1
> > 
> > words = [[x[1], x[0]] for x in words.items()]
> > words.sort()
> > words.reverse()
> > 
> > for word in words[:10]:
> >    print word[0], word[1]
> 
> Sweet. Python get's my vote for most readable in this case.
> The "for ... in ..." construct is very nice. It saves a lot
> of time and a lot of error prone indexing code. Thanks for
> posting it.


Python and Ada tie for my favorite languages (with Lisp coming in a 
close second).  Which I use, depends on the task at hand.  Ada and 
Python seem to have similar philosophies, though on opposite sides of 
the spectrum.  Python's designer had as an explicit goal:

"There should only be one obvious way to do anything".

Some think that that stifles creativity, but I disagree.  It frees the 
programmer in my mind.  While I'm not sure about the Ada designer, it 
seems that a similar philosophy was in play.  That's a very 
"engineering" type of thought, as opposed to a "hacker" type of thought.

That's actually my biggest problem with Perl.  Its designer had as a 
goal that there should be as may ways to accomplish things as there are 
programmers.  Great if you're just a hacker having fun, terrible if 
you're someone maintaining Perl code.  I think that has more to do with 
Perl's unreadability than the syntax.  I've never met a "great" Perl 
programmer (read, Perl hacker), who wasn't completely confused by their 
own two month old code.  I've seen those same programmers be able to 
digest 20,000 line Python programs in an afternoon.  I've not got nearly 
as much experience with Ada, but I can't see it being much different in 
that regard.

-- 
Adam Ruth
adamruth at mac dot com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > 
> > One of the most frustrating things I found in Ada programming was the
> > inability to make user-defined types work like the built-in types. 
> > Given
> > 
> >   A: array (1..10) of integer;
> > 
> > then the expression A(5) is a modifiable reference to the fifth
> > element of A.
> > 
> > After experience with C++ it was amazingly frustrating to learn that
> > there was no way I could define My_Container so that I could write:
> > 
> >   C: My_Container ;
> > 
> >   C(5) := 7;
> 
> 
> Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have to say:
> 
>    Replace_Element (C, Index => 5, By => 7);

I think this was a major error in the language design.  As a result it
very tedious to write a generic that will work with both predefined
and user-defined types.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<umzzdt0p6.fsf@earthlink.net>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > Well, if C++ had no operator++ it would be easy enough to write:
> >     template <class T> T preincrement(T& value)
> >     {
> >        value = value + 1;
> >        return value;
> >     }
> 
> Shouldn't preincrement return T&, not T?

Yes, it should.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
>  
> : I don't think this thread "proves" anything.  Also there is nothing in
> : this thread to indicate in any sense that an "overiding concern for
> : safety" should make code longer.  Certainly there is nothing in any of
> : the Ada given that is more checked or "safe" than in the Lisp examples.
> 
> I also don't think that this thread "proves" anything. Certainly it
> doesn't "prove" that static type checking doesn't add to safety.

Nor that it does.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Chris Humphries]

Adam Ruth wrote:
> In article <b47de02.0409261812.659a923b@posting.google.com>,
>  duggar@mit.edu (Keith H Duggar) wrote:
> 
> 
>>>I've come to this thread late, so I'm not completely sure about the 
>>>exact specs of the code, but here's my take on a Python version.  It 
>>>comes in at a svelt 10 lines, and I think it's quite readable.  I'm sure 
>>>I'm missing something though.
>>>
>>>import sys
>>>
>>>words = {}
>>>for line in sys.stdin.readlines():
>>>    for word in line.split():
>>>        words[word] = words.get(word, 0) + 1
>>>
>>>words = [[x[1], x[0]] for x in words.items()]
>>>words.sort()
>>>words.reverse()
>>>
>>>for word in words[:10]:
>>>   print word[0], word[1]
>>
>>Sweet. Python get's my vote for most readable in this case.
>>The "for ... in ..." construct is very nice. It saves a lot
>>of time and a lot of error prone indexing code. Thanks for
>>posting it.
> 
> 
> 
> Python and Ada tie for my favorite languages (with Lisp coming in a 
> close second).  Which I use, depends on the task at hand.  Ada and 
> Python seem to have similar philosophies, though on opposite sides of 
> the spectrum.  Python's designer had as an explicit goal:
> 
> "There should only be one obvious way to do anything".
> 
> Some think that that stifles creativity, but I disagree.  It frees the 
> programmer in my mind.  While I'm not sure about the Ada designer, it 
> seems that a similar philosophy was in play.  That's a very 
> "engineering" type of thought, as opposed to a "hacker" type of thought.
> 
> That's actually my biggest problem with Perl.  Its designer had as a 
> goal that there should be as may ways to accomplish things as there are 
> programmers.  Great if you're just a hacker having fun, terrible if 
> you're someone maintaining Perl code.  I think that has more to do with 
> Perl's unreadability than the syntax.  I've never met a "great" Perl 
> programmer (read, Perl hacker), who wasn't completely confused by their 
> own two month old code.  I've seen those same programmers be able to 
> digest 20,000 line Python programs in an afternoon.  I've not got nearly 
> as much experience with Ada, but I can't see it being much different in 
> that regard.
> 

That is not completely fair. It depends on the programmer as well.
Having good documentation (including comments) as well as defined
coding standards should make the code readable in any language,
perl, python. Understanding the syntax of the language helps in
both cases. If I know the syntax, and language, I can read any
language the same.

True that python by nature is easy to read, but it is unfair pit
it against some perl code itself. I have seen python code that is
hard to understand at a glance and perl code that is easy to understand
at a glance :)

I would like to see a perl programmer go over 20,000 lines of python,
such as Zope and understand what is going on. Even for experienced
python programmers or any programmer for that matter, that is a lot
of code to read. Plus in a proper environment, there should be
documentation somewhere before hand that defines what the purpose of
the code us, use cases and even a explanation of what is going on
from the mouth of the designers and programmers. That makes looking
at code much easier, whatever the language... Even though the geeks in
us would rather just look at the code first :)

Perl gets a bad rap, just because there are 12341234 ways to do one
thing, that doesn't make the language bad. I believe that Perl gets
a bad rap from bad programmers/designers and thus bad code. The language
is really a moot point if the foundation doesn't exist, or being built
as you build.

All things being equal, Ada is nice to have, yet Perl is no better off
than Python in many respects, unless you talk about OO features and
such. Perl 6 should be interesting (even though it may be vaporware for
a few more years, heh).

Only reason I could see why the argument of reading the language of
Python over Perl would be better is if there was no documentation and
you had no idea how it worked before opening up your editors and
browsing files. Then the weak link isn't the language, but the software
development team. Though it is easier to blame a language and take it
from ourselves.

Sure language syntax for readability is very nice to have, but it should
not negate the need for proper documentation and standards :)

Note: I am not attacking you bud, just pointing out something that is
frustrating :)

PS: I have done a ton of work with Python, and specifically Zope, even a
Zope 3 sprint in NYC.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On 27 Sep 2004 07:31:44 -0700, Kevin Cline wrote:

> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>...
>> kevin.cline@gmail.com (Kevin Cline) writes:
>> 
>>> One of the most frustrating things I found in Ada programming was the
>>> inability to make user-defined types work like the built-in types. 
>>> Given
>>> 
>>>   A: array (1..10) of integer;
>>> 
>>> then the expression A(5) is a modifiable reference to the fifth
>>> element of A.
>>> 
>>> After experience with C++ it was amazingly frustrating to learn that
>>> there was no way I could define My_Container so that I could write:
>>> 
>>>   C: My_Container ;
>>> 
>>>   C(5) := 7;
>> 
>> Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have to say:
>> 
>>    Replace_Element (C, Index => 5, By => 7);
> 
> I think this was a major error in the language design.

It was not an error, in the sense that no irreparable damage was done. It
seems that the issue was just put aside for better times. Ada has a rich
infrastructure supporting array types and their index types. So to reshape
Ada's arrays out of abstract "array interfaces" one need to take all that
presently hard-wired infrastructure with. Note that C++ does not solve the
problem, because it has no arrays. So it allows you to define [] and leaves
you alone with that. It is not the Ada's way (TM).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409270631.2bf81ccf@posting.google.com...
> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message
news:<uekkpt07s.fsf@earthlink.net>...
> > kevin.cline@gmail.com (Kevin Cline) writes:
> >
> > Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have
to say:
> >
> >    Replace_Element (C, Index => 5, By => 7);
>
> I think this was a major error in the language design.  As a result it
> very tedious to write a generic that will work with both predefined
> and user-defined types.

All you need to do is write the generic in terms of (AI-302) container
operations, and then use locally declared subprograms to make the array
(say) work with the generic algorithm.  The "tedium" only applies when using
a generic on an array instead of a container.

For example:

generic
   type Cursor is private;
   with function Next (C : Cursor) return Cursor is <>;
   with procedure Replace_Element (C : Cursor; By : ET) is <>;
   with function Has_Element (C : Cursor) return Boolean is <>;
procedure Generic_Op (C : Cursor);

To use this with a container type, there's nothing you need to do except
instantiate the generic algorithm.

To make this work with an array, all you need to do is:

procedure Op (A : in out Array_Type) is

   procedure Replace_Element (I : Index_Type; E : ET) is
  begin
     A (I) := E;
  end;

  function Has_Element (I : IT) return Boolean is
  begin
     return I in A'Range;
  end;

  procedure Algorithm is
    new Generic_Algorithm (Index_Type, Index_Type'Succ);

begin
   Algorithm (A'First);
end Op;

Note that here the "cursor" is just the discrete array index subtype.  The
T'Succ attribute is used as the generic actual for the Next generic formal.

Your problem is that you're still thinking in C++ terms.  C++ works by
making containers look like built-in types.  That's different from Ada,
which (as demonstrated above) makes the built-in type look like a container.


-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Adam Ruth]

In article <415828D5.8030905@unixfu.net>,
 Chris Humphries <chris@unixfu.net> wrote:

> Adam Ruth wrote:
> > In article <b47de02.0409261812.659a923b@posting.google.com>,
> >  duggar@mit.edu (Keith H Duggar) wrote:

> > Python and Ada tie for my favorite languages (with Lisp coming in a 
> > close second).  Which I use, depends on the task at hand.  Ada and 
> > Python seem to have similar philosophies, though on opposite sides of 
> > the spectrum.  Python's designer had as an explicit goal:
> > 
> > "There should only be one obvious way to do anything".
> > 
> > Some think that that stifles creativity, but I disagree.  It frees the 
> > programmer in my mind.  While I'm not sure about the Ada designer, it 
> > seems that a similar philosophy was in play.  That's a very 
> > "engineering" type of thought, as opposed to a "hacker" type of thought.
> > 
> > That's actually my biggest problem with Perl.  Its designer had as a 
> > goal that there should be as may ways to accomplish things as there are 
> > programmers.  Great if you're just a hacker having fun, terrible if 
> > you're someone maintaining Perl code.  I think that has more to do with 
> > Perl's unreadability than the syntax.  I've never met a "great" Perl 
> > programmer (read, Perl hacker), who wasn't completely confused by their 
> > own two month old code.  I've seen those same programmers be able to 
> > digest 20,000 line Python programs in an afternoon.  I've not got nearly 
> > as much experience with Ada, but I can't see it being much different in 
> > that regard.
> > 
> 
> That is not completely fair. It depends on the programmer as well.
> Having good documentation (including comments) as well as defined
> coding standards should make the code readable in any language,
> perl, python. Understanding the syntax of the language helps in
> both cases. If I know the syntax, and language, I can read any
> language the same.

That's why I said:

> > I've never met a "great" Perl 
> > programmer (read, Perl hacker), who wasn't completely confused by their 
> > own two month old code.

I'm not talking about well disciplined engineers here.  But when it 
comes to languages, some make bad programmers worse.  Perl is one of 
those languages.  Perl also tends to attract and encourage "hacker" 
style programming and bad practices.  That's not to say it has a 
monopoly, I've seen a bunch of crappy unreadable Python code in my time.

Why make life harder for yourself?  That's what I ask myself when it 
comes to language choices.  I pick a language that makes it easier to 
make better code.  No language makes it truly impossible to write good 
code, but some do make it more difficult.  Of course, no language makes 
it impossible to NOT write bad code.

> 
> Perl gets a bad rap, just because there are 12341234 ways to do one
> thing, that doesn't make the language bad. 

I disagree (in the sense of the topic, that being maintainability).  No 
matter how good a programmer you are in Perl, another programmer will 
find it more difficult to follow your logic if they're used to doing 
things other ways.  It's one more thing for them to process as they read 
your code.  The fewer things that they need to understand as they read 
your code, the faster they will read it.  

> I believe that Perl gets
> a bad rap from bad programmers/designers and thus bad code. The language
> is really a moot point if the foundation doesn't exist, or being built
> as you build.

Agree completely.  But I think the bad rap exists for a reason.  I think 
that the ratio of bad/good code is higher in Perl than Python.  Perl 
seems to encourage bad programming practices.  

> 
> All things being equal, Ada is nice to have, yet Perl is no better off
> than Python in many respects, unless you talk about OO features and
> such. Perl 6 should be interesting (even though it may be vaporware for
> a few more years, heh).
> 
> Only reason I could see why the argument of reading the language of
> Python over Perl would be better is if there was no documentation and
> you had no idea how it worked before opening up your editors and
> browsing files. Then the weak link isn't the language, but the software
> development team. Though it is easier to blame a language and take it
> from ourselves.

But that's reality.  You rarely have control of those that came before 
you.  Wouldn't you rather that they used a good language over a bad one?  
You'd certainly rather they used a good practice over a bad one.


> 
> Sure language syntax for readability is very nice to have, but it should
> not negate the need for proper documentation and standards :)

Could not agree with you more!

> 
> Note: I am not attacking you bud, just pointing out something that is
> frustrating :)

Understood.  I'm not attacking you either.  I'm attacking all the bad 
programmers who made code I need to maintain!


> 
> PS: I have done a ton of work with Python, and specifically Zope, even a
> Zope 3 sprint in NYC.

Never worked with Zope, it looks interesting, but never really fit in 
with any of my requirements.  




-- 
Adam Ruth
adamruth at mac dot com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Keith H Duggar]

> That is not completely fair. It depends on the programmer as well.
> Having good documentation (including comments) as well as defined
> coding standards should make the code readable in any language,

Any language? No amount of commenting will make Brain F*** or
Whitespace readable. That is, the comments may be readable,
the code will not be. And that is an important distinction,
we are discussing (I think) the readability of CODE not the
readability of comments.

> perl, python. Understanding the syntax of the language helps in
> both cases. If I know the syntax, and language, I can read any
> language the same.

Again as counter examples take BF and Whitespace. These are
of course extreme examples but the valid point is that language
absolutely affects readability.

> True that python by nature is easy to read, but it is unfair pit
> it against some perl code itself. I have seen python code that is
> hard to understand at a glance and perl code that is easy to understand
> at a glance :)

I think understandability and readability are really quite
different. For example, I am able to read the following
English snip from your post

> All things being equal, Ada is nice to have, yet Perl is no better off
> than Python in many respects, unless you talk about OO features and
> such. Perl 6 should be interesting (even though it may be vaporware for
> a few more years, heh).

but I do not understand it all. In other words, I find
English highly readable yet many English "programs" such as
the one above make no sense to me whatever.

> Only reason I could see why the argument of reading the language of
> Python over Perl would be better is if there was no documentation and
> you had no idea how it worked before opening up your editors and

For me, an ideally readable language would be as self-documenting
as possible. Comments should just be gravy, summaries, or
notices of something tricky or difficult to understand (not read).

> Sure language syntax for readability is very nice to have, but it should
> not negate the need for proper documentation and standards :)

Hmm, it seems you are now contradicting your general
sentiment and your earlier specific statement that

> coding standards should make the code readable in any language,

Do you or do you not believe that syntax affects readability?

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Adam Ruth <adam.ruth@mac.com> wrote in message news:<adam.ruth-CEAF21.08210127092004@localhost>...
> In article <b47de02.0409261812.659a923b@posting.google.com>,
>  duggar@mit.edu (Keith H Duggar) wrote:
> 
> > > I've come to this thread late, so I'm not completely sure about the 
> > > exact specs of the code, but here's my take on a Python version.  It 
> > > comes in at a svelt 10 lines, and I think it's quite readable.  I'm sure 
> > > I'm missing something though.
> > > 
> > > import sys
> > > 
> > > words = {}
> > > for line in sys.stdin.readlines():
> > >     for word in line.split():
> > >         words[word] = words.get(word, 0) + 1
> > > 
> > > words = [[x[1], x[0]] for x in words.items()]
> > > words.sort()
> > > words.reverse()
> > > 
> > > for word in words[:10]:
> > >    print word[0], word[1]
> > 
> > Sweet. Python get's my vote for most readable in this case.
> > The "for ... in ..." construct is very nice. It saves a lot
> > of time and a lot of error prone indexing code. Thanks for
> > posting it.
> 
> 
> Python and Ada tie for my favorite languages (with Lisp coming in a 
> close second).  Which I use, depends on the task at hand.  Ada and 
> Python seem to have similar philosophies, though on opposite sides of 
> the spectrum.  Python's designer had as an explicit goal:
> 
> "There should only be one obvious way to do anything".
> 
> Some think that that stifles creativity, but I disagree.  It frees the 
> programmer in my mind.  While I'm not sure about the Ada designer, it 
> seems that a similar philosophy was in play.  That's a very 
> "engineering" type of thought, as opposed to a "hacker" type of thought.
> 
> That's actually my biggest problem with Perl.  Its designer had as a 
> goal that there should be as may ways to accomplish things as there are 
> programmers.  

That was not so much a goal as property that emerged as the language
grew. Features were added to make it convenient to do some things, or
to improve code readability, /without worrying about feature overlap. 
So you can say either
   if (!condition) { statement; }
or
   unless (condition) { statement; }
or
   statement unless (condition);

Or you can say either
   foreach $element (list)
   {
     do something;
   }
or
   map { something } (list);

Having more than one way to do things makes it easier to write
readable code.  And also easier to write unreadable code.

> Great if you're just a hacker having fun, terrible if 
> you're someone maintaining Perl code.  

Really not so terrible.  

> I think that has more to do with Perl's unreadability than the syntax.  I've 
> never met a "great" Perl 
> programmer (read, Perl hacker), who wasn't completely confused by their 
> own two month old code.  

Then you've never met a great Perl programmer.  The great programmers
I've known can write crystal-clear code in almost any language, with
very little need for explanatory comments beyond class and function
descriptions.

I've read a lot of CPAN modules and found most of them pretty clear. 
But there are some very high-level PERL modules that allow one to do a
lot with a little code, and it takes a little effort to learn what
those modules do.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Chris Humphries]

Not to make this a flame war, but it seems that you have never
been in a professional software engineering environment that
involved work on your part other than grunt code writing. Even
someone that has been doing grunt code work for a long project
would understand what I am saying.

Hopefully it is was just communication errors on my part. :)


Keith H Duggar wrote:
>>That is not completely fair. It depends on the programmer as well.
>>Having good documentation (including comments) as well as defined
>>coding standards should make the code readable in any language,
> 
> 
> Any language? No amount of commenting will make Brain F*** or
> Whitespace readable. That is, the comments may be readable,
> the code will not be. And that is an important distinction,
> we are discussing (I think) the readability of CODE not the
> readability of comments.
> 

If Ada is about Software Engineering, then software documents and
software code go hand in hand. Something that a college student
probably has not experienced or learned yet.

> 
>>perl, python. Understanding the syntax of the language helps in
>>both cases. If I know the syntax, and language, I can read any
>>language the same.
> 
> 
> Again as counter examples take BF and Whitespace. These are
> of course extreme examples but the valid point is that language
> absolutely affects readability.
> 

Well, lets exclude those languages as I, for one, do not know of
any real production use of them or anyone that actually uses them
outside of fun and tinkering. I was talking about languages you
come across in reality, such as Perl, Python, C, C++.

I understand the point of readability, but you should understand
that any good software engineering process should include documentation,
use cases, and other things that are related to the software and
is not actual software code. The coding part is generally the easy
part if the documentation and design are done properly.

> 
>>True that python by nature is easy to read, but it is unfair pit
>>it against some perl code itself. I have seen python code that is
>>hard to understand at a glance and perl code that is easy to understand
>>at a glance :)
> 
> 
> I think understandability and readability are really quite
> different. For example, I am able to read the following
> English snip from your post
> 
> 
>>All things being equal, Ada is nice to have, yet Perl is no better off
>>than Python in many respects, unless you talk about OO features and
>>such. Perl 6 should be interesting (even though it may be vaporware for
>>a few more years, heh).
> 
> 
> but I do not understand it all. In other words, I find
> English highly readable yet many English "programs" such as
> the one above make no sense to me whatever.
> 
> 
>>Only reason I could see why the argument of reading the language of
>>Python over Perl would be better is if there was no documentation and
>>you had no idea how it worked before opening up your editors and
> 
> 
> For me, an ideally readable language would be as self-documenting
> as possible. Comments should just be gravy, summaries, or
> notices of something tricky or difficult to understand (not read).
> 
> 
>>Sure language syntax for readability is very nice to have, but it should
>>not negate the need for proper documentation and standards :)
> 
> 
> Hmm, it seems you are now contradicting your general
> sentiment and your earlier specific statement that
> 

The point was, which you totally missed, is that software design
and other documentation define what the program is, how it works,
breakdown flow and define in/outs, and other things. The code
should just be an implementation or "reality" of the documentation.

When I say "documentation", I mean documentation that exists outside
the code itself.

> 
>>coding standards should make the code readable in any language,
> 
> 
> Do you or do you not believe that syntax affects readability?

Of course I do, and thankful for it. When I say coding standards,
I mean a predefined way of how code is to look, naming conventions,
comments (and how they are to be, ie name, params descriptions, etc)
and is a strict structure that is done.

Many languages try to take care of this step for you, because honestly
we do not live in a perfect world, and many companies/firms do not have
this in place, so languages like Ada and Python help in this, as
many [style] syntax structure is defined as part of the language syntax
itself.

The readability of the code seems more important relative to the lack
of documentation.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Adam Ruth]

In article <e749549b.0409271234.1c2b4b92@posting.google.com>,
 kevin.cline@gmail.com (Kevin Cline) wrote:

> Adam Ruth <adam.ruth@mac.com> wrote in message 
> news:<adam.ruth-CEAF21.08210127092004@localhost>...
> > In article <b47de02.0409261812.659a923b@posting.google.com>,
> >  duggar@mit.edu (Keith H Duggar) wrote:
> > I think that has more to do with Perl's unreadability than the syntax.  
> > I've 
> > never met a "great" Perl 
> > programmer (read, Perl hacker), who wasn't completely confused by their 
> > own two month old code.  
> 
> Then you've never met a great Perl programmer.  The great programmers
> I've known can write crystal-clear code in almost any language, with
> very little need for explanatory comments beyond class and function
> descriptions.

Not so, I've met plenty of great Perl programmers.  It's not them I was 
referring to.  I was referring to "great" Perl programmers, or Perl 
hackers in reality.  People with no sense of engineering.  I mustn't 
have made that clear enough...  and I wasn't even writing in Perl!

> 
> I've read a lot of CPAN modules and found most of them pretty clear. 
> But there are some very high-level PERL modules that allow one to do a
> lot with a little code, and it takes a little effort to learn what
> those modules do.




-- 
Adam Ruth
adamruth at mac dot com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Chris Humphries <chris@unixfu.net> wrote in message news:<415813FE.9090803@unixfu.net>...
> Kevin Cline wrote:
> > 
> > Again, the original question was "Why isn't Ada more popular?"  
> > 
> > The answer I am giving is that most programmers don't have such an
> > overriding concern for safety that they are willing to write twice as
> > much code to get the additional safety.
> > 
> 
> (whoa, what a thread this has become!)
> 
> Thanks, and good answer. Since then asking that question, I have
> learned a lot more about Ada. John Barnes' book, "Programming in
> Ada 96, 2nd Edition" helped tremendously. A very good book. It is
> now nice to understand just what Ada _is_, and not just another
> programming language, but more an attempting at progressing software
> engineering.
> 
> I also think I understand why Ada is not more popular. Though I
> am very thankful for open source, and feel very strongly about about
> it, something bad has grown out of it: bad programmers and programs.

Bad programmers didn't come from open source.  There have always been
bad programmers, and there always will be.  Just as it is with music
and writing and film and art, 90% of all programming sucks.

> Most open source projects seem to have no formal software development
> process...
> Many young/inexperienced programmers do not even see why this is
> important, as their code works, and generally they are done with it
> then and there. 

This is also true for a surprising number of old and experienced
programmers.

> In the real world, and in my job, most of the time
> is spend updating code. Good times are when I get to design something
> new, most the time is spent doing grunt work.

This situation is common, but not inevitable.  On a good project,
design is a continuous process.  Unfortunately, most programs reach
the point where any change is so risky that developers spend all their
time trying to figure out how to squeeze in a new feature without
breaking the existing features.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1700922.2nPlMsa4Ny@linux1.krischik.com>...
> Kevin Cline wrote:
> 
> > Martin Krischik <krischik@users.sourceforge.net> wrote in message
> > news:<3673998.bj16mkkOu2@linux1.krischik.com>...
> >> Matthew Heaney wrote:
> >> 
> >> > If AI-302 doesn't meet your needs, then you need to let us know.
> >> > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note
> >> > that I'm still incorporating changes from the most recent ARG
> >> > meeting.)
> >> 
> >> I have got my most important baby (indefinite types). And I don't want to
> >> confuse the ARG. I fully agree that we need a container library inside
> >> the standart.
> >> 
> >> However it would be sad if Ada.Containers would kill off all other
> >> container libraries. Just like the STL did.
> > 
> > I think the STL killed off all the other container libraries because
> > the STL container/algorithm separation is an extremely powerful design
> > that dominates all older container library designs. Certainly STL 
> > programming is much cleaner and easeir than programming with the once
> > popular RogueWave containers.  The STL also has the advantage that it
> > is relatively easy to write new containers that will work with the STL
> > algorithms, so that even though new containers are written, they all
> > look like STL containers.
> 
> No Library is perfect, but the "I which I had" list for the STL is much
> larger then for container out of IBM's OCL. The OCL was not designed for
> academic correctness bit but for usability.
> 
> >> Im am sill looking at IBM OCL thinking
> >> how much more practical it was. std::string might me academicly correct
> >> but IString was a lot more usefull in day to day live with all the asInt
> >> (), asUnsigned (), asAnythingYouEverNeed() methods.
> > 
> > The problem with that design is that it isn't readily extensible to
> > accomodate user-defined types, and it makes generic programming very
> > difficult.
> 
> In 99.99% of all cases I don't need strings on user defined types. I need
> base_string<char>. I can see that I one day might need
> base_string<wchar_t>, but I have not until now. They made all that funky
> design which I just never need. 

That wasn't the sort of extensibility I was thinking of.  I was
referring to
the inextensibility of the series of member functions asInt(),
asUnsigned(), etc.  Collections of functions with names varying
according to the return type inhibit template programming.  If you
want to be able to conveniently extract values from a string, you can
write this template function:

template <class T> T parse(std::string s)
{
  T result;
  stringstream strm(s);
  strm >> result;
  if (!strm) throw( /* something */ );
  return result;
}

and then you can write:
  std::string s("10");
  int i = parse<int>(s);

I agree that this is not as obvious as it should be.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Brian May]

>>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes:

    Kevin> Bad programmers didn't come from open source.  There have
    Kevin> always been bad programmers, and there always will be.
    Kevin> Just as it is with music and writing and film and art, 90%
    Kevin> of all programming sucks.

I know of commercial programs that are developed (designed,
implemented, and tested) very badly just as I know of open source
projects that appear to be handled very well.

Commercial projects can be put under pressure to cut corners,
e.g. because management sees a formal software development process as
an academic exercise that is a complete waste of time "in the real
world"(TM), despite protests from programmers. The same management see
software development as a tedious and unreliable process, and don't
make the connection that the lack of a proper development process
could be leading to the difficulties. They often give solutions (that
may be inadequate) rather then requirements, turning the task of
programming into a guessing game.

Open source developers aren't under these pressures, and have more
scope for doing the right thing.

(this isn't to imply that all open source projects are developed
correctly; some are bad too; this doesn't imply all commercial
projects are developed badly either).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Matthew Heaney" <mheaney@on2.com> wrote in message news:<41583b4c$0$74190$39cecf19@news.twtelecom.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0409270631.2bf81ccf@posting.google.com...
> > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message
>  news:<uekkpt07s.fsf@earthlink.net>...
> > > kevin.cline@gmail.com (Kevin Cline) writes:
> > >
> > > Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have
>  to say:
> > >
> > >    Replace_Element (C, Index => 5, By => 7);
> >
> > I think this was a major error in the language design.  As a result it
> > very tedious to write a generic that will work with both predefined
> > and user-defined types.
> 
> All you need to do is write the generic in terms of (AI-302) container
> operations, and then use locally declared subprograms to make the array
> (say) work with the generic algorithm.  The "tedium" only applies when using
> a generic on an array instead of a container.
> 
> For example:
> 
> generic
>    type Cursor is private;
>    with function Next (C : Cursor) return Cursor is <>;
>    with procedure Replace_Element (C : Cursor; By : ET) is <>;
>    with function Has_Element (C : Cursor) return Boolean is <>;
> procedure Generic_Op (C : Cursor);
> 
> To use this with a container type, there's nothing you need to do except
> instantiate the generic algorithm.
> 
> To make this work with an array, all you need to do is:
> 
> procedure Op (A : in out Array_Type) is
> 
>    procedure Replace_Element (I : Index_Type; E : ET) is
>   begin
>      A (I) := E;
>   end;
> 
>   function Has_Element (I : IT) return Boolean is
>   begin
>      return I in A'Range;
>   end;
> 
>   procedure Algorithm is
>     new Generic_Algorithm (Index_Type, Index_Type'Succ);
> 
> begin
>    Algorithm (A'First);
> end Op;
> 
> Note that here the "cursor" is just the discrete array index subtype.  The
> T'Succ attribute is used as the generic actual for the Next generic formal.
> 
> Your problem is that you're still thinking in C++ terms.  

No doubt.

> C++ works by
> making containers look like built-in types.  That's different from Ada,
> which (as demonstrated above) makes the built-in type look like a container.

Ok, but shouldn't that code be generic?  The code above works for only
one algorithm on one particular array type.

I think that "different from Ada" here is significantly better.  Lots
of existing C and C++ code that works on arrays that can be trivially
modified to work on any array-like class, but existing Ada array code
has to be rewritten in every detail to work on a user-defined
container.  And the results of that rewrite aren't pretty.  For
example, suppose you want to multiply sparse matrices.  Instead of the
natural:

   P(I,K) := A(I,J) * B(J,K)

you'll end up with something like:

   SET_ELEMENT(P, I, K, ELEMENT(A, I, J) * ELEMENT(B, J, K))

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Brian May]

>>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes:

    Kevin> SET_ELEMENT(P, I, K, ELEMENT(A, I, J) * ELEMENT(B, J, K))

This doesn't answer the point you made, however, personally I would
write the above as:

Result := ELEMENT(A, I, J) * ELEMENT(B, J, K);
SET_ELEMENT(P, I, K, Result);

IMHO this is slightly simpler then the initial version.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1g2d9xmnita9f.5ecju0eftkqw$.dlg@40tude.net>...
> On 27 Sep 2004 07:31:44 -0700, Kevin Cline wrote:
> 
> > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>...
> >> kevin.cline@gmail.com (Kevin Cline) writes:
> >> 
> >>> One of the most frustrating things I found in Ada programming was the
> >>> inability to make user-defined types work like the built-in types. 
> >>> Given
> >>> 
> >>>   A: array (1..10) of integer;
> >>> 
> >>> then the expression A(5) is a modifiable reference to the fifth
> >>> element of A.
> >>> 
> >>> After experience with C++ it was amazingly frustrating to learn that
> >>> there was no way I could define My_Container so that I could write:
> >>> 
> >>>   C: My_Container ;
> >>> 
> >>>   C(5) := 7;
> >> 
> >> Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have to say:
> >> 
> >>    Replace_Element (C, Index => 5, By => 7);
> > 
> > I think this was a major error in the language design.
> 
> It was not an error, in the sense that no irreparable damage was done. It
> seems that the issue was just put aside for better times. Ada has a rich
> infrastructure supporting array types and their index types. So to reshape
> Ada's arrays out of abstract "array interfaces" one need to take all that
> presently hard-wired infrastructure with. Note that C++ does not solve the
> problem, because it has no arrays. So it allows you to define [] and leaves
> you alone with that. It is not the Ada's way (TM).

C++ solves the problem very nicely, it just wasn't solved once and for
all by the language designer or by the standard committee.  It's not
necessary for C++ to have a sophisticated built-in array class because
it is relatively easy to build any sort of array you like.  So we have
std::vector and boost::array, and if you need a sparse array or any
other sort you can build that too and they will all work with the
standard algorithms and you can switch out one for another with little
effort.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> "Matthew Heaney" <mheaney@on2.com> wrote in message
> news:<41583b4c$0$74190$39cecf19@news.twtelecom.net>...
> 
> > C++ works by making containers look like built-in types.  That's
> > different from Ada, which (as demonstrated above) makes the built-in
> > type look like a container.
> 
> Ok, but shouldn't that code be generic?  The code above works for only
> one algorithm on one particular array type.

You're still confused.  The local subprograms are analogous to STL
binders and function objects.  The generic part is Generic_Op.  The rest
is just glue.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Keith H Duggar]

> Not to make this a flame war, but it seems that you have never
> been in a professional software engineering environment that
> involved work on your part other than grunt code writing.

Hmm, are you sure you aren't projecting your own shortcomings
onto me? Juding from this post and your others you come across
to me as someone who just recently read a book about software
engineering and now considers himself an authority.

> Even
> someone that has been doing grunt code work for a long project
> would understand what I am saying.

If you are refering to the snip I quoted in saying I didn't
understand, I said so because the ENGLISH was vague and
imprecise.

If you are referring to your point of "documentation is very
important" I have never disputed that and few if any here
would. What I said was that it was off topic in the sense
that the thread was talking about READABILITY of CODE not
understandbility nor the readability of comments and
documentation.

Finally, judging from another of your posts where you wrote

> Many young/inexperienced programmers do not even see why this is
> important, as their code works, and generally they are done with it
> then and there. In the real world, and in my job, most of the time
> is spend updating code. Good times are when I get to design something
> new, most the time is spent doing grunt work.

you, if anyone, seem to fall squarely in the inexperienced
(with respect to software design) grunt hacker group. More
importantly, ad hominem has no place here so I would suggest
that you reframe from it. Especially if you are trying to
avoid flame. Better to focus on specific concrete responses.

> Hopefully it is was just communication errors on my part. :)

I believe it was. Also, I believe you strayed a little from
the issue of readability of CODE into the issue of
documentation and design.

> documents and software code go hand in hand. Something
> that a college student probably has not experienced or
> learned yet.

*smirks* You should try college sometime, you might actually
learn some software engineering. And don't let the email
fool you, I haven't been a "college" student in many years.
And again, ad hominem has no useful place here. That is
something that many people never learn in a lifetime.

> > Again as counter examples take BF and Whitespace. These are
> > of course extreme examples but the valid point is that language
> > absolutely affects readability.
> > 
> 
> Well, lets exclude those languages as I, for one, do not know of
> any real production use of them or anyone that actually uses them
> outside of fun and tinkering. I was talking about languages you
> come across in reality, such as Perl, Python, C, C++.

Then you should not exaggerate by saying "all". Further,
they were simply counter examples to the extreme point
that "syntax does not affect readability" which you seemed
to be arguing.

> I understand the point of readability, but you should understand
> that any good software engineering process should include documentation,
> use cases, and other things that are related to the software and
> is not actual software code. The coding part is generally the easy
> part if the documentation and design are done properly.

I'm glad you understand the point of readability. And, I
never claimed that documentation etc are unimportant. That
is somewhat obvious to me and a point that I for one have
never denied.

> The code
> should just be an implementation or "reality" of the documentation.

The "should just be" is obviously not true. Machine language
is "just an implementation" yet there are obvious reasons
we don't write in it. What code "should be" depends on who
you ask. Many argue it should serve as documentation,
specification, implementation, a design language, etc to
varying degrees. The extreme view that it "should just be
implementation" is just that, extreme. 

> When I say "documentation", I mean documentation that exists
> outside the code itself.

Isn't this thread about the readability of CODE not
not the readability of documentation?

> > Do you or do you not believe that syntax affects readability?
> 
> Of course I do, and thankful for it.

Ok, then case closed. Syntax can affect readbility. And as
I stated previously I found the Python syntax the most
readable for this particular example.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Kevin Cline wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote in message
> news:<1700922.2nPlMsa4Ny@linux1.krischik.com>...
>> Kevin Cline wrote:
>> 
>> > Martin Krischik <krischik@users.sourceforge.net> wrote in message
>> > news:<3673998.bj16mkkOu2@linux1.krischik.com>...
>> >> Matthew Heaney wrote:
>> >> 
>> >> > If AI-302 doesn't meet your needs, then you need to let us know.
>> >> > Please peruse the a-c*.ad[sb] sources at the tigris website.ￜￜ(Note
>> >> > that I'm still incorporating changes from the most recent ARG
>> >> > meeting.)
>> >> 
>> >> I have got my most important baby (indefinite types). And I don't want
>> >> to confuse the ARG. I fully agree that we need a container library
>> >> inside the standart.
>> >> 
>> >> However it would be sad if Ada.Containers would kill off all other
>> >> container libraries. Just like the STL did.
>> > 
>> > I think the STL killed off all the other container libraries because
>> > the STL container/algorithm separation is an extremely powerful design
>> > that dominates all older container library designs. Certainly STL
>> > programming is much cleaner and easeir than programming with the once
>> > popular RogueWave containers.  The STL also has the advantage that it
>> > is relatively easy to write new containers that will work with the STL
>> > algorithms, so that even though new containers are written, they all
>> > look like STL containers.
>> 
>> No Library is perfect, but the "I which I had" list for the STL is much
>> larger then for container out of IBM's OCL. The OCL was not designed for
>> academic correctness bit but for usability.
>> 
>> >> Im am sill looking at IBM OCL thinking
>> >> how much more practical it was. std::string might me academicly
>> >> correct but IString was a lot more usefull in day to day live with all
>> >> the asInt (), asUnsigned (), asAnythingYouEverNeed() methods.
>> > 
>> > The problem with that design is that it isn't readily extensible to
>> > accomodate user-defined types, and it makes generic programming very
>> > difficult.
>> 
>> In 99.99% of all cases I don't need strings on user defined types. I need
>> base_string<char>. I can see that I one day might need
>> base_string<wchar_t>, but I have not until now. They made all that funky
>> design which I just never need.
> 
> That wasn't the sort of extensibility I was thinking of.  I was
> referring to
> the inextensibility of the series of member functions asInt(),
> asUnsigned(), etc.  Collections of functions with names varying
> according to the return type inhibit template programming.  If you
> want to be able to conveniently extract values from a string, you can
> write this template function:
> 
> template <class T> T parse(std::string s)

     thow (something)

> {
>   T result;
>   stringstream strm(s);
>   strm >> result;
>   if (!strm) throw( /* something */ );
>   return result;
> }
> 
> and then you can write:
>   std::string s("10");
>   int i = parse<int>(s);

This is indeed cool. And it tells me that my code is missing a throw.

I wonder how many programmers still use C's itoa for the job. And of those
who do use stringstream how many forgot to check the result.

> I agree that this is not as obvious as it should be.

It should be part of the standart. The algorithm section contains all sorts
of search, sort, stack and whatever else algorithm  - but no string
parsers. Stack algorithms  are < 10 lines as well.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On 27 Sep 2004 21:22:03 -0700, Kevin Cline wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1g2d9xmnita9f.5ecju0eftkqw$.dlg@40tude.net>...
>> On 27 Sep 2004 07:31:44 -0700, Kevin Cline wrote:
>> 
>>> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>...
>>>> kevin.cline@gmail.com (Kevin Cline) writes:
>>>> 
>>>>> One of the most frustrating things I found in Ada programming was the
>>>>> inability to make user-defined types work like the built-in types. 
>>>>> Given
>>>>> 
>>>>>   A: array (1..10) of integer;
>>>>> 
>>>>> then the expression A(5) is a modifiable reference to the fifth
>>>>> element of A.
>>>>> 
>>>>> After experience with C++ it was amazingly frustrating to learn that
>>>>> there was no way I could define My_Container so that I could write:
>>>>> 
>>>>>   C: My_Container ;
>>>>> 
>>>>>   C(5) := 7;
>>>> 
>>>> Indeed, you cannot do this.  In AI-302 (and in Ada.Strings.*), you have to say:
>>>> 
>>>>    Replace_Element (C, Index => 5, By => 7);
>>> 
>>> I think this was a major error in the language design.
>> 
>> It was not an error, in the sense that no irreparable damage was done. It
>> seems that the issue was just put aside for better times. Ada has a rich
>> infrastructure supporting array types and their index types. So to reshape
>> Ada's arrays out of abstract "array interfaces" one need to take all that
>> presently hard-wired infrastructure with. Note that C++ does not solve the
>> problem, because it has no arrays. So it allows you to define [] and leaves
>> you alone with that. It is not the Ada's way (TM).
> 
> C++ solves the problem very nicely, it just wasn't solved once and for
> all by the language designer or by the standard committee.  It's not
> necessary for C++ to have a sophisticated built-in array class because
> it is relatively easy to build any sort of array you like.

... which won't be an implementation of that sophisticated *non-existing*
class. That's the point.

> So we have
> std::vector and boost::array, and if you need a sparse array or any
> other sort you can build that too and they will all work with the
> standard algorithms and you can switch out one for another with little
> effort.

First, that all will be templates, I do not want them, generics are
inherently bad. For instance, it is impossible to have generic programming
on containers of containers. You cannot have a list of items of "array"
types that are different instantiations. Because see above, you have no
that common abstract predecessor. That "arrays" are not arrays, we are just
fooling ourselves.

Secondly it is not checked whether the thing you are implementing *is* an
array which *will* work with all that standard algorithms. You never know
before you instantiate. Ideologically, it is stone age, not the Ada's way,
IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Chris Humphries]

Kevin Cline wrote:
> Chris Humphries <chris@unixfu.net> wrote in message news:<415813FE.9090803@unixfu.net>...
> 
>>Kevin Cline wrote:
>>
>>>Again, the original question was "Why isn't Ada more popular?"  
>>>
>>>The answer I am giving is that most programmers don't have such an
>>>overriding concern for safety that they are willing to write twice as
>>>much code to get the additional safety.
>>>
>>
>>(whoa, what a thread this has become!)
>>
>>Thanks, and good answer. Since then asking that question, I have
>>learned a lot more about Ada. John Barnes' book, "Programming in
>>Ada 96, 2nd Edition" helped tremendously. A very good book. It is
>>now nice to understand just what Ada _is_, and not just another
>>programming language, but more an attempting at progressing software
>>engineering.
>>
>>I also think I understand why Ada is not more popular. Though I
>>am very thankful for open source, and feel very strongly about about
>>it, something bad has grown out of it: bad programmers and programs.
> 
> 
> Bad programmers didn't come from open source.  There have always been
> bad programmers, and there always will be.  Just as it is with music
> and writing and film and art, 90% of all programming sucks.
> 

I didn't mean that, I apologize for the communication error. I meant
that the general open source development community and environment
doesn't generally have a software development process other than
run and see if it does what you think, then repeat. Though the *Unit
classes are spreading out and becoming more popular, though you can
usually tell that they have more formal development standards in place,
such as the Mono (http://mono-project.com which is backed by Novell) and
Zope (http://zope.org which is backed by the Zope Corporation
http://zope.com) projects.

I did not mean to imply that all open source is bad, sure there are
bad projects everywhere (closed and open source).

> 
>>Most open source projects seem to have no formal software development
>>process...
>>Many young/inexperienced programmers do not even see why this is
>>important, as their code works, and generally they are done with it
>>then and there. 
> 
> 
> This is also true for a surprising number of old and experienced
> programmers.
> 
> 
>>In the real world, and in my job, most of the time
>>is spend updating code. Good times are when I get to design something
>>new, most the time is spent doing grunt work.
> 
> 
> This situation is common, but not inevitable.  On a good project,
> design is a continuous process.  Unfortunately, most programs reach
> the point where any change is so risky that developers spend all their
> time trying to figure out how to squeeze in a new feature without
> breaking the existing features.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> Note that C++ does not solve the
> problem, because it has no arrays.

What exactly do you mean by that? I suppose it's some kind of metaphore...

Of course C++ has got arrays inherited from C which are the core language 
construct, and std::vector<> which is safe and dynamic-sized version of an 
array.

> So it allows you to define [] and leaves
> you alone with that. It is not the Ada's way (TM).

Again I don't see your point here... As to the C++(R) std::vector<>, there 
is operator [] defined.

Best regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

>>> And just for the record: atio is a C function - you need the overhead of
>>> convertion the std::string into a char* and std::strstream seem quite
>>> heavy
>>> weight for just a simple task of convertion a string from and to an int.
>>
>>     Actually, the overhead of conversion is virtually none (at least in
>> Stlport implementation). You just call std::string::c_str() which just
>> returns a pointer to the data, and which is also inlined.
>
> From what I read about std::string strings do not need to be '\0'
> terminated
> and std::string::c_str() will add a terminator if needed. Thats unlike
> std::string::data() which does not add a '\0'.

Yup, you're absolutely right. But Stlport implementation always stores '\0'
at the end, so std::string::c_str() boils down to returning a pointer. On
the other hand, the GCC implementation writes terminating '\0' every time
this function is called. However, this is still constant complexity and a
little overhead contrary to what many people suspect - that converting
std::string to char * requires copying whole the contents of the string to
some temporary buffer.

> Well on the other side
> std::string::c_str() is const.

c_str() may modify the data even despite being const if the data is declared
with mutable specifier. And that's how it's done in GCC.

> This all leaves me wonder how actually works. And if I ever need to work
> again if I had a Euro for every call where std::string::data() and
> std::string::c_str() have been mixed up.

At the beginning I was also confusing the two. But since I've read the
documentation carefully, I always remember the difference... ;-)

>> void f() {
>>
>>   //instead of std::string::fromInt(int)
>>   oss MyOutputStream;
>>   MyOutputStream << i;
>>   MyString = MyOutputStream.str();
>>
>>   //instead of std::string::toInt()
>>   iss MyInputStream;
>>   MyInputStream.str(MyString);
>>   MyInputStream >> i;
>>
>> } //f()
>
> Well, nice. But are you shure you don't leak memory here. I remember there
> was something about ownership and the str() function.

I don't know which place exactly you mean, but I'm pretty sure it all works
as supossed. Strings, streams and all other objects of std library classes
take care for their storage themselves - a user doesn't have to worry about 
this. Coud you be more specific?

>> //same things as one-liners:
>
> Please DON'T. This is comp.lang.ada after all. Three liners are quite OK.

OK, I promise this won't happen anymore! ;-)

> Not only that you can shoot yourself in the foot with C++ (You can do that
> with Ada as well) but the weapon is allways loaded (that is, cannot be
> unloaded), has no safety lever, and the trigger is allwas taut. And of
> corse it is a snipers hair trigger going off at the slightest touch.
>
> So no matter how experienced you are, you are allways in danger of
> shooting
> your food of.


I can't agree with that at all. In C++ there is almost always an
alternative. You may use std::vector<> instead of arrays, std::auto_ptr<>
instead of naked pointers etc. But still you have a choice - if you really
need to have a total low-level control on your program, you may have it.
Otherwise use higher abstraction-level utilities. What you say might be
eventually true for C, but not for C++. And the difference between the two
is enormous, unfortunately many people think C and C++ is the same...

Best regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> First, that all will be templates, I do not want them, generics are
> inherently bad. For instance, it is impossible to have generic programming
> on containers of containers. You cannot have a list of items of "array"
> types that are different instantiations.

    I don't know about Ada, but in C++ you can, and such "templates nesting" 
is even the recommended way to have multi-dimensional vectors:

typedef vector< vector < vector <int> > > vector_int_3D;

> Secondly it is not checked whether the thing you are implementing *is* an
> array which *will* work with all that standard algorithms. You never know
> before you instantiate.
> Ideologically, it is stone age, not the Ada's way,
> IMO.

    C++ templates are not checked only when instantiated. Every template 
body is parsed, whether it's instantiated anywhere or not (this is why there 
is the typename keyword).
    That's as to grammar correctness. And if you mean semantics, I don't 
thing Ada compiler will check them for you as well... You also have to write 
some program using generic instantiations to test whether they work as you 
expect them to do.

Best regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Robert Kawulak <tigrisek@interia.pl> wrote:
: 
: Of course C++ has got arrays inherited from C which are the core language 
: construct,

Prior to C99, functions had no means to know how many
floats there were in the "array" argument:

float foo(float a[]);

The article "Array Variables" by Dijkstra might be interesting.
As an addition in Ada, you can specify the type, and therefore the range,
of discrete values that can be used as index values.


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1636756.M7hCqjsVMv@linux1.krischik.com>...
> Kevin Cline wrote:
> 
> > Martin Krischik <krischik@users.sourceforge.net> wrote in message
> > news:<1700922.2nPlMsa4Ny@linux1.krischik.com>...
> >> Kevin Cline wrote:
> >> 
> >> > Martin Krischik <krischik@users.sourceforge.net> wrote in message
> >> > news:<3673998.bj16mkkOu2@linux1.krischik.com>...
> >> >> Matthew Heaney wrote:
> >> >> 
> >> >> > If AI-302 doesn't meet your needs, then you need to let us know.
> >> >> > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note
> >> >> > that I'm still incorporating changes from the most recent ARG
> >> >> > meeting.)
> >> >> 
> >> >> I have got my most important baby (indefinite types). And I don't want
> >> >> to confuse the ARG. I fully agree that we need a container library
> >> >> inside the standart.
> >> >> 
> >> >> However it would be sad if Ada.Containers would kill off all other
> >> >> container libraries. Just like the STL did.
> >> > 
> >> > I think the STL killed off all the other container libraries because
> >> > the STL container/algorithm separation is an extremely powerful design
> >> > that dominates all older container library designs. Certainly STL
> >> > programming is much cleaner and easeir than programming with the once
> >> > popular RogueWave containers.  The STL also has the advantage that it
> >> > is relatively easy to write new containers that will work with the STL
> >> > algorithms, so that even though new containers are written, they all
> >> > look like STL containers.
> >> 
> >> No Library is perfect, but the "I which I had" list for the STL is much
> >> larger then for container out of IBM's OCL. The OCL was not designed for
> >> academic correctness bit but for usability.
> >> 
> >> >> Im am sill looking at IBM OCL thinking
> >> >> how much more practical it was. std::string might me academicly
> >> >> correct but IString was a lot more usefull in day to day live with all
> >> >> the asInt (), asUnsigned (), asAnythingYouEverNeed() methods.
> >> > 
> >> > The problem with that design is that it isn't readily extensible to
> >> > accomodate user-defined types, and it makes generic programming very
> >> > difficult.
> >> 
> >> In 99.99% of all cases I don't need strings on user defined types. I need
> >> base_string<char>. I can see that I one day might need
> >> base_string<wchar_t>, but I have not until now. They made all that funky
> >> design which I just never need.
> > 
> > That wasn't the sort of extensibility I was thinking of.  I was
> > referring to
> > the inextensibility of the series of member functions asInt(),
> > asUnsigned(), etc.  Collections of functions with names varying
> > according to the return type inhibit template programming.  If you
> > want to be able to conveniently extract values from a string, you can
> > write this template function:
> > 
> > template <class T> T parse(std::string s)
> 
>      thow (something)
> 
> > {
> >   T result;
> >   stringstream strm(s);
> >   strm >> result;
> >   if (!strm) throw( /* something */ );
> >   return result;
> > }
> > 
> > and then you can write:
> >   std::string s("10");
> >   int i = parse<int>(s);
> 
> This is indeed cool. And it tells me that my code is missing a throw.

Yes, and if you define a new type, say MyType, then you just have 
to implement:
    istream& operator>>(istream& i, MyType& mt) { ...; return i; }

and then you can write: MyType mt = parse<MyType>(s);

Since the input and output for all types is handled identically,
generic programming is easy.  I once wrote a small set of template
classes to map relational database columns to object fields, like
this:

  struct Person
  {
    SocialSecurityNumber ssn;
    Date birthDate;
    std::string firstName;
    ...
  }

  DatabaseMap<Person> personMap;
  personMap
    .insert("PERSON", "SSN", &Person::ssn)
    .insert("PERSON", "DOB", &Person::dateOfBirth)
    .insert("PERSON", "FIRST", &Person::firstName)
    ...;

  personMap.Insert(someone);
  databaseCursor = // some query //;
  personMap.Read(databaseCursor, someone);
  someone.firstName = "Fred";
  personMap.Update(someone);
  ...

This would have been completely unwieldy in Ada for two reasons:
1. There would have been dozens of complex instantiations of insert.
2. AFAIK, Ada does not support pointer-to-record member so it would
have been necessary to somehow wrap each record member with a
function.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<u7jqeubqg.fsf@earthlink.net>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > "Matthew Heaney" <mheaney@on2.com> wrote in message
> > news:<41583b4c$0$74190$39cecf19@news.twtelecom.net>...
> > 
> > > C++ works by making containers look like built-in types.  That's
> > > different from Ada, which (as demonstrated above) makes the built-in
> > > type look like a container.
> > 
> > Ok, but shouldn't that code be generic?  The code above works for only
> > one algorithm on one particular array type.
> 
> You're still confused.  The local subprograms are analogous to STL
> binders and function objects.  The generic part is Generic_Op.  The rest
> is just glue.

But 14 lines of glue for every different array type that I want to use
with Generic_Op?  That's the sort of repetition that turned me away
from Ada in the first place.  I like languages where I can say what I
want, and only have to say it once.  I don't like languages where I
have to cut and paste endless variations of boilerplate code.  For
that reason I like C++ and Perl and LISP and don't like Ada and Java
and C#.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message
> news:<u7jqeubqg.fsf@earthlink.net>...
> > 
> > You're still confused.  The local subprograms are analogous to STL
> > binders and function objects.  The generic part is Generic_Op.  The rest
> > is just glue.
> 
> But 14 lines of glue for every different array type that I want to use
> with Generic_Op?  That's the sort of repetition that turned me away
> from Ada in the first place.

You're still confused.  The "unnecessary code" typically includes
up-level references to entities in the enclosing scope, e.g.

procedure Op (C : CT) is

   Sum : Integer'Base := 0;

   procedure Add_E_To_Sum (E : Natural) is
   begin
      Sum := Sum + E;
   end;

begin

   C.Iterate (Sum'Access);

   ... --do something with Sum

end Op;


> I like languages where I can say what I want, and only have to say it
> once.  I don't like languages where I have to cut and paste endless
> variations of boilerplate code.  For that reason I like C++ and Perl
> and LISP and don't like Ada and Java and C#.

That's just swell.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

Oops!  That should be:

> procedure Op (C : CT) is
> 
>    Sum : Integer'Base := 0;
> 
>    procedure Add_E_To_Sum (E : Natural) is
>    begin
>       Sum := Sum + E;
>    end;
> 
> begin
> 
>    C.Iterate (Add_E_To_Sum'Access);
> 
>    ... --do something with Sum
> 
> end Op;

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dale Stanbrough]

Kevin Cline wrote:


> 2. AFAIK, Ada does not support pointer-to-record member so it would
> have been necessary to somehow wrap each record member with a
> function.

You can take the address of a field in a record. I'm not sure what it
means if you have a representation clause for the record though.

If you do Gnat says...

gcc -c fred.adb
fred.adb:19:10: warning: taking address of object not aligned on storage 
unit

so at least one compiler tells you there is danger. Presumably once you
have the address, the pointer knows nothing about the special alignment
of the object.

What happens in the C world in similar circumstances?


Dale


The following compile with gnat v3.3...

with system; use system;

procedure Fred is
   type R is record
      a : integer;
      b : character;
   end record;

   A : System.Address;
   rec : R;

begin
   A :=  rec.a'address;
end;



with system; use system;

procedure Fred is
   type R is record
      a : integer;
      b : boolean;
   end record;

   for R use
      record
        A at 0 range 0..31;
        b at 4 range 3..3;
      end record;

   A : System.Address;
   rec : R;

begin
   A :=  rec.b'address;
end;

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Robert Kawulak wrote:

> Hi,
> 
>>>> And just for the record: atio is a C function - you need the overhead
>>>> of convertion the std::strivalidto a char* and std::strstream seem
>>>> quite heavy
>>>> weight for just a simple task of convertion a string from and to an
>>>> int.
>>>
>>>     Actually, the overhead of conversion is virtually none (at least in
>>> Stlport implementation). You just call std::string::c_str() which just
>>> returns a pointer to the data, and which is also inlined.
>>
>> From what I read about std::string strings do not need to be '\0'
>> terminated
>> and std::string::c_str() will add a terminator if needed. Thats unlike
>> std::string::data() which does not add a '\0'.
> 
> Yup, you're absolutely right. But Stlport implementation always stores
> '\0' at the end, so std::string::c_str() boils down to returning a
> pointer. On the other hand, the GCC implementation writes terminating '\0'
> every time this function is called. However, this is still constant
> complexity and a little overhead contrary to what many people suspect -
> that converting std::string to char * requires copying whole the contents
> of the string to some temporary buffer.

But that means that the strings need "capacity () - size () >= 1" so that
there is allways one spare byte for the '\0'.

>> Well on the other side
>> std::string::c_str() is const.
> 
> c_str() may modify the data even despite being const if the data is
> declared with mutable specifier. And that's how it's done in GCC.

I was thinking about "capacity () - size () == 0" - then c_str() would need
to resize. Doesn't happen in your implementation - but is this valid for
all.

>> This all leaves me wonder how actually works. And if I ever need to work
>> again if I had a Euro for every call where std::string::data() and
>> std::string::c_str() have been mixed up.
 
> At the beginning I was also confusing the two. But since I've read the
> documentation carefully, I always remember the difference... ;-)
 
>>> void f() {
>>>
>>>   //instead of std::string::fromInt(int)
>>>   oss MyOutputStream;
>>>   MyOutputStream << i;
>>>   MyString = MyOutputStream.str();
>>>
>>>   //instead of std::string::toInt()
>>>   iss MyInputStream;
>>>   MyInputStream.str(MyString);
>>>   MyInputStream >> i;
>>>
>>> } //f()
>>
>> Well, nice. But are you shure you don't leak memory here. I remember
>> there was something about ownership and the str() function.
 
> I don't know which place exactly you mean, but I'm pretty sure it all
> works as supossed. Strings, streams and all other objects of std library
> classes take care for their storage themselves - a user doesn't have to
> worry about this. Coud you be more specific?

I might me mistaken with the old strstream.
 
>>> //same things as one-liners:
>>
>> Please DON'T. This is comp.lang.ada after all. Three liners are quite OK.

> OK, I promise this won't happen anymore! ;-)
 
>> Not only that you can shoot yourself in the foot with C++ (You can do
>> that with Ada as well) but the weapon is allways loaded (that is, cannot
>> be unloaded), has no safety lever, and the trigger is allwas taut. And of
>> corse it is a snipers hair trigger going off at the slightest touch.
>>
>> So no matter how experienced you are, you are allways in danger of
>> shooting
>> your food of.

> I can't agree with that at all. In C++ there is almost always an
> alternative. You may use std::vector<> instead of arrays, std::auto_ptr<>
> instead of naked pointers etc. But still you have a choice - if you really
> need to have a total low-level control on your program, you may have it.
> Otherwise use higher abstraction-level utilities. What you say might be
> eventually true for C, but not for C++. And the difference between the two
> is enormous, unfortunately many people think C and C++ is the same...

Not quite true. I did have to make Ada::Range<class type, type First, type
Last> myself. Actually, I still have to make it. My Current implementation
is for the old standart (as in Ada::IntegerRange<int First, int Last>). C++
has protection against buffer overruns - but the new JPEC Viruses work
integer overurns.

And there is no:

typedef explicit int My_Int.

And that means that

typedef Ada :: Range <int, 1, 12> US_Hours;
typedef Ada :: Range <int, 1, 12> Month;

are the same for C++. But there are not in real live. And if I use:

class US_Hours Ada :: Range <int, 1, 12> {};
class Month Ada :: Range <int, 1, 12> {};

I loose the constructors. So there is still something to be improved.

With Regards

Martin


-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Tue, 28 Sep 2004 19:21:04 +0200, Robert Kawulak wrote:

>> Note that C++ does not solve the
>> problem, because it has no arrays.
> 
> What exactly do you mean by that? I suppose it's some kind of metaphore...
> 
> Of course C++ has got arrays inherited from C which are the core language 
> construct, and std::vector<> which is safe and dynamic-sized version of an 
> array.

Pointers are not arrays.

>> So it allows you to define [] and leaves
>> you alone with that. It is not the Ada's way (TM).
> 
> Again I don't see your point here... As to the C++(R) std::vector<>, there 
> is operator [] defined.

An ability to index is just one of many array properties. The whole list is
very large.

Provocatively, I would claim that an instance of std::vector is not an
array. For a type to be an array means that the language has some kind of
array interface defined and thus it can check a type against that interface
to verify whether the type implements the interface. There is no such thing
in C++. You can claim that the template std::vector defines such array, but
then what would you do with My_Template_Array designed independently on
std::vector? It will not be an array then!

BTW, Ada's Unbounded_String is *not* an array, alas.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Xenos]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:3060085.UHp9MgIIe7@linux1.krischik.com...
> typedef explicit int My_Int.
>
> And that means that
>
> typedef Ada :: Range <int, 1, 12> US_Hours;
> typedef Ada :: Range <int, 1, 12> Month;

This problem can be overcome by adding a "unique class" to your template if
you want them to be distinuished:

class default_class {};

template Range<class T, T lo, T hi, class U = default_class>
class Range;

Now if you need the range to be a new type:

class hours_range {};
class month_range;
typedef Range<int, 1, 12, hours_range> Hours;
typedef Range<int, 1, 12, month_range> Month;

They are now unique classes.

>
> are the same for C++. But there are not in real live. And if I use:
>
> class US_Hours Ada :: Range <int, 1, 12> {};
> class Month Ada :: Range <int, 1, 12> {};
>
> I loose the constructors. So there is still something to be improved.

Not true!  You cannot use initializer lists if the class has a constructor.
This is where Ada and C++ differ.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Wed, 29 Sep 2004 01:26:39 +0200, Robert Kawulak wrote:

>> First, that all will be templates, I do not want them, generics are
>> inherently bad. For instance, it is impossible to have generic programming
>> on containers of containers. You cannot have a list of items of "array"
>> types that are different instantiations.
> 
>     I don't know about Ada, but in C++ you can, and such "templates nesting" 
> is even the recommended way to have multi-dimensional vectors:
> 
> typedef vector< vector < vector <int> > > vector_int_3D;

It is another thing. What I meant is that you cannot have a vector
containing elements of vector<int>, vector<unsigned>, vector<long> etc.
vector<A> and vector<B> are unrelated types even if A is a descendant of B
or related to B. What do you want from a macro extension? (:-))

>> Secondly it is not checked whether the thing you are implementing *is* an
>> array which *will* work with all that standard algorithms. You never know
>> before you instantiate.
>> Ideologically, it is stone age, not the Ada's way,
>> IMO.
> 
>     C++ templates are not checked only when instantiated. Every template 
> body is parsed, whether it's instantiated anywhere or not (this is why there 
> is the typename keyword).
>     That's as to grammar correctness. And if you mean semantics, I don't 
> thing Ada compiler will check them for you as well... You also have to write 
> some program using generic instantiations to test whether they work as you 
> expect them to do.

No, Ada generics have contracts. It means that when you write:

generic
   type X is private;
procedure Foo (Object : in out X);

it is not same as

template <class X>
   void Foo (X& Object);

because then you cannot refer Baz defined on X in Foo. Baz is not in the
contract. So you need not to write any test, the Foo will not compile. You
have to add Baz to the contract:

generic
   type X is private;
   with procedure Baz (Object : in out X);
procedure Foo (Object : in out X);

Similarly with arrays:

generic
   type Index is ...
   type Element is ...
   type Vector is array (Index range <>) of Element;
procedure Foo (Container : in out Vector);

Vector here is an array not because it has ()-operation, but because it
conforms to the array interface. When you write an implementation of Foo
you can rely on this and only this, nothing else. It is far away from C++
ideology of templates.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:

: 2. AFAIK, Ada does not support pointer-to-record member

It does, but you have to tell your readers that a record
component is aliased. (And you have to specify the kind of pointer you
want, that is, read only, or update pointers.)


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message
> news:<u7jqeubqg.fsf@earthlink.net>...
> > 
> > You're still confused.  The local subprograms are analogous to STL
> > binders and function objects.  The generic part is Generic_Op.  The
> > rest is just glue.
> 
> But 14 lines of glue for every different array type that I want to use
> with Generic_Op?  That's the sort of repetition that turned me away
> from Ada in the first place.  I like languages where I can say what I
> want, and only have to say it once.  I don't like languages where I
> have to cut and paste endless variations of boilerplate code.  For
> that reason I like C++ and Perl and LISP and don't like Ada and Java
> and C#.

I should have pointed out that there's nothing that precludes this in
Ada.  It's exactly analogous to template specializations in C++.  

I gave an example of a Generic_Op that works with a container interface,
and then made that work with an array.  But of course, we could have
hidden this glue code behind a specialization of the algorithm for array
types:

generic
   type Cursor is private;
...
procedure Generic_Op (...);

generic
   type IT is (<>);
   type ET is private;
   type Array_T is array (IT) of ET;
   ...
procedure Generic_Op_Constrained_Array (...);

generic
   type IT is (<>);
   type ET is private;
   type Array_T is array (IT range <>) of ET;
   ...
procedure Generic_Op_Unconstrained_Array (...);

generic
   type IT is (<>);
   with procedure Swap (I, J : IT) is <>;
   ...
procedure Generic_Op_Anonymous_Array (...);

generic
   type IT is (<>);
   type ET (<>) is limited private;
   type Array_T is array (IT range <>) of access ET;
   ...
procedure Generic_Op_Array_Access_Component (...);


You get the idea.  This is no different from the C++ technique of
specializing a generic algorithm on the type.  

I said in my previous post that the local subprograms often make
up-level references to the enclosing scope.  Another example of that is
if I declare an anonymous array object:

declare
   A : array (1 .. N) of access Shape'Class;
begin

Pretend Generic_Op is a sort algorithm.  In order to sort this array
object, I need to use the most general specialization for arrays (it's
the one listed above that accepts a Swap procedure), because I don't
have an array type to use as the generic actual.  Something like:

declare
   A : array (1 .. N) of access Shape'Class;
begin
   ...

   Sort_A:
   declare
      function Less (I, J : Positive) return Boolean is
      begin
         return A (I) < A (J);  --or whatever
      end;

      procedure Swap (I, J : Positive) is
         SI : Shape'Class renames A (I).all'Access;
      begin
         A (I) := A (J);
         A (J) := SI;
      end;

      procedure Sort is
         new Generic_Sort_Anonymous_Array (Positive);
   begin
      Sort (A'First, A'Last);
   end Sort_A;

   ...
end;

Here the local subprograms provide the glue to bind a pure algorithm to
an actual object.  

The generic is named Generic_Sort_Anonymous_Array, but really that
algorithm works for any array-like thing that uses a discrete index to
refer to elements.  You could use it to sort a vector or deque, for
example.

This example was motivated by the ai302/examples/shapes example, which
was inspired by the example in Musser (who was himself inspired by the
same example in Strustroup).

-Matt

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

kevin.cline@gmail.com (Kevin Cline) writes:

> 2. AFAIK, Ada does not support pointer-to-record member so it would
> have been necessary to somehow wrap each record member with a
> function.

Declare the record component as aliased.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Robert Kawulak" <tigrisek@interia.pl> wrote in message
news:cje1hj$jkh$1@nemesis.news.tpi.pl...
>
>     I don't know about Ada, but in C++ you can, and such "templates
nesting"
> is even the recommended way to have multi-dimensional vectors:
>
> typedef vector< vector < vector <int> > > vector_int_3D;

Typically, you'd use a 3-dimensional array:

   type Array_Type is
      array (Positive range <>, Positive range <>, Positive range <>) of
Integer;

Of course, you can pass the type made available via an instantiation of a
generic package as the actual type of some other instantiation.  The
container libraray for Ada 2005 (see AI-302) was specially designed to allow
a container as the element of another container.  So you could say:

package IV is new Ada.Containers.Vectors (Positive, Integer);

package IVV is new A.C.V (Positive, IV.Vector);

package IVVV is new A.C.V (Positive, IVV.Vector);

You'd probably want to declare a local wrapper function to give you a nice
syntax for selecting an element:

   V : IVVV.Vector;

   function E (I, J, K : Positive) return Integer is ...;
begin
   N := E (1, 2, 3);

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> : Of course C++ has got arrays inherited from C which are the core
> language
> : construct,
>
> Prior to C99, functions had no means to know how many
> floats there were in the "array" argument:
>
> float foo(float a[]);

And that's where the second part of the quoted sentence applies: "and
std::vector<> (...)". In C++, C-style arrays are really meant to be used
mostly for "low-level of abstraction" coding. And the recommended way to
solve your problem is:

float foo(float a[], size_t a_size);

But please don't tell me this is ugly and error-prone etc. It *is*, that's 
why there are std::vector<> and std::valarray<>.

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

>>> Note that C++ does not solve the
>>> problem, because it has no arrays.
[...]
>> Of course C++ has got arrays inherited from C which are the core language
>> construct
[...]
> Pointers are not arrays.

Ah, now I see what you meant! ;-)

>>> So it allows you to define [] and leaves
>>> you alone with that. It is not the Ada's way (TM).
>>
>> Again I don't see your point here... As to the C++(R) std::vector<>,
>> there
>> is operator [] defined.
>
> An ability to index is just one of many array properties. The whole list
> is
> very large.

As well as the list of methods and operators and other members of
std::vector<>... What particular thing are you missing there?

> Provocatively,

;-P

> I would claim that an instance of std::vector is not an
> array. For a type to be an array means that the language has some kind of
> array interface defined and thus it can check a type against that
> interface
> to verify whether the type implements the interface. There is no such
> thing
> in C++.

There is - C arrays. But the definition you wrote shows that you still think
the Ada way (TM) - in C++ (R) built-in types and user-defined types are
treated the same way. Why you think that it is necessary for the core
language to know what is an array and what isn't? In Ada, you can't use
anything else than built-in array exactly as an array. In C++ you can.

> You can claim that the template std::vector defines such array,
> but
> then what would you do with My_Template_Array designed independently on
> std::vector? It will not be an array then!

The Ada way, again - who says there can be one and only one type
representing an array? In C++you have C arrays, std::vector<>,
std::valarray<> and even std::string - and all these can be treated in
uniform way as arrays.

> BTW, Ada's Unbounded_String is *not* an array, alas.

Fortunately std::string might be considered as a container, which you may
use like std::vector<char> in most cases. ;-)

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi all,

>> Yup, you're absolutely right. But Stlport implementation always stores
>> '\0' at the end, so std::string::c_str() boils down to returning a
>> pointer. On the other hand, the GCC implementation writes terminating
>> '\0'
>> every time this function is called. However, this is still constant
>> complexity and a little overhead contrary to what many people suspect -
>> that converting std::string to char * requires copying whole the contents
>> of the string to some temporary buffer.
>
> But that means that the strings need "capacity () - size () >= 1" so that
> there is allways one spare byte for the '\0'.

Well, in those particular implementations yes, but AFAIK it's not imposed by
the standard.

> I was thinking about "capacity () - size () == 0" - then c_str() would
> need
> to resize. Doesn't happen in your implementation - but is this valid for
> all.

As said above, it's not. An implementation can choose freely, but I suspect
that vast majority use "capacity () - size () >= 1" due to efficiency -
after all this one extra byte doesn't cost a lot compared to creating new
buffer for whole the string and copying it in case of a call to c_str().

>> I can't agree with that at all. In C++ there is almost always an
>> alternative. You may use std::vector<> instead of arrays, std::auto_ptr<>
>> instead of naked pointers etc. But still you have a choice - if you
>> really
>> need to have a total low-level control on your program, you may have it.
>> Otherwise use higher abstraction-level utilities. What you say might be
>> eventually true for C, but not for C++. And the difference between the
>> two
>> is enormous, unfortunately many people think C and C++ is the same...
>
> Not quite true. I did have to make Ada::Range<class type, type First, type
> Last> myself. Actually, I still have to make it. My Current implementation
> is for the old standart (as in Ada::IntegerRange<int First, int Last>).
> C++
> has protection against buffer overruns - but the new JPEC Viruses work
> integer overurns.

That one is indeed missing in the standard (that's why I've used 'almost'
above ;-) and you have to make it on your own (fortunately it's a trivial
task, and you do it only once and then reuse).

> And there is no:
>
> typedef explicit int My_Int.
>
> And that means that
>
> typedef Ada :: Range <int, 1, 12> US_Hours;
> typedef Ada :: Range <int, 1, 12> Month;
>
> are the same for C++. But there are not in real live. And if I use:
>
> class US_Hours Ada :: Range <int, 1, 12> {};
> class Month Ada :: Range <int, 1, 12> {};
>
> I loose the constructors. So there is still something to be improved.

That's all very true what you say and it IS going to be improved - there are
already papers submitted to the C++ standarisation commettee concerning
strongly-typed typedefs.

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Mark Lorenzen]

"Matthew Heaney" <mheaney@on2.com> writes:

> What operations would you like AI-302 to provide, that you think are
> missing?  It would help the designers of that library if you could be more
> specific.  Otherwise we can't help you.

After having thought about this a bit, I would say that an equivalent
of C++s function classes is missing.

If function classes were introduced, we could build pretty powerful
algorithms traversing the different containers and f.ex. implement an
infinite list (also called lazy list) container. Right now the
containers only allow for a procedure to process the elements of a
container.

Regards,
- Mark Lorenzen

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

> After having thought about this a bit, I would say that an equivalent
> of C++s function classes is missing.
>
> If function classes were introduced, we could build pretty powerful
> algorithms traversing the different containers and f.ex. implement an
> infinite list (also called lazy list) container. Right now the
> containers only allow for a procedure to process the elements of a
> container.

Well, you can do that using the procedure, and depositing a result
somewhere prior to returning.  

For example, in the wordcount example, you need to compute a predicate
function on map cursors:

   Sort_Vector :
   declare
      function "<" (L, R : Wordcount_Maps.Cursor) return Boolean is
         Result : Boolean;

         procedure Query_L (LK : String; LN : Natural) is
            procedure Query_R (RK : String; RN : Natural) is
            begin
               if LN > RN then
                  Result := True;
               elsif LN < RN then
                  Result := False;
               else
                  Result := Ada.Strings.Less_Case_Insensitive (LK, RK);
               end if;
            end Query_R;
         begin
            Query_Element (R, Query_R'Access);
         end;
      begin
         Query_Element (L, Query_L'Access);
         return Result;
      end;

      procedure Sort is
         new Wordcount_Vectors.Generic_Sort;
   begin
      Sort (V);
   end Sort_Vector;

This does everything the a "function class" would do in C++.

The ARG is currently discussing whether to allow functions to return
anonymous access types, which would allow us to write the predicate as:

      function "<" (L, R : Wordcount_Maps.Cursor) return Boolean is
         Result : Boolean;

         LN : Natural renames Query_Element (L).all;
         LN : Natural renames Query_Element (R).all;
      begin
         if LN > RN then
            return True;
         end if;

         if LN < RN then
            return False;
         end if;

        declare
           LK : String renames Query_Key (L).all;
           RK : String renames Query_Key (R).all;
        begin
           return Ada.Strings.Less_Case_Insensitive (LK, RK);
        end;
      end "<";

Please give me a specific, concrete example of something you can do in
C++, that you believe cannot be done using the AI-302 container library.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<ufz51rs1l.fsf@earthlink.net>...
> kevin.cline@gmail.com (Kevin Cline) writes:
> 
> > 2. AFAIK, Ada does not support pointer-to-record member so it would
> > have been necessary to somehow wrap each record member with a
> > function.
> 
> Declare the record component as aliased.

There seems to be some confusion between creating a pointer to a
particular member of a particular record, and the C++ pointer to
member type.

In C++:

struct X
{
  int a;
  int b;
};

X x1 = { 3, 5 };
X x2 = { 4, 6 };

int X::*ptm = &X::a;

ASSERT(x1->*ptm == 3);
ASSERT(x2->*ptm == 4);

ptm = &X::b;

ASSERT(x1->*ptm == 5);
ASSERT(x2->*ptm == 6);

The availability of pointers to members makes it possible to concisely
express the mapping between the a data member and the "A" column of a
database table.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dale Stanbrough]

kevin.cline@gmail.com (Kevin Cline) wrote:

> There seems to be some confusion between creating a pointer to a
> particular member of a particular record, and the C++ pointer to
> member type.

Indeed.

> ASSERT(x1->*ptm == 3);
> ASSERT(x2->*ptm == 4);
> 
> ptm = &X::b;
> 
> ASSERT(x1->*ptm == 5);
> ASSERT(x2->*ptm == 6);
> 
> The availability of pointers to members makes it possible to concisely
> express the mapping between the a data member and the "A" column of a
> database table.

Ada can't do this directly. You can get the starting bit position of a
field, and could convert this into a byte/word offset and add it to a
pointer.

Using the attribute 'First_Bit you can find the number of bits offset
into a record, but only for an object, not a type.
This means that you couldn't easily create a generic to do this without
creating an object first.

Does anyone know why this was restricted to objects only?

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Wed, 29 Sep 2004 20:11:46 +0200, Robert Kawulak wrote:

>>>> So it allows you to define [] and leaves
>>>> you alone with that. It is not the Ada's way (TM).
>>>
>>> Again I don't see your point here... As to the C++(R) std::vector<>,
>>> there
>>> is operator [] defined.
>>
>> An ability to index is just one of many array properties. The whole list
>> is very large.
> 
> As well as the list of methods and operators and other members of
> std::vector<>... What particular thing are you missing there?

Slices (subarrays), ranges (index subsets), aggregates (literal values),
looping (automatic iterators), stack allocated arrays ...

>> Provocatively,
> 
> ;-P
> 
>> I would claim that an instance of std::vector is not an
>> array. For a type to be an array means that the language has some kind of
>> array interface defined and thus it can check a type against that
>> interface
>> to verify whether the type implements the interface. There is no such
>> thing
>> in C++.
> 
> There is - C arrays. But the definition you wrote shows that you still think
> the Ada way (TM) - in C++ (R) built-in types and user-defined types are
> treated the same way.

Types yes, array types not. That's the point not any type is array type.
You are arguing in terms of types, try to go one step up. Array types is a
set of types.

> Why you think that it is necessary for the core
> language to know what is an array and what isn't? In Ada, you can't use
> anything else than built-in array exactly as an array. In C++ you can.

You get me wrong. I do not argue in favor of built-in arrays. I argue for
an ability to have abstract array interfaces either user-defined or
built-in, no matter. C++ does not have them and its template mechanism does
not help here (*). Ada has them built-in, but does not allow to implement
an array by, say, a record type.

>> You can claim that the template std::vector defines such array,
>> but then what would you do with My_Template_Array designed independently on
>> std::vector? It will not be an array then!
> 
> The Ada way, again - who says there can be one and only one type
> representing an array? In C++you have C arrays, std::vector<>,
> std::valarray<> and even std::string - and all these can be treated in
> uniform way as arrays.

You mean operator[] here. As I said before, it is not enough.

>> BTW, Ada's Unbounded_String is *not* an array, alas.
> 
> Fortunately std::string might be considered as a container, which you may
> use like std::vector<char> in most cases. ;-)

Can you use it *as* std::vector<char>? No, they are two different
*unrelated* types. Same as in Ada, where Unbounded_String can be used
*like*, but not *as* String.

------------
(*) The meta-language of C++ templates is untyped. So you cannot define a
set of types "Array_Containers" and require its instance (an array) as a
template parameter.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Robert Kawulak wrote:

>> But that means that the strings need "capacity () - size () >= 1" so that
>> there is allways one spare byte for the '\0'.
> 
> Well, in those particular implementations yes, but AFAIK it's not imposed
> by the standard.
> 
>> I was thinking about "capacity () - size () == 0" - then c_str() would
>> need
>> to resize. Doesn't happen in your implementation - but is this valid for
>> all.
> 
> As said above, it's not. An implementation can choose freely, but I
> suspect that vast majority use "capacity () - size () >= 1" due to
> efficiency - after all this one extra byte doesn't cost a lot compared to
> creating new buffer for whole the string and copying it in case of a call
> to c_str().

Well, since all book I have read state that the pointer is valid until a
"non const method" is called there are only two possible implementations
left: The "capacity () - size () >= 1" and the "spare buffer/pointer"
solution which would keep spearate buffers and/or pointers for different
representations.

But maybe there are exotic solutions as well.

With Regards

Martin 
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409291942.5790386d@posting.google.com...
>
> There seems to be some confusion between creating a pointer to a
> particular member of a particular record, and the C++ pointer to
> member type.
>
> In C++:
[snip]

There seems to be some confusion between creating an offset to a record
component, and simply using an Ada function pointer:

In Ada:

declare
   type T is record
      A, B : Integer;
   end record;

   function A (O : T) return Integer is
   begin
     return O.A;
   end;

   function B (O : T) return Integer is
   begin
      return O.B;
   end;

   type Query_Type is access function (O : T) return Integer;

   Query : Query_Type := A'Access;

   O1 : T := (3, 5);
   O2 : T := (4, 6);

begin

   pragma Assert (Query (O1) = 3);
   pragma Assert (Query (O2) = 4);

   Query := B'Access;

   pragma Assert (Query (O1) = 5);
   pragma Assert (Query (O2) = 6);

end;



> The availability of pointers to members makes it possible to concisely
> express the mapping between the a data member and the "A" column of a
> database table.

The availability of pointers to local functions makes it possible to
concisely express the mapping between the A record component and the "A"
column of a database table.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

>>     I don't know about Ada, but in C++ you can, and such "templates
> nesting"
[...]
> Of course, you can pass the type made available via an instantiation of a
> generic package as the actual type of some other instantiation.  The
> container libraray for Ada 2005 (see AI-302) was specially designed to
> allow a container as the element of another container.

Thanks for clarification.

So returning to what Dmitry has written:

Dmitry > For instance, it is impossible to have generic programming
Dmitry > on containers of containers. You cannot have a list of items of
Dmitry > "array" types that are different instantiations. Because see above,
Dmitry > you have no that common abstract predecessor. That "arrays" are not
Dmitry > arrays, we are just fooling ourselves.

    I think I see now what Dmitry was trying to say: you cannot have a list
of "arrays" such that one its element will be of type std::vector<int>, the
other of std::valarray<int> and so on. Do I understand you well, Dmitry?
    If yes, then I admit: it can't be done directly. But it *doesn't* mean
it's impossible! Have a look at this:

/*************************************************/

#include <cstddef>
using std::size_t;

#include <list>
using std::list;

#include <vector>
using std::vector;

#include <map>
using std::map;

// STEP 1:

// Helper template for getting element
// and index type of an array type. ArrayTraits
// is meant to be specialised for any concrete
// array type.

template<typename ArrayT>
struct ArrayTraits {
  typedef ArrayT ArrayType;
}; // struct ArrayTraits<>

// Specialisation for std::vector<>

template<typename ElementT>
struct ArrayTraits< vector<ElementT> > {
  typedef typename vector<ElementT> ArrayType;
  typedef typename ArrayType::value_type ElementType;
  typedef typename ArrayType::size_type IndexType;
}; // struct ArrayTraits< vector<ElementT> >

// Specialisation for std::map<>

template<typename ElementT, typename IndexT>
struct ArrayTraits< map<IndexT, ElementT> > {
  typedef typename map<IndexT, ElementT> ArrayType;
  typedef typename ArrayType::mapped_type ElementType;
  typedef typename ArrayType::key_type IndexType;
}; // struct ArrayTraits< map<IndexT, ElementT> >

// Specialisation for C-style arrays

template<typename ElementT>
struct ArrayTraits<ElementT[]> {
  typedef ElementT ArrayType[];
  typedef ElementT ElementType;
  typedef size_t IndexType;
}; // struct ArrayTraits<ElementT[]>

// STEP 2:

// Abstract base class for the wrapper of any
// array type (here we assume that array type
// is any type having [] operator)

template<typename ElementType, typename IndexType>
struct ArrayWrapperBase {
  virtual ElementType & operator [] (const IndexType & ) = 0;
  // ...Possibly some other array-specific operations...
  virtual ~ArrayWrapperBase() {}
}; // struct ArrayWrapperBase<>

// STEP 3:

// The wrapper class template

template<typename ArrayType>
struct ArrayWrapper:
  public ArrayWrapperBase<
    typename ArrayTraits<ArrayType>::ElementType,
    typename ArrayTraits<ArrayType>::IndexType
  >
{
  typedef typename ArrayTraits<ArrayType>::ElementType ElementType;
  typedef typename ArrayTraits<ArrayType>::IndexType IndexType;
  ArrayType & mArray; // reference to actual array object
  ArrayWrapper(ArrayType & A): mArray(A) {}
  ElementType & operator [] (const IndexType & i) { return mArray[i]; };
}; // struct ArrayWrapper<>

// STEP 4:

// Use!

int main()
{

  vector<int> AVector(10);
  ArrayWrapper< vector<int> > WrappedVector(AVector);

  map<size_t, int> AMap;
  ArrayWrapper< map<size_t, int> > WrappedMap(AMap);

  int AnArray[10];
  ArrayWrapper< int[] > WrappedArray(AnArray);

  typedef list<ArrayWrapperBase<int, size_t> *> ListOfArrays;
  ListOfArrays MyList; // list of arrays of any kind holding ints

  // creme de la creme:
  MyList.push_back(&WrappedVector);
  MyList.push_back(&WrappedMap);
  MyList.push_back(&WrappedArray);

  // the three instructions are equivalent:
  AVector[7] = 27182;
  WrappedVector[7] = 27182;
  (*MyList.front())[7] = 27182;

  // setting 5-th element of every array to 31415:
  for(ListOfArrays::iterator i = MyList.begin(); i != MyList.end(); i++)
    (**i)[4] = 31415;

} // main()


/*************************************************/

    Long and complicated? Indeed. But on the other hand I have never heard
of anybody who needed this. Yet it's possible ;-).

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Robert Kawulak <tigrisek@interia.pl> wrote:

: 
: And the recommended way to
: solve your problem is:
: 
: float foo(float a[], size_t a_size);

I don't have a problem, as I can use either languages that do
have arrays, or languages that have libraries providing array
like data types. :-) Only, C++ has not inherited arrays, that's
because C doesn't have arrays in some sense.


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi there!

> What I meant is that you cannot have a vector
> containing elements of vector<int>, vector<unsigned>, vector<long> etc.
> vector<A> and vector<B> are unrelated types even if A is a descendant of B
> or related to B. What do you want from a macro extension? (:-))

    Whoops! So in my answer for Matthew Heaney's post I've misunderstood you
again :-/
    But yes, it *is* possible to have such vector, similarly to my example
in mentioned answer (of course the code would need a few changes, it could
be even simplier). But I'm wondering what in the world would you need such a
vector for? ;-)

> No, Ada generics have contracts.

I see. But you can also have contracts for template parameters in C++. They
aren't a core language construct like in Ada (and their use is a little bit
less simple), but because of this they can be much more flexible. For
details, have a look at boost::concept_check and boost::type_traits
(http://www.boost.org).

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Björn Persson]

Kevin Cline wrote:

> In C++:

procedure Demo is

> struct X
> {
>   int a;
>   int b;
> };

   type X_Index is (A, B);
   type X is array(X_index) of Integer;

> X x1 = { 3, 5 };
> X x2 = { 4, 6 };

   X1 : X := (3, 5);
   X2 : X := (4, 6);

> int X::*ptm = &X::a;

   PTM : X_Index := A;

begin

> ASSERT(x1->*ptm == 3);
> ASSERT(x2->*ptm == 4);

   pragma Assert(X1(PTM) = 3);
   pragma Assert(X2(PTM) = 4);

> ptm = &X::b;

   PTM := B;

> ASSERT(x1->*ptm == 5);
> ASSERT(x2->*ptm == 6);

   pragma Assert(X1(PTM) = 5);
   pragma Assert(X2(PTM) = 6);

end Demo;

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<yKY6d.4590$d5.36128@newsb.telia.net>...
> Kevin Cline wrote:
> 
> > In C++:
> 
> procedure Demo is
> 
> > struct X
> > {
> >   int a;
> >   int b;
> > };
> 
>    type X Index is (A, B);
>    type X is array(X index) of Integer;

Looks like I should have written:

struct X
{
  int a;
  int b;
  float c;
  std::string d;
}

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Matthew Heaney" <mheaney@on2.com> wrote in message news:<415c36c0$0$91010$39cecf19@news.twtelecom.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0409291942.5790386d@posting.google.com...
> >
> > There seems to be some confusion between creating a pointer to a
> > particular member of a particular record, and the C++ pointer to
> > member type.
> >
> > In C++:
> [snip]
> 
> There seems to be some confusion between creating an offset to a record
> component, and simply using an Ada function pointer:
> 
> In Ada:
> 
> declare
>    type T is record
>       A, B : Integer;
>    end record;
> 
>    function A (O : T) return Integer is
>    begin
>      return O.A;
>    end;
> 
>    function B (O : T) return Integer is
>    begin
>       return O.B;
>    end;
> 
>    type Query_Type is access function (O : T) return Integer;
> 
>    Query : Query_Type := A'Access;
> 
>    O1 : T := (3, 5);
>    O2 : T := (4, 6);
> 
> begin
> 
>    pragma Assert (Query (O1) = 3);
>    pragma Assert (Query (O2) = 4);
> 
>    Query := B'Access;
> 
>    pragma Assert (Query (O1) = 5);
>    pragma Assert (Query (O2) = 6);
> 
> end;
> 
> 
> 
> > The availability of pointers to members makes it possible to concisely
> > express the mapping between the a data member and the "A" column of a
> > database table.
> 
> The availability of pointers to local functions makes it possible to
> concisely express the mapping between the A record component and the "A"
> column of a database table.

I don't personally consider this to be particularly concise.  There
were two lines C++ code, one to declare the data member:
  int a;
and one to create the table entry:
  db.insert("PERSON.SSN", &Person::ssn).

There are at least six lines of Ada code: the member declaration, a
function to access the data member, the instantiation of the insert
function for members of that type, and finally the call of the
instantiated function.  Not much of a savings over simply writing
separate create, read, and update functions for the record type.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Thu, 30 Sep 2004 20:52:21 +0200, Robert Kawulak wrote:

>> What I meant is that you cannot have a vector
>> containing elements of vector<int>, vector<unsigned>, vector<long> etc.
>> vector<A> and vector<B> are unrelated types even if A is a descendant of B
>> or related to B. What do you want from a macro extension? (:-))
> 
>     Whoops! So in my answer for Matthew Heaney's post I've misunderstood you
> again :-/
>     But yes, it *is* possible to have such vector, similarly to my example
> in mentioned answer (of course the code would need a few changes, it could
> be even simplier). But I'm wondering what in the world would you need such a
> vector for? ;-)

It is no matter. The problem is fundamental, if vector<A> and vector<B> as
types have nothing in common, then it is difficult to write a program which
can work with both. It is all about generic programming. That is not
necessarily programming using generics or templates, that is programming
with *sets* of types. Array types is an example of such set, "vector<>" is
another.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Fri, 1 Oct 2004 00:06:34 +0200, Robert Kawulak wrote:

>>>> An ability to index is just one of many array properties. The whole list
>>>> is very large.
>>> As well as the list of methods and operators and other members of
>>> std::vector<>... What particular thing are you missing there?
> 
>> Slices (subarrays), ranges (index subsets),
> 
> std::slice_array<>, std::gslice_array<>, std::indirect_array<>,
> std::mask_array<>  (all used with std::valarray<>)
> 
> The std::valarray<> class has more limitations on the held type than
> std::vector<>, but it is designed to be very efficient for such operations.

In Ada slices are ad-hoc anonymous types, it is how that should be. Because
if you want to work with array slices in a subprogram, you definitely do
not want to pass all necessary helper types down there. In Ada you just
write A(10..I) and the job is done. In C++ there is no mechanism to get
related types out of objects and other types (except pointers T* and
references T&).

[Yes you can get this in C++, I believe you, it is all Turing complete
after all! (:-))]

>> looping (automatic iterators),
> 
> std::for_each algorithm and the like... (especially useful with
> boost::lambda)

In Ada:

for Index in A'Range loop
   ...
end loop;

Here the iterator type and its constraint are constructed out of the
object. Feel the difference!

>>> Why you think that it is necessary for the core
>>> language to know what is an array and what isn't? In Ada, you can't use
>>> anything else than built-in array exactly as an array. In C++ you can.
>> You get me wrong. I do not argue in favor of built-in arrays. I argue for
>> an ability to have abstract array interfaces either user-defined or
>> built-in, no matter. C++ does not have them and its template mechanism
>> does
>> not help here (*). Ada has them built-in, but does not allow to implement
>> an array by, say, a record type.
> 
> I see your point. When designing containers in std library, its creators had
> two possibilities to choose from:
> 1. Make all the containers polymorphic,
> 2. Make all the containers use consequent naming of members and make all the
> algorithms templated.
> They have choosen 2, because it's far more efficient (no virtual calls, many
> bindings resolved at compile time and even inlined) and far more flexible.

Far less flexible you mean. 2 is called statically polymorphic, while 1 is
just polymorphic. Clearly 2 is a part of 1. Nothing prevents the compiler
to remove dispatch if the target is statically known.

> This is why C++ has no abstract interface. Instead, counterpart functions in
> all the containers are named in a uniform way, and this is their
> "interface", but in the terms of template metaprogramming.

Right. Their fault is that these interfaces though exist, are anonymous and
uncheckable. In Ada they are named and checkable. This is why C++'s
template interfaces are untyped. Ada's generic interfaces are typed, but do
not have any ADT. It is like FORTRAN-IV against Algol contest in 2004.
(:-))

>> Can you use it *as* std::vector<char>? No, they are two different
>> *unrelated* types. Same as in Ada, where Unbounded_String can be used
>> *like*, but not *as* String.
> 
> But this is where the "template metaprogramming" stuff applies - you can't
> use it directly as string, but you can make a template metafunction which in
> turn can take vector<char> or string or something else as its metaargument. 
> And in this metafunction you may use them in the same manner - this is what 
> I meant.

No you cannot, when you have to mix them. If your program needs both
vector<char> and string (to copy a part of one into another) then you have
to parametrize it twice with two types. Now consider what happens if there
are 100 different, yet related types?

[To continue the analogy, I'am trying to convince a FORTRAN-IV programmer
that there could be something beyond REAL*4 and REAL*8. (:-))]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Georg Bauhaus]

Kevin Cline <kevin.cline@gmail.com> wrote:
:   Not much of a savings over simply writing
: separate create, read, and update functions for the record type.

Why are you so keen on savings?


-- Georg

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

> But this is where the "template metaprogramming" stuff applies - you can't
> use it directly as string, but you can make a template metafunction which in
> turn can take vector<char> or string or something else as its metaargument. 

Sorry, I didn't express myself in the strict terms - I meant just
tempate function, not "template metafunction", with ordinary
parameters, not "metaargments". That is not what exactly template
metaprogramming is about, sorry for the confusion. (I was writing that
post late at night... ;-)

Regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Björn Persson]

Kevin Cline wrote:

> Looks like I should have written:
> 
> struct X
> {
>   int a;
>   int b;
>   float c;
>   std::string d;
> }

:-) I thought you'd counter with that. So now you have a structure with 
two integers, a float and a string, and you need to set a variable such 
that the one or the other integer is selected depending on the variable. 
That makes it seem like there is some kind of relation between the 
integers; a relation that isn't there with the float or the string. So 
it seems natural to group the integers together:

with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;

procedure Demo is

   type AB_Index is (A, B);
   type AB_Type is array(AB_Index) of Integer;
   type X is record
     AB : AB_Type;
     C  : Float;
     D  : Unbounded_String;
   end record;

   X1 : X := ((3, 5), 1.2, To_Unbounded_String("Apes"));
   X2 : X := ((4, 6), 7.8, To_Unbounded_String("Beeps"));

   PTM : AB_Index := A;

begin

   pragma Assert(X1.AB(PTM) = 3);
   pragma Assert(X2.AB(PTM) = 4);

   PTM := B;

   pragma Assert(X1.AB(PTM) = 5);
   pragma Assert(X2.AB(PTM) = 6);

end Demo;

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[K]

Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<pkf7d.4649$d5.36957@newsb.telia.net>...
> Kevin Cline wrote:
> 
> > Looks like I should have written:
> > 
> > struct X
> > {
> >   int a;
> >   int b;
> >   float c;
> >   std::string d;
> > }
>  
> :-) I thought you'd counter with that. So now you have a structure with 
> two integers, a float and a string, and you need to set a variable such 
> that the one or the other integer is selected depending on the variable.

No, I think that you are missing the whole point, which is to
represent a relationship between the members of the structure and
columns in a database.

This is pretty easy with the C++ pointer-to-member construct, but Ada
lacks that construct so you have to instead wrap the data members with
a function so you can store an access-to-function.  But it's worse,
since you will need two functions, one to read the datum and one to
set it.

> That makes it seem like there is some kind of relation between the 
> integers; 

There isn't.

> a relation that isn't there with the float or the string. So 
> it seems natural to group the integers together

It's not.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[K]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cjjib1$kdq$1@a1-hrz.uni-duisburg.de>...
> Kevin Cline <kevin.cline@gmail.com> wrote:
> :   Not much of a savings over simply writing
> : separate create, read, and update functions for the record type.
> 
> Why are you so keen on savings?

Because it makes an enormous difference in the cost of developing and
maintaining code.  It's much easier to write and maintain a table like
this:

   dbmap<Order> order_map;

   order_map.insert("ORDER.NUMBER", &Order::number)
             .insert("ORDER.CUSTOMER", &Order::customer_number)
             .insert("ORDER.ACCEPTED", &Order::acceptance_date)
             .insert("ORDER.PROMISED", &Order::promised_ship_date)
             ...

   and then be able to write:

   Order order;
   order_map.read(dbreader, order);
   order.promised_ship_date = ship_date(order.line_items);
   order_map.update(dbconnection, order);


than to maintain code like this:

   read_order(DatabaseReader& reader, Order& order)
   {
     order.number = reader["ORDER.NUMBER"];
     order.customer_number = reader["ORDER.CUSTOMER"];
     order.acceptance_date = parse<Date>(reader["ORDER.ACCEPTED"]);
     ...
   }

   update_order(DatabaseConnection& connection, Order& order)
   {
     writer["ORDER.NUMBER"] = order.number;
     writer["ORDER.CUSTOMER"] = ...;
   }

   create_order(...)
   {
      // more of the same
   }

Maybe you're happy keeping three copies of essentially the same code
carefully synchronized.  I'm not.  I prefer to squeeze out as much
redundancy as possible  so that changes need be made in only one
place.  That is one of the key practices that separates expert
programmers from average programmers.  The average programmer gets a
requirement to add two new fields to a record, and has to carefully
update three separate functions.  Except that once in a while he
misses one and the functions are out of sync, and an hour is lost
tracking the problem.

The expert simply has to add two members to the record definition,
then add two entries to the map, with almost no way to go wrong.

Basically, if you know what code is going to say without reading it,
then the code is redundant, and should be rewritten to eliminate the
redundancy.  I have found this to be easier in C++ than in Ada. 
Admittedly, C++ template programming could be easier.  Most
programmers would be incapable of writing
the dbmap class and the associated infrastructure.  But once written,
all programmers would be able to use the dbmap class.

In a reflective language this sort of mapping is relatively simple and
should be within the abilities of most developers.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Brian May]

>>>>> "K" == K  <slatyb@yahoo.com> writes:

    K> dbmap<Order> order_map;

    K> order_map.insert("ORDER.NUMBER", &Order::number)
    K> .insert("ORDER.CUSTOMER", &Order::customer_number)
    K> .insert("ORDER.ACCEPTED", &Order::acceptance_date)
    K> .insert("ORDER.PROMISED", &Order::promised_ship_date)
    K> ...

    K> and then be able to write:

    K> Order order;
    K> order_map.read(dbreader, order);
    K> order.promised_ship_date = ship_date(order.line_items);
    K> order_map.update(dbconnection, order);

Hmmmm... Thinking aloud: One approach that might work, at least for
some applications:

declare
        type Index_Type is (Number, Customer_Number, Acceptance_Date,
                   Promised_Ship_Date, ...);
begin
        insert(Order_Map, Number);
        insert(Order_Map, Customer_Number);
        insert(Order_Map, Acceptance_Date);
        insert(Order_Map, Promised_Ship_Date);
        ...     
end;

...          

declare      
        type Order is array (Index_Type) of ????
begin
        Read(Order_Map, dbreader, Order);
        Order(Promised_Ship_Date) := ship_date(order.line_items);
        Update(Order_Map,dbconnection, Order);
        ...
end;

(not tested; syntax may not be exactly correct)

The obvious problem with this is that all values need be the same
type. I am not sure if your code has this limitation or not.

Perhaps you could solve this with using a tagged type and
inheritance. I have a vague feeling this won't work; you can't have an
array of unconstrained types...
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Björn Persson]

K wrote:

> No, I think that you are missing the whole point, which is to
> represent a relationship between the members of the structure and
> columns in a database.

Kevin Cline posted a code example in C++. I showed how the example could 
be translated to Ada despite Ada's lack of pointer-to-member types. 
That's all. That example had nothing to do with databases, so I suppose 
it failed to show the point.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

slatyb@yahoo.com (K) writes:

> This is pretty easy with the C++ pointer-to-member construct, but Ada
> lacks that construct so you have to instead wrap the data members with
> a function so you can store an access-to-function.  But it's worse,
> since you will need two functions, one to read the datum and one to
> set it.

You're still confused:

   function A (O : access T) return Integer_Access;  --Ada95

   O : aliased T;
   N : Integer;

begin

   A (O'Access).all := 42;
   N := A (O'Access).all;

end;

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

slatyb@yahoo.com (K) writes:

> Because it makes an enormous difference in the cost of developing and
> maintaining code.  It's much easier to write and maintain a table like
> this:
> 
>    dbmap<Order> order_map;
> 
>    order_map.insert("ORDER.NUMBER", &Order::number)
>              .insert("ORDER.CUSTOMER", &Order::customer_number)
>              .insert("ORDER.ACCEPTED", &Order::acceptance_date)
>              .insert("ORDER.PROMISED", &Order::promised_ship_date)
>              ...

   procedure Insert
     (Map     : in out Map_T;
      Key     : in String;
      Process : not null access
        function (Order : access Order_T) return Integer);

declare
   M : Map_T;
begin
   M.Insert ("ORDER.NUMBER", Number'Access);
   M.Insert ("ORDER.CUSTOMER", Customer_Number'Access);
   ...

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

Brian May <bam@snoopy.apana.org.au> wrote in message news:<sa4wty9a196.fsf@snoopy.apana.org.au>...
> >>>>> "K" == K  <slatyb@yahoo.com> writes:
> 
>     K> dbmap<Order> order_map;
> 
>     K> order_map.insert("ORDER.NUMBER", &Order::number)
>     K> .insert("ORDER.CUSTOMER", &Order::customer_number)
>     K> .insert("ORDER.ACCEPTED", &Order::acceptance_date)
>     K> .insert("ORDER.PROMISED", &Order::promised_ship_date)
>     K> ...
> 
>     K> and then be able to write:
> 
>     K> Order order;
>     K> order_map.read(dbreader, order);
>     K> order.promised_ship_date = ship_date(order.line_items);
>     K> order_map.update(dbconnection, order);
> 
> Hmmmm... Thinking aloud: One approach that might work, at least for
> some applications:
> 
> declare
>         type Index_Type is (Number, Customer_Number, Acceptance_Date,
>                    Promised_Ship_Date, ...);
> begin
>         insert(Order_Map, Number);
>         insert(Order_Map, Customer_Number);
>         insert(Order_Map, Acceptance_Date);
>         insert(Order_Map, Promised_Ship_Date);

Sorry, I didn't make it clear that not all thes data members are
integers.  The dates have Date type, and other members will be strings
or other user-defined types.

>         ...
> end;
> 
> (not tested; syntax may not be exactly correct)
> 
> The obvious problem with this is that all values need be the same
> type. I am not sure if your code has this limitation or not.

No, it doesn't.  That's the point.  The insert function is a template
member function with a declaration like this:

   template <class RecordType>
   class DatabaseMap
   {
     vector<ColumnMap> entries;
     ...
     template <class MemberType>
     DatabaseMap& insert(Column c, MemberType
RecordType::*member_pointer)
     {
        entries.push_back(new ColumnMemberMap<RecordType, MemberType>
                              (c, member_pointer));
        return this;
     }
   }

Matt has suggested ways this can be done in Ada, but it requires to
create a function for every data member to be mapped, and additionally
you will have to instantiate the insert function for each different
member type.  That is so much work that it destroys the value of the
technique.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Randy Brukardt]

"K" <slatyb@yahoo.com> wrote in message
news:4c2ec8a8.0410012335.dcf9001@posting.google.com...
...
> than to maintain code like this:
>
>    read_order(DatabaseReader& reader, Order& order)
>    {
>      order.number = reader["ORDER.NUMBER"];
>      order.customer_number = reader["ORDER.CUSTOMER"];
>      order.acceptance_date = parse<Date>(reader["ORDER.ACCEPTED"]);
>      ...
>    }

It's orthogonal to your original point, but Ada contains features to make it
impossible to forget to modify some section of code when components are
added. That mitigates any needed duplication to some extent.

procedure Read_Order (Reader : DatabaseReader_Type; Order : in out
Order_Type) is
begin
    Order := (Number => Reader("Order.Number"),
                   Customer_Number => Reader("Order.Customer"),
                   ...);
end Read_Order;

If a component is added to Order, the compiler will complain if this
aggregate is not updated.

I'd probably use an enumeration type to map the names of the fields in order
to bring completeness checking to that side of the equation as well.

But I admit that I still can't figure out what it is that this "pointer to
member" does that is different than taking an access of a component. The
only thing that Ada doesn't have here is an equivalent to "void", which is
of course about safety - all access types have to have a designated type.

                     Randy.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Brian May]

>>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes:

    Kevin> template <class RecordType>
    Kevin> class DatabaseMap
    Kevin> {
    Kevin> vector<ColumnMap> entries;
    Kevin> ...
    Kevin> template <class MemberType>
    Kevin> DatabaseMap& insert(Column c, MemberType
    Kevin> RecordType::*member_pointer)
    Kevin> {
    Kevin> entries.push_back(new ColumnMemberMap<RecordType, MemberType>
    Kevin> (c, member_pointer));
    Kevin> return this;
    Kevin> }
    Kevin> }


Ok.

So thinking out aloud, if I got this correct, your example of:

   dbmap<Order> order_map;

   order_map.insert("ORDER.NUMBER", &Order::number)
             .insert("ORDER.CUSTOMER", &Order::customer_number)
             .insert("ORDER.ACCEPTED", &Order::acceptance_date)
             .insert("ORDER.PROMISED", &Order::promised_ship_date)
             ...


Would be equivalent to:

vector<ColumnMap> entries;

entries[0] := new ColumnMemberMap<order_map, MyInteger>("ORDER.NUMBER",i
                                &Order::number)
entries[1] := new ColumnMemberMap<order_map, MyInteger>("ORDER.CUSTOMER",i
                                &Order::customer_number);
entries[2] := new ColumnMemberMap<order_map, MyInteger>("ORDER.ACCEPT",i
                                &Order::acceptance_date);
entries[3] := new ColumnMemberMap<order_map, MyDate>("ORDER.PROMISED",i
                                &Order::promised_ship_date);

vector<ColumnMap> entries;

What is the relationship between ColumnMemberMap and ColumnMap?

I might assume:

typedef ColumnType *ColumnMap;  /* ColumnMap points to ColumnType */

class ColumnType {

};

template <class RecordType, class MemberType>
class ColumnMemberMap : XYZ {
      ColumnMemberMap(Column c, MemberType RecordType::*member_pointer) {
         ...
      }
};

If so, I think this could be done in Ada (yes, this is messy, it has
gone through several revisions, it could be tidied up):

declare
        -- holds the data
        type Column_Type is tagged private;
        type Column_Access is access all Column_Type'Class;

        generic
                type Member_Type is private;
        package Members
                type Column_Type is new Column_Type with private;

                procedure Set(Column : Column_Type, Member : Member_Type);
                function Get(Column : Column_Type) return Member_Type;
        private
                ...
        end Members;

        ...

        -- function to retrieve the data

        package Integer_Members is new Members(MyInteger);
        package Date_Members is new Members(MyDate);

        -- returns new Integer_Members.Column_Type if Integer
        -- returns new Date_Members.Column_Type    if Date
        -- etc
        function Get(dbreader : dbreader_type; C : Unbounded_String)
                 return Column_Access;

        ...



        type Index_Type is (Number, Customer_Number, Acceptance_Date,
                   Promised_Ship_Date, ...);

        
        type Order_Map_Type is array (Index_Type) of Unbounded_String;
        type Order_Type is array (Index_Type) of Column_Access;

        Order_Map : Order_Map_Type;
        Order     : Order;


begin
        Order_Map :=  (
                Number =>             +"ORDER.NUMBER",
                Customer_Number =>    +"ORDER.CUSTOMER",
                Acceptance_Date =>    +"ORDER.ACCEPTANCE",
                Promised_Ship_Date => +"ORDER.PROMISED",
                ...     
        );

        for I in Order_Map'Range loop
            declare
                C : constant Unbounded_String := Order_Map(I);
                D : constant Column_Access := Get(dbreader,C);
            begin
                Order(I) := D;
            end;
        end loop;
end;


In a real application, I would split this out into other functions,
like you have.

Presumably "Get" would already be defined and the one function would
get an access type to any type. This might not be what you
anticipated, but my imagination is running out right now.

The only disadvantage I can immediately see is that setting/retrieving
values would require some sort of (perhaps ugly) cast, also meaning
run-time type checks would be used, not compile-time type checks
(unless you have a per field conversion function, which would increase
complexity).

Disclaimer: NOT TESTED!!!

Hopefully this makes some sort of sense, other then proving me insane
;-)
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> But I admit that I still can't figure out what it is that this "pointer to
> member" does that is different than taking an access of a component. The
> only thing that Ada doesn't have here is an equivalent to "void", which is
> of course about safety - all access types have to have a designated type.

>From the example posted, it appears a "pointer to member" is an offset
from the start of the record, rather than an absolute pointer. So, in
psuedo-Ada : 

type A_Type is record
    A : Integer;
    B : Integer;
end record;

type A_Component_Access_Type is access component A_Type;

Access_B : A_Component_Access_Type := A_Type.B'Component_Access;
--  Note that 'Component_Access takes a _type_, not an _Object_.

D : A_Type := (1, 2);
E : A_Type := (3, 4);

F : Integer := D.Access_B.all;
G : Integer := E.Access_B.all;

Now F = 2 and G = 4. Of course, this is the same as:

F : Integer := D.B;
G : Integer := E.B;

But if the names are long and complex, the pointer to member might be
a good optimization (like a renames). I'm not clear on exactly how
that would work.

I don't see how it relates to database fields.

-- 
-- Stephe

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> The problem is fundamental, if vector<A> and vector<B> as
> types have nothing in common, then it is difficult to write a program
> which can work with both. It is all about generic programming.

    But I'm still trying to figure out what problems does this entail (and
why, in this respect, Ada arrays could be better than all array types in
C++, which is what this discussion was about). My understanding is that
vector<A> and vector<B> (or Ada arrays of elements of these types) *must* be
different types because A and B are different types. Of course they've got
some common properties and methods independent on the type of held elements
like the number of elements, but I don't see any difficulties connected with
this - all vector classes have the same interface, so it's easy to write a
code that copes with vectors of elements of different types.
    Could you clarify this (or at least give some links concerning generic
programming issues you are writing about)?
Thanks.

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> In Ada slices are ad-hoc anonymous types, it is how that should be.
> Because
> if you want to work with array slices in a subprogram, you definitely do
> not want to pass all necessary helper types down there. In Ada you just
> write A(10..I) and the job is done.

    In C++ you may write std::vector(V.begin + 9, V.begin() + I) and this is
also anonymous object which is subvector of another vector V. Or you can
pass only iterators and the job is done better, because there's no copying
of elements and you can operate on any container, not only on a vector.

> [Yes you can get this in C++, I believe you, it is all Turing complete
> after all! (:-))]

:)))

>> std::for_each algorithm and the like... (especially useful with
>> boost::lambda)
>
> In Ada:
>
> for Index in A'Range loop
>   ...
> end loop;
>
> Here the iterator type and its constraint are constructed out of the
> object. Feel the difference!

    The only case where Ada is less verbose than C++ ;-) But on the other
hand you cannot do this with a list, a map, a deque, nor you can do the
following so concisely:

std::vector V(10);

// Apply SomeFunction to elements [4, 9] in reverse order:
std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction);

For instance (using boost::lambda) print those elements:

// Print elements [4, 9] in reverse order:
std::for_each(V.rbegin() + 1, V.rend() - 3, std::cout << _1);

Feel the difference! ;-)

>> I see your point. When designing containers in std library, its creators
>> had
>> two possibilities to choose from:
>> 1. Make all the containers polymorphic,
>> 2. Make all the containers use consequent naming of members and make all
>> the
>> algorithms templated.
>> They have choosen 2, because it's far more efficient (no virtual calls,
>> many
>> bindings resolved at compile time and even inlined) and far more
>> flexible.
>
> Far less flexible you mean.

    C++ doesn't have a single-rooted object hierarchy. So if containers
weren't templates, they'd have to contain elements of some abstract class,
call it CElement. Now, if you want to have a container of elements of some
class not derived from CElement or even a container of int, then you'd have
to make some wrapper classes - this would cost you a lot of time to make it
work with the library. So in this case runtime polymorphism doesn't seem to
me to be more flexible than the template solution...

> No you cannot, when you have to mix them. If your program needs both
> vector<char> and string (to copy a part of one into another) then you have
> to parametrize it twice with two types. Now consider what happens if there
> are 100 different, yet related types?

    Nothing happens. ;-) If you have a function template copying elements of
one container into another, then it'll work fine even for 100 container
types, as long as they use the same interface. Can you specify what do you
mean when saying 'mix them'?

> [To continue the analogy, I'am trying to convince a FORTRAN-IV programmer
> that there could be something beyond REAL*4 and REAL*8. (:-))]

    I feel the same ;-). But of course the point is not to fight and win,
but to learn something. I've already learned a few things from this
discussion :).

Best regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Ole-Hjalmar Kristensen]

>>>>> "K" == K  <slatyb@yahoo.com> writes:

    K> Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<pkf7d.4649$d5.36957@newsb.telia.net>...
    >> Kevin Cline wrote:
    >> 
    >> > Looks like I should have written:
    >> > 
    >> > struct X
    >> > {
    >> >   int a;
    >> >   int b;
    >> >   float c;
    >> >   std::string d;
    >> > }
    >> 
    >> :-) I thought you'd counter with that. So now you have a structure with 
    >> two integers, a float and a string, and you need to set a variable such 
    >> that the one or the other integer is selected depending on the variable.

    K> No, I think that you are missing the whole point, which is to
    K> represent a relationship between the members of the structure and
    K> columns in a database.

    K> This is pretty easy with the C++ pointer-to-member construct, but Ada
    K> lacks that construct so you have to instead wrap the data members with
    K> a function so you can store an access-to-function.  But it's worse,
    K> since you will need two functions, one to read the datum and one to
    K> set it.

A plain pointer works just fine for binding data members to columns in
a database, so you don't need the special pointer-to-member construct
in this case.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Sun, 3 Oct 2004 21:53:32 +0200, Robert Kawulak wrote:

>>> std::for_each algorithm and the like... (especially useful with
>>> boost::lambda)
>>
>> In Ada:
>>
>> for Index in A'Range loop
>>   ...
>> end loop;
>>
>> Here the iterator type and its constraint are constructed out of the
>> object. Feel the difference!
> 
>     The only case where Ada is less verbose than C++ ;-) But on the other
> hand you cannot do this with a list, a map, a deque,

It is because they are not arrays. But why an ordered list should not
implement an array interface? In my view it should, making the above legal
for lists.

> nor you can do the following so concisely:
> 
> std::vector V(10);
> 
> // Apply SomeFunction to elements [4, 9] in reverse order:
> std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction);

for Index in reverse V'First + 4..V'Last loop
   SomeFunction (V (Index)); -- Better to place its body here, if short
end loop;

> For instance (using boost::lambda) print those elements:
> 
> // Print elements [4, 9] in reverse order:
> std::for_each(V.rbegin() + 1, V.rend() - 3, std::cout << _1);
> 
> Feel the difference! ;-)

I do! I hate implicit iterators, I prefer loops where possible. Especially,
because exit conditions, nested iterations, exception handling become
visible.

[ Ranting: 40 years spent in developing readable, safe, well-structured
language constructs, only to replace them with nested function calls a la
Lisp? ]

>>> I see your point. When designing containers in std library, its creators
>>> had
>>> two possibilities to choose from:
>>> 1. Make all the containers polymorphic,
>>> 2. Make all the containers use consequent naming of members and make all
>>> the
>>> algorithms templated.
>>> They have choosen 2, because it's far more efficient (no virtual calls,
>>> many
>>> bindings resolved at compile time and even inlined) and far more
>>> flexible.
>>
>> Far less flexible you mean.
> 
>     C++ doesn't have a single-rooted object hierarchy. So if containers
> weren't templates, they'd have to contain elements of some abstract class,
> call it CElement. Now, if you want to have a container of elements of some
> class not derived from CElement or even a container of int, then you'd have
> to make some wrapper classes - this would cost you a lot of time to make it
> work with the library.

Yes, unless:

1. (for new types) language supports multiple interface inheritance. C++
does, Ada 2005 will.

2. (for existing types) language supports supertyping. If it does, then
creating a wrapper will be a matter of one or two code lines. You create a
helper type which is both a subtype of CElement and a supertype of int.

> So in this case runtime polymorphism doesn't seem to
> me to be more flexible than the template solution...

Formally it is more flexible and powerful. The problem is that OO languages
like C++ and Ada are much too much concentrated on generics, which are a
dead end IMO, instead of investing more efforts in better ADT.

>> No you cannot, when you have to mix them. If your program needs both
>> vector<char> and string (to copy a part of one into another) then you have
>> to parametrize it twice with two types. Now consider what happens if there
>> are 100 different, yet related types?
> 
>     Nothing happens. ;-) If you have a function template copying elements of
> one container into another, then it'll work fine even for 100 container
> types, as long as they use the same interface.

Which interface you mean? string is an instance of another template. It is
not vector<>, and there is no way to make it conform to vector<>, because
there is no such thing as "vector interface".

> Can you specify what do you mean when saying 'mix them'? 

All cases were:

template <class A, class B> Foo (vector <A>& X, vector <B>& Y)
{
   ...
   Do_Something (X [I], Y [J]);
   ...
}

cannot be replaced with:

template <class A> Foo (vector <A>& X, vector <A>& Y)
{
   ...
   Do_Something (X [I], Y [J]);
   ...
}

Technically, you have to factor vector<> out of vector<A>, vector<B>, etc.
When you do, that will be the ARRAY.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Sun, 3 Oct 2004 21:35:22 +0200, Robert Kawulak wrote:

>> The problem is fundamental, if vector<A> and vector<B> as
>> types have nothing in common, then it is difficult to write a program
>> which can work with both. It is all about generic programming.
> 
>     But I'm still trying to figure out what problems does this entail (and
> why, in this respect, Ada arrays could be better than all array types in
> C++, which is what this discussion was about).

I didn't say that Ada get it solved. I think that Ada is on the right way
there, while C++ moves in the opposite direction.

> My understanding is that
> vector<A> and vector<B> (or Ada arrays of elements of these types) *must* be
> different types because A and B are different types.

They need not to be. To be honest, in Ada you cannot put a constraint on
array's element type, but you can do it for the index type. For the
discussion, there is no much difference what to constrain/derive from. When
you use a template, say: <int From_Index, int To_Index, class Element>,
then different values of From_Index, To_Index constitute different types of
instances. It is unacceptable. This was solved in Ada 83. It has a notion
of array type which can be constrained (the set of all possible constraints
gives that desired ARRAY types set):

type String is array (Integer range <>) of Character;
subtype Subrange is Integer range 1..20;
subtype Substring is String (Subrange);
   -- String and Substring are related types. You can program for Substring
   -- in terms of String.

Yes, Ada does not have it for array elements. You cannot derive from the
element type and get the array of derived elements a subtype of the array
of element. Neither you can dispatch on subtypes etc. But if you have
arrays you could fix it some day...

> Of course they've got
> some common properties and methods independent on the type of held elements
> like the number of elements, but I don't see any difficulties connected with
> this - all vector classes have the same interface,

This "same interface" is not a language object. It is a fiction, which
cannot be described in language terms independently on its implementation.
So you physically unable to program in terms of this interface. It simply
does not exist. What can you do with vector<>? Operator[] defined on it is
not a function. It is a template function. You cannot call it outside of
another template. That template must in turn have the vector's element type
as a parameter etc.

> so it's easy to write a code that copes with vectors of
> elements of different types.

Really? Write code which reads from the stream a type X (from some defined,
but large set of types) and then returns empty vector<X>.

>     Could you clarify this (or at least give some links concerning generic
> programming issues you are writing about)?

Stepanov? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Matthew Heaney]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> It is because they are not arrays. But why an ordered list should not
> implement an array interface? In my view it should, making the above
> legal for lists.

Stop obsessing about syntax.  If you want a consistent interface for
containers, you have that in AI-302 (but of course it's not an "array"
interface):

procedure Op (Container : <container's type>) is
   C : Cursor := First (Container);
begin
   while Has_Element (C) loop
      Process (C);  --or Process (Element (C))
      Next (C);
   end loop;
end Op;

Actually, if you intend on iterating over all the elements in a
container, the passive iterator is preferred:

procedure Op (Container : <containers's type> is
begin
   Container.Iterate (Process'Access);
end;

If you have an array type, then you can give it a container-like
interface for the purpose of binding an array object to a generic
algorithm.  I showed how to do this in an earlier post.
   


> I do! I hate implicit iterators, I prefer loops where
> possible. Especially, because exit conditions, nested iterations,
> exception handling become visible.

If you intend on traversing every element in the container, then use a
passive iterator.  It's more efficient, and less error-prone.

If you have exit conditions, then go ahead and use an active-iterator
style loop.


> [ Ranting: 40 years spent in developing readable, safe, well-structured
> language constructs, only to replace them with nested function calls a la
> Lisp? ]

This is a specious comparison.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Mon, 04 Oct 2004 12:16:58 GMT, Matthew Heaney wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> It is because they are not arrays. But why an ordered list should not
>> implement an array interface? In my view it should, making the above
>> legal for lists.
> 
> Stop obsessing about syntax.

Aha, but semantically that all is just a Turing machine. So yes, I am
obsessed with syntax. (:-))

> If you want a consistent interface for
> containers, you have that in AI-302 (but of course it's not an "array"
> interface):
> 
> procedure Op (Container : <container's type>) is
>    C : Cursor := First (Container);
> begin
>    while Has_Element (C) loop
>       Process (C);  --or Process (Element (C))
>       Next (C);
>    end loop;
> end Op;
> 
> Actually, if you intend on iterating over all the elements in a
> container, the passive iterator is preferred:
> 
> procedure Op (Container : <containers's type> is
> begin
>    Container.Iterate (Process'Access);
> end;
> 
> If you have an array type, then you can give it a container-like
> interface for the purpose of binding an array object to a generic
> algorithm.  I showed how to do this in an earlier post.

This is what I think the wrong way is - to use Ada's arrays like STL
containers, instead of the reverse. You will probably agree that iteration
is a fundamental programming pattern. As such, it IMO deserves a separate
language construct rather than being hidden in a subroutine call.

>> I do! I hate implicit iterators, I prefer loops where
>> possible. Especially, because exit conditions, nested iterations,
>> exception handling become visible.
> 
> If you intend on traversing every element in the container, then use a
> passive iterator.  It's more efficient, and less error-prone.
> 
> If you have exit conditions, then go ahead and use an active-iterator
> style loop.

Just compare:

 declare
    C : Cursor := First (Container);
 begin
    while Has_Element (C) loop
       Process (Element (C));
       Next (C);
    end loop;
 end;

with

 for C in Container'Range loop
    Process (Container (C));
 end loop;
 
You have to know about Cursor, First, Has_Element, Element and Next only to
call Process on each element of a container!

[ Don't even try to tell me that First is like 'First etc. Because, being
obsessed with syntax, I will reply that then it should be named 'First!
(:-)) ]

>> [ Ranting: 40 years spent in developing readable, safe, well-structured
>> language constructs, only to replace them with nested function calls a la
>> Lisp? ]
> 
> This is a specious comparison.

I tried hard... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> But why an ordered list should not
> implement an array interface? In my view it should, making the above legal
> for lists.

  I think this is a wrong way - list is not a kind of array to implement its 
interface. But both list and vector are *containers*, and they both have the 
common container interface - and that's why std::for_each and other std lib 
algorithms work on any conatiner (be it std::list, std::vector, C-style 
array or a user-defined type).

>> nor you can do the following so concisely:
>>
>> std::vector V(10);
>>
>> // Apply SomeFunction to elements [4, 9] in reverse order:
>> std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction);
>
> for Index in reverse V'First + 4..V'Last loop
>   SomeFunction (V (Index)); -- Better to place its body here, if short
> end loop;

  Sorry, my mistake. :-P I didn't know about this...

> [ Ranting: 40 years spent in developing readable, safe, well-structured
> language constructs, only to replace them with nested function calls a la
> Lisp? ]

;-)

>>> Far less flexible you mean.
>>
>>     C++ doesn't have a single-rooted object hierarchy. So if containers
>> weren't templates, they'd have to contain elements of some abstract
>> class,
>> call it CElement. Now, if you want to have a container of elements of
>> some
>> class not derived from CElement or even a container of int, then you'd
>> have
>> to make some wrapper classes - this would cost you a lot of time to make
>> it
>> work with the library.
>
> Yes, unless:
>
> 1. (for new types) language supports multiple interface inheritance. C++
> does, Ada 2005 will.

  'elements of some class -=#not#=- derived from CElement' - I meant if you
can derive, then there's no problem.

> 2. (for existing types) language supports supertyping. If it does, then
> creating a wrapper will be a matter of one or two code lines. You create a
> helper type which is both a subtype of CElement and a supertype of int.

  And you see, that's the point. I wrote: 'to make it work', and it's
not as easy as it seems. In order to work with container algorithms and
cooperate with other containers, your wrapper should also implement wrappers
for wrapped type's iterators with wrappers for wrapped type's iterators'
functions... Doesn't look to me like 'a matter of one or two code lines' ;-)

>> If you have a function template copying elements of
>> one container into another, then it'll work fine even for 100 container
>> types, as long as they use the same interface.
>
> Which interface you mean? string is an instance of another template. It is
> not vector<>, and there is no way to make it conform to vector<>, because
> there is no such thing as "vector interface".

  *container* interface. String is not exactly a vector, but might be
treated similarily to one because of it's container-like interface.

>> Can you specify what do you mean when saying 'mix them'?
>
> All cases were:
>
> template <class A, class B> Foo (vector <A>& X, vector <B>& Y)
> {
>   ...
>   Do_Something (X [I], Y [J]);
>   ...
> }
>
> cannot be replaced with:
>
> template <class A> Foo (vector <A>& X, vector <A>& Y)
> {
>   ...
>   Do_Something (X [I], Y [J]);
>   ...
> }

  Wouldn't this do?

template <class A, class B> Foo (A & X, B & Y)
{
  ...
  Do_Something (X [I], Y [J]);
  ...
}

Regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> This "same interface" is not a language object. It is a fiction, which
> cannot be described in language terms independently on its implementation.
> So you physically unable to program in terms of this interface. It simply
> does not exist.

  It's not a fiction, it's a kind of agreement. The language doesn't see
this interface directly, but you can use it. And if you try to violate it in
a place where conformance to this interface is crucial, your program won't
compile.

> What can you do with vector<>? Operator[] defined on it is
> not a function. It is a template function.

  Function template, you mean ;-)

> You cannot call it outside of
> another template. That template must in turn have the vector's element
> type
> as a parameter etc.

  So what? You just make a template instead of a function and the job is
done. In all the places you call this template function, a compiler
generates appropriate function from your template looking at the type of
it's arguments, and that's it.

>> so it's easy to write a code that copes with vectors of
>> elements of different types.
>
> Really? Write code which reads from the stream a type X (from some
> defined,
> but large set of types) and then returns empty vector<X>.

  Of course this can be done (Turing complete... ;-), but this is a very
different kind of problem, isn't it? It's just like reading a type X and
returning an object of type X. I don't think this would be much simpler if
std::vector<> was implemented as runtime-polymorphic, not using generics. Of
course there's the need to create a runtime-polymorphic wrapper class for
std::vector<>, but the problem of choosing the appropriate type from a large
set given this type's name as a string is the same in both cases. Besides
can you do this better in Ada than in C++? (Or it wasn't your point to
compare C++ with Ada in this respect, just to compare runtime vs. static
polymorphism?)

> Stepanov? (:-))

  Could you give some references (links, book titles...)? I became curious
(but it doesn't mean you've already convinced me ;-).

With regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Wed, 6 Oct 2004 19:28:31 +0200, Robert Kawulak wrote:

>> This "same interface" is not a language object. It is a fiction, which
>> cannot be described in language terms independently on its implementation.
>> So you physically unable to program in terms of this interface. It simply
>> does not exist.
> 
>   It's not a fiction, it's a kind of agreement. The language doesn't see
> this interface directly, but you can use it. And if you try to violate it in
> a place where conformance to this interface is crucial, your program won't
> compile.

Yes. For *you*, it is not a fiction, because you know its semantics. The
problem is how you communicate your personal percept of semantics to other
people. It is what a language all about...

>> What can you do with vector<>? Operator[] defined on it is
>> not a function. It is a template function.
> 
> Function template, you mean ;-)

R-r-right! (:-))

>> You cannot call it outside of
>> another template. That template must in turn have the vector's element
>> type as a parameter etc.
> 
>   So what? You just make a template instead of a function and the job is
> done. In all the places you call this template function, a compiler
> generates appropriate function from your template looking at the type of
> it's arguments, and that's it.

But this is what I meant. Templates constitute a meta-language. That is
inherently bad, provided there is a way to solve the problem within the
native language (maintaining a reasonable level of expressiveness). This
argument will stand even if templates became run-time things, which are
not, making the solution even worse.

BTW, Stepanov's point against OO and dynamic polymorphism was that he could
not do generic programming with it. I believe he was wrong.  

>>> so it's easy to write a code that copes with vectors of
>>> elements of different types.
>>
>> Really? Write code which reads from the stream a type X (from some
>> defined, but large set of types) and then returns empty vector<X>.
> 
>   Of course this can be done (Turing complete... ;-), but this is a very
> different kind of problem, isn't it? It's just like reading a type X and
> returning an object of type X.

Yes. The problem is that 1) it happens at run-time, 2) you have to name the
result type.

> I don't think this would be much simpler if
> std::vector<> was implemented as runtime-polymorphic, not using generics. Of
> course there's the need to create a runtime-polymorphic wrapper class for
> std::vector<>, but the problem of choosing the appropriate type from a large
> set given this type's name as a string is the same in both cases. Besides
> can you do this better in Ada than in C++?

Yes, the infrastructure is ready. Ada has S'Class'Input attribute (ARM
13.13.2) which represents a factory pattern. Basically it reads the type
tag from stream and then dispatches to an appropriate constructor, which is
*guaranteed* to exist. The result is a class-wide object. Unfortunately it
works only with tagged types, which do not include "true" arrays. But
nothing prevents us from making arrays tagged, if I only could convince Ada
community that this is necessary (:-)).

> (Or it wasn't your point to
> compare C++ with Ada in this respect, just to compare runtime vs. static
> polymorphism?)

Both.

>> Stepanov? (:-))
> 
>   Could you give some references (links, book titles...)?

http://www.sgi.com/tech/stl/drdobbs-interview.html
http://c2.com/cgi/wiki?GenericProgramming

> I became curious (but it doesn't mean you've already convinced me ;-).

You are not the only one, whom I cannot convince... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Wed, 6 Oct 2004 19:20:29 +0200, Robert Kawulak wrote:

>> But why an ordered list should not
>> implement an array interface? In my view it should, making the above legal
>> for lists.
> 
>   I think this is a wrong way - list is not a kind of array to implement its 
> interface. But both list and vector are *containers*, and they both have the 
> common container interface - and that's why std::for_each and other std lib 
> algorithms work on any conatiner (be it std::list, std::vector, C-style 
> array or a user-defined type).

In my view, array is a container and container is an abstract array.
Iterators should be introduced as index types, subdivided into ordered and
unordered ones. For ordered index types you can have ranges. From index
types you can build tuples, which depending on whether indices are ordered
or not, should allow subranges, projections (diagonals etc). Upon tuples
and element types one can build arrays. Subtyping of array types should
allow constraining/deriving of both index and element types.

>>>> Far less flexible you mean.
>>>
>>>     C++ doesn't have a single-rooted object hierarchy. So if containers
>>> weren't templates, they'd have to contain elements of some abstract
>>> class,
>>> call it CElement. Now, if you want to have a container of elements of
>>> some
>>> class not derived from CElement or even a container of int, then you'd
>>> have
>>> to make some wrapper classes - this would cost you a lot of time to make
>>> it
>>> work with the library.
>>
>> Yes, unless:
>>
>> 1. (for new types) language supports multiple interface inheritance. C++
>> does, Ada 2005 will.
> 
>   'elements of some class -=#not#=- derived from CElement' - I meant if you
> can derive, then there's no problem.

Yes, but differently to C++ in Ada that would cover almost 90% of all
cases. The reason is that in Ada we routinely clone/derive predefined
types:

type Velocity is new Float; -- Clone
type Velocity_Array is array ... of Velocity;

If we do it anyway, then it costs nothing to add a clause requiring
Velocity to implement, say, Comparable. Moreover, the predefined Float type
should be Comparable anyway!

>> 2. (for existing types) language supports supertyping. If it does, then
>> creating a wrapper will be a matter of one or two code lines. You create a
>> helper type which is both a subtype of CElement and a supertype of int.
> 
>   And you see, that's the point. I wrote: 'to make it work', and it's
> not as easy as it seems. In order to work with container algorithms and
> cooperate with other containers, your wrapper should also implement wrappers
> for wrapped type's iterators with wrappers for wrapped type's iterators'
> functions... Doesn't look to me like 'a matter of one or two code lines' ;-)

It is not different from the generic way. Your element should have some
operations. In C++ it is checked upon inlining. In Ada it is checked upon
instantiation. With my proposal it will be checked when you create a
wrapper. The only difference is in the place and time.

>>> If you have a function template copying elements of
>>> one container into another, then it'll work fine even for 100 container
>>> types, as long as they use the same interface.
>>
>> Which interface you mean? string is an instance of another template. It is
>> not vector<>, and there is no way to make it conform to vector<>, because
>> there is no such thing as "vector interface".
> 
>   *container* interface. String is not exactly a vector, but might be
> treated similarily to one because of it's container-like interface.

1. Who and how guaranties that? 2. You cannot have a conform to the
interface object without specifying its concrete type. The rest follows
from that.

>>> Can you specify what do you mean when saying 'mix them'?
>>
>> All cases were:
>>
>> template <class A, class B> Foo (vector <A>& X, vector <B>& Y)
>> {
>>   ...
>>   Do_Something (X [I], Y [J]);
>>   ...
>> }
>>
>> cannot be replaced with:
>>
>> template <class A> Foo (vector <A>& X, vector <A>& Y)
>> {
>>   ...
>>   Do_Something (X [I], Y [J]);
>>   ...
>> }
> 
>   Wouldn't this do?
> 
> template <class A, class B> Foo (A & X, B & Y)
> {
>   ...
>   Do_Something (X [I], Y [J]);
>   ...
> }

Where is any difference? You still have to specify both class A and class B
in the template parameter profile. Whereas the elements types are of little
interest for Foo. The contract of Foo is:

1. Foo takes two arrays as parameters.
2.a Nothing is said whether indices or elements types are related.
2.c They are members of some type set
  2.c.1 They have a common ancestor = the set is dynamically polymorphic
    2.c.1.a One is a subtype of another
  2.c.2 The set is generic = statically polymorphic
  ----
[ 2.c is equivalent, in my view, to requiring arrays to be from some set
  of types narrower than just ARRAY. If the language allows to specify
  ARRAY, then it will be also no problem to define its constrained subsets.
]
2.d They are same types

With templates you can reasonable implement only 2.d. Of course, one could
extend templates to support some sophisticated type pattern matching
mechanism, add constraints on formal types etc. IMO, that would be wasting
of time. I believe that inheritance is a much more clearer and safer way of
defining type sets than loose parametrization.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

>>> This "same interface" is not a language object. It is a fiction, which
>>> cannot be described in language terms independently on its
>>> implementation.
>>> So you physically unable to program in terms of this interface. It
>>> simply
>>> does not exist.
>>
>>   It's not a fiction, it's a kind of agreement. The language doesn't see
>> this interface directly, but you can use it. And if you try to violate it
>> in
>> a place where conformance to this interface is crucial, your program
>> won't
>> compile.
>
> Yes. For *you*, it is not a fiction, because you know its semantics. The
> problem is how you communicate your personal percept of semantics to other
> people. It is what a language all about...

    Similarily, I could say that Ada has no classes. Of course it has
packages, tagged records etc. but no true classes with true methods. Classes
in Ada are just as fictious as interfaces in C++ template metalanguage, yet
it doesn't mean you can't use OOP in Ada (and interfaces for templates in
C++).

> Templates constitute a meta-language. That is
> inherently bad, provided there is a way to solve the problem within the
> native language (maintaining a reasonable level of expressiveness).

    I'm afraid that our discussion will never reach its conclusion ;-) The 
reason is our opposite approach to templates and using them to implement 
containers. Of course everything that is done using templates may be as well 
done without them (although not always so easily). The point is that in many 
cases they simplify the design and, what is crucial for C++, they provide 
containers with efficiency. There's no need for dynamic binding, wrappers 
and those ugly downcasts :-P. Statically and dynamically polymorphic 
containers are just two different points of view, two different 
philosophies. It's nearly impossible to objectively say which one is the 
proper, for it depends on what is important to you. Both approaches have 
pros and cons (as we both tried to show in all our posts) and both aren't 
ideal in all cases. I think C++ chose the templates approach because it's 
closer to C++'s 'spirit' (don't pay for what you don't use, make built-in 
and UDTs the same etc). For contrary, Java has taken the opposite approach. 
And you are forced to use dynamic dispatching and downcasting, which doesn't 
sound attractive to me (at least you don't need wrappers, because Java 
object hierarchy is single-rooted).
    Anyway, I promise to have a look at the links you've provided (thanks), 
I'm sure I'll learn something new.

> Ada has S'Class'Input attribute (ARM
> 13.13.2) which represents a factory pattern. Basically it reads the type
> tag from stream and then dispatches to an appropriate constructor, which
> is
> *guaranteed* to exist. The result is a class-wide object.

    Good to know ;-)

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> In my view, array is a container and container is an abstract array.
> Iterators should be introduced as index types

    In my view it's not. Not every container has semantics of an array
(random access to every element and efficient insertions at the end of an
array), although every array may have semantics of container. I think that
for this reason containers shouldn't be all treated as abstract arrays,
because this could be misleading. After all the reason for diversity of
container types is their certain operations' efficiency difference.

> Iterators should be introduced as index types, subdivided into ordered and
> unordered ones.

    But aren't all iterators already ordered? Otherwise they couldn't
iterate...

> For ordered index types you can have ranges.

    Can't you have them with iterators?

>>> 1. (for new types) language supports multiple interface inheritance. C++
>>> does, Ada 2005 will.
>>
>>   'elements of some class -=#not#=- derived from CElement' - I meant if
>> you
>> can derive, then there's no problem.
>
> Yes, but differently to C++ in Ada that would cover almost 90% of all
> cases.

    This comparison seems to me a bit unfair. Don't you think that if C++
would use polymorphic containers, then its type system would also be
adjusted to cover 90% of all cases?

>>   And you see, that's the point. I wrote: 'to make it work', and it's
>> not as easy as it seems. In order to work with container algorithms and
>> cooperate with other containers, your wrapper should also implement
>> wrappers
>> for wrapped type's iterators with wrappers for wrapped type's iterators'
>> functions... Doesn't look to me like 'a matter of one or two code lines'
>> ;-)

    Ah, sorry - I've mistaken making a wrapper for elements for making a
wrapper for containers here... Never mind ;-)

> In C++ it is checked upon inlining. In Ada it is checked upon
> instantiation. With my proposal it will be checked when you create a
> wrapper. The only difference is in the place and time.

    What do you mean by 'inlining' here? C++ templates are also
instantiated, either explicitly or implicitly (in a place you use it).

>> template <class A, class B> Foo (A & X, B & Y)
>> {
>>   ...
>>   Do_Something (X [I], Y [J]);
>>   ...
>> }
[...]
> The contract of Foo is:
>
> 1. Foo takes two arrays as parameters.

    As long as we don't come to a common conclusion what an array is, this 
is meaningless...

> 2.a Nothing is said whether indices or elements types are related.

    Isn't that true here?

With regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Sun, 10 Oct 2004 23:09:24 +0200, Robert Kawulak wrote:

>> Yes. For *you*, it is not a fiction, because you know its semantics. The
>> problem is how you communicate your personal percept of semantics to other
>> people. It is what a language all about...
> 
>     Similarily, I could say that Ada has no classes. Of course it has
> packages, tagged records etc. but no true classes with true methods. Classes
> in Ada are just as fictious as interfaces in C++ template metalanguage, yet
> it doesn't mean you can't use OOP in Ada (and interfaces for templates in
> C++).

Yes, Ada does not have OO-ish classes. Whatever is usually meant under OO
"class" is either rubbish or just another name for type. Ada's classes
(T'Class) are type closures.
 
>> Templates constitute a meta-language. That is
>> inherently bad, provided there is a way to solve the problem within the
>> native language (maintaining a reasonable level of expressiveness).
> 
>     I'm afraid that our discussion will never reach its conclusion ;-) The 
> reason is our opposite approach to templates and using them to implement 
> containers. Of course everything that is done using templates may be as well 
> done without them (although not always so easily). The point is that in many 
> cases they simplify the design and, what is crucial for C++, they provide 
> containers with efficiency.

There is a broader picture. Consider parametrization in general, as a tool
for generic programming. The generic algorithms are represented as
operations defined on the sets of types. Sets of types are obtained by
varying the parameter or parameters. In this view C++ templates where the
parameter is a string containing either name of a type or an integer
literal is just a tiny stain on the face of the universe! (:-))

There are other, more structured and controllable ways of parametrization.
For example, 1) we all know built-in unconstrained arrays in languages like
Ada. They are parametrized by index bounds. 2) Ada 83 introduced type
discriminants and subtyping based on constraining discriminants. 3) OO
languages provide dynamically polymorphic types, were the specific type(s)
plays the role of the varying parameter (type tag, vtable etc).

> There's no need for dynamic binding, wrappers 
> and those ugly downcasts :-P. Statically and dynamically polymorphic 
> containers are just two different points of view, two different 
> philosophies.

They are not so different, see above.

> It's nearly impossible to objectively say which one is the 
> proper, for it depends on what is important to you. Both approaches have 
> pros and cons (as we both tried to show in all our posts) and both aren't 
> ideal in all cases. I think C++ chose the templates approach because it's 
> closer to C++'s 'spirit' (don't pay for what you don't use, make built-in 
> and UDTs the same etc).

I think #define is even more in C++'s spirit. Note also how simple and
effective it is! (:-))

> For contrary, Java has taken the opposite approach. 
> And you are forced to use dynamic dispatching and downcasting, which doesn't 
> sound attractive to me (at least you don't need wrappers, because Java 
> object hierarchy is single-rooted).

Need of donwcasting just highlights language design faults. There are also,
similar cases in Ada, alas. Yes, ADT in its present state is unsuitable for
building a decent container library. But that does not mean that it never
be...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Mon, 11 Oct 2004 00:21:06 +0200, Robert Kawulak wrote:

>> In my view, array is a container and container is an abstract array.
>> Iterators should be introduced as index types
> 
>     In my view it's not. Not every container has semantics of an array
> (random access to every element and efficient insertions at the end of an
> array), although every array may have semantics of container.

This is a property of the index type, I believe. If your index (iterator)
has only the operation 'Succ, and no 'Pred then the array built upon it
will become a stream, this in turn will allow an implementation, which does
not provide random access. And note that my point regards views and only. A
container may have other, non-array, views. Its array view might be strict
read-only etc. I want to separate interface and implementation, you know.

> I think that
> for this reason containers shouldn't be all treated as abstract arrays,
> because this could be misleading. After all the reason for diversity of
> container types is their certain operations' efficiency difference.
> 
>> Iterators should be introduced as index types, subdivided into ordered and
>> unordered ones.
> 
>     But aren't all iterators already ordered? Otherwise they couldn't
> iterate...

Not necessarily. You can have weaker orders. Consider multidimensional
arrays, trees and graphs. However, yes, "index" or "pointer" would be a
more precise word than "iterator".

>> For ordered index types you can have ranges.
> 
>     Can't you have them with iterators?

Only if the container defines a corresponding helper type. In my view it
should be the reverse. If a type is an ordered index then its contract is
to have ranges and all operations on them.

>>>> 1. (for new types) language supports multiple interface inheritance. C++
>>>> does, Ada 2005 will.
>>>
>>>   'elements of some class -=#not#=- derived from CElement' - I meant if
>>> you
>>> can derive, then there's no problem.
>>
>> Yes, but differently to C++ in Ada that would cover almost 90% of all
>> cases.
> 
>     This comparison seems to me a bit unfair. Don't you think that if C++
> would use polymorphic containers, then its type system would also be
> adjusted to cover 90% of all cases?

C++ is beyond hope, anyway. C++ OO model is in my view irreparably corrupt.
And I do not much care how #defines called templates will evolve. It is not
my business! (:-))

>> In C++ it is checked upon inlining. In Ada it is checked upon
>> instantiation. With my proposal it will be checked when you create a
>> wrapper. The only difference is in the place and time.
> 
>     What do you mean by 'inlining' here? C++ templates are also
> instantiated, either explicitly or implicitly (in a place you use it).

I prefer "inline" because C++ instantiation may fail due to errors in the
template body. That is because C++ templates are in fact macros. When and
if, C++ will switch to a contract model, then I will call it instantiation.

>>> template <class A, class B> Foo (A & X, B & Y)
>>> {
>>>   ...
>>>   Do_Something (X [I], Y [J]);
>>>   ...
>>> }
> [...]
>> The contract of Foo is:
>>
>> 1. Foo takes two arrays as parameters.
> 
>     As long as we don't come to a common conclusion what an array is, this 
> is meaningless...

But we don't need that, because in a contract model, array is just an
interface of a set of types with some operations defined. This eliminates
any philosophical question about where all arrays go when you turn the
computer off! (:-)) We just define the operations we consider to be useful
and call it array. Then anything declared to implement that interface will
be an instance of the array.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of languages

[Brian May]

Somebody really has ***too*** much time...

See <URL:http://www.99-bottles-of-beer.net/>.

There are two versions in Ada ;-).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada Popularity: Comparison of languages

[Peter Hermann]

Brian May <bam@snoopy.apana.org.au> wrote:
> Somebody really has ***too*** much time...
> 
> See <URL:http://www.99-bottles-of-beer.net/>.
> 
> There are two versions in Ada ;-).

reload (-:

http://www.csv.ica.uni-stuttgart.de/homes/ph/resources_on_ada.html

at end :-)

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

>>> In C++ it is checked upon inlining. In Ada it is checked upon
>>> instantiation. With my proposal it will be checked when you create a
>>> wrapper. The only difference is in the place and time.
>>
>>     What do you mean by 'inlining' here? C++ templates are also
>> instantiated, either explicitly or implicitly (in a place you use it).
>
> I prefer "inline" because C++ instantiation may fail due to errors in the
> template body. That is because C++ templates are in fact macros. When and
> if, C++ will switch to a contract model, then I will call it
> instantiation.

  Still I don't get it - what's wrong in that "C++ instantiation may fail 
due to errors in the template body"? Why shouldn't it fail? (Actually 
compilation may fail even when there's no instantiation, because templates 
bodies are always parsed, templates are not only ^C^V or #define as you say 
;-) And what would this "contract model" change? Nota bene, you can have 
contracts with templates - if you use some inappropriate type as template's 
parameter, it won't compile, and you can strenghten contracts using 
boost::concept_check and boost::type_traits mentioned before in this 
discussion.

Regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> I think #define is even more in C++'s spirit. Note also how simple and
> effective it is! (:-))

  I don't think so, many people (including Bjarne S.) were actually 
considering removal of preprocessor from C++ quite seriously...

Best regards,
Robert Kawulak

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Fri, 15 Oct 2004 11:25:03 +0200, Robert Kawulak wrote:

>>>> In C++ it is checked upon inlining. In Ada it is checked upon
>>>> instantiation. With my proposal it will be checked when you create a
>>>> wrapper. The only difference is in the place and time.
>>>
>>>     What do you mean by 'inlining' here? C++ templates are also
>>> instantiated, either explicitly or implicitly (in a place you use it).
>>
>> I prefer "inline" because C++ instantiation may fail due to errors in the
>> template body. That is because C++ templates are in fact macros. When and
>> if, C++ will switch to a contract model, then I will call it
>> instantiation.
> 
>   Still I don't get it - what's wrong in that "C++ instantiation may fail 
> due to errors in the template body"? Why shouldn't it fail? (Actually 
> compilation may fail even when there's no instantiation, because templates 
> bodies are always parsed, templates are not only ^C^V or #define as you say 
> ;-)

#define is also parsed! In compiled languages "parsed" is far less than
"compiled" and the results of these two actions are much different too. The
margin is not absolute of course, but parsed template body is closer to
parsed #define body than to a compiled true body.

> And what would this "contract model" change? Nota bene, you can have 
> contracts with templates - if you use some inappropriate type as template's 
> parameter, it won't compile,

Neither a macro expansion of #define would. Contracts are 1) imposed on
both sides, 2) checked *prior* the contracting parties engage each other. 

> and you can strenghten contracts using 
> boost::concept_check and boost::type_traits mentioned before in this 
> discussion.

It is still not a contract. You consider only the case when the
macro/template parameter does not fulfill the requirements of the
macro/template body, and ones of the expansion context. As long as these
requirements are not formulated, but are a subject of investigation of the
body (=implementation), it is not a contract. What if the *implementation*
does not fulfill the contract, while the parameter does? How can you judge
without explicit contract specification?

And finally, when you manage to have true contracts for templates. What
would be the gain? Your templates with contracts would be just like Ada
generics. As a meta-language they would have types (=classes of parameters)
but no user-defined ones (no ADT). Sorry, but it is early 70s of
programming languages! Why do we need a meta-language with no ADT, for a
language with ADT? There should be damn good reason for that, or? (Turing
does not count! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Martin Krischik]

Robert Kawulak wrote:

> Hi,
> 
>> I think #define is even more in C++'s spirit. Note also how simple and
>> effective it is! (:-))
> 
>   I don't think so, many people (including Bjarne S.) were actually
> considering removal of preprocessor from C++ quite seriously...

Sad that they did not.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> #define is also parsed! In compiled languages "parsed" is far less than
> "compiled" and the results of these two actions are much different too.

  OK, by saying 'parsed' I meant 'compiled'... Don't catch me in my
words! ;-)

> The
> margin is not absolute of course, but parsed template body is closer to
> parsed #define body than to a compiled true body.

  Templates are not so close to #defines. Using the 'export', keyword their
implementation may be *compiled* in only one translation unit, and you may
use them anywhere given only their declarations  - just like ordinary
functions and objects (well, at least in theory, because there are not so
many compilers supporting 'export' yet... But I hope this will change soon).

> What if the *implementation*
> does not fulfill the contract, while the parameter does?

  Ah, I see (at last ;-) what's your point. But is it really necessary to
check if the *implementation* is contract-conformant? If it's not
contract-conformant, then you get a compile-time error anytime you try to
use it, the only difference I see is that such an error is detected only
during instantiation. I know it'd be nice if the implementation would be
checked for contract-conformance during compilation (parsing, whatever ;-),
but OTOH I don't see not doing this such an issue...

Regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Kevin Cline]

"Robert Kawulak" <tigrisek@interia.pl> wrote in message news:<cl6gok$q0e$1@nemesis.news.tpi.pl>...
> Hi,
> 
> > #define is also parsed! In compiled languages "parsed" is far less than
> > "compiled" and the results of these two actions are much different too.
> 
>   OK, by saying 'parsed' I meant 'compiled'... Don't catch me in my
> words! ;-)
> 
> > The
> > margin is not absolute of course, but parsed template body is closer to
> > parsed #define body than to a compiled true body.
> 
>   Templates are not so close to #defines. Using the 'export', keyword their
> implementation may be *compiled* in only one translation unit, and you may
> use them anywhere given only their declarations  - just like ordinary
> functions and objects (well, at least in theory, because there are not so
> many compilers supporting 'export' yet... But I hope this will change soon).
> 
> > What if the *implementation*
> > does not fulfill the contract, while the parameter does?
> 
>   Ah, I see (at last ;-) what's your point. But is it really necessary to
> check if the *implementation* is contract-conformant? If it's not
> contract-conformant, then you get a compile-time error anytime you try to
> use it, the only difference I see is that such an error is detected only
> during instantiation. I know it'd be nice if the implementation would be
> checked for contract-conformance during compilation (parsing, whatever ;-),
> but OTOH I don't see not doing this such an issue...

Actually, this wouldn't be so nice.  As it is, member functions are 
instantiated individually, so we can write:

  template <class T> class Container
  {
    typedef ... const_iterator;
    void write(ostream& out) const
    {
      for (const_iterator i ... )
      {
         out << *i;
      }
    }
  }

and still be able to instantiate Container<X> even if
operator<<(ostream&, X)
is not defined.  There is no error unless we call Container<X>::write.

Of course, modern C++ experts would assert that functions like write
should be free functions and not class member functions.

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Dmitry A. Kazakov]

On Wed, 20 Oct 2004 22:06:28 +0200, Robert Kawulak wrote:

>> What if the *implementation*
>> does not fulfill the contract, while the parameter does?
> 
>   Ah, I see (at last ;-) what's your point. But is it really necessary to
> check if the *implementation* is contract-conformant? If it's not
> contract-conformant, then you get a compile-time error anytime you try to
> use it, the only difference I see is that such an error is detected only
> during instantiation.

But software design, at least with Ada, is not about detecting errors. That
would be debugging. (:-)) The advantage of contracts is in knowledge. With
templates when you instantiate and get an error, you cannot judge who was
wrong, contract is the code of laws to judge. [Provided that you have a
gift of deciphering template error messages, which tend to be longer than
the source code!]

> I know it'd be nice if the implementation would be
> checked for contract-conformance during compilation (parsing, whatever ;-),
> but OTOH I don't see not doing this such an issue...

Kevin Cline in other post gave an excellent example of how awful it is. His
example shows that a template developer have to write extensive tests to
detect errors which, otherwise, would be routinely detected by any
compiler.

In his view it is an advantage that no error will be detected until write
is used. In my view it is a fallacy. If write is declared in Container,
then it is a contract, is it? Then if an instantiation with some T makes
its use impossible, then the contract is violated. On the other hand, if
that instantiation is right and there is no need in write for a Container,
then it is Container which violates the implied contract by placing there
write. This or that way, the result is same. A contract model works only if
it does not leak.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Robert Kawulak]

Hi,

> But software design, at least with Ada, is not about detecting errors.
> That would be debugging. (:-))

  Would you like your compiler not to find errors then? (Just kidding... ;-)

Regards,
Robert

Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[Larry Kilgallen]

In article <clp51f$729$2@nemesis.news.tpi.pl>, "Robert Kawulak" <tigrisek@interia.pl> writes:
> Hi,
> 
>> But software design, at least with Ada, is not about detecting errors.
>> That would be debugging. (:-))
> 
>   Would you like your compiler not to find errors then? (Just kidding... ;-)

I would like my compiler not to find errors.
I just want my compiler to be _capable_ of finding errors,
on the distant chance there were any.

So far the compilers are doing better at finding errors than I am at
making the chance be distant.