Computer Language Shootout

Computer Language Shootout

[Eric Merritt]

I noticed that Ada is not represented in the shootout,
it also looks like the author is willing to accept Ada
if the code is submitted. Is any one interested in a
little side project for Ada promotion? I would do it
my self but I am so new to the language that I am
afraid I would miss allot of optimizations, etc.
Anyway the page is interesting if anyone wants to
check it out.

http://www.bagley.org/~doug/shootout/

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

Re: Computer Language Shootout

[tmoran]

Just looking at some of the benchmark examples gives me a headache.  The
author himself gives some of the reasons they are "lies, damned lies, and
benchmarks".  Most are small, so comprehensibility of code is untested.
Speed is the most important thing, and you are apparently supposed to do
things the same way as the other programming language versions, so you are
pretty much left testing a particular compiler's code generator or library
routines (eg reading lines of text).  He allows tricks like reading the
entire source file in one operation, then scanning it from memory, which
is not testing the same thing as multiple single-line reads.  His
lines-of-code metric, which he admits is terrible, counts non-comment
source lines, so there's a strong pressure to avoid white space.  In the
example with threads he mentions that a solution using Python's
synchronized Queue class is not legitimate - I presume that means one
couldn't use the obvious Ada solution with protected types, but would have
to ignore that Ada advantage.  etc etc etc

Re: Computer Language Shootout

[Al Christians]

tmoran@acm.org wrote:
> 
> Just looking at some of the benchmark examples gives me a headache.  
+ ...  lots of valid criticism of the shootout.

But Ada surely ought to do very well.  I know there are some places 
where O'Caml (does well in the shootout) is likely faster.  Maybe a few
places where C/C++ might beat Ada.   But Ada (ie GNAT)  is very good for 
performance, and the shootout is for people who care about that.  It's
an opportunity.  Ada (GNAT) should be miles ahead of all of the 
interpreted and bytecode languages, and will be in the group at the
front of the pack (I'd bet).


Al

Re: Computer Language Shootout

[martin.m.dowie]

"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1004764329.23677.comp.lang.ada@ada.eu.org...
> I noticed that Ada is not represented in the shootout,
> it also looks like the author is willing to accept Ada
> if the code is submitted. Is any one interested in a
> little side project for Ada promotion? I would do it
> my self but I am so new to the language that I am
> afraid I would miss allot of optimizations, etc.
> Anyway the page is interesting if anyone wants to
> check it out.
>
> http://www.bagley.org/~doug/shootout/


Irrespective of where the benchmarks are any actual use or not (they
aren't...)
this could be a pretty good advert for Ada. I did write a program for the
first
benchmark (simple array allocations) and it was as fast as the 'C'
equivilant.

It seems a shame that just now the language isn't even represented...

Re: Computer Language Shootout

[Ted Dennison]

In article <hoOE7.4555$Cl3.1150494@news6-win.server.ntlworld.com>,
martin.m.dowie says...
>Irrespective of where the benchmarks are any actual use or not (they
>aren't...)
>this could be a pretty good advert for Ada. I did write a program for the
>first
>benchmark (simple array allocations) and it was as fast as the 'C'
>equivilant.

How did it compare on their SLOC measurement?


The last time I read over that, its goals, methods, and conclusions seemed so
bogus that I didn't think it was worth participating. The ideal language for
them would be some compiled form of APL. Anything that proports to compare
languages in a general way and is stilted towards APL isn't worth my time.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Computer Language Shootout

[martin.m.dowie]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:cQSE7.11173$xS6.15277@www.newsranger.com...
> How did it compare on their SLOC measurement?

no idea - I just wanted to prove, to myself as much as anything, that Ada95
could
hack it with the fastest of them... and it could.


> The last time I read over that, its goals, methods, and conclusions seemed
so
> bogus that I didn't think it was worth participating. The ideal language
for
> them would be some compiled form of APL. Anything that proports to compare
> languages in a general way and is stilted towards APL isn't worth my time.

I'm sure there are hundred of reasons why this sort of benchmarking is
'bogus' but
not actually entering a suite of Ada programs for (potentially favourable)
comparisons
just means that even more people think the language is dead. :-(

Re: Computer Language Shootout

[Larry Kilgallen]

In article <cQSE7.11173$xS6.15277@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:

> The last time I read over that, its goals, methods, and conclusions
> seemed so bogus that I didn't think it was worth participating. The
> ideal language for them would be some compiled form of APL. Anything
> that proports to compare languages in a general way and is stilted
> towards APL isn't worth my time.

Hey, at least they are at the proper end of the alphabet :-)

Seriously, anything that gets the Ada name out there as being current
is worthwhile.  If Ada comes out dead last in the terseness competition
it will attract favorable notice from those who have ever had to read
obfuscated code.

Re: Computer Language Shootout

[research@ijs.co.nz]

On 3 Nov 2001 08:49:27 -0600, Kilgallen@SpamCop.net (Larry Kilgallen)
wrote:

>In article <cQSE7.11173$xS6.15277@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
>
>> The last time I read over that, its goals, methods, and conclusions
>> seemed so bogus that I didn't think it was worth participating. The
>> ideal language for them would be some compiled form of APL. Anything
>> that proports to compare languages in a general way and is stilted
>> towards APL isn't worth my time.
>
>Hey, at least they are at the proper end of the alphabet :-)
>
>Seriously, anything that gets the Ada name out there as being current
>is worthwhile.  If Ada comes out dead last in the terseness competition
>it will attract favorable notice from those who have ever had to read
>obfuscated code.


For the 'echo server' shootout, I coded up a solution, and Ada 95 was
going to be last since 251 lines long. This is the page on the "echo
server" shootout: the programs are expected to fork (or multitask) and
both send and receive bytes:

http://www.bagley.org/~doug/shootout/bench/echo/


Adasockets could be replaced with the newly available GNAT Sockets
code. But that maybe would not make the code smaller.

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/g-socket.ads?rev=1.2&content-type=text/x-cvsweb-markup

The lengthiest entry, the (forking) g++ code was about 129 lines long.

Maybe the G++ entry could produce zombies or core-dumps at run time:

   int sigchld = 0;
   void reaper (int sig) { sigchld = 1; }
 ...
      signal(SIGCHLD, reaper);
      if ((pid = fork()) == -1)
	    sysabort("server/fork");


The  Ruby solution is about 29 lines long. Ruby might even be 
initialising Winsockets (which could add maybe another 97
non-comment lines to any Ada 'echo' entry (bringing the total to
just over 300 lines).

I can e-mail out my echo server code to anybody else interested in
having Ada compete (i.e. lose) under a clean adjective-free
["stilted .. APL"] test where pairs of integers are compared.

The shootout could be altered (a committee investigates; hack his
site?), and these can be the new requirements

 * code must be fast with 0 run time error problems, when running on
    a slow CPU (this can eliminate Java easily: run time socket I/O
    errors creep in and make it maybe 5 times slower than Ada)
 * multitasking, requeue statements of each language demonstrated.
 * portability to Windows operating systems and no forking.
 * assembly inlining tests
 

I see that there is a TCP Stack coded in Java now:
 http://www.websprocket.com/

Re: Computer Language Shootout

[tmoran]

>For the 'echo server' shootout, I coded up a solution, and Ada 95 was
>going to be last since 251 lines long. This is the page on the "echo
  I coded it using the Claw.Sockets library and, after pretty-printing
to normalize white space, the result is 60 lines.  Amusingly, that's
exactly the average of the lengths in his table.  The loop consists of
calls on "send" and "recv" and a little bit of status checking and
comparing the echoed 19 characters to the original, so most of the
time ought to be in the OS.  Claw runs only on Windows, though,
not Linux, so I guess it's excluded.
  Looking at the gcc version, it's not clear to me why an Ada
transliteration should be significantly different in size.

Re: Computer Language Shootout

[Larry Kilgallen]

If Ada becomes a member of the language "club" this fellow runs,
it might be possible to suggest additional problems for the group.

When I had a discussion with him some months ago his attitude on
new languages seemed to be a matter of waiting until he personally
had time to deal with them.

Re: Computer Language Shootout

[Preben Randhol]

On Sat, 3 Nov 2001 08:52:56 -0000, martin.m.dowie wrote:
> 
> Irrespective of where the benchmarks are any actual use or not (they
> aren't...)
> this could be a pretty good advert for Ada. I did write a program for the
> first
> benchmark (simple array allocations) and it was as fast as the 'C'
> equivilant.

Did you suppress run-time tests etc in Ada ?

Preben Randhol
-- 
Please, stop bombing civilians in Afghanistan. One cannot write off
killing innocent children and other civilians as "collateral damage".
A civilian is a civilian whether he or she is American or from another
country in the world.           http://web.amnesty.org/11september.htm

Re: Computer Language Shootout

[martin.m.dowie]

> Did you suppress run-time tests etc in Ada ?

Yes as the problem was simply writing various values to the array
and doing a few loops, a 'Range did the trick. I didn't see any need
for them to be there. If I had thought about it more, I would now have
checked to see if the compiler actually put any in, or if it was smart
enough to work out that none were required...

Re: Computer Language Shootout

[Adrian Hoe]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<1aKyQDuwXbPB@eisner.encompasserve.org>...
> If Ada becomes a member of the language "club" this fellow runs,
> it might be possible to suggest additional problems for the group.
> 
> When I had a discussion with him some months ago his attitude on
> new languages seemed to be a matter of waiting until he personally
> had time to deal with them.


Personally, I think the effort is in good intention. Remember the
disclaimers he wrote, "I'm just a beginner in many of these languages,
so if you can help me improve any of the solutions, please drop me an
email. Thanks." This could help providing some useful insight. I have
not see erlang, OCAMl, and most of the other languages, like mlton,
stalin, mercury, smlnj and all other funny names. When I take a look
at those codes, clearly readbility is low, perhaps near to zero, and
it took me sometime to vaguely understand those code.

The shootout, of course, is not well designed and managed but
certainly has a lot to improve:

1. with plentyful of experienced software engineers in CLA, can
provide a proven methodology for the purpose.

2. Provide clearly written Ada code for comparison and I am confident
Ada will win the war in this area.

What do you think?

Re: Computer Language Shootout

[David Brown]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:

> When I had a discussion with him some months ago his attitude on
> new languages seemed to be a matter of waiting until he personally
> had time to deal with them.

He also seems to suggest that Ada didn't seem very interesting to him.
Perhaps he needs some "convincing".

Dave Brown

Re: Computer Language Shootout

[AG]

<tmoran@acm.org> wrote in message
news:eo5F7.19081$wj5.9421656@news1.rdc1.sfba.home.com...
> >For the 'echo server' shootout, I coded up a solution, and Ada 95 was
> >going to be last since 251 lines long.
>   I coded it using the Claw.Sockets library and, after pretty-printing
> to normalize white space, the result is 60 lines.

Isn't it true though that, given a long enough SLOC support from the
compiler,
any Ada program can be written on a single line? Or, at least, use as long
lines
as are supported by the compiler. That'll show them for sure ... :) So, what
was
that metric about?

Re: Computer Language Shootout

[tmoran]

>>   I coded it using the Claw.Sockets library and, after pretty-printing
>> to normalize white space, the result is 60 lines.
>Isn't it true though that, given a long enough SLOC support from the
>compiler, any Ada program can be written on a single line?
  Changing variable names to single letters and dropping unrequired
white space, the whole program fits in about 1200 characters.
With Gnat's 255 line length limit, that's under 5 lines.  If that's
the metric, this code is the winner. ;)

Re: Computer Language Shootout

[Larry Kilgallen]

In article <DvLF7.6224$9M2.575294@news.xtra.co.nz>, "AG" <ang@xtra.co.nz> writes:
> 
> <tmoran@acm.org> wrote in message
> news:eo5F7.19081$wj5.9421656@news1.rdc1.sfba.home.com...
>> >For the 'echo server' shootout, I coded up a solution, and Ada 95 was
>> >going to be last since 251 lines long.
>>   I coded it using the Claw.Sockets library and, after pretty-printing
>> to normalize white space, the result is 60 lines.
> 
> Isn't it true though that, given a long enough SLOC support from the
> compiler,
> any Ada program can be written on a single line? Or, at least, use as long
> lines
> as are supported by the compiler. That'll show them for sure ... :) So, what
> was
> that metric about?

What you describe is indeed an Ada capability.

More frequent is more important than more accurate when it comes to broad
publicity for Ada.  This is public relations, not software engineering.

Re: Computer Language Shootout

[Richard Riehle]

AG wrote:

> Isn't it true though that, given a long enough SLOC support from the
> compiler,
> any Ada program can be written on a single line? Or, at least, use as long
> lines
> as are supported by the compiler. That'll show them for sure ... :) So, what
> was
> that metric about?

In modern programming, there are a lot of problems with the SLOC metric.
For example, do we count the SLOC of any libraries we might use?   If we
count only the code of the program in question, does it matter if we put
several statements on one line?    Wouldn't it be more useful to count the
number of statements instead of the number of lines?

Another problem.   Some languages are better at writing short programs than
others.   Ada is excellent for larger programs developed by a team of
engineers.   It is terrible for "hello world" programs.    One could write a
great "hello world" program in a few lines of assembler.   In any other
language, there are supporting libraries for I/O that must be considered
as part of the solution space.

Let's see what happens in this "shootout" as the size of the programs increases
to, say, 100K non-comment source code statements.   Now double that size.
Then double that.   How is Visual Basic faring?  How is C faring?   Indeed,
compared to Ada, how is C++ holding up?   Under the criteria of selecting
the right tool for the right job,  Ada holds its own.

Unfortunately, this "shootout" is being conducted by someone without the
slightest idea, by his own admission, what it takes to build software in
a wide range of domains, especially large-scale software.   It is an odd
revisiting of Zeno's Paradox all over.

Richard Riehle

Re: Computer Language Shootout

[AG]

<tmoran@acm.org> wrote in message
news:ERMF7.707$Mt6.409626@news1.rdc1.sfba.home.com...
> >>   I coded it using the Claw.Sockets library and, after pretty-printing
> >> to normalize white space, the result is 60 lines.
> >Isn't it true though that, given a long enough SLOC support from the
> >compiler, any Ada program can be written on a single line?
>   Changing variable names to single letters and dropping unrequired
> white space, the whole program fits in about 1200 characters.
> With Gnat's 255 line length limit, that's under 5 lines.  If that's
> the metric, this code is the winner. ;)

That's the spirit - was the whole point of my post (Sorry I didn't make
the irony even clearer but I did put a smiley in there, didn't I?)

Computer Language Shootout

[Craig Carey]

The Ada 95 entries have appeared that the new
 "Computer Language Shootout" website:

   http://dada.perl.it/shootout/gnat.html

Ada came first of 32 entries in this OO test:

   http://dada.perl.it/shootout/methcall.html

The Ada entry to read numbers from a file was slow.

The specs for the integer summing program are here: 
   http://www.bagley.org/~doug/shootout/bench/sumcol/

I argue here that the Gcc sumcol entry should be rejected. The C
programmers assumed that the file's lines were known, thus they
knew there was only 100 lines. Speed is not important with 100
lines files, but losing a patch of the competition due to buggy
code from C programmer might easily be more important.

That says programs "can assume" that each line has no more than 128
characters. Thus checking can be omitted and a crash is OK. A quite 
different wording was used in the specs, for lines containing 2
integers.

The specs author, Mr Bagley wrote that the programs "should" read
integers "line by line". The C programmers in fact were never told
whether to use the first integer or the 2nd (if there are two or
more). Also they were required to read an integer when there was
none, which suggests error checking but their C code has none.

I speak for comp.lang.ada and express a pessimism that a C
programmer could recognize that winning arguably bug-infested C
entries ought be disqualified.

-------

As for having 100% of all other entries except my Ada entry, crash due
to bugs, the heapsort test could have been developed into that. Other
programmers had confusion between the 1 that was the result of repeated
halving, with the 1 that was the first index of the array being sorted.

The tester in Italy rejected my regular expression program. It looks
like large programs are getting rejected. That submission used my
strings package. Also entries using Charles code wa rejected. The
tester does not reply readily.

Also the "wc" word count example was small, but that was rejected.
I guess that the tester could not linking in the Windows "_setmode"
and "_read" routines. GNAT has a routine but that is not a standard
like Microsoft C. ('Ada.Streams.Stream_IO.Read (File, Item, Last)' does
not allow File to be associated with the Standard Input so accurate
reading from the console is not a feature of Ada).





Craig Carey

--------------------------

How To Cross-Compile to a Linux target while compiling in a FreeBSD 5
host. Some new instructions are here:
http://www.ijs.co.nz/code/ada95-freebsd-to-linux-cross-compiler.txt

Re: Computer Language Shootout

[Preben Randhol]

Craig Carey wrote:


I tried the Ackermann's Function but on my computer it used only
0.092 s with 8 as argument. Are all these test run on the same machine
(for all languages?)

I compiled on a GNAT 3.14p wil -gnatp and -O2

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Preben Randhol]

Craig Carey wrote:
> 
> The Ada entry to read numbers from a file was slow.
>
> The specs for the integer summing program are here: 
>    http://www.bagley.org/~doug/shootout/bench/sumcol/

I don't understand why your code is so complicated: Why not simply do:

   with Ada.Text_IO; use Ada.Text_IO;

   procedure sumcol is
      Sum : Integer := 0;
      Number : String (1 .. 128);
      Last : Natural := 1;
   begin
      while not End_of_Line (Standard_Input) loop
         Get_Line (Standard_Input, Number, Last => Last);
         Sum := Sum + Integer'Value (Number (1 .. Last));
      end loop;

      Put_Line ("Sum: " & Integer'Image (Sum));
   end sumcol;

And the spec above says that the line is only 128 characters wide, so
why do you allocate a string for 4096 ?

> I argue here that the Gcc sumcol entry should be rejected. The C
> programmers assumed that the file's lines were known, thus they
> knew there was only 100 lines. Speed is not important with 100
> lines files, but losing a patch of the competition due to buggy
> code from C programmer might easily be more important.

I cannot see that they used this assumption for the code here:

   http://dada.perl.it/shootout/sumcol.gcc.html

> That says programs "can assume" that each line has no more than 128
> characters. Thus checking can be omitted and a crash is OK. A quite 
> different wording was used in the specs, for lines containing 2
> integers.
>
> The specs author, Mr Bagley wrote that the programs "should" read
> integers "line by line". The C programmers in fact were never told
> whether to use the first integer or the 2nd (if there are two or
> more). Also they were required to read an integer when there was
> none, which suggests error checking but their C code has none.

I find the spec a bit unclear about this. As I understand it and this
seems to be the way most implementations are done, is that one can
expect one integer per line.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Matthew Heaney]

Craig Carey <research@ijs.co.nz> wrote in message news:<n54tgvgugor0ag2qsv97t9mf9sn9rr542i@4ax.com>...
> The Ada 95 entries have appeared that the new
>  "Computer Language Shootout" website:
> 
>    http://dada.perl.it/shootout/gnat.html

I just cobbled together the "hash table (associative array)" example
using the hashed set in Charles.  Here it is:

 
procedure Test_Hash is

   Map : String_Integer_Maps.Container_Type;

   N : Natural := 0;
   
   Last : Natural;

begin

   if Ada.Command_Line.Argument_Count > 0 then
      Get (Ada.Command_Line.Argument (1), N, Last);
   end if;      

   Resize (Map, N);
   
   for I in Integer range 1 .. N loop
      Insert (Map, To_Key (I, Base => 16), I);
   end loop;
   
   declare
      I : Iterator_Type := First (Map);
      J : constant Iterator_Type := Back (Map);
   begin
      while I /= J loop
         Put (Key (I));
         Put (":");
         Put (Element (I), Width => 0);
         New_Line;
         I := Succ (I);
      end loop;
      
      New_Line;
   end;
   
   Put ("map.length=");
   Put (Length (Map), Width => 0);
   New_Line;
   
   declare
      Count : Integer'Base := 0;
   begin      
      for I in reverse Integer range 1 .. N loop
         if Find (Map, To_Key (I, Base => 10)) then
            Count := Count + 1;
         end if;
      end loop;
      
      Put ("map.count=");
      Put (Count, Width => 0);
      New_Line;
   end;

end Test_Hash;

The latest release (20030710) of Charles has better hash table
support.  There are also containers for storing elements whose type is
limited.

http://home.earthlink.net/~matthewjheaney/charles/index.html

I must say, nothing beats having a predefined container library. 
Problems that would otherwise take hours to solve now take just
minutes.

-Matt

Re: Computer Language Shootout

[Matthew Heaney]

mheaney@on2.com (Matthew Heaney) wrote in message news:<1ec946d1.0307111358.fb772@posting.google.com>...
> > The Ada 95 entries have appeared that the new
> >  "Computer Language Shootout" website:
> > 
> >    http://dada.perl.it/shootout/gnat.html
> 
> I just cobbled together the "hash table (associative array)" example
> using the hashed set in Charles.  Here it is:

Here's the "hash2" shootout problem, coded using the hashed map in
Charles:

procedure Test_Hash is

   M1, M2 : String_Integer_Maps.Container_Type;

   N : Positive;
   
   type Element_Access is access all
String_Integer_Maps.Element_Subtype;
   for Element_Access'Storage_Size use 0;
   
   function To_Access is new Generic_Element (Element_Access);
   
begin

   if Ada.Command_Line.Argument_Count = 0 then
      N := 1;
   else
      declare
         Last : Natural;
      begin
         Get (Ada.Command_Line.Argument (1), N, Last);
      end;
   end if;      

   Resize (M1, 10000);
   
   for I in Integer range 0 .. 9999 loop
      Insert (M1, "foo_" & To_Key (I, Base => 10), I);
   end loop;
   
   Put ("m1[foo_1]=");
   Put (Element (Find (M1, "foo_1")), Width => 0);
   New_Line;
   
   Put ("m1[foo_9999]=");
   Put (Element (Find (M1, "foo_9999")), Width => 0);
   New_Line;

   Resize (M2, Length (M1));
   
   for I in Integer range 1 .. N loop
      declare
         I1 : Iterator_Type := First (M1);
         J1 : constant Iterator_Type := Back (M1);
         
         I2 : Iterator_Type;
         B : Boolean;
      begin
         while I1 /= J1 loop
            Insert (M2, Key (I1), 0, I2, B);

            declare
               E : Element_Subtype renames To_Access (I2).all;
            begin
               E := E + Element (I1);
            end;
            
            I1 := Succ (I1);
         end loop;
      end;
   end loop;
                   
   Put ("m2[foo_1]=");
   Put (Element (Find (M2, "foo_1")), Width => 0);
   New_Line;
   
   Put ("m2[foo_9999]=");
   Put (Element (Find (M2, "foo_9999")), Width => 0);
   New_Line;

end Test_Hash;


I don't imagine that any of the shootout examples would be difficult
to implement in Ada95, or any less efficient.

http://home.earthlink.net/~matthewjheaney/charles/index.html

-Matt

Re: Computer Language Shootout

[Matthew Heaney]

mheaney@on2.com (Matthew Heaney) wrote in message news:<1ec946d1.0307111358.fb772@posting.google.com>...
> Craig Carey <research@ijs.co.nz> wrote in message news:<n54tgvgugor0ag2qsv97t9mf9sn9rr542i@4ax.com>...
> > The Ada 95 entries have appeared that the new
> >  "Computer Language Shootout" website:
> > 
> >    http://dada.perl.it/shootout/gnat.html
> 
> I just cobbled together the "hash table (associative array)" example
> using the hashed set in Charles.  Here it is:

Here's the word frequency example:

procedure Wordfreq is

   Line  : String (1 .. 133);
   Last  : Natural;
   
   Word : Charles.Strings.Unbounded.Container_Type;
   Map : String_Integer_Maps.Container_Type;

   type Integer_Access is access all Integer;
   for Integer_Access'Storage_Size use 0;
   
   function To_Access is
      new Generic_Element (Integer_Access);   
      
   procedure Insert is
      I : Iterator_Type;
      B : Boolean;
   begin
      if Is_Empty (Word) then
         return;
      end if;

      Insert (Map, To_String (Word), 0, I, B);
      
      declare
         Count : Integer renames To_Access (I).all;
      begin
         Count := Count + 1;
      end;
      
      Clear (Word);
   end Insert;
               
begin

   while not End_Of_File loop
   
      Get_Line (Line, Last);
            
      for I in Line'First .. Last loop
         if Is_Alphanumeric (Line (I)) then
            Append (Word, To_Lower (Line (I)));            
         else
            Insert;
         end if;
      end loop;
      
      if Last < Line'Last then
         Insert;
      end if;
      
   end loop;       
   
   declare
      A : array (1 .. Length (Map)) of Iterator_Type;
      
      function Is_Less (R, L : Positive) return Boolean is
         RI : constant Iterator_Type := A (R);
         LI : constant Iterator_Type := A (L);
      begin
         if Element (RI) = Element (LI) then
            return Key (RI) > Key (LI);
         else
            return Element (RI) > Element (LI);
         end if;
      end Is_Less;
      
      procedure Swap (I, J : Positive) is
         E : constant Iterator_Type := A (I);
      begin
         A (I) := A (J);
         A (J) := E;
      end;
      
      procedure Sort is
         new Charles.Algorithms.Generic_Quicksort (Positive);
         
      I : Iterator_Type := First (Map);
   begin
      for Index in A'Range loop
         A (Index) := I;
         I := Succ (I);
      end loop;
      
      Sort (First => A'First, Back => A'First + A'Length);

      for Index in A'Range loop
         Put (Element (A (Index)), Width => 0);
         Put (':');
         Put (Key (A (Index)));
         New_Line;
      end loop;
   end;
         
end Wordfreq;

The Charles library includes the map used in the example, as well as
the generic algorithm for sorting a container.

http://home.earthlink.net/~matthewjheaney/charles/index.html

Instead of using an array as in the example, I could have used a list,
which comes with its own sort operation.  (For a list, the sort is
stable.)

-Matt

Re: Computer Language Shootout

[Matthew Heaney]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbgtckk.54b.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Craig Carey wrote:
> > 
> > The Ada entry to read numbers from a file was slow.
> >
> > The specs for the integer summing program are here: 
> >    http://www.bagley.org/~doug/shootout/bench/sumcol/
> 
> I don't understand why your code is so complicated: Why not simply do:
> 
>    with Ada.Text_IO; use Ada.Text_IO;
> 
>    procedure sumcol is
>       Sum : Integer := 0;
>       Number : String (1 .. 128);
>       Last : Natural := 1;
>    begin
>       while not End_of_Line (Standard_Input) loop
>          Get_Line (Standard_Input, Number, Last => Last);
>          Sum := Sum + Integer'Value (Number (1 .. Last));
>       end loop;
> 
>       Put_Line ("Sum: " & Integer'Image (Sum));
>    end sumcol;
> 
> And the spec above says that the line is only 128 characters wide, so
> why do you allocate a string for 4096 ?

It's not necessary to pass the object Standard_Input explicitly to
End_Of_Line and Get_Line, because those operations are overloaded to
read from standard input by default.

You can also generate better code by declaring the Sum as Integer'Base
instead of Integer; this turns off constraint checks.

declare
   Sum : Integer'Base := 0;

   Line : String (1 .. 128);
   Last : Natural;
begin
   while not End_Of_File loop
      Get_Line (Line, Last);
      Sum := Sum + Integer'Value (Line (Line'First .. Last));
   end loop;
   ...
end;

You could also have used Integer_Text_IO.Get to read the value from
the string buffer, instead of using Integer'Value.  This would allow
you to read multiple values from a single line (assuming that was
required in this program).


-Matt

Re: Computer Language Shootout

[Robert I. Eachus]

Matthew Heaney wrote:

 > It's not necessary to pass the object Standard_Input explicitly to
 > End_Of_Line and Get_Line, because those operations are overloaded to
 > read from standard input by default.

I know, I'm a language lawyer.  But I hardly ever claim to be anything
else.  I am sure you meant that these operations are overloaded to use 
Current_Output, which defaults to Standard_Output. ;-)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are
insignificant beside two prime questions, which are: 1. Can he shoot? 2.
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and
Steve Miller.

Re: Computer Language Shootout

[Isaac Gouy]

Aldo Calpini will only publish programs on his Win32 Language Shootout
if they are sent to him by the author, giving consent for their use.

Please read the FAQ on his website:
http://dada.perl.it/shootout/faq.html
And don't expect him to respond to email or publish your contribution
anytime real soon ;-)


Note: I don't think anyone has attempted to do 
Echo Client/Server in Ada 95 (for MS Windows). 


best wishes, Isaac


> Here's the word frequency example:

Re: Computer Language Shootout

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F149243.80304@attbi.com...
> Matthew Heaney wrote:
>
>  > It's not necessary to pass the object Standard_Input explicitly to
>  > End_Of_Line and Get_Line, because those operations are overloaded to
>  > read from standard input by default.
>
> I know, I'm a language lawyer.  But I hardly ever claim to be anything
> else.  I am sure you meant that these operations are overloaded to use
> Current_Output, which defaults to Standard_Output. ;-)

Actually, I meant End_Of_File, not End_Of_Line.

Do you really mean that End_Of_File and Get_Line use Current_Output?  I
thought they used Current_Input.

Aside: I don't ever use End_Of_Line, since the locution

  if Last < Line'Last then

conveys all the information I need wrt whether the entire line has been
consumed.  What is End_Of_Line buying me that the idiom above does not?

-Matt

Re: Computer Language Shootout

[Matthew Heaney]

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0307151920.7f9fc721@posting.google.com...
> Aldo Calpini will only publish programs on his Win32 Language Shootout
> if they are sent to him by the author, giving consent for their use.

Thanks, I'll take a look at his FAQ.

My immediate interest was in posting examples of hash tables in general, and
using the Charles library in particular.  I noticed that in shootout matrix,
the programs that required a hash table weren't completed.  But there is no
reason for this -- I was able to write all three examples in just a few
minutes.


> Note: I don't think anyone has attempted to do
> Echo Client/Server in Ada 95 (for MS Windows).

I make my living writing streaming media servers (I wrote the TrueCast
server at On2), so I don't think writing this example will be very difficult
for me.  I'll take a look when I have a chance.

-Matt

Re: Computer Language Shootout

[Preben Randhol]

Matthew Heaney wrote:
> 
> It's not necessary to pass the object Standard_Input explicitly to
> End_Of_Line and Get_Line, because those operations are overloaded to
> read from standard input by default.

End_Of_File you mean, yes I agree.

> You can also generate better code by declaring the Sum as Integer'Base
> instead of Integer; this turns off constraint checks.

I see.

> You could also have used Integer_Text_IO.Get to read the value from
> the string buffer, instead of using Integer'Value.  This would allow
> you to read multiple values from a single line (assuming that was
> required in this program).

Ah yes of course.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Isaac Gouy]

> I noticed that in shootout matrix, the programs that required 
> a hash table weren't completed.  But there is no reason for this 

"Tests Not Implemented For This Language" may be misleading.

I believe it's just the inverse of the implementations that have been
added to the shootout. I don't believe it's a statement that no
implementations have been received for those tests. I could be wrong
;-)

Re: Computer Language Shootout

[Robert I. Eachus]

Matthew Heaney wrote:

> Do you really mean that End_Of_File and Get_Line use Current_Output?  I
> thought they used Current_Input.

Oops! That's what I get for posting after midnight.

> Aside: I don't ever use End_Of_Line, since the locution
> 
>   if Last < Line'Last then
> 
> conveys all the information I need wrt whether the entire line has been
> consumed.  What is End_Of_Line buying me that the idiom above does not?

Has the actual end of line been consumed?  If the line is the same 
length as your buffer, the Get_Line can read exactly Last characters but 
still be positioned at the end of line.  In one case, you will be left 
at the end of line, and in the other you won't.  The orginal code you 
posted for word count has disappeared from the Newsgroup server I use, 
so I am commenting in general.  Sometimes you need to check that you 
have consumed all the characters, sometimes you need to check that you 
are at end of line, and in some cases both checks are needed.  In this 
case I think you can read and count a bogus line if the input line is 
exactly 133 characters long.  The first read will get all 133 
characters, the second will get no characters and the new line.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Computer Language Shootout

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F15930C.2070907@attbi.com>...
> 
> Has the actual end of line been consumed?  If the line is the same 
> length as your buffer, the Get_Line can read exactly Last characters but 
> still be positioned at the end of line.  

Yes.  That's AI-50 behavior.

> In one case, you will be left 
> at the end of line, and in the other you won't.  The orginal code you 
> posted for word count has disappeared from the Newsgroup server I use, 
> so I am commenting in general.  Sometimes you need to check that you 
> have consumed all the characters, sometimes you need to check that you 
> are at end of line, and in some cases both checks are needed.  In this 
> case I think you can read and count a bogus line if the input line is 
> exactly 133 characters long.  The first read will get all 133 
> characters, the second will get no characters and the new line.

The code I posted will work even in this case, because it doesn't
adjust the line count unless it has read the newline (which is
indicated by Last < Line'Last).

Re: Computer Language Shootout

[Preben Randhol]

Robert I. Eachus wrote:
> Matthew Heaney wrote:
> 
>> Do you really mean that End_Of_File and Get_Line use Current_Output?  I
>> thought they used Current_Input.
> 
> Oops! That's what I get for posting after midnight.
> 
>> Aside: I don't ever use End_Of_Line, since the locution
>> 
>>   if Last < Line'Last then
>> 
>> conveys all the information I need wrt whether the entire line has been
>> consumed.  What is End_Of_Line buying me that the idiom above does not?
> 
> Has the actual end of line been consumed?  If the line is the same 
> length as your buffer, the Get_Line can read exactly Last characters but 
> still be positioned at the end of line.  In one case, you will be left 
> at the end of line, and in the other you won't. 

I sometimes use this procedure:

   procedure Get_Whole_Line
      (File : in     File_Type;
       Item :    out String;
       Last :    out Natural)
   is
   begin
      Get_Line (File => File, Item => Item, Last => Last);
      if Last = Item'Last then
         --  The line was longer than allowed, skipping the rest.
         --  Can also raise an exception if necessary.
         Skip_Line (File => File);
      else
         --  Just to remove the extras although it is not really
         --  necessary, can be skipped.
         Fixed.Delete (Source => Item, From => Last + 1, Through => Item'Last);
      end if;

   end Get_Whole_Line;

if I only want to read characters until Item'Last from a file and
consider the rest the line as junk.

> case I think you can read and count a bogus line if the input line is 
> exactly 133 characters long.  The first read will get all 133 
> characters, the second will get no characters and the new line.

But the first is not counted only the second as Last < Item'Last, so I
think it should be correct.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Wesley Groleau]

Preben Randhol wrote:
> I sometimes use this procedure:
> 
>    procedure Get_Whole_Line
>       (File : in     File_Type;
>        Item :    out String;
>        Last :    out Natural)
>    is

I often use a function, which reads
from the file into a temporary,
and then returns Temp (1 .. Last)

The difficulty is knowing how big to make
the temporary.

The benefit is that the function can be used
in a declaration, relieving the client from
dealing with that difficulty.

Re: Computer Language Shootout

[Jean-Pierre Rosen]

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


"Wesley Groleau" <wesgroleau@despammed.com> a �crit dans le message news:
evacnf433pJrU4uiXTWJgA@gbronline.com...
> Preben Randhol wrote:
> > I sometimes use this procedure:
> >
> >    procedure Get_Whole_Line
> >       (File : in     File_Type;
> >        Item :    out String;
> >        Last :    out Natural)
> >    is
>
> I often use a function, which reads
> from the file into a temporary,
> and then returns Temp (1 .. Last)
>
> The difficulty is knowing how big to make
> the temporary.
>
This one reads a line with no length limit:

function Get_Line return String is
   Buffer : String (1..500); -- or whatever
   Last : Natural;
begin
   Get_Line (Buffer, Last);
   if Last < Buffer'Last then
      return Buffer (1..Last);
   else
      return Buffer & Get_Line;
   end if;
end Get_Line;

In most cases, there will be only one call, while having no upper limit.
The size of the buffer is just a matter of optimization.

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

Re: Computer Language Shootout

[Preben Randhol]

Wesley Groleau wrote:
> I often use a function, which reads
> from the file into a temporary,
> and then returns Temp (1 .. Last)
> 
> The difficulty is knowing how big to make
> the temporary.
> 
> The benefit is that the function can be used
> in a declaration, relieving the client from
> dealing with that difficulty.

I agree, but as I use this for reading files I usually have a predefined
string that I read each line into, then parse it and then read next
line, so I really don't need a function to do it :-)

However functions are nice for this you described and other
circumstances.


-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Preben Randhol]

Jean-Pierre Rosen wrote:
> This one reads a line with no length limit:
> 
> function Get_Line return String is
>    Buffer : String (1..500); -- or whatever
>    Last : Natural;
> begin
>    Get_Line (Buffer, Last);
>    if Last < Buffer'Last then
>       return Buffer (1..Last);
>    else
>       return Buffer & Get_Line;
>    end if;
> end Get_Line;
> 
> In most cases, there will be only one call, while having no upper limit.

Hmm, clever!

> The size of the buffer is just a matter of optimization.

Yes. I guess it is not so smart to set it to say 1..5 as you would
call the function recursively a lot :-)

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Robert A Duff]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> This one reads a line with no length limit:
> 
> function Get_Line return String is
>    Buffer : String (1..500); -- or whatever
>    Last : Natural;
> begin
>    Get_Line (Buffer, Last);
>    if Last < Buffer'Last then
>       return Buffer (1..Last);
>    else
>       return Buffer & Get_Line;
>    end if;
> end Get_Line;
> 
> In most cases, there will be only one call, while having no upper limit.
> The size of the buffer is just a matter of optimization.

This is a nice trick, but I suggest you grow the buffer exponentially,
in case lines are very long.  Like, double it on each recursion level.

Too bad this was not included in Text_IO itself.  It would save
beginners a lot of trouble.  Sigh.

- Bob

Re: Computer Language Shootout

[Wesley Groleau]

Jean-Pierre Rosen wrote:
> This one reads a line with no length limit:

Cool!  As a guy who likes recursion and
uses it a lot, I _should_ have thought of that.
But I didn't.  :-)

Re: Computer Language Shootout

[Wesley Groleau]

Preben Randhol wrote:
> I agree, but as I use this for reading files I usually have a predefined
> string that I read each line into, then parse it and then read next
> line, so I really don't need a function to do it :-)

I often use it for reading files, too.

Either I have a declare block for each line,
or I have a procedure called for each line
that uses the function to get the line.

It's nice to use attributes for length
and last, or to be able to pass

My_String

to other subs instead of

My_String (My_String'First .. Last)

Re: Computer Language Shootout

[Dmitry A. Kazakov]

On Thu, 17 Jul 2003 19:36:19 +0200, "Jean-Pierre Rosen"
<rosen@adalog.fr> wrote:

>
>"Wesley Groleau" <wesgroleau@despammed.com> a �crit dans le message news:
>evacnf433pJrU4uiXTWJgA@gbronline.com...
>> Preben Randhol wrote:
>> > I sometimes use this procedure:
>> >
>> >    procedure Get_Whole_Line
>> >       (File : in     File_Type;
>> >        Item :    out String;
>> >        Last :    out Natural)
>> >    is
>>
>> I often use a function, which reads
>> from the file into a temporary,
>> and then returns Temp (1 .. Last)
>>
>> The difficulty is knowing how big to make
>> the temporary.
>>
>This one reads a line with no length limit:
>
>function Get_Line return String is
>   Buffer : String (1..500); -- or whatever
>   Last : Natural;
>begin
>   Get_Line (Buffer, Last);
>   if Last < Buffer'Last then
>      return Buffer (1..Last);
>   else
>      return Buffer & Get_Line;
>   end if;
>end Get_Line;
>
>In most cases, there will be only one call, while having no upper limit.
>The size of the buffer is just a matter of optimization.

ARM states for Get_Line:

"... Reading stops if the end of the string is met. Reading also stops
if the end of the line is met before meeting the end of the string; in
this case Skip_Line is (in effect) called with a spacing of 1. The
values of characters not assigned are not specified."

What will happen if a line is exactly of 500 character length? From
the quote above I suppose that Get_Line will boldly go to the next
line. If so, then your program would merge all lines of 500 character
length into one adding the first shorter line, or raise an unexpected
End_Error if there is no one.

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

Re: Computer Language Shootout

[Thomas Wolf]

mailbox@dmitry-kazakov.de wrote:
> On Thu, 17 Jul 2003 19:36:19 +0200, "Jean-Pierre Rosen"
> <rosen@adalog.fr> wrote:
> 
> >This one reads a line with no length limit:
> >
> >function Get_Line return String is
> >   Buffer : String (1..500); -- or whatever
> >   Last : Natural;
> >begin
> >   Get_Line (Buffer, Last);
> >   if Last < Buffer'Last then
> >      return Buffer (1..Last);
> >   else
> >      return Buffer & Get_Line;
> >   end if;
> >end Get_Line;
> >
> >In most cases, there will be only one call, while having no upper limit.
> >The size of the buffer is just a matter of optimization.
> 
> ARM states for Get_Line:
> 
> "... Reading stops if the end of the string is met. Reading also stops
> if the end of the line is met before meeting the end of the string; in
> this case Skip_Line is (in effect) called with a spacing of 1. The
> values of characters not assigned are not specified."
> 
> What will happen if a line is exactly of 500 character length? From
> the quote above I suppose that Get_Line will boldly go to the next
> line. If so, then your program would merge all lines of 500 character
> length into one adding the first shorter line, or raise an unexpected

No. If the line has 499 characters, they'll be read, Last will be 499,
and Skip_Line (1) will be called, so that the *next* Get_Line will
read the next line.

If there are 501 characters on the line, the first 500 will be read,
Last will be 500, Skip_Line will not be called, and the next Get_Line
will read 1 character, Last will be 1, and Skip_Line (1) will be called.

If there are exactly 500 characters on the line, they'll be read, and
Last will be 500. Skip_Line *will not* be called, because Get_Line stops
due to having met the end of the string (it hasn't yet met the end of the
line). The *next* Get_Line will read zero characters, Last will be zero,
and Skip_Line (1) will be called.

-- 
-----------------------------------------------------------------
Thomas Wolf                          e-mail: t_wolf@angelfire.com

Re: Computer Language Shootout

[Jean-Pierre Rosen]

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


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> a �crit dans le message
news: > ARM states for Get_Line:
>
> "... Reading stops if the end of the string is met. Reading also stops
> if the end of the line is met before meeting the end of the string; in
> this case Skip_Line is (in effect) called with a spacing of 1. The
> values of characters not assigned are not specified."
>
> What will happen if a line is exactly of 500 character length? From
> the quote above I suppose that Get_Line will boldly go to the next
> line. If so, then your program would merge all lines of 500 character
> length into one adding the first shorter line, or raise an unexpected
> End_Error if there is no one.
>
No. In this case, the recursive call will return an empty string (Skip_Line
is not called),
which is harmless and returns the correct value. Note that the recursive
call will make
the Skip_Line!

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

Re: Computer Language Shootout

[Matthew Heaney]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<198fhv0avvpqc39dq7paiqpf3lntca8v4g@4ax.com>...
> On Thu, 17 Jul 2003 19:36:19 +0200, "Jean-Pierre Rosen"
> <rosen@adalog.fr> wrote:
> 
> What will happen if a line is exactly of 500 character length? From
> the quote above I suppose that Get_Line will boldly go to the next
> line. If so, then your program would merge all lines of 500 character
> length into one adding the first shorter line, or raise an unexpected
> End_Error if there is no one.

No, Get_Line will read exactly 500 characters, and leave the line
terminator in the input stream.  The line terminator won't get
consumed until the next read.

This behavior is why the following idiom for consuming a line of text
works:

  Get_Line (Line, Last);
 
  if Last < Line'Last then
     --we consumed line terminator, too
  else
     --we have not consumed the line terminator yet
  end if;

In a sense, you can imagine the that bytes in the range Line (Last + 1
.. Line'Last) hold a virtual line terminator.

See my "get_line mystery" article for more info.

Re: Computer Language Shootout

[Robert Spooner]

Robert A Duff wrote:
> "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
> 
> 
>>This one reads a line with no length limit:
>>
>>function Get_Line return String is
>>   Buffer : String (1..500); -- or whatever
>>   Last : Natural;
>>begin
>>   Get_Line (Buffer, Last);
>>   if Last < Buffer'Last then
>>      return Buffer (1..Last);
>>   else
>>      return Buffer & Get_Line;
>>   end if;
>>end Get_Line;
>>
>>In most cases, there will be only one call, while having no upper limit.
>>The size of the buffer is just a matter of optimization.
> 
> 
> This is a nice trick, but I suggest you grow the buffer exponentially,
> in case lines are very long.  Like, double it on each recursion level.
> 
> Too bad this was not included in Text_IO itself.  It would save
> beginners a lot of trouble.  Sigh.
> 
> - Bob
I tried this using the following program and gnat version 3.13p on 
windows professional 2000 with the following result:

with Ada.Text_IO;

procedure No_String_Length_Limit_Test is

    package Tio renames Ada.Text_IO;


    function Get_Line (Buffer_Size : Positive := 1) return String is
       Buffer : String (1..Buffer_Size);
       Last   : Natural;
    begin
       Tio.Get_Line (Buffer, Last);
       if Last < Buffer'Last then
          return Buffer(1..Last);
       else
          return Buffer & Get_Line (2*Buffer_Size);
       end if;
    end Get_Line;


begin -- No_String_Length_Limit_Test

    loop
       Tio.Put ("Enter a message, <Return> to exit: ");
       declare
          The_Message : String := Get_Line;
       begin
          exit when The_Message'Length = 0;
          Tio.Put_Line ("The message is " & The_Message);
       end;
    end loop;

end No_String_Length_Limit_Test;

no_string_length_limit_test.adb:16:26: ambiguous operand for concatenation
no_string_length_limit_test.adb:16:26: possible interpretation at line 8
Done--error detected.

Can someone tell me why the operand is ambiguous?

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Computer Language Shootout

[David C. Hoos]

Interesting... It looks like a GNAT bug to me.  With 3.15p, the message
about line 8 occurs twice, apparently meaning that it couldn't decide on a
call to Get_Line with or without an actual parameter.

I say this, because without the default parameter declaration (i.e., always
requiring a parameter, there is no ambiguity;

Also, changing your conditional doce to the following also removes the
ambiguity, as far as GNAT is concerned:

       if Last < Buffer'Last then
          return Buffer(1..Last);
       else
          declare
             Temp : String := Get_Line (2*Buffer_Size);
          begin
             return Buffer & Temp;
          end;
       end if;

This should be reported to GNAT as a bug.

----- Original Message ----- 
From: "Robert Spooner" <rls19@psu.edu>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Friday, July 18, 2003 1:04 PM
Subject: Re: Computer Language Shootout


> Robert A Duff wrote:
> > "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
> >
> >
> >>This one reads a line with no length limit:
> >>
> >>function Get_Line return String is
> >>   Buffer : String (1..500); -- or whatever
> >>   Last : Natural;
> >>begin
> >>   Get_Line (Buffer, Last);
> >>   if Last < Buffer'Last then
> >>      return Buffer (1..Last);
> >>   else
> >>      return Buffer & Get_Line;
> >>   end if;
> >>end Get_Line;
> >>
> >>In most cases, there will be only one call, while having no upper limit.
> >>The size of the buffer is just a matter of optimization.
> >
> >
> > This is a nice trick, but I suggest you grow the buffer exponentially,
> > in case lines are very long.  Like, double it on each recursion level.
> >
> > Too bad this was not included in Text_IO itself.  It would save
> > beginners a lot of trouble.  Sigh.
> >
> > - Bob
> I tried this using the following program and gnat version 3.13p on
> windows professional 2000 with the following result:
>
> with Ada.Text_IO;
>
> procedure No_String_Length_Limit_Test is
>
>     package Tio renames Ada.Text_IO;
>
>
>     function Get_Line (Buffer_Size : Positive := 1) return String is
>        Buffer : String (1..Buffer_Size);
>        Last   : Natural;
>     begin
>        Tio.Get_Line (Buffer, Last);
>        if Last < Buffer'Last then
>           return Buffer(1..Last);
>        else
>           return Buffer & Get_Line (2*Buffer_Size);
>        end if;
>     end Get_Line;
>
>
> begin -- No_String_Length_Limit_Test
>
>     loop
>        Tio.Put ("Enter a message, <Return> to exit: ");
>        declare
>           The_Message : String := Get_Line;
>        begin
>           exit when The_Message'Length = 0;
>           Tio.Put_Line ("The message is " & The_Message);
>        end;
>     end loop;
>
> end No_String_Length_Limit_Test;
>
> no_string_length_limit_test.adb:16:26: ambiguous operand for concatenation
> no_string_length_limit_test.adb:16:26: possible interpretation at line 8
> Done--error detected.
>
> Can someone tell me why the operand is ambiguous?
>
> Bob
> -- 
>                              Robert L. Spooner
>                       Registered Professional Engineer
>                         Associate Research Engineer
>                    Intelligent Control Systems Department
>
>           Applied Research Laboratory        Phone: (814) 863-4120
>           The Pennsylvania State University  FAX:   (814) 863-7841
>           P. O. Box 30
>           State College, PA 16804-0030       rls19@psu.edu
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Computer Language Shootout

[Pascal Obry]

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

> "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
> 
> > This one reads a line with no length limit:
> > 
> > function Get_Line return String is
  [...]
>
> Too bad this was not included in Text_IO itself.  It would save
> beginners a lot of trouble.  Sigh.

But this approach can use a lot of stack space and become very slow.
Returning an unconstraint object on the stack has a cost.

Pascal.

-- 

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

Re: Computer Language Shootout

[Preben Randhol]

Robert Spooner wrote:
> I tried this using the following program and gnat version 3.13p on 
> windows professional 2000 with the following result:
> 
> with Ada.Text_IO;
> 
> procedure No_String_Length_Limit_Test is
> 
>     package Tio renames Ada.Text_IO;
> 
> 
>     function Get_Line (Buffer_Size : Positive := 1) return String is
>        Buffer : String (1..Buffer_Size);
>        Last   : Natural;
>     begin
>        Tio.Get_Line (Buffer, Last);
>        if Last < Buffer'Last then
>           return Buffer(1..Last);
>        else
>           return Buffer & Get_Line (2*Buffer_Size);

This removes the ambigutie:

            return Buffer & Get_Line (Buffer_Size => 2*Buffer_Size);

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Robert A Duff]

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

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
> > 
> > > This one reads a line with no length limit:
> > > 
> > > function Get_Line return String is
>   [...]
> >
> > Too bad this was not included in Text_IO itself.  It would save
> > beginners a lot of trouble.  Sigh.
> 
> But this approach can use a lot of stack space and become very slow.
> Returning an unconstraint object on the stack has a cost.

True, but I think the design goal of Text_IO ought to be correctness,
and convenience for the programmer, not efficiency.  I'm sick of
programs that have arbitrary line-length limits.  I'll happily pay a
little efficiency cost to correct that.  And in the cases where
efficiency matters, a different strategy can be used (namely, the
Get_Line that takes a fixed-length buffer, or a get-next-token kind of
approach, which doesn't care about line lengths).

- Bob

Re: Computer Language Shootout

[Pascal Obry]

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

> True, but I think the design goal of Text_IO ought to be correctness,
> and convenience for the programmer, not efficiency.  I'm sick of
> programs that have arbitrary line-length limits.  I'll happily pay a
> little efficiency cost to correct that.  And in the cases where
> efficiency matters, a different strategy can be used (namely, the
> Get_Line that takes a fixed-length buffer, or a get-next-token kind of
> approach, which doesn't care about line lengths).

Agreed, why not add this in Ada 2005 ? Is there an AI for that ?

Pascal.

-- 

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

Re: Computer Language Shootout

[Samuel Tardieu]

>>>>> "Bob" == Robert A Duff <Robert> writes:

Bob> True, but I think the design goal of Text_IO ought to be
Bob> correctness, and convenience for the programmer, not efficiency.
Bob> I'm sick of programs that have arbitrary line-length limits.
Bob> I'll happily pay a little efficiency cost to correct that.  And
Bob> in the cases where efficiency matters, a different strategy can
Bob> be used (namely, the Get_Line that takes a fixed-length buffer,
Bob> or a get-next-token kind of approach, which doesn't care about
Bob> line lengths).

Bob,

while I understand why and where such a function would be practical, I
am opposed to it being part of the standard.

The reason is that it would make it much too easy to crash any Ada
program by feeding it with a long string that would exhaust the stack
area (be it the primary stack or, as in GNAT, a secondary stack). In
programs with tasking, the stack for each task is usually very
limited.

You can always use Ada.Strings.Unbounded.Text_IO.Get_Line and convert
it to a string *after you check the length*. You will achieve the same
effect and will not have to rely on (expensive or unreliable) stack
checks.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Computer Language Shootout

[Robert I. Eachus]

Samuel Tardieu wrote:
>>>>>>"Bob" == Robert A Duff <Robert> writes:
>>>>>
> 
> Bob> True, but I think the design goal of Text_IO ought to be
> Bob> correctness, and convenience for the programmer, not efficiency.
> Bob> I'm sick of programs that have arbitrary line-length limits.
> Bob> I'll happily pay a little efficiency cost to correct that.  And
> Bob> in the cases where efficiency matters, a different strategy can
> Bob> be used (namely, the Get_Line that takes a fixed-length buffer,
> Bob> or a get-next-token kind of approach, which doesn't care about
> Bob> line lengths).

> You can always use Ada.Strings.Unbounded.Text_IO.Get_Line and convert
> it to a string *after you check the length*. You will achieve the same
> effect and will not have to rely on (expensive or unreliable) stack
> checks.

A properly declared Get_Line function would make a reasonable addition 
to Ada.Text_IO.  (And probably similar functions in the nested 
generics.)  But the RM certainly wouldn't mandate any particular 
implementation.  I also think there should be a Get_Line procedure with 
an Unbounded_String parameter, and the same for Put_Line.

-- 

                                                 Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Computer Language Shootout

[Samuel Tardieu]

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

Robert> A properly declared Get_Line function would make a reasonable
Robert> addition to Ada.Text_IO.  (And probably similar functions in
Robert> the nested generics.)  But the RM certainly wouldn't mandate
Robert> any particular implementation.

I don't think so. Also, you can bet that beginners will use such a
convenient function without understanding the implications for the
stack, and will soon be hit by a stack exhaustion.

The RM does acknowledge that stacks exist through task-specific
storage controlled by pragma Storage_Size applied to a task.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Computer Language Shootout

[Robert I. Eachus]

Samuel Tardieu wrote:

> I don't think so. Also, you can bet that beginners will use such a
> convenient function without understanding the implications for the
> stack, and will soon be hit by a stack exhaustion.

What implications for the stack?  If the next line is too large to fit 
on the stack, there is a problem.  If it isn't, then there won't be any 
stack space lost and unreclaimed.  I personally use exactly this idiom, 
in fact if you look you can find a recent case where I posted code that 
used it to read an entire file into one String.  (The stack space used 
is roughly bounded by 2*file size, and the documentation in the code 
mentions that this program is intended for small files.)

I also think you misunderstand my meaning about adding the function to 
Text_IO.  The only thing added by the An implementation would NOT use 
this implementation of the function.  If I were writing it, I would use 
a (OS specific) call to find out how many characters I would read, if 
available, and create exactly that much space on the stack.  If I 
couldn't determine the size, I would read into a relatively large 
scratchpad in the heap, and deal with overruns carefully.

In any case, I would check the remaining stack space and raise 
Storage_Error rather than overflow it.  (But that would be done, if 
necessary, as part of the normal function return code, since the value 
might not go to the stack.)  Dave Emery calls Storage_Error a parachute 
that opens on impact because it can't guarantee that you have enough 
stack space to run the handler.  However, if this function is in the RM, 
then it is much more likely that Storage_Error will be raised in a place 
where reasonable handlers have enough (stack) room to operate.

Remember that an implementation has lots of extra abilities like this, 
since they can generate "implementation dependent" code all over the 
place without concern.

> The RM does acknowledge that stacks exist through task-specific
> storage controlled by pragma Storage_Size applied to a task.

But the RM does NOT require that a function return a String (or any 
other array value) on the stack.  This is deliberate.  An implementation 
can return such values on the heap, and ensure that the storage is 
reclaimed by the caller.  In the "normal" idiom for a using a Get_Line 
function:

   begin -- may a subprogram begin or a block
     while not End_of_File loop
       declare
         Line: String := Get_Line;
       begin
         --process line
       end;
     end loop;
   exception
     -- Errors raised by Get_Line take you here...
   end;

even if the storage reclamation is deferred until the end of the declare 
block, no harm is done.  Where the exceptions are handled may come as a 
surprise to beginners, but it shouldn't.

But notice that an implementation can choose--for this particular code 
structure--to optimize things by merging the blocks into the stack frame 
of the surrounding subprogram.  If it does, it can either grow and 
shrink the stack frame with each iteration of the loop, or put the 
storage for Line on the heap, and reclaim it each time around the loop. 
  All of this comes under what should be called the "as if" clause in 
the RM 1.1.3(15)--the user visible effects are all the same.  (For 
reading a huge line, in one case the potential Storage_Error will come 
from stack overflow, and in the other from heap overflow, but that is 
well within the "as if" semantics rule.)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Computer Language Shootout

[Samuel Tardieu]

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

Robert> If I were writing it, I would use a (OS specific) call to find
Robert> out how many characters I would read, if available, and create
Robert> exactly that much space on the stack.  If I couldn't determine
Robert> the size, I would read into a relatively large scratchpad in
Robert> the heap, and deal with overruns carefully.

Such a function would be a nightmare to implement properly. Not only
would it be unusable in systems which do not allow dynamic allocation
(absence of heap for example), but also it would force the compiler to
keep track of how the object was created (object from the stack or
from the heap). Also, creating a "relatively large scratchpad" won't
cover all cases, you will have to realloc memory in some cases. Also,
you would waste precious heap memory in multitasking systems, maybe
causing other tasks to raise Storage_Error on memory allocation
attempts.

Being more on the embedded side, I dislike any dynamic memory
allocation which is not caused by an explicit "new".

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Computer Language Shootout

[Robert I. Eachus]

Samuel Tardieu wrote:

> Being more on the embedded side, I dislike any dynamic memory
> allocation which is not caused by an explicit "new".

You are allowed to have such likes and dislikes.  But I hope that when 
you have them in Ada programs you realize that there are standard 
packages that are not intended for use in such an environment.  The ARG 
is not going to require implementations to implement Text_IO in that 
way, if we did, it would just make us look silly.  Text_IO is a high 
level abstraction that is intended to hide file layouts, protocols and 
buffering from the user.  If you want your file buffers allocated by an 
explicit new, rather than an OS call, don't use Text_IO. 
Streams.Stream_IO or even Low_Level_IO are more appropriate in that 
situation.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Computer Language Shootout

[Jean-Pierre Rosen]

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


"Robert Spooner" <rls19@psu.edu> a �crit dans le message news:
bf9crp$18rg$1@f04n12.cac.psu.edu...
> I tried this using the following program and gnat version 3.13p on
> windows professional 2000 with the following result:
>
> with Ada.Text_IO;
>
> procedure No_String_Length_Limit_Test is
>
>     package Tio renames Ada.Text_IO;
>
>
>     function Get_Line (Buffer_Size : Positive := 1) return String is
>        Buffer : String (1..Buffer_Size);
>        Last   : Natural;
>     begin
>        Tio.Get_Line (Buffer, Last);
>        if Last < Buffer'Last then
>           return Buffer(1..Last);
>        else
>           return Buffer & Get_Line (2*Buffer_Size);
>        end if;
>     end Get_Line;
>
>
> begin -- No_String_Length_Limit_Test
>
>     loop
>        Tio.Put ("Enter a message, <Return> to exit: ");
>        declare
>           The_Message : String := Get_Line;
>        begin
>           exit when The_Message'Length = 0;
>           Tio.Put_Line ("The message is " & The_Message);
>        end;
>     end loop;
>
> end No_String_Length_Limit_Test;
>
> no_string_length_limit_test.adb:16:26: ambiguous operand for concatenation
> no_string_length_limit_test.adb:16:26: possible interpretation at line 8
> Done--error detected.
>
> Can someone tell me why the operand is ambiguous?
>
Because there are two possible meanings :-)
1) return the catenation of Buffer with the result of the call to Get_Line
with (2*Buffer_Size) as
   a parameter (what you intended).
2) return the catenation of Buffer with the single character obtained by
indexing the result of the
   call to Get_Line (with the default paramater) by the index value
(2*Buffer_Size).

No Gnat bug here!

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

Re: Computer Language Shootout

[Samuel Tardieu]

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

Robert> The ARG is not going to require implementations to implement
Robert> Text_IO in that way, if we did, it would just make us look
Robert> silly.  Text_IO is a high level abstraction that is intended
Robert> to hide file layouts, protocols and buffering from the user.

Of course. However, I am still waiting to see any implementation of
the proposed function which is neither dangerous (Denial of Service by
feeding a string which is too long) nor inefficient (relying on stack
checks is definitely inefficient), and works without heavy
modifications to compilers (I do not think it is worth adding extra
complexity - and bugs - to the compiler for a convenience function
that can be written easily by the user).

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Computer Language Shootout

[Dmitry A. Kazakov]

On 18 Jul 2003 23:22:10 +0200, Pascal Obry <p.obry@wanadoo.fr> wrote:

>
>Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
>> "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
>> 
>> > This one reads a line with no length limit:
>> > 
>> > function Get_Line return String is
>  [...]
>>
>> Too bad this was not included in Text_IO itself.  It would save
>> beginners a lot of trouble.  Sigh.
>
>But this approach can use a lot of stack space and become very slow.
>Returning an unconstraint object on the stack has a cost.

I don't think that the following, heap-based, version could be much
faster:

Increment : constant := 500;

type String_Ptr is access all String;
procedure Free is
   new Ada.Unchecked_Deallocation (String, String_Ptr);

procedure Read_Line
          (  Line   : in out String_Ptr;
             Length : out Natural
             )  is
   Size : Natural;
begin
   Get_Line (Line.all, Size);
   Length := Size;
   while Size = Line'Last loop
      declare
         Old_Line : String_Ptr := Line;
      begin
         Line := new String'(Old_Line.all & (1..Increment => ' '));
         Free (Old_Line);
      end;
      Get_Line (Line (Length + 1..Line'Last), Size);
      Length := Length + Size;
   end loop;   
end Read_Line;

used as:

   Line    : String_Ptr := new String'(1..Increment => ' ');
   Length  : Natural;
begin is
   Read_Line (Line, Length);
   ...
   Free (Line);
exception
   when others =>
      Free (Line);
      raise;
   
Though it should remove exponential growth [at cost of nasty
pointers].

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

Re: Computer Language Shootout

[Jeffrey Creem]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:vp9nhv8ju4t5kjrvdtd3sp3qgt59nu31tt@4ax.com...

stuff deleted

>    Get_Line (Line.all, Size);
>    Length := Size;
>    while Size = Line'Last loop
>       declare
>          Old_Line : String_Ptr := Line;
>       begin
>          Line := new String'(Old_Line.all & (1..Increment => ' '));
>          Free (Old_Line);
>       end;
>       Get_Line (Line (Length + 1..Line'Last), Size);
>       Length := Length + Size;
>    end loop;
> end Read_Line;
>
> used as:
>
>    Line    : String_Ptr := new String'(1..Increment => ' ');
>    Length  : Natural;
> begin is
>    Read_Line (Line, Length);



Note, this will probably be slower. I see this all the time in code and I
wish it would go away. There is no need
to pad the string with blank characters. Yes it makes looking at the string
in a debugger a little easier but if
this thing gets called in a loop it is going to be much slower than it
should due to all the temporary creation and copying.

If someone really felt they had to put characters in the unused portion of a
string, I would expect that using something like @
would be the better choice to help hunt down messed up string index
values.....But I would rather that the
unused portion of the string be left alone.

Re: Computer Language Shootout

[Dmitry A. Kazakov]

On Mon, 21 Jul 2003 11:00:38 GMT, "Jeffrey Creem" <jeff@thecreems.com>
wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:vp9nhv8ju4t5kjrvdtd3sp3qgt59nu31tt@4ax.com...
>
>stuff deleted
>
>>    Get_Line (Line.all, Size);
>>    Length := Size;
>>    while Size = Line'Last loop
>>       declare
>>          Old_Line : String_Ptr := Line;
>>       begin
>>          Line := new String'(Old_Line.all & (1..Increment => ' '));
>>          Free (Old_Line);
>>       end;
>>       Get_Line (Line (Length + 1..Line'Last), Size);
>>       Length := Length + Size;
>>    end loop;
>> end Read_Line;
>>
>> used as:
>>
>>    Line    : String_Ptr := new String'(1..Increment => ' ');
>>    Length  : Natural;
>> begin is
>>    Read_Line (Line, Length);
>
>Note, this will probably be slower. I see this all the time in code and I
>wish it would go away. There is no need
>to pad the string with blank characters. Yes it makes looking at the string
>in a debugger a little easier but if
>this thing gets called in a loop it is going to be much slower than it
>should due to all the temporary creation and copying.

Agree:

   Line := new String (1..Old_Line'Length + Increment);
   Line (1..Old_Line'Length) := Old_Line.all;

However, I would expect padding be implemented using sort of memset,
which should be "instant" as compared with "new".

Actually there could be another excuse: a corrupted "commit on access"
memory policy in some OS. Which reminds me speculating upon actions.
(:-))

>If someone really felt they had to put characters in the unused portion of a
>string, I would expect that using something like @
>would be the better choice to help hunt down messed up string index
>values.....But I would rather that the
>unused portion of the string be left alone.

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

Re: Computer Language Shootout

[Hyman Rosen]

Samuel Tardieu wrote:
> Of course. However, I am still waiting to see any implementation of
> the proposed function which is neither dangerous (Denial of Service by
> feeding a string which is too long) nor inefficient (relying on stack
> checks is definitely inefficient), and works without heavy
> modifications to compilers (I do not think it is worth adding extra
> complexity - and bugs - to the compiler for a convenience function
> that can be written easily by the user).

I don't think I understand your point. You are saying that such a
function is too dangerous and inefficient for compiler implementors
to write, but that such a function can be written easily by the user?

Re: Computer Language Shootout

[Samuel Tardieu]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

Sam> Of course. However, I am still waiting to see any implementation of
Sam> the proposed function which is neither dangerous (Denial of Service
Sam> by feeding a string which is too long) nor inefficient (relying on
Sam> stack checks is definitely inefficient), and works without heavy
Sam> modifications to compilers (I do not think it is worth adding extra
Sam> complexity - and bugs - to the compiler for a convenience function
Sam> that can be written easily by the user).

Hyman> I don't think I understand your point. You are saying that such
Hyman> a function is too dangerous and inefficient for compiler
Hyman> implementors to write, but that such a function can be written
Hyman> easily by the user?

Exactly: if the user is expecting data from the outside, he can write
such a loop and do explicit memory allocation from the heap if he
wants to. At least, it is explicit.

But I still think that in a vast majority of cases, it is a good thing
that users ask themselves "what is the biggest line length I will ever
get?" and write such a function only if they really need to.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Computer Language Shootout

[Hyman Rosen]

Samuel Tardieu wrote:
> But I still think that in a vast majority of cases, it is a good thing
> that users ask themselves "what is the biggest line length I will ever
> get?" and write such a function only if they really need to.

No, it is a terrible thing. To this day, I cannot open up a large
xterm on my Sun workstation and run "vi". It tells me "Screen too
large for internal buffer". UNIX utilities used to be full of such
line limits until the GNU folks came along and eliminated them from
their versions of the programs. Many of the old utilities would
silently truncate long lines, or consider them to be multiple lines,
or crash.

I have had the experience of needing to run text utilities on an
ordinary text file which happened to have lines which were several
hundred thousand characters long. No utility author would ever have
specified such a large limit.

Re: Computer Language Shootout

[tmoran]

>I have had the experience of needing to run text utilities on an
>ordinary text file which happened to have lines which were several
>hundred thousand characters long. No utility author would ever have
>specified such a large limit.
  I suppose some people have probably tried to use a pliers to tighten
the head bolts on their car's engine.  The relevant phrase is "Use
the right tool for the job".

Re: Computer Language Shootout

[Samuel Tardieu]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

Hyman> I have had the experience of needing to run text utilities on
Hyman> an ordinary text file which happened to have lines which were
Hyman> several hundred thousand characters long. No utility author
Hyman> would ever have specified such a large limit.

If the author had allocated his strings on the stack rather than doing
it explicitely himself (look at the code, I bet that it called
realloc() a lot of time while processing long lines), the program had
surely crashed.

I am not for arbitrary limits. I am for responsive (and
user-controlled) allocation of dynamic memory.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Computer Language Shootout

[Hyman Rosen]

tmoran@acm.org wrote:
>   I suppose some people have probably tried to use a pliers to tighten
> the head bolts on their car's engine.  The relevant phrase is "Use
> the right tool for the job".

Huh? It was a plain old text file, it just happened to have long
lines. What makes the standard text processing utilities be the
wrong tool? If you really care, it was a .newsrc file, and for
some neewsgroups the reading pattern had been such that the lines
were a very long sequence of comma-separated pairs of dash-separated
numbers.

How short does a line have to be for sed or awk to be the right tool?
Fortunately for me, I was using GNU versions, and they remained the
right tool.

Re: Computer Language Shootout

[Hyman Rosen]

Samuel Tardieu wrote:
> If the author had allocated his strings on the stack rather than doing
> it explicitely himself (look at the code, I bet that it called
> realloc() a lot of time while processing long lines), the program had
> surely crashed.

The ability of Ada to return variable-sized arrays on the stack is
a great feature of the language, and is often touted here in this
newsgroup. It would be a shame if this feature really had to be
avoided in any case where arbitrary user input must be processed.

Re: Computer Language Shootout

[Preben Randhol]

Hyman Rosen wrote:
> No, it is a terrible thing. To this day, I cannot open up a large
> xterm on my Sun workstation and run "vi". 

Install vim instead. http://vim.sf.net.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Hyman Rosen]

Preben Randhol wrote:
> Hyman Rosen wrote:
>>No, it is a terrible thing. To this day, I cannot open up a large
>>xterm on my Sun workstation and run "vi". 
> 
> Install vim instead. http://vim.sf.net.

My point exactly :-)

Re: Computer Language Shootout

[Preben Randhol]

Hyman Rosen wrote:
> Preben Randhol wrote:
>> Hyman Rosen wrote:
>>>No, it is a terrible thing. To this day, I cannot open up a large
>>>xterm on my Sun workstation and run "vi". 
>> 
>> Install vim instead. http://vim.sf.net.
> 
> My point exactly :-)

Not quite, because vim (Vi Improved) offers a great many improvements
over the old vi. I mean who worries about 640kb RAM which sombeody once
said should be enough for everybody ;-) It is in the past. One always
have to make some kind of restrictions which in the future may not work
anymore.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Vinzent Hoefler]

Preben Randhol wrote:

>I mean who worries about 640kb RAM which sombeody once
>said should be enough for everybody ;-)

He[0] was right. Anything that needs more than 64K is bloat. ;)


Vin"only 128K on 'my' embedded system"zent.

[0] Yes, I know *who* said that.

Re: Computer Language Shootout

[Preben Randhol]

Vinzent Hoefler wrote:
> He[0] was right. Anything that needs more than 64K is bloat. ;)

Oops, there went most of my Ada programs out the window ;-)

Preben
-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Computer Language Shootout

[Robert Spooner]

Jean-Pierre Rosen wrote:
> ...
> No Gnat bug here!
> 

Thanks. I can see that now. I'm sure glad the compiler didn't just 
choose what it thought I meant and just do that without telling me. 
Using named notation resolves the ambiguity. (dumb computer doesn't know 
what I mean :)

-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Computer Language Shootout

[Randy Brukardt]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbhsp7d.hr.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Vinzent Hoefler wrote:
> > He[0] was right. Anything that needs more than 64K is bloat. ;)
>
> Oops, there went most of my Ada programs out the window ;-)

Nah, just recompile them with Janus/Ada for MS-DOS. :-) [Minium program size
is about 5K.]

                   Randy.

Re: Computer Language Shootout

[Robert I. Eachus]

Robert Spooner wrote:
 > Thanks. I can see that now. I'm sure glad the compiler didn't just
> choose what it thought I meant and just do that without telling me. 
> Using named notation resolves the ambiguity. (dumb computer doesn't know 
> what I mean :)

Smart compiler, to know there were two possible interpretations.  It is 
the telepathic compiler you need if you want DWITIM (do what I think I 
mean) semantics. ;-)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.