need help learning Ada for a modula-2 programmer

need help learning Ada for a modula-2 programmer

[agent]

The following code does not compile.  I don't understand why.

The string processing fails to compile, saying "prefix of image must
be a type"

and 

"move is undefined"

I don't yet understand string processing with Ada

--rob

with Ada.Calendar; use Ada.Calendar;
Package timliba is

--  REVISION HISTORY
--  ----------------
--   6 Oct 13 -- Converted to gm2.  And changed its name.
--  19 Jan 14 -- Converted to Ada.

  SubType String10Type is String(1..10);
  TYPE DAYNAMESType is ARRAY (1..7) OF String10Type;
  TYPE MONTHNAMESType is ARRAY (1..12) OF String10Type;
  Type DateTimeType is RECORD
    SystemTime: Time;
    month,day,year,hours,minutes,seconds : Natural;
    ElapsedSec : Duration;
  END Record;

  DateTime: DateTimeType;

  DAYNAMES : Constant DayNamesType  := ("Sunday    ","Monday
","Tuesday   ","Wednesday ", "Thursday  ","Friday    ","Saturday  ");
  MONTHNAMES : Constant MonthNamesType := ("January   ","February
","March     ","April     ","May       ",
      "June      ","July      ","August    ","September ","October
","November  ","December  ");

PROCEDURE TIME2MDY(M,D,Y : Out Natural);
-- System Time To Month, Day, and Year Conversion.

Procedure GetDateTime(DateTime: Out DateTimeType);
-- DateTimeType is my record time type containing everything.

Function JULIAN(M,D,Y : Natural) return Natural;

PROCEDURE GREGORIAN(Juldate : Natural; M,D,Y : OUT Natural);

END timliba;



-- with environa; use environa;
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
with Ada.Characters; use Ada.Characters;
with Ada.Characters.Conversions;  use Ada.Characters.Conversions;
with Ada.Characters.Handling; use Ada.Characters.Handling;
with Ada.Characters.Latin_1; use Ada.Characters.Latin_1;
with Ada.Calendar; use Ada.Calendar;

Package body timliba is

--  REVISION HISTORY
--  ----------------
--  14 Apr 92 -- Created JULIAN and GREGORIAN procs, which are
accurate beyond 3/1/2100.
--  25 Jul 93 -- Changed GREG2JUL and JUL2GREG limits to those imposed
by the
--                algorithm, ie, only years <2100 are now allowed.
--  25 Jul 94 -- Changed limits of allowed years to 1700 from 1900.
--  10 Nov 02 -- Converted to SBM2 Win v4.
--  17 May 03 -- First Win32 version.
--  26 May 03 -- Adjusted algorithm for Julian fcn so year has a
pivot.
--   6 Oct 13 -- Converted to gm2.
--  19 Jan 14 -- Converted to Ada.

  SubType String255 is String(1..255);
  K,IDX,PTR,c,RETCOD                           : Natural;
  CH                                           : CHARacter;
  FLAG,FLAG2,FLAG3,FLAG4,FLAG5,EOFFLG          : BOOLEAN;
--  PROMPT,NAMDFT,TYPDFT,INFNAM,OUTFNAM,
--  TMPBUF,NUMBUF,DRVPATH,INBUF,TOKEN            : BUFTYP;
--  TKNSTATE                                     : FSATYP;
  I,J                                          : INTEGER;

  TYPE ADIPMType is ARRAY (0..11) OF INTEGER;

--  This is a typed constant that represents the difference btwn the
last day
--  of the previous month and 30, assuming each month was 30 days
long.
--  The variable name is an acronym of Accumulated Days In Previous
Months.

  ADIPM : CONSTant ADIPMType :=  (0,1,-1,0,0,1,1,2,3,3,4,4);
  FUDGEFACTOR : CONSTant LONG_FLOAT := 5.0;
-- These are declared in the spec file
--  Type DateTimeType is RECORD
--    SystemTime: Time;
--    month,day,year,hours,minutes,seconds : Natural;
--    ElapsedSec : Duration;
--  END Record;


PROCEDURE TIME2MDY(M,D,Y : Out Natural) is
-- *********************************** TIME2MDY
*************************
-- System Time To Month, Day, and Year Conversion.

  Systime : Time;

BEGIN
  Systime := Clock;
  M := Month(Systime);
  D := Day(Systime);
  Y := Year(Systime);
END TIME2MDY;

Procedure GetDateTime(DateTime : Out DateTimeType) is
   CardSec : Natural;

BEGIN
  DateTime.SystemTime := Clock;

Split(DateTime.SystemTime,DateTime.year,DateTime.month,DateTime.day,DateTime.ElapsedSec);
  CardSec := Natural(DateTime.ElapsedSec+0.5);
  DateTime.hours := CardSec / 3600;
  CardSec := CardSec - DateTime.hours * 3600;
  DateTime.minutes := CardSec / 60;
  DateTime.seconds := CardSec MOD 60;
END GetDateTime;


PROCEDURE MDY2STR(M,D,Y : Natural; MDYSTR : Out String255) is
-- ***************************** MDY2STR
*********************************
-- Month Day Year Cardinals To String.

  DateSepChar : constant character :=  '/';
  MSTR,DSTR,YSTR : String(1..2);
  IntermedStr    : String(1..10);
  m0,d0,y0       : Natural;

BEGIN
  m0 := M;
  d0 := D;
  y0 := Y;
  IntermedStr := m0'Image & DateSepChar & d0'Image & DateSepChar &
y0'Image;
--  DSTR := D'Image;
--  YSTR := Y'Image;
--  MDYSTR := To255(IntermedStr);
    Move(IntermedStr,MDYstr);
END MDY2STR;



Function JULIAN(M,D,Y : Natural) return Natural is

  M0,D0,Y0   : Natural;
  Juldate    : Natural;

BEGIN
  IF Y < 30 THEN
    Y0 := Y + 2000 - 1;
  ELSIF Y < 100 THEN
    Y0 := Y + 1900 - 1;
  ELSE
    Y0 := Y - 1;
  END IF;
  IF (M < 1) OR (M > 12) OR (D < 1) OR (D > 31) OR (Y < 1700) OR (Y >
2500) THEN
-- Month, Day or Year is out of range
    Juldate := 0;
    RETURN(Juldate);
  END IF;

  M0 := M - 1;

  Juldate :=  Y0 * 365     -- Number of days in previous normal years
            + Y0 / 4   -- Number of possible leap days
            - Y0 / 100 -- Subtract all century years
            + Y0 / 400 -- Add back the true leap century years
            + ADIPM(M0) + M0 * 30 + D;

  IF ((( Y MOD 4 = 0) AND ( Y MOD 100 /= 0)) OR ( Y MOD 400 = 0)) AND
--   123            3     3               32    2              21
                                                                 (M >
2) THEN
    Juldate := Juldate + 1;
  END IF;
  RETURN Juldate;
END JULIAN;

PROCEDURE GREGORIAN(Juldate : Natural; M,D,Y : OUT Natural) is

  Y0,M0,D0,L,JD : Natural;

BEGIN
  Y0 := Juldate / 365;
  M0 := 1;
  D0 := 1;

  WHILE JULIAN(M0,D0,Y0) > Juldate LOOP Y0 := Y0 - 1; END Loop;

  M0 := 12;
  WHILE JULIAN(M0,D0,Y0) > Juldate Loop M0 := M0 - 1; END Loop;

  WHILE JULIAN(M0,D0,Y0) < Juldate Loop D0 := D0 + 1; END Loop;

  M := M0;
  D := D0;
  Y := Y0;
END GREGORIAN;

END timliba;

Re: need help learning Ada for a modula-2 programmer

[adambeneschan]

On Monday, January 27, 2014 5:06:43 PM UTC-8, ag...@drrob1.com wrote:
> The following code does not compile.  I don't understand why.
> 
> The string processing fails to compile, saying "prefix of image must
> be a type"
> 
> and 
> 
> "move is undefined"

The syntax of 'Image in Ada is Type'Image(Value), not Value'Image.  Since M0 is a Natural, instead of M0'Image you would say Natural'Image(M0).  (Some compilers accept M0'Img, but that is not part of the Ada standard.  Compilers are allowed to define their own attributes such as 'Img.)

There's no built-in Move procedure.  Also, you need to be aware that the "String" type is a fixed-length array of characters; it isn't suitable for variable-length strings unless you keep track of the length yourself.  If this is what you want, you should use the type Unbounded_String in the package Ada.Strings.Unbounded.  The way you've written it:

PROCEDURE MDY2STR(M,D,Y : Natural; MDYSTR : Out String255) is 

  IntermedStr    : String(1..10); 

  Move(IntermedStr,MDYSTR);

The way you'd copy a string, or part of it, is just to assign it with :=.  However, this won't work:

  MDYSTR := IntermedStr;

because the two Strings are different lengths.  To assign the first 10 characters of MDYSTR, you need to do something like

  MDYSTR(MDYSTR'First .. MDYSTR'First + IntermedStr'Length - 1) := IntermedStr;

where MDYSTR'First is the first index (which is always 1, because of how you defined String255, but it's still best not to hardwire values when you can avoid it); IntermedStr'Length is always 10, so this will assign to characters 1..10 of MDYSTR.  However, the remaining characters of MDYSTR will be unchanged and may be garbage.  Working with strings of differing lengths like this can get difficult, which is why you may want to look into Unbounded_String which will take care of a lot of that for you.

                                  -- Adam

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 01/27/2014 06:06 PM, agent@drrob1.com wrote:
> The following code does not compile.  I don't understand why.
>
> The string processing fails to compile, saying "prefix of image must
> be a type"

That seems like a pretty straightforward error message.

 >    M0,D0,Y0       : Natural;
 >    ...
 >    Intermedstr := M0'Image & Datesepchar & D0'Image & Datesepchar &
 > Y0'Image;

M0 is not a type, but you are using it as the prefix of 'Image. Since the prefix 
of 'Image must be a type, as the error message told you, you need to use a type 
as the prefix of 'Image:

Integer'Image (M0)

Note that Intermedstr is 10 characters long, and the result of your expression 
(once you've corrected the use of 'Image) may not be 10 characters long. In that 
case, you will get Constraint_Error raised by the assignment.

> "move is undefined"

Again, quite straightforward.

You attempt to call Move, but you haven't defined such a procedure, nor have you 
withed anything that defines it.

You may be thinking of Ada.Strings.Fixed.Move, in which case you'd need to with 
Ada.Strings.Fixed.

> I don't yet understand string processing with Ada

String processing in Ada is quite simple. Type String is an unconstrained 
1-dimensional array type, and is no different from any other unconstrained 
1-dimensional array type. As long as you don't think that there's something 
special about String you shouldn't have any problem.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: need help learning Ada for a modula-2 programmer

[Brian Drummond]

On Mon, 27 Jan 2014 20:06:43 -0500, agent wrote:

> The following code does not compile.  I don't understand why.
> 
> The string processing fails to compile, saying "prefix of image must be
> a type"
> 
> and
> 
> "move is undefined"
> 
> I don't yet understand string processing with Ada

The specific errors have been addressed by others, but as a former M2 fan 
who has transitioned to Ada, I have a suggestion to help with this last 
point...

Ada allows variable sized arrays (including strings) to be allocated on 
the stack - PROVIDED the actual runtime size is known at the point of 
allocation. 

It also allows the size (or first and last indices) of an array to be 
queried at runtime.

It also allows new declaration regions within blocks of code (funnily 
enough, beginning with the word "declare"...)

Put together, these can greatly reduce the pain of processing with fixed 
length strings, so that actually using variable length strings is rarer 
than you might imagine at first sight.

So for example you can write MDY2STR as a function:

function MDY2STR(M,D,Y : Natural) return String is 

   DateSepChar : constant character :=  '/';
   IntermedStr : constant String := 
                   natural'image(M) & DateSepChar &
                   natural'image(D) & DateSepChar &
                   natural'image(Y);
   -- This works DESPITE the length of the string being unknown at
   -- compile time, because the values M,D,Y are known, so the length 
   -- can be computed, before each execution of the initialiser 
   -- on each call of MDY2STR. "constant" means it will never be changed
   -- and its scope (local to MDY2STR) guarantees it will be released on
   -- return
   BEGIN
      return IntermedStr;
   END MDY2STR;

And you can call it in a loop which uses a different length string each 
time:

   FixedStr : String255;
   Year, Month, Day : natural;
   ...
   Year  := yyy;
   Month := mmm;
   for Day in 1 .. Days_In(Month) loop
      declare
         varString : String := MDY2STR(M=>Month, D=>Day, Y=> Year);
         -- this string could be constant. As it isn't we may edit it
         -- as long as we don't change its length.
         -- Note named association to prevent D,M,Y/Y,M,D type mistakes!
         -- Declaring ranged subtypes for month, day would also help
      begin
         FixedStr := (others => " ");        -- empty fixed string
         FixedStr(varString'range) := varString;  -- assign to some of it
      end 
      -- now we have interfaced our variable length string to 
      -- an M2 type fixed string
   end loop;
   
Once you get used to some Ada patterns for string handling, "fixed" 
strings of runtime-determined length are flexible and easy to use.

- Brian

Re: need help learning Ada for a modula-2 programmer

[Jerry]

On Monday, January 27, 2014 6:06:43 PM UTC-7, ag...@drrob1.com wrote:
<snip>

The way that I came to terms with Ada strings (coming from Pascal) was to first, learn about the three different kinds of strings; second, pretty much forget what I knew about Pascal strings; third, realize that most of the built-in Ada functions require a fixed-length string as arguments; fourth, work with mostly unbounded strings until it is necessary to pass them to a function, at which time use To_String (and To_Unbounded when going in the other direction); and finally, write all your own subprograms so that they too use fixed-length strings. I rarely or never use Pascal-style strings which are most closely mimiced in Ada by bounded-length strings.

When I started Ada, learning about strings and subtypes were the two most important concepts that got me writing basic code effectively. (I could add, Ada's most excellent approach to variable-length arrays.)

Jerry

Re: need help learning Ada for a modula-2 programmer

[Mike H]

In message <ccf2b46a-bb34-4484-b02c-584cfae4e6fa@googlegroups.com>, 
Jerry <lanceboyle@qwest.net> writes
>When I started Ada, learning about strings and subtypes were the two 
>most important concepts that got me writing basic code effectively. (I 
>could add, Ada's most excellent approach to variable-length arrays.)
>
I agree, approaching string types as being no different from other forms 
of array types (and vice-versa) is the right way to go in Ada.

As an exercise, the OP might like to try writing a body for

generic
    type Item is private;
    type Index is (<>);
    type Array_type is array (index range <>) of Item;
function Shift_right_circular
    (A        : Array_type;
    Places : Natural) return Array_type;

Hint: some of the attributes 'FIRST, 'LAST, 'LENGTH, 'PRED, 'POS, 'SUCC, 
'VAL and etc. may be of some use. If the body is about a dozen lines of 
code then you may feel satisfied that you have really cracked it.

-- 
The thing I like best about the Internet is that no one
knows that, in reality, I am just another old dog!
Mike

Re: need help learning Ada for a modula-2 programmer

[Dirk Heinrichs]

agent@drrob1.com wrote:

> with Ada.Calendar; use Ada.Calendar;
> Package timliba is
> 
> --  REVISION HISTORY
> --  ----------------
> --   6 Oct 13 -- Converted to gm2.  And changed its name.
> --  19 Jan 14 -- Converted to Ada.
> 

You've already received some valuable on-topic replies, so here's an off-
topic (but hopefully as valuable) one ;)

You should avoid putting the revision history _into_ your files. It's the 
job of your version control system to handle this. Putting it into the file 
increases the probability of getting merge conflicts.

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de

Re: need help learning Ada for a modula-2 programmer

[Jacob Sparre Andersen]

Mike H wrote:

> As an exercise, the OP might like to try writing a body for
>
> generic
>    type Item is private;
>    type Index is (<>);
>    type Array_type is array (index range <>) of Item;
> function Shift_right_circular
>    (A        : Array_type;
>    Places : Natural) return Array_type;

Generalising the array index beyond type Integer takes up ten lines in
my first take on the task.  (Recursion _might_ make it shorter.)

Greetings,

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."                                    -- C. A. R. Hoare

Re: need help learning Ada for a modula-2 programmer

[Randy Brukardt]

"Dirk Heinrichs" <dirk.heinrichs@altum.de> wrote in message 
news:lcbc0j$cci$1@online.de...
> agent@drrob1.com wrote:
>
>> with Ada.Calendar; use Ada.Calendar;
>> Package timliba is
>>
>> --  REVISION HISTORY
>> --  ----------------
>> --   6 Oct 13 -- Converted to gm2.  And changed its name.
>> --  19 Jan 14 -- Converted to Ada.
>>
>
> You've already received some valuable on-topic replies, so here's an off-
> topic (but hopefully as valuable) one ;)
>
> You should avoid putting the revision history _into_ your files. It's the
> job of your version control system to handle this. Putting it into the 
> file
> increases the probability of getting merge conflicts.

I strongly disagree with this advice. The time to write revision history 
entries is when you are either about to write the code or just finished 
doing so (and more rarely, in the middle). That's when all of the important 
issues are fresh in your mind. It's definitely not at check-in time, which 
occurs after all testing is completed. For the Janus/Ada compiler, that 
means after running the entire ACATS and in-house test suites (twice, in 
Ada2007 mode and Ada95 mode). That's at a minumum 4 hours later - by which 
time you're likely to have forgotten half of the information that ought to 
be in the change log. It's also important to have it in the file if the 
source is likely to be separated from the version control at some point --  
which is almost envitable in today's world (for instance, when the version 
control in use is changed).

The point about merges is correct, except that it really isn't a problem 
with a manual merge (what's one more difference out of dozens?). Assuming 
you have a proper tool for doing those (a multi-window editor with a good 
window-comparison tool), there is no problem. I'd agree that an automated 
merge might have problems, but for me, the idea that an automated merge is 
of any value is laughable. For an automated merge to have any value, it has 
to know all of the contents of the two new files and the contents of 
whatever file they originated from. But that latter item is unknowable in 
general - even the programmers don't know it accurately. One might imagine 
that very strict rules about version control use would help; but I've never 
been on a programming team that didn't break whatever rules were in place 
from time-to-time. And some people (like my co-founder) were completely 
incapable of following any rules whatsoever, no matter how easy and 
unobstrusive they might be.

IMHO, if your depending on merges, especially automated merges, to keep your 
version control consistent, you're already in trouble. You're probably 
losing a percentage of your team's work every day.

                                                 Randy.

Re: need help learning Ada for a modula-2 programmer

[Georg Bauhaus]

"Randy Brukardt" <randy@rrsoftware.com> wrote:
> "Dirk Heinrichs" <dirk.heinrichs@altum.de> wrote in message 

>> 
>> You should avoid putting the revision history _into_ your files. It's the
>> job of your version control system to handle this. Putting it into the 
>> file
>> increases the probability of getting merge conflicts.
> 
> I strongly disagree with this advice. The time to write revision history 
> entries is when you are either about to write the code or just finished 
> doing so (and more rarely, in the middle). That's when all of the important 
> issues are fresh in your mind. It's definitely not at check-in time, which 
> occurs after all testing is completed. 

Depending on the VC system, and on the note taking features of the
IDE, the two approaches can be combined. One branch is for frequent
commits of things just finished, and another branch is for whole change 
sets (after testing). The description of the whole change sets can then
draw
upon notes that were written earlier, when adding to the frequent commits
branch.

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 01/29/2014 05:15 AM, Mike H wrote:
>
> generic
>     type Item is private;
>     type Index is (<>);
>     type Array_type is array (index range <>) of Item;
> function Shift_right_circular
>     (A        : Array_type;
>     Places : Natural) return Array_type;

I'd call that Rotate_Right, personally.

-- 
Jeff Carter
"Sir Robin the not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 01/29/2014 01:41 PM, Jacob Sparre Andersen wrote:
>
> Generalising the array index beyond type Integer takes up ten lines in
> my first take on the task.  (Recursion _might_ make it shorter.)

Mine is the same number of lines whether the index is numeric or not. 2 of the 
lines differ to handle non-numeric indices.

-- 
Jeff Carter
"Sir Robin the not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68

Re: need help learning Ada for a modula-2 programmer

[Bill Findlay]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 01/29/2014 05:15 AM, Mike H wrote:
>> 
>> generic
>>     type Item is private;
>>     type Index is (<>);
>>     type Array_type is array (index range <>) of Item;
>> function Shift_right_circular
>>     (A        : Array_type;
>>     Places : Natural) return Array_type;
> 
> I'd call that Rotate_Right, personally.

I suspect that Mike H is rightpondian.  Shift right circular is what we
call it.

-- 
Bill Findlay

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 01/29/2014 06:44 PM, Bill Findlay wrote:
>
> I suspect that Mike H is rightpondian.  Shift right circular is what we
> call it.

I'm bilingual, but haven't encountered that one before.

-- 
Jeff Carter
"Sir Robin the not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68

Re: need help learning Ada for a modula-2 programmer

[Nasser M. Abbasi]

On 1/29/2014 10:58 AM, Dirk Heinrichs wrote:
> agent@drrob1.com wrote:
>
>> with Ada.Calendar; use Ada.Calendar;
>> Package timliba is
>>
>> --  REVISION HISTORY
>> --  ----------------
>> --   6 Oct 13 -- Converted to gm2.  And changed its name.
>> --  19 Jan 14 -- Converted to Ada.
>>
>
> You've already received some valuable on-topic replies, so here's an off-
> topic (but hopefully as valuable) one ;)
>
> You should avoid putting the revision history _into_ your files. It's the
> job of your version control system to handle this. Putting it into the file
> increases the probability of getting merge conflicts.
>

Wrong advice.

Revision history belongs to the source code itself. If you remove it
and put it in some separate container such as a database, then you
are stuck to having that database along side for ever, and it means
no one can see the revisions made to the source code, unless they
access and install some additional software and files.

--Nasser

Where to put change descriptions (Was: need help learning Ada for a modula-2 programmer)

[Jacob Sparre Andersen]

Nasser M. Abbasi wrote:
> Dirk Heinrichs wrote:
>> agent@drrob1.com wrote:

>>> --  REVISION HISTORY

>> You should avoid putting the revision history _into_ your files. It's
>> the job of your version control system to handle this. Putting it
>> into the file increases the probability of getting merge conflicts.

> Revision history belongs to the source code itself. If you remove it
> and put it in some separate container such as a database, then you are
> stuck to having that database along side for ever, and it means no one
> can see the revisions made to the source code, unless they access and
> install some additional software and files.

It looks like we've found a case of two rather different schools of
thought.  (Luckily we agree that it is good to document changes. ;-)

Once upon a time I kept revision histories in my source files, but the
way I did it (which looked rather a lot like <agent@drrob1.com>s
example), it didn't really add any value.

One reason that revision histories in source files don't make sense to
me is that I often make changes which impact more than one source file.
Which source file should I put that change description in?  Should I
update it in parallel in all the source files I change as I work on the
change?

I agree that one should document the changes in a change (commit) as
early as possible.  I usually do that by writing an issue describing
what I think I have to do and why I think I have to do it.  Once the
issue is written, I start on the change.  More or less in the order;
interface, tests, body (and finally; figuring out what went wrong).

As I already have documented beforehand where and why I want to go, it
is seldom hard to write a meaningful description of the change once I
have verified that it passes both regression tests and new tests.

Greetings,

Jacob
-- 
»But you have to be a bit wary of a ship that collects
 snowflakes.«                                  -- Diziet Sma

Re: need help learning Ada for a modula-2 programmer

[Jacob Sparre Andersen]

Jeffrey Carter wrote:
> On 01/29/2014 01:41 PM, Jacob Sparre Andersen wrote:
>>
>> Generalising the array index beyond type Integer takes up ten lines
>> in my first take on the task.  (Recursion _might_ make it shorter.)
>
> Mine is the same number of lines whether the index is numeric or
> not. 2 of the lines differ to handle non-numeric indices.

I'm curious how you're doing it.  My implementation has one declaration
of a constant (to manage shifts further than one array length) and one
return statement (split over two lines to make it more readable).

The non-numeric index version has another ten lines to make the
mathematical operations used in the return statement work on a
non-numeric index.

Hmmm...  I think I may have figured it out...

Yes.

Converting back and forth between type Index and integers in-line makes
the return statement somewhat less readable. :-(

Using Ada 2012 I can do it with exactly the requested dozen lines (two
of which are blank to improve readability ;-).

Greetings,

Jacob

PS: I'm waiting for the OP to post his/her solution before I'm going to
    post mine.  Please hurry up.
-- 
Never attribute to malice what can adequately be explained by incompetence.

Re: need help learning Ada for a modula-2 programmer

[Georg Bauhaus]

"Nasser M. Abbasi" <nma@12000.org> wrote:

> Revision history belongs to the source code itself. If you remove it
> and put it in some separate container such as a database, then you
> are stuck to having that database along side for ever, and it means
> no one can see the revisions made to the source code, unless they
> access and install some additional software and files.

If the authors decide that others should see the revision notes,
then they can attach them. Release management typically 
relies on corresponding facilities. One form of attachment is
a text file, Changelog. IMHO that's a good way of organizing 
publicly visible history. I don't have to infer it, then, from all kinds of
source files.

Re: need help learning Ada for a modula-2 programmer

[Simon Wright]

Georg Bauhaus <rm-host.bauhaus@maps.arcor.de> writes:

> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>> "Dirk Heinrichs" <dirk.heinrichs@altum.de> wrote in message 
>
>>> 
>>> You should avoid putting the revision history _into_ your
>>> files. It's the job of your version control system to handle
>>> this. Putting it into the file increases the probability of getting
>>> merge conflicts.
>> 
>> I strongly disagree with this advice. The time to write revision
>> history entries is when you are either about to write the code or
>> just finished doing so (and more rarely, in the middle). That's when
>> all of the important issues are fresh in your mind. It's definitely
>> not at check-in time, which occurs after all testing is completed.
>
> Depending on the VC system, and on the note taking features of the
> IDE, the two approaches can be combined. One branch is for frequent
> commits of things just finished, and another branch is for whole
> change sets (after testing). The description of the whole change sets
> can then draw upon notes that were written earlier, when adding to the
> frequent commits branch.

I don't use git, but AIUI 'rebasing' supports frequent commits with the
ability to elide them later so you only see the overall effect. What
happens to the change log I don't know.

Mercurial has queues[1] which allow you to build up a patch over time,
updating the overall commit message as you go.

Personally I don't find it hard to remember what the changes were over a
reasonably short period, but then it's easy to do one thing at a time on
personal projects. Of course, that's not the same as remembering what
the changes were _for_, but I'm not sure that the RCS is the right place
for that anyway?

[1] http://mercurial.selenic.com/wiki/MqTutorial

Re: need help learning Ada for a modula-2 programmer

[Simon Wright]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 01/29/2014 05:15 AM, Mike H wrote:
>>
>> generic
>>     type Item is private;
>>     type Index is (<>);
>>     type Array_type is array (index range <>) of Item;
>> function Shift_right_circular
>>     (A        : Array_type;
>>     Places : Natural) return Array_type;
>
> I'd call that Rotate_Right, personally.

My memory says right end-around shift (REA). But I no longer have the
Ferranti F1600 instruction code booklets (or my simulator code) to
confirm!

Re: need help learning Ada for a modula-2 programmer

[Mike H]

In message <878utybjxc.fsf@adaheads.sparre-andersen.dk>, Jacob Sparre 
Andersen <jacob@jacob-sparre.dk> writes
>Generalising the array index beyond type Integer takes up ten lines in
>my first take on the task.  (Recursion _might_ make it shorter.)
>
-- ===================================================
-- Below is the 'body' of a generic function whose formal specification 
is ...
--
-- generic
--    type Item is private;
--    type Index is (<>);
--    type Array_type is array (index range <>)of Item;
-- function Shift_right_circular
--    (A     : Array_type;
--    Places : Natural) return Array_type;
--
-- ===================================================
--
function Shift_right_circular
   (A      : Array_type;
    Places : Natural) return Array_type is

    -- Split A into two slices A(I1 .. I2) & A(I3 .. I4). The position
    -- of the split is between I2 and I3. I3 is offset from I1 by 
distance P.
    -- I2 is the predecessor of I3.
    P      : Natural := Places rem A'LENGTH;
    I2, I3 : Index; -- Note: type of Index will be known from the 
instantiation

begin

    if P > 0 then
       -- The two slices of A are rejoined as (I3 .. I4) & (I1 .. I2).
       P  := Index'POS(A'FIRST) + P;
       I3 := Index'VAL(P);
       I2 := Index'PRED(I3);
       return A(I3 .. A'LAST) & A(A'FIRST .. I2);
    else
         -- P = 0 is an anomalous case (I3 has no predecessor so the line
         -- "I2 := Index'PRED(I3)" would raise a constraint error), so 
....
       return A;
    end if;

end Shift_right_circular;

--
In PLAN (ICL 1900 assembler) the mnemonic was SRC
The thing I like best about the Internet is that no one
knows that, in reality, I am just another old dog!
Rightpondian Mike

Re: need help learning Ada for a modula-2 programmer

[Bill Findlay]

On 30/01/2014 14:20, in article ZiGSOnCA$l6SFwTY@ada-augusta.demon.co.uk,
"Mike H" <postmaster@ada-augusta.demon.co.uk> wrote:

> In PLAN (ICL 1900 assembler) the mnemonic was SRC
> The thing I like best about the Internet is that no one
> knows that, in reality, I am just another old dog!

Someone else who knows what the DELTY instruction does!
Shall we let the others guess? 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: need help learning Ada for a modula-2 programmer

[Mike H]

In message <CF1013A9.40D6F%yaldnif.w@blueyonder.co.uk>, Bill Findlay 
<yaldnif.w@blueyonder.co.uk> writes
>Someone else who knows what the DELTY instruction does!
>Shall we let the others guess? 8-)
>
My sweetest memory of ICL 1900s was at the end of the shift when one 
typed "Die". To which the machine would respond "Really?". One then 
replied "Yes" and without even a sigh of resignation, the machine would 
say "OK" and comply.
-- 
Mike
Swim? Naturally at Severn Vale
<http://www.severnvalesc.org/>

Re: need help learning Ada for a modula-2 programmer

[Pascal Obry]

Le mercredi 29 janvier 2014 à 22:29 -0600, Nasser M. Abbasi a écrit : 
> On 1/29/2014 10:58 AM, Dirk Heinrichs wrote:
> > agent@drrob1.com wrote:
> >
> >> with Ada.Calendar; use Ada.Calendar;
> >> Package timliba is
> >>
> >> --  REVISION HISTORY
> >> --  ----------------
> >> --   6 Oct 13 -- Converted to gm2.  And changed its name.
> >> --  19 Jan 14 -- Converted to Ada.
> >>
> >
> > You've already received some valuable on-topic replies, so here's an off-
> > topic (but hopefully as valuable) one ;)
> >
> > You should avoid putting the revision history _into_ your files. It's the
> > job of your version control system to handle this. Putting it into the file
> > increases the probability of getting merge conflicts.
> >
> 
> Wrong advice.

Hard to understand why a commonly used and spread usage in all big open
source projects could be wrong!!!

A revision history means just nothing in a source file as what is
important is the *set of* sources (or repository state) for a given bug
fix or feature.

And why should a developer have to duplicate information about what has
been done when it is recorded into the VCS?

My 2 cents!

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: need help learning Ada for a modula-2 programmer

[Dirk Heinrichs]

Randy Brukardt wrote:

> I strongly disagree with this advice. The time to write revision history
> entries is when you are either about to write the code or just finished
> doing so (and more rarely, in the middle). That's when all of the
> important issues are fresh in your mind. It's definitely not at check-in
> time, which occurs after all testing is completed. For the Janus/Ada
> compiler, that means after running the entire ACATS and in-house test
> suites (twice, in Ada2007 mode and Ada95 mode). That's at a minumum 4
> hours later - by which time you're likely to have forgotten half of the
> information that ought to be in the change log.

Is this really the cycle every developer needs to go through? I'd think that 
in this case the long running tests would be performed at a later stage, for 
example when your current change branch is merged.

> It's also important to
> have it in the file if the source is likely to be separated from the
> version control at some point -- which is almost envitable in today's
> world (for instance, when the version control in use is changed).

Which version control is this that you'd change to w/o having proper tools 
for migrating _all_ your data (incl. metadata)?

> IMHO, if your depending on merges, especially automated merges, to keep
> your version control consistent, you're already in trouble. You're
> probably losing a percentage of your team's work every day.

I don't get that one.

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de

Re: need help learning Ada for a modula-2 programmer

[Marius Amado-Alves]

> Hard to understand why a commonly used and spread usage in all big open
> source projects could be wrong!!!

Argumentum ad populum.

FWIW I think revision *notes* as comments on the source file are often ok and helpful, lacking a truly integrated environment. I often place such notes in the locus of change.

Mind, revision *notes*; not a long changelog/revision history style passage: that looks a bit awkward to me too. Like long headers, might impair readability.

BTW long headers are quite *common* too (e.g. GNAT) but that does not make them a *good* practice.

Re: need help learning Ada for a modula-2 programmer

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> And why should a developer have to duplicate information about what
> has been done when it is recorded into the VCS?

I've been asking myself that. The GCC convention[1] (using SVN or a
synchronized git, I don't know which is the master) is to note with each
commit the overall purpose and, for each changed file, a summary of the
changes. This seems sensible, and I've adopted it for my own projects;
it can seem like just regurgitating the source changes, but there's
almost always a _why_ to be added.

[1] http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html

Re: need help learning Ada for a modula-2 programmer

[Randy Brukardt]

"Georg Bauhaus" <rm-host.bauhaus@maps.arcor.de> wrote in message 
news:1714405286412767995.744595rm-host.bauhaus-maps.arcor.de@news.arcor.de...
> "Nasser M. Abbasi" <nma@12000.org> wrote:
>
>> Revision history belongs to the source code itself. If you remove it
>> and put it in some separate container such as a database, then you
>> are stuck to having that database along side for ever, and it means
>> no one can see the revisions made to the source code, unless they
>> access and install some additional software and files.
>
> If the authors decide that others should see the revision notes,
> then they can attach them. Release management typically
> relies on corresponding facilities. One form of attachment is
> a text file, Changelog. IMHO that's a good way of organizing
> publicly visible history. I don't have to infer it, then, from all kinds 
> of
> source files.

The public "changelog" has to be a separately maintained document, IMHO. It 
needs to be a summary of important changes, not the detailed changes that 
get documented in the source files. No end-user needs to know "8/31/08 - 
RLB - Corrected comments to reflect Ada 2007 terminology" or "5/13/11 - 
RLB - Renamed Is_Field to Is_Component to reflect Ada RM terminology". We 
also keep lists of fixed bugs and enhancements separately as users generally 
care about one or the other but not both at the same time.

To some extent, this is clearly a YMMV situation. It depends on the ultimate 
product/customer and the team and the managment.

                                 Randy.

Re: need help learning Ada for a modula-2 programmer

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1391099324.30150.70.camel@pascal.home.net...
...
>And why should a developer have to duplicate information about what has
>been done when it is recorded into the VCS?

(1) Because the VCS only contains a summary of what was done, the details 
are only in the source code. A lot of my VCS entries look like "Fixed bug 
14-06" which doesn't tell you much.
(2) Because the VCS is a separate program, meaning you have to find that 
program, bring it to the top, and then pull up the VCS information in 
question. It's usually easier to find the change log in the source file.
(3) Because the change comment should be local to the change (although I 
don't do this consistently for historical reasons); it makes a lot more 
sense when it is directly next to the code that is affected.
(4) Because sooner or later the source code is going to be separated from 
the VCS (via download, customer delivery, tools change, etc.), and the 
change information will be lost or inaccessible.

I probably could come up with plenty of additional reasons if I wanted too. 
My philosophy is that *everything* about a program ought to be embodied in 
the Ada source files. It shouldn't be necessary to use anything else to 
build an Ada program. (Not project files, not batch scripts, nor anything 
other than you compiler's "Make" tool). I admit that we're not quite there, 
but on modern machines most of these other artifacts are unnecessary. (It 
only takes 20 minutes to recompile the entire Janus/Ada compiler. Most of 
these other things are from an era when it took 12 hours to recompile the 
compiler - saving compilation time by organization was much more important. 
We really don't need to do that now.)

                              Randy.

Re: need help learning Ada for a modula-2 programmer

[Randy Brukardt]

"Dirk Heinrichs" <dirk.heinrichs@altum.de> wrote in message 
news:lce0ob$rid$1@online.de...
> Randy Brukardt wrote:
>
>> I strongly disagree with this advice. The time to write revision history
>> entries is when you are either about to write the code or just finished
>> doing so (and more rarely, in the middle). That's when all of the
>> important issues are fresh in your mind. It's definitely not at check-in
>> time, which occurs after all testing is completed. For the Janus/Ada
>> compiler, that means after running the entire ACATS and in-house test
>> suites (twice, in Ada2007 mode and Ada95 mode). That's at a minumum 4
>> hours later - by which time you're likely to have forgotten half of the
>> information that ought to be in the change log.
>
> Is this really the cycle every developer needs to go through? I'd think 
> that
> in this case the long running tests would be performed at a later stage, 
> for
> example when your current change branch is merged.

Change branch? I suppose it depends on your workflow, but I would never 
waste time with such a thing. I always divide my work is almost always 
divided into subtasks with an ideal duration of 4 hours or so. I only check 
in changes at the end of a subtask, after testing (not necessarily full 
testing, but as much as I can run before I go home). The goal is that the 
compiler will work the same or better after the completion of a subtask; it 
shouldn't be the case that it works worse. With such a workflow, there is no 
need for a change branch, because there almost never will be a need to roll 
back more than one subtask (that is, to the previous item in the VCS).

About the only time I would use a branch is if I was doing an experimental 
rewrite of some component. In that case, one branch or the other will 
ultimately be abandoned completely. I would never, ever trust an automated 
merge of any sort, I've got way too many horror stories with that.

>> It's also important to
>> have it in the file if the source is likely to be separated from the
>> version control at some point -- which is almost envitable in today's
>> world (for instance, when the version control in use is changed).
>
> Which version control is this that you'd change to w/o having proper tools
> for migrating _all_ your data (incl. metadata)?

What sort of VCS would have "proper tools" for mitigrating from an arbitrary 
other VCS? I can't imagine such a thing. Maybe there would be a tool for 
mitigrating from some really popular VCS, but that almost guarantees that it 
would be bad. :-) I'm never met a VCS which understands that the 
relationship between versions of files is a graph, not a tree, and that 
tools for maintaining multiple versions of a program, using various 
combinations of versions of files, is what real programmers often have to 
do. I built a homebrew system to sit on top of a VCS to provide and manage 
those relationships, and I can't imagine how anyone could have "tools" to 
migrate that information when they don't even understand the basic problem. 
(The only use I have for a VCS is to manage the differences; nobody does 
relationships usefully.) I spent a month writing way to convert  the VCS 
files from PVCS to CVS back in the day, and I wouldn't wish that on anyone.

>> IMHO, if your depending on merges, especially automated merges, to keep
>> your version control consistent, you're already in trouble. You're
>> probably losing a percentage of your team's work every day.
>
> I don't get that one.

An automated merge always has to guess what's new and what's old, and 
everytime it gets it wrong, you will lose some changes. Now, I suppose if 
you have a formal change branch and if there is only one change involved, 
then the merge will be flawless. But that's true because there shouldn't 
have ever been a branch in the first place. So the "merge" in question is 
essentially the same as my normal check-in. The problem comes if multiple 
people modify the source at the same time. In that case, an automated merge 
is just an accident waiting to happen - it just *appears* to be safer than 
the complete loss of whomever checks in last.

I'm of the opinion that only a file's owner should be allowed to check in 
changes to it. Other people need to send the owner changes which they merge 
manually. (Preferably, the work is distributed by Ada packages so that there 
is no need for this.) I suppose one could use a change branch for this 
(non-owner changes) -- in order to avoid having to have a second way to 
communicate source code, but that's primarily a convinience; such a branch 
would be dead after the manual merge and nothing of it would remain in the 
main VCS logs.

                                                       Randy.

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 01/30/2014 05:24 AM, Simon Wright wrote:
> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
>
>> I'd call that Rotate_Right, personally.
>
> My memory says right end-around shift (REA). But I no longer have the
> Ferranti F1600 instruction code booklets (or my simulator code) to
> confirm!

Rotate_Right is what Ada uses (package Interfaces).

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 01/30/2014 07:20 AM, Mike H wrote:
>
>     P      : Natural := Places rem A'LENGTH;

This tends to fail in the (perfectly reasonable) case where A'Length = 0.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Re: need help learning Ada for a modula-2 programmer

[Mike H]

In message <lcenro$g2t$2@dont-email.me>, Jeffrey Carter 
<spam.jrcarter.not@spam.not.acm.org> writes
>On 01/30/2014 07:20 AM, Mike H wrote:
>>
>>     P      : Natural := Places rem A'LENGTH;
>
>This tends to fail in the (perfectly reasonable) case where A'Length = 0.
>
Ouch! Null arrays!
-- Mike
There are more things in heaven and earth, Horatio, than are dreamt of in your
philosophy. - Hamlet (1.5.167-8)

Re: need help learning Ada for a modula-2 programmer

[agent]

On Tue, 28 Jan 2014 12:18:33 GMT, Brian Drummond
<brian3@shapes.demon.co.uk> wrote:

>The specific errors have been addressed by others, but as a former M2 fan 
>who has transitioned to Ada, I have a suggestion to help with this last 
>point...
>
>Ada allows variable sized arrays (including strings) to be allocated on 
>the stack - PROVIDED the actual runtime size is known at the point of 
>allocation. 
>
>It also allows the size (or first and last indices) of an array to be 
>queried at runtime.
>
>It also allows new declaration regions within blocks of code (funnily 
>enough, beginning with the word "declare"...)
>
>Put together, these can greatly reduce the pain of processing with fixed 
>length strings, so that actually using variable length strings is rarer 
>than you might imagine at first sight.
>
>So for example you can write MDY2STR as a function:
>

Brian, I need more help here.  I have another function I am trying to
get working, that you may recognize from M2 code

PROCEDURE GetCommandLine(CommandLine : OUT String) is
BEGIN
  n := argument_count;
  k := 1;

  WHILE k <= n LOOP
    move(argument(k),argstr);   -  tried this-
    argstr := argument(k);         -- and this.  Neither works.

    cmdlinefrag := cmdlinefrag & argstr;
    cmdlinefrag := cmdlinefrag & ' ';
    k := Natural'SUCC(k);
  END LOOP; -- while k < n
  CommandLine := cmdlinefrag;
END GetCommandLine;

I am getting "wrong lengty for array of type string" errors.

I was able to get this code working using variable length strings.  I
used bounded strings by copying the code from the texttools.common
routines.

I don't understand how to get this working using standard strings.
This is easy for me using ARRAY OF CHARACTER types in M2 and
procedures from the Strings standard module.

Thanks again for your help.

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 02/01/2014 07:47 PM, agent@drrob1.com wrote:
>
> PROCEDURE GetCommandLine(CommandLine : OUT String) is
> BEGIN
>    n := argument_count;
>    k := 1;
>
>    WHILE k <= n LOOP
>      move(argument(k),argstr);   -  tried this-
>      argstr := argument(k);         -- and this.  Neither works.

Where is Argstr defined?

>      cmdlinefrag := cmdlinefrag & argstr;

Same for Cmdlinefrag.

> I don't understand how to get this working using standard strings.
> This is easy for me using ARRAY OF CHARACTER types in M2 and
> procedures from the Strings standard module.

The actual length of Commandline is determined by the actual parameter. If you 
want to return a String of just the right length, you'll either need an out 
parameter of an (Un)Bounded_String type, or a function that returns String.

For the latter approach, you could use recursion:

function Command_Line return String is
    function Piece (Arg : in Positive) return String is
       -- Empty declarative part
    begin -- Piece
       if Arg > Ada.Command_Line.Argument_Count then
          return "";
       elsif Arg = Ada.Command_Line.Argument_Count then
          return Ada.Command_Line.Argument (Arg);
       else
          return Ada.Command_Line.Argument (Arg) & ' ' & Piece (Arg + 1);
       end if;
    end Piece;
begin -- Command_Line
    return Piece (1);
end Command_Line;

-- 
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88

Re: need help learning Ada for a modula-2 programmer

[agent]

On Sat, 01 Feb 2014 23:09:16 -0700, Jeffrey Carter
<spam.jrcarter.not@spam.not.acm.org> wrote:

>On 02/01/2014 07:47 PM, agent@drrob1.com wrote:
>>
>> PROCEDURE GetCommandLine(CommandLine : OUT String) is
>> BEGIN
>>    n := argument_count;
>>    k := 1;
>>
>>    WHILE k <= n LOOP
>>      move(argument(k),argstr);   -  tried this-
>>      argstr := argument(k);         -- and this.  Neither works.
>
>Where is Argstr defined?
>
>>      cmdlinefrag := cmdlinefrag & argstr;
>
>Same for Cmdlinefrag.
>
>> I don't understand how to get this working using standard strings.
>> This is easy for me using ARRAY OF CHARACTER types in M2 and
>> procedures from the Strings standard module.
>
>The actual length of Commandline is determined by the actual parameter. If you 
>want to return a String of just the right length, you'll either need an out 
>parameter of an (Un)Bounded_String type, or a function that returns String.
>
>For the latter approach, you could use recursion:
>
>function Command_Line return String is
>    function Piece (Arg : in Positive) return String is
>       -- Empty declarative part
>    begin -- Piece
>       if Arg > Ada.Command_Line.Argument_Count then
>          return "";
>       elsif Arg = Ada.Command_Line.Argument_Count then
>          return Ada.Command_Line.Argument (Arg);
>       else
>          return Ada.Command_Line.Argument (Arg) & ' ' & Piece (Arg + 1);
>       end if;
>    end Piece;
>begin -- Command_Line
>    return Piece (1);
>end Command_Line;

ArgStr and CmdlineFrag are defined at the module level.  The working
version of this code declares them to be bounded strings.  Brian said
that he uses fixed length strings almost always.  I am interested in
how that could be done.

Is it correct that having a function return a fixed string is more
flexible than a string param in a procedure?  I am getting the sense
that having a function return the string on the stack works by not
setting its dimensions in advance, but a param has to set them in
advance.  So the trick is to use the stack for strings by recursion,
as you just did?

I don't use recursion in my code.  This is probably because the first
language I learned was Fortran 66, and I never needed it before.

With the single exception of the quicksort algorithm.  Which I copied
from a book.

Thx

Re: need help learning Ada for a modula-2 programmer

[gautier_niouzes]

> Is it correct that having a function return a fixed string is more
> flexible than a string param in a procedure?  I am getting the sense
> that having a function return the string on the stack works by not
> setting its dimensions in advance, but a param has to set them in
> advance.  So the trick is to use the stack for strings by recursion,
> as you just did?

You perfectly got the advantage of using a function for obtaining a String (or any unconstrained type) whose length (or range(s) or parameters) is not known in advance.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont

Re: need help learning Ada for a modula-2 programmer

[Brian Drummond]

On Sat, 01 Feb 2014 21:47:15 -0500, agent wrote:

> On Tue, 28 Jan 2014 12:18:33 GMT, Brian Drummond
> <brian3@shapes.demon.co.uk> wrote:
> 
>>The specific errors have been addressed by others, but as a former M2
>>fan who has transitioned to Ada ...
>>Ada allows variable sized arrays (including strings) to be allocated on
>>the stack - PROVIDED the actual runtime size is known at the point of
>>allocation.

> Brian, I need more help here.  I have another function I am trying to
> get working, that you may recognize from M2 code
> 
> PROCEDURE GetCommandLine(CommandLine : OUT String) is BEGIN
>   n := argument_count;
>   k := 1;
> 
>   WHILE k <= n LOOP
>     move(argument(k),argstr);   -  tried this-
>     argstr := argument(k);         -- and this.  Neither works.
> 
>     cmdlinefrag := cmdlinefrag & argstr;
>     cmdlinefrag := cmdlinefrag & ' ';
>     k := Natural'SUCC(k);
>   END LOOP; -- while k < n CommandLine := cmdlinefrag;
> END GetCommandLine;

> I am getting "wrong length for array of type string" errors.
  
Looking at this code I believe the immediate problem is a fixed length 
"argstr" instead of a newly declared one (of the correct size!) for each 
iteration of the loop. 

But there's a wider problem in that the actual parameter for 
CommandLine : OUT String needs to be correctly sized; or (as a function) 
you need to build a correctly sized string piece by piece.

Jeffrey has shown you a recursive way and there's (generally) nothing 
wrong with that. (If your target system has 128 bytes of RAM, that's 
another matter of course!).

If you want a non-iterative approach, one way is to loop twice, first 
calculating the required length, then declare the required length string 
and loop again filling it. This string can then be returned as the 
function result.

function GetCommandLine return String is 
   length : natural := 0;
BEGIN
   for i in 1 to argument_count loop
      length := length + argument(i)'length;
   end loop;
   length := length + argument_count; -- for the spaces!
   declare 
      result : String (1 .. length);
      pos : natural := 1;
   begin
      for i in 1 to argument_count loop
         result(pos .. pos + argument(i)'length)
            := argument(i) & " ";
         pos := pos + argument(i)'length;         
      end loop;
      return result;
   end;
end GetCommandLine;

> I was able to get this code working using variable length strings.  I
> used bounded strings by copying the code from the texttools.common
> routines.

And finally there is nothing wrong with occasional use of bounded or 
unbounded strings if you decide they are the best tool for the job (or if 
it works and you don't want to mess with it further!) Don't infer that I 
avoid them; they simply aren't usually my first choice!

- Brian

Re: need help learning Ada for a modula-2 programmer

[Jeffrey Carter]

On 02/02/2014 08:02 AM, agent@drrob1.com wrote:
>
> ArgStr and CmdlineFrag are defined at the module level.  The working
> version of this code declares them to be bounded strings.  Brian said
> that he uses fixed length strings almost always.  I am interested in
> how that could be done.
>
> Is it correct that having a function return a fixed string is more
> flexible than a string param in a procedure?  I am getting the sense
> that having a function return the string on the stack works by not
> setting its dimensions in advance, but a param has to set them in
> advance.  So the trick is to use the stack for strings by recursion,
> as you just did?

A String object always has a fixed length, and an [in] out parameter is always 
an object. So if you want the flexibility of a variable-length result, you 
either need an unbounded parameter or a function. When a function result is 
itself made up of an unknown number of pieces concatenated together, recursion 
is a useful technique.

> I don't use recursion in my code.  This is probably because the first
> language I learned was Fortran 66, and I never needed it before.

An iterative version would collect the pieces in an Unbounded_String:

function Command_Line return String is
    Result : Ada.Strings.Unbounded.Unbounded_String;

    use type Ada.Strings.Unbounded.Unbounded_String;
begin -- Command_Line
    All_Arguments : for Arg in 1 .. Ada.Command_Line.Argument_Count loop
       Result := Result & Ada.Command_Line.Argument (Arg);

       if Arg < Ada.Command_Line.Argument_Count then
          Result := Result & ' ';
       end if;
    end loop All_Arguments;

    return Ada.Strings.Unbounded.To_String (Result);
end Command_Line;

> With the single exception of the quicksort algorithm.  Which I copied
> from a book.

I first encountered quick sort in /Software Tools/, which implemented it without 
recursion.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: need help learning Ada for a modula-2 programmer

[agent]

On Sun, 02 Feb 2014 17:18:44 GMT, Brian Drummond
<brian3@shapes.demon.co.uk> wrote:

>On Sat, 01 Feb 2014 21:47:15 -0500, agent wrote:
>
>> On Tue, 28 Jan 2014 12:18:33 GMT, Brian Drummond
>> <brian3@shapes.demon.co.uk> wrote:
>> 
>> PROCEDURE GetCommandLine(CommandLine : OUT String) is BEGIN
>>   n := argument_count;
>>   k := 1;
>> 
>>   WHILE k <= n LOOP
>>     move(argument(k),argstr);   -  tried this-
>>     argstr := argument(k);         -- and this.  Neither works.
>> 
>>     cmdlinefrag := cmdlinefrag & argstr;
>>     cmdlinefrag := cmdlinefrag & ' ';
>>     k := Natural'SUCC(k);
>>   END LOOP; -- while k < n CommandLine := cmdlinefrag;
>> END GetCommandLine;
>
>> I am getting "wrong length for array of type string" errors.
>  
>Looking at this code I believe the immediate problem is a fixed length 
>"argstr" instead of a newly declared one (of the correct size!) for each 
>iteration of the loop. 
>
>But there's a wider problem in that the actual parameter for 
>CommandLine : OUT String needs to be correctly sized; or (as a function) 
>you need to build a correctly sized string piece by piece.
>
>Jeffrey has shown you a recursive way and there's (generally) nothing 
>wrong with that. (If your target system has 128 bytes of RAM, that's 
>another matter of course!).
>
>If you want a non-iterative approach, one way is to loop twice, first 
>calculating the required length, then declare the required length string 
>and loop again filling it. This string can then be returned as the 
>function result.
>
>function GetCommandLine return String is 
>   length : natural := 0;
>BEGIN
>   for i in 1 to argument_count loop
>      length := length + argument(i)'length;
>   end loop;
>   length := length + argument_count; -- for the spaces!
>   declare 
>      result : String (1 .. length);
>      pos : natural := 1;
>   begin
>      for i in 1 to argument_count loop
>         result(pos .. pos + argument(i)'length)
>            := argument(i) & " ";
>         pos := pos + argument(i)'length;         
>      end loop;
>      return result;
>   end;
>end GetCommandLine;
>
>> I was able to get this code working using variable length strings.  I
>> used bounded strings by copying the code from the texttools.common
>> routines.
>
>And finally there is nothing wrong with occasional use of bounded or 
>unbounded strings if you decide they are the best tool for the job (or if 
>it works and you don't want to mess with it further!) Don't infer that I 
>avoid them; they simply aren't usually my first choice!
>
>- Brian

No matter what I try, I'm getting a constraint error.  I don't
understand what's wrong.

The compiler noticed that FOR i in 1 to argument_count is wrong.
That's modula-2 syntax.

I missed that at first, even after the compiler complained.

Re: need help learning Ada for a modula-2 programmer

[agent]

On Sun, 02 Feb 2014 19:10:16 -0500, agent@drrob1.com wrote:

>On Sun, 02 Feb 2014 17:18:44 GMT, Brian Drummond
><brian3@shapes.demon.co.uk> wrote:
>
>>On Sat, 01 Feb 2014 21:47:15 -0500, agent wrote:
>>
>>> On Tue, 28 Jan 2014 12:18:33 GMT, Brian Drummond
>>> <brian3@shapes.demon.co.uk> wrote:
>>> 
>>> PROCEDURE GetCommandLine(CommandLine : OUT String) is BEGIN
>>>   n := argument_count;
>>>   k := 1;
>>> 
>>>   WHILE k <= n LOOP
>>>     move(argument(k),argstr);   -  tried this-
>>>     argstr := argument(k);         -- and this.  Neither works.
>>> 
>>>     cmdlinefrag := cmdlinefrag & argstr;
>>>     cmdlinefrag := cmdlinefrag & ' ';
>>>     k := Natural'SUCC(k);
>>>   END LOOP; -- while k < n CommandLine := cmdlinefrag;
>>> END GetCommandLine;
>>
>>> I am getting "wrong length for array of type string" errors.
>>  
>>Looking at this code I believe the immediate problem is a fixed length 
>>"argstr" instead of a newly declared one (of the correct size!) for each 
>>iteration of the loop. 
>>
>>But there's a wider problem in that the actual parameter for 
>>CommandLine : OUT String needs to be correctly sized; or (as a function) 
>>you need to build a correctly sized string piece by piece.
>>
>>Jeffrey has shown you a recursive way and there's (generally) nothing 
>>wrong with that. (If your target system has 128 bytes of RAM, that's 
>>another matter of course!).
>>
>>If you want a non-iterative approach, one way is to loop twice, first 
>>calculating the required length, then declare the required length string 
>>and loop again filling it. This string can then be returned as the 
>>function result.
>>
>>function GetCommandLine return String is 
>>   length : natural := 0;
>>BEGIN
>>   for i in 1 to argument_count loop
>>      length := length + argument(i)'length;
>>   end loop;
>>   length := length + argument_count; -- for the spaces!
>>   declare 
>>      result : String (1 .. length);
>>      pos : natural := 1;
>>   begin
>>      for i in 1 to argument_count loop
>>         result(pos .. pos + argument(i)'length)
>>            := argument(i) & " ";
>>         pos := pos + argument(i)'length;         
>>      end loop;
>>      return result;
>>   end;
>>end GetCommandLine;
>>
>>> I was able to get this code working using variable length strings.  I
>>> used bounded strings by copying the code from the texttools.common
>>> routines.
>>
>>And finally there is nothing wrong with occasional use of bounded or 
>>unbounded strings if you decide they are the best tool for the job (or if 
>>it works and you don't want to mess with it further!) Don't infer that I 
>>avoid them; they simply aren't usually my first choice!
>>
>>- Brian
>
>No matter what I try, I'm getting a constraint error.  I don't
>understand what's wrong.
>
>The compiler noticed that FOR i in 1 to argument_count is wrong.
>That's modula-2 syntax.
>
>I missed that at first, even after the compiler complained.
>
>

I just figured out the constraint error.  I was using a simple
assignment.  When I started using the move command, it started
working.

I just needed to make the statement
  pos := pos + argument(i)'length + 1;  

Now it works.

Every human language has its idioms, and computer languages are not an
exception.

Thanks guys

Re: need help learning Ada for a modula-2 programmer

[Dmitry A. Kazakov]

On Sun, 02 Feb 2014 12:48:51 -0700, Jeffrey Carter wrote:

> On 02/02/2014 08:02 AM, agent@drrob1.com wrote:
>>
>> I don't use recursion in my code.  This is probably because the first
>> language I learned was Fortran 66, and I never needed it before.
> 
> An iterative version would collect the pieces in an Unbounded_String:
> 
> function Command_Line return String is
>     Result : Ada.Strings.Unbounded.Unbounded_String;

A side note.

The exercise does not make much sense anyway because the result is not the
actual command line as it would not include the command itself (the
application path) and the arguments returned would be most likely
translated and expanded (e.g. wildcards substituted, files found, I/O
redirection removed).

If the OP wants to get the command line he should use the OS services
instead. E.g.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx

(accessible through Win32Ada bindings). Or reading from

/proc/self/cmdline

under Linux, etc.

In any case the behavior is highly dependent on the OS in question.

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

Re: need help learning Ada for a modula-2 programmer

[Brian Drummond]

On Sun, 02 Feb 2014 19:10:16 -0500, agent wrote:

> On Sun, 02 Feb 2014 17:18:44 GMT, Brian Drummond
> <brian3@shapes.demon.co.uk> wrote:

>>function GetCommandLine return String is
>>   length : natural := 0;
>>BEGIN
>>   for i in 1 to argument_count loop
>>      length := length + argument(i)'length;
>>   end loop;

> No matter what I try, I'm getting a constraint error.  I don't
> understand what's wrong.
> 
> The compiler noticed that FOR i in 1 to argument_count is wrong.
> That's modula-2 syntax.

It's also VHDL syntax : VHDL and Ada are quite similar, and I keep 
switching between them, which is why I got it wrong!

- Brian

Re: need help learning Ada for a modula-2 programmer

[agent]

On Wed, 29 Jan 2014 12:15:58 +0000, Mike H
<postmaster@ada-augusta.demon.co.uk> wrote:

>In message <ccf2b46a-bb34-4484-b02c-584cfae4e6fa@googlegroups.com>, 
>Jerry <lanceboyle@qwest.net> writes
>>When I started Ada, learning about strings and subtypes were the two 
>>most important concepts that got me writing basic code effectively. (I 
>>could add, Ada's most excellent approach to variable-length arrays.)
>>
>I agree, approaching string types as being no different from other forms 
>of array types (and vice-versa) is the right way to go in Ada.
>
This misunderstands where I am coming from.  To me, Ada is a second
language.  I am used to how Modula-2 treats strings, which is the same
as C, by null terminating them.

So Ada standard (fixed) string types are quite different than that.

Re: need help learning Ada for a modula-2 programmer

[J-P. Rosen]

Le 04/02/2014 00:12, agent@drrob1.com a écrit :
>> >I agree, approaching string types as being no different from other forms 
>> >of array types (and vice-versa) is the right way to go in Ada.
>> >
> This misunderstands where I am coming from.  To me, Ada is a second
> language.  I am used to how Modula-2 treats strings, which is the same
> as C, by null terminating them.
> 
> So Ada standard (fixed) string types are quite different than that.
> 
But you need to understand that Modula-2 strings are closer to bounded
strings than to fixed strings: a string with maximum length and current
length.

The difference is that the way the maximum length is computed is
abstracted away in Ada, while it is visible (a special character) in
Modula2.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: need help learning Ada for a modula-2 programmer

[agent]

On Tue, 28 Jan 2014 14:51:52 -0800 (PST), Jerry <lanceboyle@qwest.net>
wrote:

>On Monday, January 27, 2014 6:06:43 PM UTC-7, ag...@drrob1.com wrote:
><snip>
>
>The way that I came to terms with Ada strings (coming from Pascal) was to first, learn about the three different kinds of strings; second, pretty much forget what I knew about Pascal strings; third, realize that most of the built-in Ada functions require a fixed-length string as arguments; fourth, work with mostly unbounded strings until it is necessary to pass them to a function, at which time use To_String (and To_Unbounded when going in the other direction); and finally, write all your own subprograms so that they too use fixed-length strings. I rarely or never use Pascal-style strings which are most closely mimiced in Ada by bounded-length strings.
>
>When I started Ada, learning about strings and subtypes were the two most important concepts that got me writing basic code effectively. (I could add, Ada's most excellent approach to variable-length arrays.)
>
>Jerry

If I understand this correctly, you advise me to pass standard fixed
strings as params, but I can use unbounded strings internally in a
routine.  

Why are you recommending I not use unbounded strings as params?