Re: functions, packages & characters

Re: functions, packages & characters

[Christoph Grein]

From the code you provided we can see that you are completely unfamiliar with 
Ada, this will never compile.

This is not an accusation, we all have been beginners some time :-) but please 
take an intoductory book about Ada (see AdaPower) and work thru it. There are so 
many problems in the code it's really no use to correct them all. You really 
have to get a basic understanding of Ada first.

Begin with a hello world program:

with Ada.Text_IO;

procedure Hello is
  procedure Say_Hello is
  begin
    Ada.Text_IO.Put_Line ("Hello Greenhorn :-)");
  end Say_Hello;
begin
  Say_Hello;
end Hello;


> I have been looking at my program and wondered if this woul work
> 
> package obtain is
>   function Get_Line;   <--- return type missing
> end obtain;
> 
> with Text_io;
> use Text_io;
> package body obtain is
> begin                             <--- remove this line (wrong here)
> function Get_Line (Text :String)  <--- body does not match specification
>        return Unbounded_String;   <--- replace ; by is begin
>   Get_Line;                       <--- Parameters missing
                                    <--- return stement missing
> end;                              <--- another end statement missing

etc....

> 
> With Text_IO;
> use Text_IO;
> with obtain
> procedure main is
>   ---
>   ---pre: tags are in the text
>   ---post:tags have been correctly reformatted
>   ---
>   Text: File;
> 
> function Find_Dblslash (//)
>          return Single Slash(/)procedure main is
> begin 
> Put_Line ("Please enter text: ");
> use obtain;

Re: functions, packages & characters

[Unversed Angel]

>From the code you provided we can see that you are completely unfamiliar with
>
>Ada, this will never compile.
>
Yes i am new to Ada but the problem with
the other program was that i'd  been staring at the screen too long.
This program is more similar with what i need to do next but i have no idea if
its any good.
Any help would be appreciated.




with Text_io; use Text_io;
procedure main is 
---pre: text is in the mark up language
---post: text has been converted to english
---test: once thru
t:string

procedure Get_line is
---pre:text needs to be input
 Line_Buffer : String (1 .. 1000);
  Line_Length : Natural range 0 .. Line_Buffer'Last;
  Line_Store  : array (1 .. 10_000) of Unbounded_String;
  Line_Count  : Natural range 0 .. Line_Store'Last;
begin
  loop
    Get_Line (Line_Buffer, Line_Length);
    Line_Count := Line_Count + 1;
    Line_Store (Line_Count) :=
      To_Unbounded_String (Line_Buffer (1 .. Line_Length));
    new_line;
  end loop;
end;

Procedure doubleslash is 
---pre:mark up language has been input
---post:doubleslash has been converted to single slash
---test: /,//,///
begin
 Loop
  For i in t'range loop
    if t(i)=// then
      t:=/;
    end if;
 end loop;
end;

procedure /N is 
pre:             
 

Re: functions, packages & characters

[Hyman Rosen]

Unversed Angel wrote:
>  Line_Buffer : String (1 .. 1000);

It's the twenty-first century. Isn't it about time we
got rid of fixed-size input buffers? Thank goodness
for the GNU reimplementation of the UNIX utilities,
which have done away with maximum line sizes, but on
my Sun, I still can't vi in a 200 column xterm.

Unless you have very domain-specific information,
using a fixed-size input buffer is an invitation
to errors. You will never pick a large-enough size.
I once had to process a .newsrc file, which is plain
text, whose longest line was several hundred thousand
characters long. The most pernicious error in such a
case is for the program to silently truncate the line,
or to split it into multiple lines. Using unbounded
input buffers prevents this from happening.

Re: functions, packages & characters

[Randy Brukardt]

Hyman Rosen wrote in message <3C753C66.8020509@mail.com>...
>Unversed Angel wrote:
>>  Line_Buffer : String (1 .. 1000);
>
>It's the twenty-first century. Isn't it about time we
>got rid of fixed-size input buffers? Thank goodness
>for the GNU reimplementation of the UNIX utilities,
>which have done away with maximum line sizes, but on
>my Sun, I still can't vi in a 200 column xterm.


Nice try, but he's using Ada.Text_IO.Get_Line, which takes a fixed
length string. So he pretty much has to use a fixed size buffer.

Text_IO doesn't have direct support for unbounded strings (because
having it would drag the unbounded string library into almost every
program, whether you used it or not). Possibly, there ought to be a
Get_Line for Unbounded strings in a child package of Text_IO (but this
does not exist in Ada 95). This would be quite a bit slower than the
regular Get_Line for long lines, but it could be made acceptably fast
for the common case of short lines. It is possible to write such a
Get_Line out of the primitives in Text_IO, but the result would be
unacceptably slow (because you would have to read a character at a
time - you can't use Get_Line because you can't tell between the case of
a line which exactly fills the buffer and a line which is too long and
does not -- but in the former case, the line terminator is skipped).

                      Randy.

Re: functions, packages & characters

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u7b1g6cooeo49@corp.supernews.com...
> It is possible to write such a
> Get_Line out of the primitives in Text_IO, but the result would be
> unacceptably slow (because you would have to read a character at a
> time - you can't use Get_Line because you can't tell between the case of
> a line which exactly fills the buffer and a line which is too long and
> does not -- but in the former case, the line terminator is skipped).

This statement is incorrect.  You can test for this case via the predicate:

   if Last < Line'Last then
      --means we've consumed all the input

Which means you can make your input buffer as large as you like.

In general, you should use Get_Line this way:

declare
   Max : constant := 80;           --or whatever
   Line : String (1 .. Max + 1);  --note value of Line'Last
   Last : Natural;
begin
   loop
      Get_Line (Line, Last);
      --do something with Line (Line'First .. Last)
      exit when Last < Line'Last;
   end loop;
end;

You can search comp.lang.ada at google.com for several posts I've written on
this very subject (search for "get_line").


--STX
with Ada.Text_IO;            use Ada.Text_IO;
with Ada.Strings.Unbounded;  use Ada.Strings.Unbounded;

procedure Test_Get_Line is

   Max : constant := 10;
   Line : String (1 .. Max + 1);
   Last : Natural;

   Buffer : Unbounded_String;

begin

   Put ("ready: ");

   loop
      Get_Line (Line, Last);
      Append (Buffer, Line (Line'First .. Last));
      exit when Last < Line'Last;
   end loop;

   Put_Line ("line is '" & To_String (Buffer) & "'");


end Test_Get_Line;

Re: functions, packages & characters

[Matthew Heaney]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u7b4d1bmd1f7ef@corp.supernews.com...
>
> You can search comp.lang.ada at google.com for several posts I've written
on
> this very subject (search for "get_line").

Actually, I forget that David hosted this article at adapower a while ago:

http://www.adapower.com/lang/get_line.html

Re: functions, packages & characters

[Randy Brukardt]

Matthew Heaney wrote in message ...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
>news:u7b1g6cooeo49@corp.supernews.com...
>> It is possible to write such a
>> Get_Line out of the primitives in Text_IO, but the result would be
>> unacceptably slow (because you would have to read a character at a
>> time - you can't use Get_Line because you can't tell between the case
of
>> a line which exactly fills the buffer and a line which is too long
and
>> does not -- but in the former case, the line terminator is skipped).
>
>This statement is incorrect.

Not exactly. This was true in Ada 83, but it was fixed circa 1985 (and
added to the validation tests a couple of years later [AI83-00050]).
There are a bunch of comments in our Text_IO implementation about this
change.

Still, I must be going senile: all I can imagine is that I "learned"
about Get_Line when this was true (at least in the compiler I used), and
haven't forgotten the "rule" even though it hasn't been true in a long
time.

>You can search comp.lang.ada at google.com for several posts I've
written on
>this very subject (search for "get_line").


Not interested; I've been using Get_Line since before you were born. :-)
(OK, not really...)

>   loop
>      Get_Line (Line, Last);
>      Append (Buffer, Line (Line'First .. Last));
>      exit when Last < Line'Last;
>   end loop;

This is, of course, the inefficiency that I was commenting on. This
would be slow, and would cause an awful lot of memory allocation and
deallocation, with the possible exception of the first iteration. It
would only be a good idea if the size of Line was larger than almost all
expected lines.

(Personally, I never use Unbounded strings, mainly because it took me
years to figure out how to use regular Ada strings effectively, and
Unbounded strings don't buy anything if you are used to doing that.)

                Randy Brukardt

Re: functions, packages & characters

[Marin David Condic]

I'm curious about why you think this would be slow? (I may have to build a
small chunk of code and time it! :-) In most applications I can think of,
you can usually set some kind of arbitrary max sized buffer (the size of
"Line" below...) that is going to accommodate most lines in your average
text file. (Usually, you have some notion of the kinds of text files you
want to process, right?) The presumption is that you might infrequently have
to go 'round the loop a second (or third or fourth) time to glom onto the
rest of the line, so for 99% (or some high percentage of the time) you're
just doing a single Get_Line (is that inefficient?) and a single Append to
an unbounded string (again, is that necessarily inefficient?)

I've never looked into the underlying implementation of Unbounded_String in
any Ada compiler, so I have no clue as to how naturally (in)efficient they
may be. I'm guessing a typical implementation is going to be some collection
of memory blocks strung together with pointers and some counters. Would
"Append" require some huge overhead?

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


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u7bcro6je1h519@corp.supernews.com...
> >   loop
> >      Get_Line (Line, Last);
> >      Append (Buffer, Line (Line'First .. Last));
> >      exit when Last < Line'Last;
> >   end loop;
>
> This is, of course, the inefficiency that I was commenting on. This
> would be slow, and would cause an awful lot of memory allocation and
> deallocation, with the possible exception of the first iteration. It
> would only be a good idea if the size of Line was larger than almost all
> expected lines.
>

Re: functions, packages & characters

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a55iip$4s7$1@nh.pace.co.uk...
> I've never looked into the underlying implementation of Unbounded_String
in
> any Ada compiler, so I have no clue as to how naturally (in)efficient they
> may be. I'm guessing a typical implementation is going to be some
collection
> of memory blocks strung together with pointers and some counters. Would
> "Append" require some huge overhead?

Often you (re)allocate the internal buffer in powers of 2, so it would
require only a few iterations to acquire an adequately-sized buffer.

Re: functions, packages & characters

[Marin David Condic]

Hmmmmmm... Hadn't thought of that. I could see how that might perform well
for some expected usages, but might get nasty if you're doing lots of
reallocating. I was thinking along the lines of making a linked list of some
standard block size (like 64 bytes - 4 for a link & the rest data) which
might make it quick for appending but would no doubt suffer when you try to
do other things...

There are no perfect answers, are there? :-)

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


"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u7klg886r837b7@corp.supernews.com...
>
> Often you (re)allocate the internal buffer in powers of 2, so it would
> require only a few iterations to acquire an adequately-sized buffer.
>
>
>

Re: functions, packages & characters

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a5dmb1$nb5$1@nh.pace.co.uk...
> Hmmmmmm... Hadn't thought of that. I could see how that might perform well
> for some expected usages, but might get nasty if you're doing lots of
> reallocating.

Well, hopefully it will reduce the need for reallocation.  The STL vector
and string classes are nice because they allow you to actually reserve a
specific amount of internal memory.  In the Charles library, I added a
Set_Length operation to do the same thing.

http://home.earthlink.net/~matthewjheaney/charles/charles-unbounded_arrays__
ads.htm
http://home.earthlink.net/~matthewjheaney/charles/
http://home.earthlink.net/~matthewjheaney/charles-20020213.zip


> I was thinking along the lines of making a linked list of some
> standard block size (like 64 bytes - 4 for a link & the rest data) which
> might make it quick for appending but would no doubt suffer when you try
to
> do other things...

That's more or less how a deque works.

Re: functions, packages & characters

[Randy Brukardt]

Marin David Condic wrote in message ...
>I'm curious about why you think this would be slow? (I may have to
build a
>small chunk of code and time it! :-) In most applications I can think
of,
>you can usually set some kind of arbitrary max sized buffer (the size
of
>"Line" below...) that is going to accommodate most lines in your
average
>text file. (Usually, you have some notion of the kinds of text files
you
>want to process, right?) The presumption is that you might infrequently
have
>to go 'round the loop a second (or third or fourth) time to glom onto
the
>rest of the line, so for 99% (or some high percentage of the time)
you're
>just doing a single Get_Line (is that inefficient?) and a single Append
to
>an unbounded string (again, is that necessarily inefficient?)

I thought I said that if you make the buffer large enough, it wouldn't
be so slow -- but it also would require a large buffer for many
applications (if it didn't, there would be little reason to use
unbounded strings in the first place).

>I've never looked into the underlying implementation of
Unbounded_String in
>any Ada compiler, so I have no clue as to how naturally (in)efficient
they
>may be. I'm guessing a typical implementation is going to be some
collection
>of memory blocks strung together with pointers and some counters. Would
>"Append" require some huge overhead?


I can only comment on the Janus/Ada one (which may not be
representative). It just allocates a string of the correct length for
every operation. That is the easiest implementation (and the one that
GNAT 3.14 uses), but it uses the heap a lot. Improving the performance
of this library has not been a priority, as there isn't any point in
trying to "optimize" it unless you have some real applications using it
that are too slow. Otherwise, you run the risk of making the "average"
application slower.

In any case, Ada.Strings.Unbounded is inappropriate for long-running
applications (such as the AdaIC web server), because continued use of
the heap will eventually lead to fragmentation and memory exhaustion
(and decreasing performance in a virtual memory environment).

                Randy.

Re: functions, packages & characters

[Marin David Condic]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u7l4ih2guo0gf6@corp.supernews.com...
>
> I thought I said that if you make the buffer large enough, it wouldn't
> be so slow -- but it also would require a large buffer for many
> applications (if it didn't, there would be little reason to use
> unbounded strings in the first place).
>
O.K. I must have misunderstood. Clearly if you pick a buffer size that
accommodates *most* of the lines you're likely to read, you'd have no real
problem dealing with some small percentage of the cases where you'd have
something reallocating more and more memory.


>
>
> I can only comment on the Janus/Ada one (which may not be
> representative). It just allocates a string of the correct length for
> every operation. That is the easiest implementation (and the one that
> GNAT 3.14 uses), but it uses the heap a lot. Improving the performance
> of this library has not been a priority, as there isn't any point in
> trying to "optimize" it unless you have some real applications using it
> that are too slow. Otherwise, you run the risk of making the "average"
> application slower.
>
Interesting. So in the cases where you'd be doing insertions, deletions and
so forth, you'd be forcing a reallocation for every operation? Obviously,
that could get expensive if you're doing a lot of string manipulation. I
could imagine it being a bit more efficient if it allocated memory in blocks
to enable some expansion & contraction without having to go back for more
every time.


> In any case, Ada.Strings.Unbounded is inappropriate for long-running
> applications (such as the AdaIC web server), because continued use of
> the heap will eventually lead to fragmentation and memory exhaustion
> (and decreasing performance in a virtual memory environment).
>
If the strings you're dealing with require a lot of manipulation this would
be the case. I've had apps that deal with a relatively static body of text -
you may not know its initial size, but once loaded it might remain stable.
Its always important to look at how it gets used and understand what the
penalties are for using a given feature.

I've used Unbounded_String a lot and never found it to behave poorly in the
kinds of apps I've done that way. Of course, most of these didn't really
stress test it - they've been pretty straightforward text manipulation
things where the ease of use for Unbounded_String outweighed whatever
inefficiencies may have been there.

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

Re: functions, packages & characters

[David Starner]

On Mon, 25 Feb 2002 13:37:51 -0600, Randy Brukardt <randy@rrsoftware.com> wrote:
> I thought I said that if you make the buffer large enough, it wouldn't
> be so slow -- but it also would require a large buffer for many
> applications (if it didn't, there would be little reason to use
> unbounded strings in the first place).

Why? I can think of many cases where the normal case may be 40-50
characters, but for robustness, you need the possibility of handling
lines 1500 characters long. Nobody's really concerned about the speed of
the long case, so long as the the normal case is handled correctly, but
the long case should be handled for robustness and generality.

-- 
David Starner - starner@okstate.edu
What we've got is a blue-light special on truth. It's the hottest thing 
with the youth. -- Information Society, "Peace and Love, Inc."

Re: functions, packages & characters

[Hyman Rosen]

David Starner wrote:
> Why? I can think of many cases where the normal case may be 40-50
> characters, but for robustness, you need the possibility of handling
> lines 1500 characters long.

No, no, a thousand times no! If what you are writing is at all
general purpose, with the inputs not strictly under your control,
do the world a favor and don't limit input buffer size to any
fixed value. If nothing else, fixing the buffer size means that
you must introduce logic to handle the case where the input is
longer. Then you have to document the limit, and document what
happens in the exceptional case. It's all extra work to make the
code *less* useful, so why do it that way?

Re: functions, packages & characters

[David Starner]

On Tue, 26 Feb 2002 10:44:18 -0500, Hyman Rosen <hyrosen@mail.com> wrote:
> David Starner wrote:
>> Why? I can think of many cases where the normal case may be 40-50
>> characters, but for robustness, you need the possibility of handling
>> lines 1500 characters long.
> 
> No, no, a thousand times no! 

1500 was meant as an arbitrarily large value.

-- 
David Starner - starner@okstate.edu
What we've got is a blue-light special on truth. It's the hottest thing 
with the youth. -- Information Society, "Peace and Love, Inc."

Re: functions, packages & characters

[Hyman Rosen]

David Starner wrote:
> 1500 was meant as an arbitrarily large value.

No arbitrary value is large enough. You *must* provide
for input buffer size limited only by memory constraints,
or you will cause some innocent user needless grief.

As I said before, my troublesome case was a .newsrc file,
plain text, where one line was several hundred thousand
characters long. Fortunately, I was using tools which
handled it with aplomb.

Re: functions, packages & characters

[Chad R. Meiners]

I believe this is what David is saying.  Normally when you write code to
accept arbitrarily large input, you write it so that it's only constraint is
memory.

-CRM

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C7C7E2D.6090602@mail.com...
> David Starner wrote:
> > 1500 was meant as an arbitrarily large value.
>
> No arbitrary value is large enough. You *must* provide
> for input buffer size limited only by memory constraints,
> or you will cause some innocent user needless grief.
>
> As I said before, my troublesome case was a .newsrc file,
> plain text, where one line was several hundred thousand
> characters long. Fortunately, I was using tools which
> handled it with aplomb.
>

Re: functions, packages & characters

[Hyman Rosen]

Chad R. Meiners wrote:
> I believe this is what David is saying.  Normally when you write code to
> accept arbitrarily large input, you write it so that it's only constraint is
> memory.

He said "1500 was meant as an arbitrarily large value". But there
is no such thing as an arbitrarily large value. To deal with large
input lines, you need to use some other technique, such as the
recursive Get_Line.

Re: functions, packages & characters

[Chad R. Meiners]

Do you have any formal training in mathematics?  Please do not take offense
to this question, but you seem to misunderstand what is meant by the phase
"for arbitrarily large values of x".

-CRM

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C7E7A76.6030402@mail.com...
> Chad R. Meiners wrote:
> > I believe this is what David is saying.  Normally when you write code to
> > accept arbitrarily large input, you write it so that it's only
constraint is
> > memory.
>
> He said "1500 was meant as an arbitrarily large value". But there
> is no such thing as an arbitrarily large value. To deal with large
> input lines, you need to use some other technique, such as the
> recursive Get_Line.
>

Re: functions, packages & characters

[Hyman Rosen]

Chad R. Meiners wrote:
> Do you have any formal training in mathematics?  Please do not take offense
> to this question, but you seem to misunderstand what is meant by the phase
> "for arbitrarily large values of x".

Oh, I see I misunderstood what David Starner was saying - my bad.
He didn't mean "use 1500 when typical size is 40 or 50", he meant
"be prepared for arbitrarily large input, with 1500 as a sample".

I have a degree in engineering, and the math to go with it. I do
know what "for arbitrarily large values of x" means, but I seem
to have trouble parsing English.

Hey, maybe it's time to start the thread on the difference between
arbitrary and random! :-)

Re: functions, packages & characters

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C81DDFA.8090306@mail.com...
> Hey, maybe it's time to start the thread on the difference between
> arbitrary and random! :-)
>

:-)  Perhaps, but then you have to mark it off topic. ;-)

Re: functions, packages & characters

[David Starner]

On Wed, 27 Feb 2002 22:55:40 -0500, Chad R. Meiners <crmeiners@hotmail.com> wrote:
> I believe this is what David is saying.  Normally when you write code to
> accept arbitrarily large input, you write it so that it's only constraint is
> memory.

Exactly. 

-- 
David Starner - starner@okstate.edu
What we've got is a blue-light special on truth. It's the hottest thing 
with the youth. -- Information Society, "Peace and Love, Inc."

Re: functions, packages & characters

[Marin David Condic]

I think the situation would be to use something like a 1500 character buffer
& go 'round the block to reallocate the Unbounded_String if and only if the
line length exceeded the 1500 characters. That way, the only time you'd
force any reallocations upon appending to the Unbounded_String would be the
case where the line length is greater than the 1500 characters of the
buffer. It would perform fast for most of the cases and probably wouldn't
perform too bad for the few cases where the line exceeded the buffer.

If you're going to Text_IO, you really need to have some kind of fixed
length string into which you read. Hence the need for *some* buffer limit -
but not necessarly a limit on the line length of the what the program can
accept.

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


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C7C7E2D.6090602@mail.com...
> David Starner wrote:
> > 1500 was meant as an arbitrarily large value.
>
> No arbitrary value is large enough. You *must* provide
> for input buffer size limited only by memory constraints,
> or you will cause some innocent user needless grief.
>
> As I said before, my troublesome case was a .newsrc file,
> plain text, where one line was several hundred thousand
> characters long. Fortunately, I was using tools which
> handled it with aplomb.
>

Re: functions, packages & characters

[tmoran]

> continued use of the heap will eventually lead to fragmentation and
> memory exhaustion
  Only if you use an inappropriate variety of memory management.

Re: functions, packages & characters

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u7bcro6je1h519@corp.supernews.com...
>
> >   loop
> >      Get_Line (Line, Last);
> >      Append (Buffer, Line (Line'First .. Last));
> >      exit when Last < Line'Last;
> >   end loop;
>
> This is, of course, the inefficiency that I was commenting on.

No, the inefficiency you were commenting on was the size of the string
buffer Line, which you said had to be one.  That is wrong -- as in my
example, it can be of arbitrary size.

> This would be slow, and would cause an awful lot of memory allocation and
> deallocation, with the possible exception of the first iteration.

Well, the inefficiency of appending to an Unbounded_String is a separate
issue.  We were talking about the inefficiency of Get_Line.  If you don't
like Unbounded_String, then use another data structure.

> It would only be a good idea if the size of Line was larger than almost
all
> expected lines.

Fine, then declare a large size for Line.  I typically use 81 or 133, when
reading text from standard input.

> (Personally, I never use Unbounded strings, mainly because it took me
> years to figure out how to use regular Ada strings effectively, and
> Unbounded strings don't buy anything if you are used to doing that.)

If Unbounded_String offends you, then use a recursive implementation to
return an unconstrained String.  Or use another data structure.

The point is that of course you can distinguish when you've consumed the
entire input line.  My example illustrates the standard idiom, per AI-50.

Re: functions, packages & characters

[Jeffrey Carter]

Randy Brukardt wrote:
> 
> you can't use Get_Line because you can't tell between the case of
> a line which exactly fills the buffer and a line which is too long and
> does not -- but in the former case, the line terminator is skipped).

This is a curious statement to be coming from the Keeper of Ada-Auth and
developer of Janus Ada. Get_Line does not skit the line terminator if
the string is completely filled. A.10.7 says Get_Line

Reads successive characters from the specified input file and assigns
them to successive characters of the specified string. 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.

Any implementation that skips the line terminator when the string is
completely filled is clearly incorrect. WWJD? (What Would Janus Do?)

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: functions, packages & characters

[Marin David Condic]

Wait a minute...... I seem to recall a nifty example of how you could return
an arbitrary length string from a function that used Get/Get_Line (?) and
recursed in the event that the line was longer than the buffer. It might be
in a code example somewhere like on AdaPower? If you can do that, why not a
similar subprogram for Unbounded_String? It would be even easier and not
require recursion since you could just keep reading some arbitrary sized
buffer in a loop and appending it to an Unbounded_String that is returned to
the caller.

Speed may be an issue, but with a reasonably large buffer, I don't think it
would be unacceptably slow. Why would you have to read it one character at a
time? (I will admit that I have not tried anything like this, so there may
be some tiny devil in the details that I'm missing...)

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


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u7b1g6cooeo49@corp.supernews.com...
>
> Text_IO doesn't have direct support for unbounded strings (because
> having it would drag the unbounded string library into almost every
> program, whether you used it or not). Possibly, there ought to be a
> Get_Line for Unbounded strings in a child package of Text_IO (but this
> does not exist in Ada 95). This would be quite a bit slower than the
> regular Get_Line for long lines, but it could be made acceptably fast
> for the common case of short lines. It is possible to write such a
> Get_Line out of the primitives in Text_IO, but the result would be
> unacceptably slow (because you would have to read a character at a
> time - you can't use Get_Line because you can't tell between the case of
> a line which exactly fills the buffer and a line which is too long and
> does not -- but in the former case, the line terminator is skipped).
>

Re: functions, packages & characters

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a55hpd$4cp$1@nh.pace.co.uk...
> Wait a minute...... I seem to recall a nifty example of how you could
return
> an arbitrary length string from a function that used Get/Get_Line (?) and
> recursed in the event that the line was longer than the buffer. It might
be
> in a code example somewhere like on AdaPower?

declare
   function Get_Line return String is
      Line : String (1 .. 80 + 1);
      Last : Natural;
   begin
      Text_IO.Get_Line (Line, Last);
      if Last < Line'Last then
        return Line (Line'First .. Last);
      else
         return Line & Get_Line;
      end if;
   end Get_Line;

   Line : constant String := Get_Line;
begin
   Put_Line (Line);
end;


> If you can do that, why not a
> similar subprogram for Unbounded_String? It would be even easier and not
> require recursion since you could just keep reading some arbitrary sized
> buffer in a loop and appending it to an Unbounded_String that is returned
to
> the caller.

I showed this in my last post.


> Speed may be an issue, but with a reasonably large buffer, I don't think
it
> would be unacceptably slow. Why would you have to read it one character at
a
> time?

No, you don't have to read one character at a time, as is shown above.

Re: functions, packages & characters

[Jeffrey Carter]

Marin David Condic wrote:
> 
> Wait a minute...... I seem to recall a nifty example of how you could return
> an arbitrary length string from a function that used Get/Get_Line (?) and
> recursed in the event that the line was longer than the buffer. It might be
> in a code example somewhere like on AdaPower? If you can do that, why not a
> similar subprogram for Unbounded_String? It would be even easier and not
> require recursion since you could just keep reading some arbitrary sized
> buffer in a loop and appending it to an Unbounded_String that is returned to
> the caller.

Such as function PragmARC.Get_Line? It uses a String of only 100
characters, yet still avoids recursion in most applications. A procedure
that built a result in a mode in out [Un]Bounded_String parameter is
perfectly doable would not need to be recursive. But the point of a
Get_Line function, which dates from the days of Ada 83 (see
"Variable-Length String Input in Ada" by J. Carter in ADA LETTERS, 1989
May/Jun), is that you rarely need a variable string abstraction in Ada
if you really understand how to use one-dimensional arrays in Ada.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: functions, packages & characters

[Hyman Rosen]

Randy Brukardt wrote:
> Nice try, but he's using Ada.Text_IO.Get_Line, which takes a fixed
> length string. So he pretty much has to use a fixed size buffer.

I was commenting on code in general, not his specifically.
But in any case, what kind of an attitude is this? "We're
going to do it wrong because the language primitives make
it easier to do it that way."?

Re: functions, packages & characters

[unversedangel]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C753C66.8020509@mail.com>...
> Unversed Angel wrote:
> >  Line_Buffer : String (1 .. 1000);
> Unless you have very domain-specific information,
> using a fixed-size input buffer is an invitation
> to errors. You will never pick a large-enough size.

I had already realised that unbounded_strings were the best way to go
but i have no idea what to do next as this program will not compile.


with Text_io; use Text_io;
procedure main is 
---pre: text is in the mark up language
---post: text has been converted to english
---test: once thru

procedure Get_line is
---pre:text needs to be input
---post:text has been input
---test: once thru
 Line_Buffer : String(Unbounded_String);
  Line_Length : Natural range 0 .. Line_Buffer'Last;
  Line_Store  : array (1 .. 10_000) of Unbounded_String;
  Line_Count  : Natural range 0 .. Line_Store'Last;
begin
  loop
    Get_Line (Line_Buffer, Line_Length);
    Line_Count := Line_Count + 1;
    Line_Store (Line_Count) :=
      To_Unbounded_String (Line_Buffer (1 .. Line_Length));
    new_line;
  end loop;
end;
   
Procedure doubleslash is 
---pre:mark up language has been input
---post:doubleslash has been converted to single slash
---test: /,//,///
begin
 Loop
  For i in s'range loop
    if s(i)="//" then
      s:='/';
    end if;
 end loop;
end;

procedure unformatted is 
---pre: mark up language has been input
---post:/N tag has left the text formatted as it was
---test: /N, /N/N,/N/U 
 Loop 
  For i in s'range loop
    if s(i)=/N then 
       do nothing 
      elseif exit
      end if;         
    end if;      
  end_loop;
End;  

Begin --of main
     s:string;
Put("Please enter text: ");
Get_Line(s);
doubleslash;
unformatted;
end;

Re: functions, packages & characters

[unversedangel]

unversedangel@aol.com (Unversed Angel) wrote in message news:<20020221130715.12738.00000034@mb-bg.aol.com>...
 i thought of an unbounded string but the program will not go through
the compiler, no matter which one i use or how i change the program.


with Text_io; use Text_io;
procedure main is 
---pre: text is in the mark up language
---post: text has been converted to english
---test: once thru

procedure Get_line is
---pre:text needs to be input
---post:text has been input
---test: once thru
 Line_Buffer : String(Unbounded_String);
  Line_Length : Natural range 0 .. Line_Buffer'Last;
  Line_Store  : array (1 .. 10_000) of Unbounded_String;
  Line_Count  : Natural range 0 .. Line_Store'Last;
begin
  loop
    Get_Line (Line_Buffer, Line_Length);
    Line_Count := Line_Count + 1;
    Line_Store (Line_Count) :=
      To_Unbounded_String (Line_Buffer (1 .. Line_Length));
    new_line;
  end loop;
end;
   
Procedure doubleslash is 
---pre:mark up language has been input
---post:doubleslash has been converted to single slash
---test: /,//,///
begin
 Loop
  For i in s'range loop
    if s(i)="//" then
      s:='/';
    end if;
 end loop;
end;

procedure unformatted is 
---pre: mark up language has been input
---post:/N tag has left the text formatted as it was
---test: /N, /N/N,/N/U 
 Loop 
  For i in s'range loop
    if s(i)=/N then 
       do nothing 
      elseif exit
      end if;         
    end if;      
  end_loop;
End;  

Begin --of main
     s:string;
Put("Please enter text: ");
Get_Line(s);
doubleslash;
unformatted;
end;
-------------------Target: Win32 (Intel) Debug--------------------
main.adb: Error: line 11 col 23 LRM:4.1(3), Direct name,
Unbounded_String, is not visible, Ignoring future references

main.adb: Error: line 11 col 40 LRM:3.3.1(5), an object declaration
with an indefinite subtype must have an initialization expression,
continuing

main.adb: Error: line 20 col 7 LRM:4.1(3), Direct name,
To_Unbounded_String, is not visible, Ignoring future references

main.adb: Error: line 31 col 12 LRM:4.1(3), Direct name, s, is not
visible, Ignoring future references

main.adb: Error: line 36 col 1 Parse error: expected END_LOOP, got
END, Skipping up to semicolon

main.adb: Error: line 38 col 1 LRM:5.1(2), Parse error expecting
statement got PROCEDURE, skipping to after next semicolon

main.adb: Error: line 48 col 5 Parse error: expected END, got END_IF,
Inserting END

main.adb: Error: line 48 col 5 Parse error: expected SEMICOLON, got
END_IF, Inserting SEMICOLON

main.adb: Error: line 48 col 5 LRM:3.1(3), Parse error expecting
declaration got END_IF, Skipping to after next semicolon

main.adb: Error: line 49 col 11 Parse error: expected COLON, got
SEMICOLON, Inserting COLON

main.adb: Error: line 49 col 11 LRM:4.1(2), Syntax error: the token
SEMICOLON can not be used as a name, skipping to next separator

main.adb: Error: line 50 col 1 Parse error: expected BEGIN, got END,
Inserting BEGIN

main.adb: Error: line 50 col 1 LRM:5.1(2), Unexpected ending token END
where statement is required, continuing

main.adb: Error: line 52 col 1 LRM:10.1.1(5), BEGIN is unexpected
here, Continuing

main.adb: Error: line 53 col 6 LRM:10.1.1(5), Identifier is unexpected
here, Continuing

main.adb: Error: line 53 col 7 LRM:10.1.1(5), COLON is unexpected
here, Continuing

main.adb: Error: line 53 col 8 LRM:10.1.1(5), Identifier is unexpected
here, Continuing

main.adb: Error: line 53 col 14 LRM:10.1.1(5), SEMICOLON is unexpected
here, Continuing

main.adb: Error: line 54 col 1 LRM:10.1.1(5), Identifier is unexpected
here, Continuing

main.adb: Error: line 54 col 4 LRM:10.1.1(5), LEFT PARENTHESIS is
unexpected here, Continuing

main.adb: Error: line 54 col 5 LRM:10.1.1(5), Character String is
unexpected here, Continuing

main.adb: Error: line 54 col 26 LRM:10.1.1(5), RIGHT PARENTHESIS is
unexpected here, Continuing

main.adb: Error: line 54 col 27 LRM:10.1.1(5), SEMICOLON is unexpected
here, Continuing

main.adb: Error: line 55 col 1 LRM:10.1.1(5), Identifier is unexpected
here, Continuing

main.adb: Error: line 55 col 9 LRM:10.1.1(5), LEFT PARENTHESIS is
unexpected here, Continuing

main.adb: Error: line 55 col 10 LRM:10.1.1(5), Identifier is
unexpected here, Continuing

main.adb: Error: line 55 col 11 LRM:10.1.1(5), RIGHT PARENTHESIS is
unexpected here, Continuing

main.adb: Error: line 55 col 12 LRM:10.1.1(5), SEMICOLON is unexpected
here, Continuing

main.adb: Error: line 56 col 1 LRM:10.1.1(5), Identifier is unexpected
here, Continuing

main.adb: Error: line 56 col 12 LRM:10.1.1(5), SEMICOLON is unexpected
here, Continuing

main.adb: Error: line 57 col 1 LRM:10.1.1(5), Identifier is unexpected
here, Continuing

main.adb: Error: line 57 col 12 LRM:10.1.1(5), SEMICOLON is unexpected
here, Continuing

main.adb: Error: line 58 col 1 LRM:10.1.1(5), END is unexpected here,
Continuing

main.adb: Error: line 58 col 4 LRM:10.1.1(5), SEMICOLON is unexpected
here, Continuing

Front end of ..\..\..\..\my documents\cs131\main.adb failed with 34
errors. (0 Warnings)
Tool execution failed.

Re: functions, packages & characters

[Hyman Rosen]

unversedangel@aol.com wrote:
> unversedangel@aol.com (Unversed Angel) wrote in message
 > news:<20020221130715.12738.00000034@mb-bg.aol.com>...
>  i thought of an unbounded string but the program will not go through
> the compiler, no matter which one i use or how i change the program.

You clearly have no clue as to what you are doing.
Did you perhaps not bother to attend or pay attention
to your classes? Did you not bother to read or
understand your textbook? No one here is going to do
your homework for you. I suspect most readers of this
newsgroup hope you will fail, so that they will never
have to encounter you at work!

Computer programs are not clay, to be pushed and prodded
until they fit through an opening. They are built with
intention and design, by people who understand what they
are doing and the tools they are using.

Re: functions, packages & characters

[Marin David Condic]

You seem to be missing some fundamental concepts of Ada - and possibly
programming in general. Type checking is your problem here and that is
something lots of languages do - not just Ada. One type is not
interchangeable with another - that's the whole reason for their existence.
A String is not identical to a Character so you have assignments and
comparisons that are incorrect.

You really should spend some time looking at one of the Ada books or
tutorials that have been recommended. Barring that, you ought to be making
better use of your compiler. It undoubtedly is outputting error messages
that will help you figure out what is going on. If you can't figure out what
the error messages are telling you, you could post the relavent code
snippets here & possibly get a more detailed explanation.

You don't say what compiler you are using, but if you are using Gnat, try
the following command line options:

gnatmake -gnatvl <your_program_name_here>

That will give you verbose error messages and a program listing that may be
helpful when posting questions.

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


<unversedangel@aol.com> wrote in message
news:dcb99faa.0202211448.537be1d4@posting.google.com...
> unversedangel@aol.com (Unversed Angel) wrote in message
news:<20020221130715.12738.00000034@mb-bg.aol.com>...
>  i thought of an unbounded string but the program will not go through
> the compiler, no matter which one i use or how i change the program.
>
>
> with Text_io; use Text_io;
> procedure main is
> ---pre: text is in the mark up language
> ---post: text has been converted to english
> ---test: once thru
>
> procedure Get_line is
> ---pre:text needs to be input
> ---post:text has been input
> ---test: once thru
>  Line_Buffer : String(Unbounded_String);
>   Line_Length : Natural range 0 .. Line_Buffer'Last;
>   Line_Store  : array (1 .. 10_000) of Unbounded_String;
>   Line_Count  : Natural range 0 .. Line_Store'Last;
> begin
>   loop
>     Get_Line (Line_Buffer, Line_Length);
>     Line_Count := Line_Count + 1;
>     Line_Store (Line_Count) :=
>       To_Unbounded_String (Line_Buffer (1 .. Line_Length));
>     new_line;
>   end loop;
> end;
>
> Procedure doubleslash is
> ---pre:mark up language has been input
> ---post:doubleslash has been converted to single slash
> ---test: /,//,///
> begin
>  Loop
>   For i in s'range loop
>     if s(i)="//" then
>       s:='/';
>     end if;
>  end loop;
> end;
>
> procedure unformatted is
> ---pre: mark up language has been input
> ---post:/N tag has left the text formatted as it was
> ---test: /N, /N/N,/N/U
>  Loop
>   For i in s'range loop
>     if s(i)=/N then
>        do nothing
>       elseif exit
>       end if;
>     end if;
>   end_loop;
> End;
>
> Begin --of main
>      s:string;
> Put("Please enter text: ");
> Get_Line(s);
> doubleslash;
> unformatted;
> end;
> -------------------Target: Win32 (Intel) Debug--------------------
> main.adb: Error: line 11 col 23 LRM:4.1(3), Direct name,
> Unbounded_String, is not visible, Ignoring future references
>
> main.adb: Error: line 11 col 40 LRM:3.3.1(5), an object declaration
> with an indefinite subtype must have an initialization expression,
> continuing
>
> main.adb: Error: line 20 col 7 LRM:4.1(3), Direct name,
> To_Unbounded_String, is not visible, Ignoring future references
>
> main.adb: Error: line 31 col 12 LRM:4.1(3), Direct name, s, is not
> visible, Ignoring future references
>
> main.adb: Error: line 36 col 1 Parse error: expected END_LOOP, got
> END, Skipping up to semicolon
>
> main.adb: Error: line 38 col 1 LRM:5.1(2), Parse error expecting
> statement got PROCEDURE, skipping to after next semicolon
>
> main.adb: Error: line 48 col 5 Parse error: expected END, got END_IF,
> Inserting END
>
> main.adb: Error: line 48 col 5 Parse error: expected SEMICOLON, got
> END_IF, Inserting SEMICOLON
>
> main.adb: Error: line 48 col 5 LRM:3.1(3), Parse error expecting
> declaration got END_IF, Skipping to after next semicolon
>
> main.adb: Error: line 49 col 11 Parse error: expected COLON, got
> SEMICOLON, Inserting COLON
>
> main.adb: Error: line 49 col 11 LRM:4.1(2), Syntax error: the token
> SEMICOLON can not be used as a name, skipping to next separator
>
> main.adb: Error: line 50 col 1 Parse error: expected BEGIN, got END,
> Inserting BEGIN
>
> main.adb: Error: line 50 col 1 LRM:5.1(2), Unexpected ending token END
> where statement is required, continuing
>
> main.adb: Error: line 52 col 1 LRM:10.1.1(5), BEGIN is unexpected
> here, Continuing
>
> main.adb: Error: line 53 col 6 LRM:10.1.1(5), Identifier is unexpected
> here, Continuing
>
> main.adb: Error: line 53 col 7 LRM:10.1.1(5), COLON is unexpected
> here, Continuing
>
> main.adb: Error: line 53 col 8 LRM:10.1.1(5), Identifier is unexpected
> here, Continuing
>
> main.adb: Error: line 53 col 14 LRM:10.1.1(5), SEMICOLON is unexpected
> here, Continuing
>
> main.adb: Error: line 54 col 1 LRM:10.1.1(5), Identifier is unexpected
> here, Continuing
>
> main.adb: Error: line 54 col 4 LRM:10.1.1(5), LEFT PARENTHESIS is
> unexpected here, Continuing
>
> main.adb: Error: line 54 col 5 LRM:10.1.1(5), Character String is
> unexpected here, Continuing
>
> main.adb: Error: line 54 col 26 LRM:10.1.1(5), RIGHT PARENTHESIS is
> unexpected here, Continuing
>
> main.adb: Error: line 54 col 27 LRM:10.1.1(5), SEMICOLON is unexpected
> here, Continuing
>
> main.adb: Error: line 55 col 1 LRM:10.1.1(5), Identifier is unexpected
> here, Continuing
>
> main.adb: Error: line 55 col 9 LRM:10.1.1(5), LEFT PARENTHESIS is
> unexpected here, Continuing
>
> main.adb: Error: line 55 col 10 LRM:10.1.1(5), Identifier is
> unexpected here, Continuing
>
> main.adb: Error: line 55 col 11 LRM:10.1.1(5), RIGHT PARENTHESIS is
> unexpected here, Continuing
>
> main.adb: Error: line 55 col 12 LRM:10.1.1(5), SEMICOLON is unexpected
> here, Continuing
>
> main.adb: Error: line 56 col 1 LRM:10.1.1(5), Identifier is unexpected
> here, Continuing
>
> main.adb: Error: line 56 col 12 LRM:10.1.1(5), SEMICOLON is unexpected
> here, Continuing
>
> main.adb: Error: line 57 col 1 LRM:10.1.1(5), Identifier is unexpected
> here, Continuing
>
> main.adb: Error: line 57 col 12 LRM:10.1.1(5), SEMICOLON is unexpected
> here, Continuing
>
> main.adb: Error: line 58 col 1 LRM:10.1.1(5), END is unexpected here,
> Continuing
>
> main.adb: Error: line 58 col 4 LRM:10.1.1(5), SEMICOLON is unexpected
> here, Continuing
>
> Front end of ..\..\..\..\my documents\cs131\main.adb failed with 34
> errors. (0 Warnings)
> Tool execution failed.

functions, packages & characters

[Unversed Angel]

Hi, i am new to programming and am learning Ada.
I have been staring at the screen all day and don't know what to do.
I want to know if you can put a couple of functions through a procedure because
my compiler keeps stopping me, should i be using packages and how would i do
that?
Also i need to replace a // with one / in my program and can't find anything
similar in any books.
Any help would be useful.

Re: functions, packages & characters

[tmoran]

> I want to know if you can put a couple of functions through a procedure
  What do you mean by "put a function through a procedure"?

> my compiler keeps stopping me,
  The compiler is not trying to be difficult, it just doesn't understand
either.

> Also i need to replace a // with one / in my program
  Surely your editor/word processor has a "replace" capability.

Re: functions, packages & characters

[Unversed Angel]

I want to know if i can include several functions in one main program.
I don't know how to find/use the "replace" capability and so far i have this
but since i've been at the screen all day i don't know if it's gibberish or
not.
with Text_IO;
use Text_IO;
procedure Simple1 is
  ---
  ---pre: tags are in the text
  ---post:tags have been correctly reformatted
  ---
  Text: File;
begin
  Put_Line ("Please enter text: ");
      function Get_Line (Text :String)
        return Unbounded_String;
      begin
      Get_Line;  
      end;
       function Find_Dblslash (//)
         return Single Slash(/);
       begin  
       if any c=// then use function Find_dblslash;
       end if;
       end;
end;

Re: functions, packages & characters

[tmoran]

> I want to know if i can include several functions in one main program.
  Yes, you can declare functions in the declarative part of another
function (or procedure or block).  So you could modify your program
to declare your function Get_Line just after "Text: File;" for instance.
Of course you would have to give an executable body for the function too,
or perhaps in this case you just want it to rename the standard
To_Unbounded_String function.  Similarly you could declare a
function Find_Dblslash, including coding what it does.  Take a look at
your Ada texts/tutorials to see examples.

Re: functions, packages & characters

[Unversed Angel]

I have been looking at my program and wondered if this woul work

package obtain is
function Get_Line;
end obtain;

with Text_io;
use Text_io;
package body obtain is
begin
function Get_Line (Text :String)
       return Unbounded_String;
  Get_Line;  
end;

With Text_IO;
use Text_IO;
with obtain
procedure main is
  ---
  ---pre: tags are in the text
  ---post:tags have been correctly reformatted
  ---
  Text: File;

function Find_Dblslash (//)
         return Single Slash(/)procedure main is
begin 
Put_Line ("Please enter text: ");
use obtain;

Re: functions, packages & characters

[Marin David Condic]

It appears that you really need to get a bit more formal training regarding
the structure of Ada programs. A good place to start would be to go to:
http://www.adapower.com/ and look under "Books" and "Learn Ada" (The latter
will point you at on line tutorials and books so you don't even have to
spend money or wait for something to come in from the bookstore.) Try
working through one of these books and their examples, because it will clear
up the fundamental misunderstandings you have about how to structure the
code. From there we can be a *lot* more helpful with specific questions
about individual features of the language.

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


"Unversed Angel" <unversedangel@aol.com> wrote in message
news:20020221032525.25608.00002542@mb-mc.aol.com...
> I have been looking at my program and wondered if this woul work
>
> package obtain is
> function Get_Line;
> end obtain;
>
> with Text_io;
> use Text_io;
> package body obtain is
> begin
> function Get_Line (Text :String)
>        return Unbounded_String;
>   Get_Line;
> end;
>
> With Text_IO;
> use Text_IO;
> with obtain
> procedure main is
>   ---
>   ---pre: tags are in the text
>   ---post:tags have been correctly reformatted
>   ---
>   Text: File;
>
> function Find_Dblslash (//)
>          return Single Slash(/)procedure main is
> begin
> Put_Line ("Please enter text: ");
> use obtain;
>

Re: functions, packages & characters

[tmoran]

> package obtain is
> function Get_Line;
> end obtain;
>
> with Text_io;
> use Text_io;
> package body obtain is
> begin  <- oops

  You are making progress toward a syntactically legal Ada program.
But you don't write a novel by starting with a bunch of sentence
fragments and trying to rearrange them until a Publisher says "Yes!".
First you learn how to compose legal, meaningful, sentences.  Then you
decide on a structure and plot for your novel, and finally you write
sentences to show the reader the story.  It appears you really need an
Ada textbook, either paper or online.  Or at the very least, study some
existing Ada programs and copy and modify to get one to do what you
want.  Look at www.adapower.com for references to books, tutorials, and
sample source code.