calenday (was Re: IBM Acquires Rational Ada

calenday (was Re: IBM Acquires Rational Ada

[Peter Hermann]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> But I still believe that there is hope that this may change
> over time. I think that the Ada standards need to move beyond
> the focus of the embedded market to the business and general
> purpose use to improve its acceptability.  Give us a _PROPER_
> Ada.Calendar package for a start! (can't determine the day of
> the week for example)

http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads

which is ready to be built into ada.calendar of gnat for Ada2005.
Of course only after finding a common consensus about the most 
useful spec. :-)
I am ready to accept suggestions.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Peter Hermann wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> 
>>But I still believe that there is hope that this may change
>>over time. I think that the Ada standards need to move beyond
>>the focus of the embedded market to the business and general
>>purpose use to improve its acceptability.  Give us a _PROPER_
>>Ada.Calendar package for a start! (can't determine the day of
>>the week for example)
> 
> http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads
> 
> which is ready to be built into ada.calendar of gnat for Ada2005.
> Of course only after finding a common consensus about the most 
> useful spec. :-)
> I am ready to accept suggestions.

I would suggest one more small point WRT to:

type day_name_type is (mon,tue,wed,thu,fri,sat,sun);

Add a representation clause to guarantee that the values
start with sun => 0, mon => 1 etc.  For some code, it is
much easier to work with the day of the week in the form
of a number.

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

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W. Gay
VE3WWG" <ve3wwg@cogeco.ca> wrote:
> 
> I would suggest one more small point WRT to:
> 
> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> 
> Add a representation clause to guarantee that the values
> start with sun => 0, mon => 1 etc.  For some code, it is
> much easier to work with the day of the week in the form
> of a number.

I'm puzzled by this advice.

day_name_type'Pos(mon) .. day_name_type'Pos(sun)

is necessarily 0 .. 6, is it not?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[David C. Hoos]

----- Original Message ----- 
From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, December 16, 2002 1:04 PM
Subject: Re: calenday (was Re: IBM Acquires Rational Ada


> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W. Gay
> VE3WWG" <ve3wwg@cogeco.ca> wrote:
> > 
> > I would suggest one more small point WRT to:
> > 
> > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> > 
> > Add a representation clause to guarantee that the values
> > start with sun => 0, mon => 1 etc.  For some code, it is
> > much easier to work with the day of the week in the form
> > of a number.
> 
> I'm puzzled by this advice.
> 
> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
> 
> is necessarily 0 .. 6, is it not?
> 
Yes, the _pos_ attribute is defined by the language as you state,
but Warren is looking to have the _representation_ specified in
the package specification.  This insures that instantiations of
Ada.Unchecked_Conversion between day_name_type and
integer types produce specified results.

> -- 
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 16/12/02 20:25, in article
mailman.1040070362.25927.comp.lang.ada@ada.eu.org, "David C. Hoos"
<david.c.hoos.sr@ada95.com> wrote:

> 
> ----- Original Message -----
> From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
> 
> 
>> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W. Gay
>> VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>> 
>>> I would suggest one more small point WRT to:
>>> 
>>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>> 
>>> Add a representation clause to guarantee that the values
>>> start with sun => 0, mon => 1 etc.  For some code, it is
>>> much easier to work with the day of the week in the form
>>> of a number.
>> 
>> I'm puzzled by this advice.
>> 
>> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
>> 
>> is necessarily 0 .. 6, is it not?
>> 
> Yes, the _pos_ attribute is defined by the language as you state,
> but Warren is looking to have the _representation_ specified in
> the package specification.  This insures that instantiations of
> Ada.Unchecked_Conversion between day_name_type and
> integer types produce specified results.
> 

Yes, but if what you want is "to work with the day of the week in
the form of a number", why use Unchecked_Conversion when
day_name_type'Pos does what you want without further ado?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[David C. Hoos]

----- Original Message -----
From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, December 16, 2002 2:37 PM
Subject: Re: calenday (was Re: IBM Acquires Rational Ada


> On 16/12/02 20:25, in article
> mailman.1040070362.25927.comp.lang.ada@ada.eu.org, "David C. Hoos"
> <david.c.hoos.sr@ada95.com> wrote:
>
> >
> > ----- Original Message -----
> > From: "Bill Findlay" <yaldnifw@blueyonder.co.uk>
> >
> >
> >> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W.
Gay
> >> VE3WWG" <ve3wwg@cogeco.ca> wrote:
> >>>
> >>> I would suggest one more small point WRT to:
> >>>
> >>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> >>>
> >>> Add a representation clause to guarantee that the values
> >>> start with sun => 0, mon => 1 etc.  For some code, it is
> >>> much easier to work with the day of the week in the form
> >>> of a number.
> >>
> >> I'm puzzled by this advice.
> >>
> >> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
> >>
> >> is necessarily 0 .. 6, is it not?
> >>
> > Yes, the _pos_ attribute is defined by the language as you state,
> > but Warren is looking to have the _representation_ specified in
> > the package specification.  This insures that instantiations of
> > Ada.Unchecked_Conversion between day_name_type and
> > integer types produce specified results.
> >
>
> Yes, but if what you want is "to work with the day of the week in
> the form of a number", why use Unchecked_Conversion when
> day_name_type'Pos does what you want without further ado?
Suppose you have an array of day_name_type that you want to
convert to an array of numbers.  It's much cheaper to use
Unchecked_Conversion than it is to loop through the array and
call the 'Pos function or the 'Val function on each element of
the array.

>
> --
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 16/12/02 21:41, in article
mailman.1040074922.28258.comp.lang.ada@ada.eu.org, "David C. Hoos"
<david.c.hoos.sr@ada95.com> wrote:

[snip]
>>>> On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W.Gay
>>>> VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>>>> 
>>>>> I would suggest one more small point WRT to:
>>>>> 
>>>>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>>>> 
>>>>> Add a representation clause to guarantee that the values
>>>>> start with sun => 0, mon => 1 etc.  For some code, it is
>>>>> much easier to work with the day of the week in the form
>>>>> of a number.

> Suppose you have an array of day_name_type that you want to
> convert to an array of numbers.  It's much cheaper to use
> Unchecked_Conversion than it is to loop through the array and
> call the 'Pos function or the 'Val function on each element of
> the array.
> 

Isn't mon => 0, ..., sun => 6 guaranteed to be the
encoding of this type in any case, even without a
representation clause?

Defining sun => 0, mon => 1, inconsistently with 'Pos, is going
to create a distributed inefficiency in processing this type.

Can you see this being worth the hypothetical saving in unchecked array
conversion? (We are discussing unconditional advice here.)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> 
> Add a representation clause to guarantee that the values
> start with sun => 0, mon => 1 etc.

Hmmm. It shouldn't fall to the C++ programmer to point out
that 13.4/6 requires that "the associated integer codes shall
satisfy the predefined ordering relation of the type".

Re: calenday (was Re: IBM Acquires Rational Ada

[tmoran]

> This insures that instantiations of
> Ada.Unchecked_Conversion between day_name_type and
> integer types produce specified results.
  An enumeration of days of the week is unlikely to be of the same 'size
as integer'size, so the result is "implementation defined".  And why
worry about that when
  My_Day : constant  array(Day_Of_Week) of Integer
    := (Sunday => 7, Monday => 0, ...
is so simple, portable, and modifiable.

Re: calenday (was Re: IBM Acquires Rational Ada

[Grein, Christoph]

RM 13.4(8) For nonboolean enumeration types, if the coding is not specified for 
the type, then for each value of the type, the internal code shall be equal to 
its position number.

So your proposal is superfluous.

And there is no global agreement whether the week starts with Sunday or Monday. 
Historically, it starts with Sunday, but there are countries where it starts 
with Monday.

> >>> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> >>> 
> >>> Add a representation clause to guarantee that the values
> >>> start with sun => 0, mon => 1 etc.  For some code, it is
> >>> much easier to work with the day of the week in the form
> >>> of a number.
> >> 
> >> I'm puzzled by this advice.
> >> 
> >> day_name_type'Pos(mon) .. day_name_type'Pos(sun)
> >> 
> >> is necessarily 0 .. 6, is it not?
> >> 
> > Yes, the _pos_ attribute is defined by the language as you state,
> > but Warren is looking to have the _representation_ specified in
> > the package specification.  This insures that instantiations of
> > Ada.Unchecked_Conversion between day_name_type and
> > integer types produce specified results.
> > 
> 
> Yes, but if what you want is "to work with the day of the week in
> the form of a number", why use Unchecked_Conversion when
> day_name_type'Pos does what you want without further ado?

Re: calenday (was Re: IBM Acquires Rational Ada

[Grein, Christoph]

> > Yes, but if what you want is "to work with the day of the week in
> > the form of a number", why use Unchecked_Conversion when
> > day_name_type'Pos does what you want without further ado?
> Suppose you have an array of day_name_type that you want to
> convert to an array of numbers.  It's much cheaper to use
> Unchecked_Conversion than it is to loop through the array and
> call the 'Pos function or the 'Val function on each element of
> the array.

This seems unbelievable with RM 13.4(8) in mind.

Re: calenday (was Re: IBM Acquires Rational Ada

[Simon Wright]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> I would suggest one more small point WRT to:
> 
> type day_name_type is (mon,tue,wed,thu,fri,sat,sun);

This (and month_name_type) seems very English and abbreviated.

> Add a representation clause to guarantee that the values
> start with sun => 0, mon => 1 etc.  For some code, it is
> much easier to work with the day of the week in the form
> of a number.

I would have thought the chance of this being standardised was very
close to zero! given 'Pos.

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> RM 13.4(8) For nonboolean enumeration types, if the coding is not
> specified for the type, then for each value of the type, the internal
> code shall be equal to its position number.
> 
> So your proposal is superfluous.

And illegal, as our resident C++ guru pointed out.  ;-)

> And there is no global agreement whether the week starts with Sunday
> or Monday.  Historically, it starts with Sunday, but there are
> countries where it starts with Monday.

I read somewhere that there is an ISO standard for dates and times that
says the week starts on Monday.

However, I think I can quote a book that predates ISO by thousands of
years, which says Sunday is the first day of the week.  ;-)

I go with Sunday first.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
> > I would suggest one more small point WRT to:
> > 
> > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> 
> This (and month_name_type) seems very English 

Well, "begin" and "end" are English, too.  It seems to me that if you
want to print out day names in some other language, the program could
internallly use Sunday, Monday, etc, and then do a table lookup to find
the appropriate String to print.

> and abbreviated.

...and uses non-standard case.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> > > Yes, but if what you want is "to work with the day of the week in
> > > the form of a number", why use Unchecked_Conversion when
> > > day_name_type'Pos does what you want without further ado?
> > Suppose you have an array of day_name_type that you want to
> > convert to an array of numbers.  It's much cheaper to use
> > Unchecked_Conversion than it is to loop through the array and
> > call the 'Pos function or the 'Val function on each element of
> > the array.
> 
> This seems unbelievable with RM 13.4(8) in mind.

I don't buy the unchecked-conversion-of-array efficiency argument.
It might be true that unchecked conversion of an array is faster than
a loop with 'Pos.  And unchecked conversion of a *pointer* to the array
would certainly be faster.  But there is no need to resort to such
low-level hackery.  Keep arrays of Day_Name_Type.  Whenever you need to
process a particular day using arithmetic, use 'Pos and 'Val.  There is
never a need to have an array of days-as-integers, and there is never a
need to do a whole-array conversion.

Note that 'Pos and 'Val should generate zero machine code,
if you stay away from enumeration representation clauses.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Bill Findlay wrote:
> On 16/12/02 21:41, in article
> mailman.1040074922.28258.comp.lang.ada@ada.eu.org, "David C. Hoos"
> <david.c.hoos.sr@ada95.com> wrote:
> 
> [snip]
> 
>>>>>On 16/12/02 18:38, in article 3DFE1D97.6020109@cogeco.ca, "Warren W.Gay
>>>>>VE3WWG" <ve3wwg@cogeco.ca> wrote:
>>>>>
>>>>>>I would suggest one more small point WRT to:
>>>>>>
>>>>>>type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>>>>>
>>>>>>Add a representation clause to guarantee that the values
>>>>>>start with sun => 0, mon => 1 etc.  For some code, it is
>>>>>>much easier to work with the day of the week in the form
>>>>>>of a number.
>>>>>
> 
>>Suppose you have an array of day_name_type that you want to
>>convert to an array of numbers.  It's much cheaper to use
>>Unchecked_Conversion than it is to loop through the array and
>>call the 'Pos function or the 'Val function on each element of
>>the array.
> 
> Isn't mon => 0, ..., sun => 6 guaranteed to be the
> encoding of this type in any case, even without a
> representation clause?
> 
> Defining sun => 0, mon => 1, inconsistently with 'Pos, is going
> to create a distributed inefficiency in processing this type.
> 
> Can you see this being worth the hypothetical saving in unchecked array
> conversion? (We are discussing unconditional advice here.)

Actually, I was not thinking of Unchecked_Conversion when
I suggested the representation clause. You are right in that
the 'Pos(mon) is zero anyway (I didn't know that this was
guaranteed by the language). It is also apparently bad
practice to rely on the representation, because I get the
impression that some Ada compilers may ignore the representation
clause.

My question now is, why is Monday first?  My own personal
preference would be to have Sunday first to be consistent
with the UNIX practice in the use of localtime/gmtime and
mktime(3C) routines.

Was there a reason that Monday was chosen as the first in
this series?

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

Re: calenday (was Re: IBM Acquires Rational Ada

[Peter Hermann]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> My question now is, why is Monday first?  My own personal
> preference would be to have Sunday first to be consistent
> with the UNIX practice in the use of localtime/gmtime and
> mktime(3C) routines.

> Was there a reason that Monday was chosen as the first in
> this series?

I personally very much prefer the Monday to be first
because it is more practical, e.g. 
subtype working_day_type is day_type range mon..fri;

I only can vote for monday in a democracy ;-)
i.e.  I do not want to ignite a flame war with
people from different cultures.
We had these discussions several times and we did not
find consensus. So my hope is in favor of M=1     :-)


-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 17/12/02 16:26, in article atnj76$c7n$1@news.uni-stuttgart.de, "Peter
Hermann" <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> 
> I personally very much prefer the Monday to be first
> because it is more practical, e.g.
> subtype working_day_type is day_type range mon..fri;
> 

Sunday-first does not prevent you declaring this subtype.
What it would do is require a range check for the working-day predicate,
instead of the single comparison with Monday-first.

> I only can vote for monday in a democracy ;-)
> i.e.  I do not want to ignite a flame war with
> people from different cultures.
> We had these discussions several times and we did not
> find consensus. So my hope is in favor of M=1     :-)
> 

Well, if M is Monday, then you actually favour M=0!

Is this issue the calendrical equivalent of big- vs little-endianism?
8-)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

>... It is also apparently bad
> practice to rely on the representation, because I get the
> impression that some Ada compilers may ignore the representation
> clause.

Ada compilers cannot ignore rep clauses.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[tmoran]

> > > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> the program could internallly use Sunday, Monday, etc, and then do a table
> lookup to find the appropriate String to print.

type Day_Name is (Monday, Tuesday ...
Short_Day_Name : constant array(Day_Name) of String(1 .. 3) := ("Mon", ...
makes it easy to print three letter abbreviations, and Day_Name'image(Day)
would print the full (English) names if you want full length names.  Going
the reverse direction, with an array of different length strings, is
rather less convenient.
  "And on the seventh day He rested" suggests Sunday should be last and
Monday first.  OTOH, both moon and sun are mere astronomical objects,
whereas Thor was a god, so clearly Thursday should be first. ;)

Re: calenday (was Re: IBM Acquires Rational Ada

[Bill Findlay]

On 17/12/02 19:08, in article 9DKL9.380955$P31.141586@rwcrnsc53,
"tmoran@acm.org" <tmoran@acm.org> wrote:

> "And on the seventh day He rested" suggests Sunday should be last and
> Monday first.  OTOH, both moon and sun are mere astronomical objects,
> whereas Thor was a god, so clearly Thursday should be first. ;)

Nope, Tuesday gets it on that basis. 8-)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <1040155235.443519@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> tmoran@acm.org wrote:
>>   "And on the seventh day He rested" suggests Sunday should be last
> 
> Not for Jews. For us, the seventh day is Saturday.

So the general problem is that enumerated types follow the model
of integer types rather than modular types :-)

Re: calenday (was Re: IBM Acquires Rational Ada

[Hyman Rosen]

tmoran@acm.org wrote:
>   "And on the seventh day He rested" suggests Sunday should be last

Not for Jews. For us, the seventh day is Saturday.

Re: calenday (was Re: IBM Acquires Rational Ada

[David C. Hoos]

----- Original Message -----
From: <tmoran@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, December 17, 2002 1:08 PM
Subject: Re: calenday (was Re: IBM Acquires Rational Ada


> > > > type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
> > the program could internallly use Sunday, Monday, etc, and then do a
table
> > lookup to find the appropriate String to print.
>
> type Day_Name is (Monday, Tuesday ...
> Short_Day_Name : constant array(Day_Name) of String(1 .. 3) := ("Mon", ...
> makes it easy to print three letter abbreviations, and Day_Name'image(Day)
> would print the full (English) names if you want full length names.  Going
> the reverse direction, with an array of different length strings, is
> rather less convenient.
>   "And on the seventh day He rested" suggests Sunday should be last and
> Monday first.  OTOH, both moon and sun are mere astronomical objects,
> whereas Thor was a god, so clearly Thursday should be first. ;)

The day of rest  prescribed in the Ten Commandments is the seventh day
or the sabbath, derived from the Hebrew verb shabath  ("rested"), and which
is reflected in the name of the seventh day of the week in several of the
Romance languages -- e.g., Italian "Sabato."
Moreover, the name for the first day of the week in several of the Romance
languages is derived from the Latin Domini ("Lord") -- e.g., Italian
"Domenica."
As a matter of fact the names of the days of the week in Portuguese are
Domingo, Segunda-fiera, Terca-fiera, Quarta-fiera, Quinta-fiera,
Sexta-fiera, Sabado.

So... ISO notwithstanding, it's pretty clear from historical usage that
Sunday is
the first day of the week.

http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: calenday (was Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

Grein, Christoph fed this fish to the penguins on Monday 16 December 
2002 09:47 pm:


> And there is no global agreement whether the week starts with Sunday
> or Monday. Historically, it starts with Sunday, but there are
> countries where it starts with Monday.
>
        For purposes of payroll processing, my former employer started the 
week on Saturday.

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: calenday (was Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

tmoran@acm.org fed this fish to the penguins on Tuesday 17 December 
2002 11:08 am:

> Monday first.  OTOH, both moon and sun are mere astronomical objects,
> whereas Thor was a god, so clearly Thursday should be first. ;)

        Ah, but Freya was a goddess, so by all rights Friday should be 
first... Of course, Odin (Woden) was putative chief god, and likely 
would insist that his day (Wednesday) be first.

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: calenday (was Re: IBM Acquires Rational Ada

[Wes Groleau]

> However, I think I can quote a book that predates ISO by thousands of
> years, which says Sunday is the first day of the week.  ;-)

If you are speaking of the book I think you are
speaking of, I am not aware of any passage that
actually names the first day or seventh day.  :-)

Re: calenday (was Re: IBM Acquires Rational Ada

[Steven Murdoch]

In article <9DKL9.380955$P31.141586@rwcrnsc53>,
 tmoran@acm.org writes:
>  "And on the seventh day He rested" suggests Sunday should be last and
>Monday first.  OTOH, both moon and sun are mere astronomical objects,
>whereas Thor was a god, so clearly Thursday should be first. ;)

ISO 8601 defines the first day of the week to be Monday, and this practice
is also quite widespread (it is the convention in the UK and much of Europe)

Also ISO 8601 defines Monday to be day 1 and Sunday to be day 7 so I would
suggest forcing the representation to be 1..7, if this is not what
the languge defaults to. This also makes many of the date processing
functions slightly easier to understand.

See:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
for more information.

Steven Murdoch.

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

Wes Groleau <wesgroleau@despammed.com> writes:

> If you are speaking of the book I think you are
> speaking of, I am not aware of any passage that
> actually names the first day or seventh day.  :-)

I believe it calls the seventh day "sabbath".
I don't know if that's a name or a description or both.
But it's certainly the same day we call "saturday"
in the United States.  If you think it's referring to
what we call "sunday", I think you must have lost count
somewhere in the last few thousand years.  ;-)

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Grein, Christoph]

> Was there a reason that Monday was chosen as the first in
> this series?

The bible has Sabbath as the last day of the week, so Sunday is the first 
historically.

But we call Saturday/Sunday the week-end :-)

There is an ISO standard saying Monday is the first day of the week (as Robert A 
Duff pointed out).

Re: calenday (was Re: IBM Acquires Rational Ada

[Grein, Christoph]

>   "And on the seventh day He rested" suggests Sunday should be last and

No, JHVH rested on Sabbath...

Re: calenday (was Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

Robert A Duff fed this fish to the penguins on Tuesday 17 December 2002 
06:09 pm:

> I believe it calls the seventh day "sabbath".
> I don't know if that's a name or a description or both.
> But it's certainly the same day we call "saturday"
> in the United States.  If you think it's referring to
> what we call "sunday", I think you must have lost count
> somewhere in the last few thousand years.  ;-)
>
        Shall we add the minor confusion that, in many cultures, the "day" 
began at /sunset/ (hence such things as "Christmas eve", 
"Halloween"[aka All Hallows Eve] -- even though the calendar is labeled 
Dec 24, once the sun set, the /next/ day was considered to have 
started: Christmas).

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: calenday (was Re: IBM Acquires Rational Ada

[Grein, Christoph]

> > Monday first.  OTOH, both moon and sun are mere astronomical objects,
> > whereas Thor was a god, so clearly Thursday should be first. ;)
> 
>         Ah, but Freya was a goddess, so by all rights Friday should be 
> first... Of course, Odin (Woden) was putative chief god, and likely 
> would insist that his day (Wednesday) be first.

Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag
                        ~~~~~~~~
                        This is only in the middle of the week if we 
start with Sunday :-)

Re: calenday (was Re: IBM Acquires Rational Ada

[Grein, Christoph]

> ISO 8601 defines the first day of the week to be Monday, and this 
practice
> is also quite widespread (it is the convention in the UK and much of 
Europe)
> 
> Also ISO 8601 defines Monday to be day 1 and Sunday to be day 7 so I 
would
> suggest forcing the representation to be 1..7, if this is not what
> the languge defaults to. This also makes many of the date processing
> functions slightly easier to understand.
> 
> See:
> http://www.cl.cam.ac.uk/~mgk25/iso-time.html
> for more information.
> 
> Steven Murdoch.

But still 'Pos (Monday) will return 0. Rep Specs don't affect the 'Pos 
and 'Val attributes.

Re: calenday (was Re: IBM Acquires Rational Ada

[Anders Wirzenius]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcchedcpuy9.fsf@shell01.TheWorld.com...
> I read somewhere that there is an ISO standard for dates and times that
> says the week starts on Monday.
>
> However, I think I can quote a book that predates ISO by thousands of
> years, which says Sunday is the first day of the week.  ;-)
>
> I go with Sunday first.
>
> - Bob

ISO 8601

br
Anders

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wccn0n4oazy.fsf@shell01.TheWorld.com...
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>
> >... It is also apparently bad
> > practice to rely on the representation, because I get the
> > impression that some Ada compilers may ignore the representation
> > clause.
>
> Ada compilers cannot ignore rep clauses.
>

They may not be allowed to ignore them, but they sure can refuse to obey
them. Is there a practical difference between: "I can't hear you.
LaLaLaLaLa..." and "Yeah. Right. When hell freezes over!" Either way, I
don't get what I wanted.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Karel Miklav]

Is there a package or something to work with locales in Ada (like in C, 
you know :) )?


Grein, Christoph wrote:
> RM 13.4(8) For nonboolean enumeration types, if the coding is not specified for 
> the type, then for each value of the type, the internal code shall be equal to 
> its position number.
> 
> So your proposal is superfluous.
> 
> And there is no global agreement whether the week starts with Sunday or Monday. 
> Historically, it starts with Sunday, but there are countries where it starts 
> with Monday.
> 
> 
>>>>>type day_name_type is (mon,tue,wed,thu,fri,sat,sun);
>>>>>
>>>>>Add a representation clause to guarantee that the values
>>>>>start with sun => 0, mon => 1 etc.  For some code, it is
>>>>>much easier to work with the day of the week in the form
>>>>>of a number.
>>>>
>>>>I'm puzzled by this advice.
>>>>
>>>>day_name_type'Pos(mon) .. day_name_type'Pos(sun)
>>>>
>>>>is necessarily 0 .. 6, is it not?
>>>>
>>>
>>>Yes, the _pos_ attribute is defined by the language as you state,
>>>but Warren is looking to have the _representation_ specified in
>>>the package specification.  This insures that instantiations of
>>>Ada.Unchecked_Conversion between day_name_type and
>>>integer types produce specified results.
>>>
>>
>>Yes, but if what you want is "to work with the day of the week in
>>the form of a number", why use Unchecked_Conversion when
>>day_name_type'Pos does what you want without further ado?

Re: calenday (was Re: IBM Acquires Rational Ada

[Ted Dennison]

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote in message news:<gj2ota.bk3.ln@beastie.ix.netcom.com>...
>         For purposes of payroll processing, my former employer started the 
> week on Saturday.

If we lend credence to anything ever done by any company's payroll
department, we're going to be awfully confused indeed (and rather
hungry too, I'd wadger).

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> But we call Saturday/Sunday the week-end :-)

And we call the other five "week days"; two "days of the week" are not
"week days".  Who designed this crazy language?  (English, I mean?)  ;-)

Not to mention the fact that "day" means "24 hours" or "some portion of
24 hours when the sun is up".

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
> news:wccn0n4oazy.fsf@shell01.TheWorld.com...
> > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> >
> > >... It is also apparently bad
> > > practice to rely on the representation, because I get the
> > > impression that some Ada compilers may ignore the representation
> > > clause.
> >
> > Ada compilers cannot ignore rep clauses.
> >
> 
> They may not be allowed to ignore them, but they sure can refuse to obey
> them. Is there a practical difference between: "I can't hear you.
> LaLaLaLaLa..." and "Yeah. Right. When hell freezes over!" Either way, I
> don't get what I wanted.

Yes, there is a practical difference.  In particular, it means that
Warren W. Gay's "bad practice to rely on the representation" comment
above is wrong.  You *can* rely on rep clauses, in the sense that if
your compiler doesn't complain, it must obey the rep clause.
Furthermore, there is a fairly substantial subset of rep clauses that
must be supported by all compilers.  For example, the suggestion of
rep-clausing the Day_Name_Type should be completely portable.  (But I
still think it's not a good idea.)

On the other hand, I agree with your rants about the non-portability of
rep clauses.  If I were designing a language from scratch, I would try
to nail down the rules for rep clauses so that all compilers support
exactly the same ones.  Or, at least, all compilers for the same machine
(where "same machine" can be interpreted to mean that the various values
in System, such as Storage_Unit and Word_Size are the same).  I think I
would also require fairly "complete" support, in the sense of requiring
"weird" bit fields that are extremely inefficient to access.  As you
say, it's very frustrating to use rep clauses for 90% of the cases, and
then be forced to use a completely different mechanism when you run
across "weird" hardware you need to interface to.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Rants? Well, perhaps I have a bad habbit of typing with a "shrill" accent.
:-)

Actually, I don't really care about portability. In my business, we'd seldom
have to port something that was this machine-dependent. I'll accept a
totally vendor/processor specific answer - as is usually a requirement when
you've got to dip into rep clauses anyway.

And I wouldn't really characterize the need as relating to "weird" hardware.
I've not usually found much problem, for example, getting a rep-clause to
work to line up with some register word or other device. Usually, its a case
of someone with a communication link packing things together as tightly as
possible or from hardware substantially different from the thing doing the
reading. You get odd-sized bit fields, things that span byte or word or
longword boundaries, unusual numeric formats (1750a 48-bit float, for
example?) and things of that nature. You try to create a record that will
deal with the data and you discover your compiler is going to whine and
snivel about being asked to span things across unusual boundaries. The
instant the possibility exists that you aren't going to be able to make one
message in your catalog work with the compiler in hand, you're likely to
head for an overall solution that *will* work in all cases - id est
twiddling the bits by hand in some manner. You don't usually want to
implement 90% of the messages as records with rep-clauses and then the
remaining 10% as a byte array & access routines. You'd end up building two
totally different infrastructures and should one of your 90% ever change and
the compiler refuse to help, you're rebuilding something dramatically.

Hence (at least part of) my angst over the rep-clause. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wcc3cov1hlu.fsf@shell01.TheWorld.com...
>
> On the other hand, I agree with your rants about the non-portability of
> rep clauses.  If I were designing a language from scratch, I would try
> to nail down the rules for rep clauses so that all compilers support
> exactly the same ones.  Or, at least, all compilers for the same machine
> (where "same machine" can be interpreted to mean that the various values
> in System, such as Storage_Unit and Word_Size are the same).  I think I
> would also require fairly "complete" support, in the sense of requiring
> "weird" bit fields that are extremely inefficient to access.  As you
> say, it's very frustrating to use rep clauses for 90% of the cases, and
> then be forced to use a completely different mechanism when you run
> across "weird" hardware you need to interface to.
>
> - Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Wes Groleau]

Robert A Duff wrote:
> I believe it calls the seventh day "sabbath".

That it does.  But to insist that our Saturday
is exactly a multiple of seven days from that
Sabbath is to insist that the Jews never lost count
through all their dispersions and returnings.
Or anyone else before or since.

Which I suppose is possible.

Personally, I believe Noah lost count after
about eighty days on the ark.  :-)

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Rants? Well, perhaps I have a bad habbit of typing with a "shrill" accent.
> :-)

No offense intended.  :-)

> Actually, I don't really care about portability. In my business, we'd seldom
> have to port something that was this machine-dependent. I'll accept a
> totally vendor/processor specific answer - as is usually a requirement when
> you've got to dip into rep clauses anyway.
> 
> And I wouldn't really characterize the need as relating to "weird" hardware.
> I've not usually found much problem, for example, getting a rep-clause to
> work to line up with some register word or other device. Usually, its a case
> of someone with a communication link packing things together as tightly as
> possible or from hardware substantially different from the thing doing the
> reading. You get odd-sized bit fields, things that span byte or word or
> longword boundaries, unusual numeric formats (1750a 48-bit float, for
> example?) and things of that nature. 

That's the sort of thing I meant: you're interfacing to something
(hardware or software protocols) that is "weird" from the point of view
of the computer hardware you're running on.  Sometimes the compiler
supports bit fields that are "natural" for *this* computer, but your
data is coming from a computer with a different word size, or different
natural alignments, etc.

>...You try to create a record that will
> deal with the data and you discover your compiler is going to whine and
> snivel about being asked to span things across unusual boundaries. The
> instant the possibility exists that you aren't going to be able to make one
> message in your catalog work with the compiler in hand, you're likely to
> head for an overall solution that *will* work in all cases - id est
> twiddling the bits by hand in some manner. You don't usually want to
> implement 90% of the messages as records with rep-clauses and then the
> remaining 10% as a byte array & access routines.

Yeah, that's a pain.  But so is doing all 100% the bit-twiddling way.
Sigh.

>...You'd end up building two
> totally different infrastructures and should one of your 90% ever change and
> the compiler refuse to help, you're rebuilding something dramatically.

Hahah!  So you *do* care about portability!  (To newer versions of the
same compiler, at least.)  In any case, I think the RM should tell you
which rep clauses are legal, rather than tripping over
implementation-dependent compiler error messages.  I think you agree
with that...
 
- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Warren W. Gay VE3WWG]

Robert A Duff wrote:
> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
...
>>And I wouldn't really characterize the need as relating to "weird" hardware.
>>I've not usually found much problem, for example, getting a rep-clause to
>>work to line up with some register word or other device. Usually, its a case
>>of someone with a communication link packing things together as tightly as
>>possible or from hardware substantially different from the thing doing the
>>reading. You get odd-sized bit fields, things that span byte or word or
>>longword boundaries, unusual numeric formats (1750a 48-bit float, for
>>example?) and things of that nature. 
> 
> That's the sort of thing I meant: you're interfacing to something
> (hardware or software protocols) that is "weird" from the point of view
> of the computer hardware you're running on.  Sometimes the compiler
> supports bit fields that are "natural" for *this* computer, but your
> data is coming from a computer with a different word size, or different
> natural alignments, etc.

Imagine trying to deal with 9-bit bytes as they had on the Honeywell
Level 66 machines (36 bit words) ;-)  No 9 bit bytes ever
made it to the Internet (due to its octet nature), but if you
had to create a hardware interface to such a beast, you may be in
a different situation ;-)

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

Re: calenday (was Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

Robert A Duff fed this fish to the penguins on Wednesday 18 December 
2002 07:06 am:


> "week days".  Who designed this crazy language?  (English, I mean?) 
> ;-)

        The Celts, the Romans, the Saxons, the Danes, and the Normans.

        What did you expect of a language-by-committee (especially when the 
committee members had only serial meetings <G>)

-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: calenday (was Re: IBM Acquires Rational Ada

[Dennis Lee Bieber]

Ted Dennison fed this fish to the penguins on Wednesday 18 December 
2002 06:52 am:

> 
> If we lend credence to anything ever done by any company's payroll
> department, we're going to be awfully confused indeed (and rather
> hungry too, I'd wadger).

        True -- when they implemented a scheme to make every other Friday part 
of a 3-day weekend, the start of the week became "noon" on Friday.

day     M  Tu  W  Th  Fam | Fpm  M  Tu  W  Th  F
hours   9   9  9   9   4  |  4                      44
                          |      9   9  9   9  -    36
                       40 |                    40
-- 
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: calenday (was Re: IBM Acquires Rational Ada

[Dale Stanbrough]

In article <wcc7ke71i4g.fsf@shell01.TheWorld.com>,
 Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> And we call the other five "week days"; two "days of the week" are not
> "week days".  Who designed this crazy language?  (English, I mean?)  ;-)

The same sort of people that realised that people are very good
at decoding meaning based on context, with qualification 
required only when it is ambiguous.

...which sounds very much like a computer language we could be
discussing :-).

Dale

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <3E00BF83.3060301@most.ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@most.ftw.rsc.raytheon.com> writes:
> Robert A Duff wrote:
>> I believe it calls the seventh day "sabbath".
> 
> That it does.  But to insist that our Saturday
> is exactly a multiple of seven days from that
> Sabbath is to insist that the Jews never lost count
> through all their dispersions and returnings.

Dispersions are good, because you get to compare two independent
time sources.  There are no Talmudic calendar disputes recorded,
are there ?

So I suppose we can conclude that no group of Jews in the Diaspora
spent any significant portion of time moving at anything close to
the speed of light :-)

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Robert A Duff wrote in message ...
>"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>>...You'd end up building two
>> totally different infrastructures and should one of your 90% ever
change and
>> the compiler refuse to help, you're rebuilding something
dramatically.
>
>Hahah!  So you *do* care about portability!  (To newer versions of the
>same compiler, at least.)  In any case, I think the RM should tell you
>which rep clauses are legal, rather than tripping over
>implementation-dependent compiler error messages.  I think you agree
>with that...


OK, so why did you refuse to work further on the AIs defining this. :-)
:-)

In fairness to Bob, the ARG struggled with these issues (the
"recommended level of support") for years. But a consensus on the
answers could never be reached. Part of the problem has been that new
members tend to vote against the solutions proposed. They have to be
personally talked into the solution. But that, to me, indicates the
rules are too complex -- nothing should require a personal chat with the
designers before it can be agreed to.

So while I tend to agree with Bob that the RM should tell you, I
disagree with him on WHAT it should tell you. And I suspect that that
will never change, as there are as at least as many correct answers as
there are targets and compiler implementors.

                Randy.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3E00C9AB.8040108@cogeco.ca>...
>Robert A Duff wrote:
>> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>...
>>>And I wouldn't really characterize the need as relating to "weird"
hardware.
>>>I've not usually found much problem, for example, getting a
rep-clause to
>>>work to line up with some register word or other device. Usually, its
a case
>>>of someone with a communication link packing things together as
tightly as
>>>possible or from hardware substantially different from the thing
doing the
>>>reading. You get odd-sized bit fields, things that span byte or word
or
>>>longword boundaries, unusual numeric formats (1750a 48-bit float, for
>>>example?) and things of that nature.
>>
>> That's the sort of thing I meant: you're interfacing to something
>> (hardware or software protocols) that is "weird" from the point of
view
>> of the computer hardware you're running on.  Sometimes the compiler
>> supports bit fields that are "natural" for *this* computer, but your
>> data is coming from a computer with a different word size, or
different
>> natural alignments, etc.
>
>Imagine trying to deal with 9-bit bytes as they had on the Honeywell
>Level 66 machines (36 bit words) ;-)  No 9 bit bytes ever
>made it to the Internet (due to its octet nature), but if you
>had to create a hardware interface to such a beast, you may be in
>a different situation ;-)


We had to write a cross-compiler to such a machine (the U2200). That was
interesting. :-) (Especially handling 36-bit constants on the 32-bit
machine.) It's one reason why I am not enthusastic about trying to set
strong rules for rep. clauses -- because they vary so much on different
hardware.

         Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Robert A Duff]

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

> OK, so why did you refuse to work further on the AIs defining this. :-)
> :-)

;-)

> In fairness to Bob, the ARG struggled with these issues (the
> "recommended level of support") for years. But a consensus on the
> answers could never be reached.

In my earlier posting, I said that if I were designing a language from
scratch I would do all these glorious portable things.  In the context
of Ada, it is probably neither possible nor desirable, given the history
-- existing language rules, existing compiler implementations, existing
Ada code.

- Bob

Re: calenday (was Re: IBM Acquires Rational Ada

[Torsten Poulin]

Dennis Lee Bieber wrote:

>> "week days". Who designed this crazy language? (English, I
>> mean?) ;-)

> The Celts, the Romans, the Saxons, the Danes, and the Normans.

> What did you expect of a language-by-committee (especially when
> the committee members had only serial meetings <G>)

Danish calls the 24 hour period "d�gn"� and the period when the
sun is up "dag". Apparently, the committee responsible for the
design of English overlooked this neat little feature. Maybe yet
another example of the all too common not-invented-here syndrome
:)

� Actually, "d�gn" can be used for any 24 hour period, no matter
when it begins.
-- 
Torsten

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wcc4r9b40ka.fsf@shell01.TheWorld.com...
>
> Hahah!  So you *do* care about portability!  (To newer versions of the
> same compiler, at least.)  In any case, I think the RM should tell you
> which rep clauses are legal, rather than tripping over
> implementation-dependent compiler error messages.  I think you agree
> with that...
>
Nahhh. There comes a point in some really serious embedded projects where
you freeze the version of the compiler because you can't invalidate all your
verification effort by switching to a new one. Its more like the case where
some bozo at the other end of the hose says "You know that message we used
to agree was going to look like this? I've got a problem at this end which
means I've got to change it to look like that....." and now the message you
used to have coaxed the compiler into accepting needs to be redone as the
bit-twiddling variety. Better to pick an answer that is going to work 100%
of the time than get stuck with major rework later.

Now all other things being equal, I'd rather have 100% portability and 100%
guarantees about what *must* work on all compilers rather than dealing with
two compilers dancing to the beat of their own drummers. It would be nice to
have rep clauses that gave you 100% of everything you ever asked for in a
record layout. If I can't have any of the above, I'll settle for
implementation dependent behavior that gets me the layouts I want. (Like I
said, for a given project, you often know you're never going to change
compilers - and if you did, you'd have much bigger fish to fry than settling
out a few rep clauses.)

If none of that is practical, then lets go invent some new kind of data
structure similar to a record that is used strictly for pulling the bits
apart in an arbitrary byte stream.  Usually, when you're dealing with this,
you're pulling data together from a variety of places where it is used
computationally and packing it up to ship it off somewhere, so all you care
about is packing and unpacking it. Since I (with my limited intellect) can
figure out how to write a bunch of procedures and functions with hard-coded
bit/byte positions in them to pick apart what I want from a byte array, I'd
think the compiler could do the same and give me a little help getting the
job done. If that requires some special pragmas or modified data structure
with different rules, I can live with that.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[tmoran]

> deal with the data and you discover your compiler is going to whine and
> snivel about being asked to span things across unusual boundaries.
What's wrong with the routine to align things, followed by an
Unchecked_Conversion to something with an acceptable rep spec, approach?

   type Bit_Width_Lists is array(Integer range <>) of Positive;
   procedure Align (Source : in     Packed_Data;
                    Control: in     Bit_Width_Lists;
                    Target :    out Ada.Streams.Stream_Element_Array);
   -- Copy sequential bit strings, inserting padding as needed to ensure
   -- that each starts on an alignment boundary in Target.

Unless only a few of the resultant fields are accessed, this won't be much
slower than having the compiler do the shifting and masking, and if some
fields are accessed a lot, it will actually be faster.  This doesn't help
with endianness or foreign floating point etc, but those are semantic
level things that a rep spec can't describe anyway.

Re: calenday (was Re: IBM Acquires Rational Ada

[Anders Wirzenius]

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


"Torsten Poulin" <t_usenet_drop@hotmail.com> wrote in message news:atr20s$1tqm3$1@ID-89913.news.dfncis.de...
> � Actually, "d�gn" can be used for any 24 hour period, no matter
> when it begins.

As can "week".

Anders

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <3E01BA24.7648FEC2@konad.de>, Frank Piron <frank.piron@konad.de> writes:

> The C - Programmer works for performance and nowaday for
> nothing but performance.

I believe that would be "apparent performance from the source viewpoint"
ignoring the importance of compiler optimization.

Re: calenday (was Re: IBM Acquires Rational Ada

[Frank Piron]

Hi,

seems to me, that the "calendary" discussion is typical
for ADA95 enthusiasts.

The C - Programmer works for performance and nowaday for
nothing but performance.

The Java - Programmer works for building longer and longer
class names, hoping that someday there is at least one
java application which is platform independent.

The Visual Basic - Programmer works for ... aahhh, money ?

But the ADA community does work for eternity and the hall of
fame in computer programming.

So everything has to be thought out till the very end. But for
the price that many good ideas never come to work.

Frank Piron

Peter Hermann schrieb:
> 
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> > But I still believe that there is hope that this may change
> > over time. I think that the Ada standards need to move beyond
> > the focus of the embedded market to the business and general
> > purpose use to improve its acceptability.  Give us a _PROPER_
> > Ada.Calendar package for a start! (can't determine the day of
> > the week for example)
> 
> http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads
> 
> which is ready to be built into ada.calendar of gnat for Ada2005.
> Of course only after finding a common consensus about the most
> useful spec. :-)
> I am ready to accept suggestions.
> 
> --
> --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
> --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
> --http://www.csv.ica.uni-stuttgart.de/homes/ph/
> --Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Karel Miklav]

I thouhgt they're simply joking :)


Frank Piron wrote:
> Hi,
> 
> seems to me, that the "calendary" discussion is typical
> for ADA95 enthusiasts.
> 
> The C - Programmer works for performance and nowaday for
> nothing but performance.
> 
> The Java - Programmer works for building longer and longer
> class names, hoping that someday there is at least one
> java application which is platform independent.
> 
> The Visual Basic - Programmer works for ... aahhh, money ?
> 
> But the ADA community does work for eternity and the hall of
> fame in computer programming.
> 
> So everything has to be thought out till the very end. But for
> the price that many good ideas never come to work.
> 
> Frank Piron
> 
> Peter Hermann schrieb:
> 
>>Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
>>
>>>But I still believe that there is hope that this may change
>>>over time. I think that the Ada standards need to move beyond
>>>the focus of the embedded market to the business and general
>>>purpose use to improve its acceptability.  Give us a _PROPER_
>>>Ada.Calendar package for a start! (can't determine the day of
>>>the week for example)
>>
>>http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/calenday.ads
>>
>>which is ready to be built into ada.calendar of gnat for Ada2005.
>>Of course only after finding a common consensus about the most
>>useful spec. :-)
>>I am ready to accept suggestions.
>>
>>--
>>--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
>>--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
>>--http://www.csv.ica.uni-stuttgart.de/homes/ph/
>>--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Well, there's all kinds of ways of getting what you want. The thing is that
you have the rep clause there for this purpose, so you hate to come up with
a kludge to get around the fact that it won't.

I'll grant that most of the time, it really isn't a problem. The bulk of the
time, I don't care about representation at all. When I do care about
representation, its typically only as something is going into or coming out
of some device and once I've got it picked apart, the data can go into
un-represented things where the compiler can do what it likes. Even when
we're talking about down at the device level, it usually works because
people don't tend to do things that are all that strange. But there are
still times when getting the data packed as tight as possible - or dealing
with some legacy system - is necessary and you get into issues with the
compiler.

Tagged records probably present the worst problems if you try to throw
representation clauses on them. I've only tinkered with one compiler in this
regard, so I can't speak for all of them and I realize that there are
special problems in this respect. But if you're going to allow rep clauses
on tagged records, there ought to be some ability to actually make them
work. Two problems I had were that a) you have no mechanism to find the
position/size of the tag, so you have no mechanism to offset everything from
it and b) the compiler insisted that all extensions of the record start on a
longword boundary and there was no apparent way to tell it to start
elsewhere - even though it would have been an even byte or word boundary. It
seems to me that those are problems that *could* be addressed and maybe the
rep clause would be more useful.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

<tmoran@acm.org> wrote in message news:5JfM9.395655$P31.145145@rwcrnsc53...
> > deal with the data and you discover your compiler is going to whine and
> > snivel about being asked to span things across unusual boundaries.
> What's wrong with the routine to align things, followed by an
> Unchecked_Conversion to something with an acceptable rep spec, approach?
>
>    type Bit_Width_Lists is array(Integer range <>) of Positive;
>    procedure Align (Source : in     Packed_Data;
>                     Control: in     Bit_Width_Lists;
>                     Target :    out Ada.Streams.Stream_Element_Array);
>    -- Copy sequential bit strings, inserting padding as needed to ensure
>    -- that each starts on an alignment boundary in Target.
>
> Unless only a few of the resultant fields are accessed, this won't be much
> slower than having the compiler do the shifting and masking, and if some
> fields are accessed a lot, it will actually be faster.  This doesn't help
> with endianness or foreign floating point etc, but those are semantic
> level things that a rep spec can't describe anyway.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Frank Piron <frank.piron@konad.de> wrote in message
news:3E01BA24.7648FEC2@konad.de...
>
> But the ADA community does work for eternity and the hall of
> fame in computer programming.
>
> So everything has to be thought out till the very end. But for
> the price that many good ideas never come to work.
>
Alas. All too true. :-(
At least it is a Noble Fault.

If the mentality were to shift *slightly* towards finding a Good Enough
answer that would satisfy 90% of the needs - and doing so in a timely
manner - we might be able to make Ada more attractive to the masses.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Juanma Barranquero]

On Thu, 19 Dec 2002 09:20:01 GMT, "Anders Wirzenius"
<anders.wirzenius@pp.qnet.fi> wrote:

>> � Actually, "d�gn" can be used for any 24 hour period, no matter
>> when it begins.
>
>As can "week".

You suffer from unacceptable short weeks, I gather.

                                        /L/e/k/t/u



P.S.: Sorry, just couldn't resist.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Marin David Condic wrote in message ...
>Tagged records probably present the worst problems if you try to throw
>representation clauses on them. I've only tinkered with one compiler in
this
>regard, so I can't speak for all of them and I realize that there are
>special problems in this respect. But if you're going to allow rep
clauses
>on tagged records, there ought to be some ability to actually make them
>work. Two problems I had were that a) you have no mechanism to find the
>position/size of the tag, so you have no mechanism to offset everything
from
>it and b) the compiler insisted that all extensions of the record start
on a
>longword boundary and there was no apparent way to tell it to start
>elsewhere - even though it would have been an even byte or word
boundary. It
>seems to me that those are problems that *could* be addressed and maybe
the
>rep clause would be more useful.


a) is not a problem in practice. We did this in Claw, and all compilers
put the tag at offset 0. (A few can be told to put it elsewhere, but
that wasn't generally available a few years ago when we did that.) The
size is a problem in that it is implementation-defined.
Ada.Tags.Tag'Size is the correct value, but it isn't static, so you
can't use it in representation clauses. We ended up declaring a constant
TAG_SIZE that we use in the rep. clauses (and compare to
Ada.Tags/Tag'Size as a validity check). However, it is 4 (bytes) in all
of the compilers that we tried, so it really wasn't necessary.

b) is clearly compiler specific. I'd suggest trying to convince your
compiler vendor to improve their compiler. Janus/Ada doesn't require any
alignment for the extension part. And I don't recall having problems
with this in Claw, although perhaps we were lucky.

The biggest non-portability is in the ability (or lack thereof) to put
extension components into "holes" in the parent. This is useful, but can
be really hard to implement (it causes problems with the predefined "="
operation, and I believe that there are other problems that I don't
remember at the moment).

            Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <atv5fj$ldi$1@slb5.atl.mindspring.net>, "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> I'd suspect that declaring in the standard that all tags shall start at
> offset 0 and extend for 32 bits would not cause anyone any rework. I doubt
> it would come up often that the offset needed to be anything other than
> zero - I can't think of why I'd want it to or why I couldn't make things
> work somehow if it were always zero. Having a predefined constant for size
> and a mandated (dare I use that word?) starting point at the beginning of
> the record ought to be good enough.

It depends on whether there are external constraints on the record.
VMS kernel data structures, for instance, use the first 64 bits for
a doubly-linked list, the next 16 bits for length and the 16 bits
after that for a "type" (the closest thing to a constraint or tag).

Interoperation with other languages is crucial in this domain, unlike
all-Ada environments.

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <v04c0ul05vht40@corp.supernews.com>, "Randy Brukardt" <randy@rrsoftware.com> writes:

> a) is not a problem in practice. We did this in Claw, and all compilers
> put the tag at offset 0. (A few can be told to put it elsewhere, but
> that wasn't generally available a few years ago when we did that.) The
> size is a problem in that it is implementation-defined.

Which compilers allowed you (at the time) to specify the tag position ?

What language construct did they use to accept that specification ?

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:v04c0ul05vht40@corp.supernews.com...
>
>
> a) is not a problem in practice. We did this in Claw, and all compilers
> put the tag at offset 0. (A few can be told to put it elsewhere, but
> that wasn't generally available a few years ago when we did that.) The
> size is a problem in that it is implementation-defined.
> Ada.Tags.Tag'Size is the correct value, but it isn't static, so you
> can't use it in representation clauses. We ended up declaring a constant
> TAG_SIZE that we use in the rep. clauses (and compare to
> Ada.Tags/Tag'Size as a validity check). However, it is 4 (bytes) in all
> of the compilers that we tried, so it really wasn't necessary.
>
I'd suspect that declaring in the standard that all tags shall start at
offset 0 and extend for 32 bits would not cause anyone any rework. I doubt
it would come up often that the offset needed to be anything other than
zero - I can't think of why I'd want it to or why I couldn't make things
work somehow if it were always zero. Having a predefined constant for size
and a mandated (dare I use that word?) starting point at the beginning of
the record ought to be good enough.


> b) is clearly compiler specific. I'd suggest trying to convince your
> compiler vendor to improve their compiler. Janus/Ada doesn't require any
> alignment for the extension part. And I don't recall having problems
> with this in Claw, although perhaps we were lucky.
>
Well, someone must have thought it was more important to longword-align
things than to give the programmer what he asked for. :-) The important part
is that if you're going to have a rep-clause, it needs to give the
programmer control over the representation - even if it introduces
inefficiencies.


> The biggest non-portability is in the ability (or lack thereof) to put
> extension components into "holes" in the parent. This is useful, but can
> be really hard to implement (it causes problems with the predefined "="
> operation, and I believe that there are other problems that I don't
> remember at the moment).
>
That starts sounding a bit extreme. The overwhelming bulk of the time, I'd
be trying to use rep-clauses because things are packed tightly together -
not overlapping things. Most typically for tagged records, you'd have a
class called "Message" that included message header info then followed by a
variety of message formats - very naturally expressed in OO Design. But if
you can't control representation, you can't make it work with what happens
on the wire. Short of the base class ending in the middle of a byte (never
seen that) and wanting the derived class to pick up in the middle of that
byte, I can't think of a case where I'd want derived class parts put into
holes in the base class. Maybe it happens, but I think you could probably
put on my tombstone "He never packed derived class data into holes in the
base class..." :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: calenday (was Re: IBM Acquires Rational Ada

[Hyman Rosen]

Marin David Condic wrote:
> I'd suspect that declaring in the standard that all tags shall start at
> offset 0 and extend for 32 bits would not cause anyone any rework.

Since the tag is often a pointer, forcing it to 32 bits
is highly inappropriate. Furthermore, it's possible that
teh layout for such objects is described by a platform
or compiler ABI that the Ada compiler needs to match.

The whole concept of representation specs on tagged
records seems pretty dodgy to me.

Re: calenday (was Re: IBM Acquires Rational Ada

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1040410199.497867@master.nyc.kbcfp.com...
> The whole concept of representation specs on tagged
> records seems pretty dodgy to me.

I agree. AFAIK, the only reason to use a representation clause is to make
sure that a type matches some external data layout. Tagged types, by their
very nature, do not fit into this category. This seems to be one of those
theoretical issues with no practical consequences.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Frank J. Lhota wrote in message ...
>"Hyman Rosen" <hyrosen@mail.com> wrote in message
>news:1040410199.497867@master.nyc.kbcfp.com...
>> The whole concept of representation specs on tagged
>> records seems pretty dodgy to me.
>
>I agree. AFAIK, the only reason to use a representation clause is to
make
>sure that a type matches some external data layout. Tagged types, by
their
>very nature, do not fit into this category. This seems to be one of
those
>theoretical issues with no practical consequences.


Not true. It's perfectly possible to use rep. clauses to insure storage
minimization better than the compiler's pragma Pack. (Usually, Pack
assumes some amount of efficiency is required.)

Also, it is perfectly possible to pass a tagged record to an external
data layout, if that layout includes a tag already (such as COM on
Microsoft machines), or if you are passing the object minus the tag to
the external system, but need type extension to define the external
format properly (that's what happened to use with bitmaps in Claw).

I agree this isn't likely to be a common use, but it has happened, and I
understand that Rational finds that they have customers which think
these capabilities are very important. It's best not to argue with
customers. :-)

              Randy.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Larry Kilgallen wrote in message
<7HQjlgUY7GDY@eisner.encompasserve.org>...
>In article <v04c0ul05vht40@corp.supernews.com>, "Randy Brukardt"
<randy@rrsoftware.com> writes:
>
>> a) is not a problem in practice. We did this in Claw, and all
compilers
>> put the tag at offset 0. (A few can be told to put it elsewhere, but
>> that wasn't generally available a few years ago when we did that.)
The
>> size is a problem in that it is implementation-defined.
>
>Which compilers allowed you (at the time) to specify the tag position ?
>
>What language construct did they use to accept that specification ?

Janus/Ada doesn't allow to specify the location of the tag explicitly,
but it doesn't require a particular position, either. So if you put a
component at location 0, the compiler will put the tag elsewhere (in the
first hole big enough). And if you specify the location of all other
components and the record size, it's pretty clear where the tag is. :-)

Pascal Leroy of Rational has indicated that they had at least one
customer who needed tags other than at location 0, so that their
compiler supports that as well. I don't know if they explicitly allow
specifying it, and I don't know the syntax if they do. I would presume
it is an attribute, following the standard, see 13.5.1(15).

             Randy.

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

Marin David Condic wrote in message ...
> I'd suspect that declaring in the standard that all tags shall start
at
> offset 0 and extend for 32 bits would not cause anyone any rework. I
doubt
> it would come up often that the offset needed to be anything other
than
> zero - I can't think of why I'd want it to or why I couldn't make
things
> work somehow if it were always zero. Having a predefined constant for
size
> and a mandated (dare I use that word?) starting point at the beginning
of
> the record ought to be good enough.

As noted elsewhere, Rational has at least one customer that wants to be
able to place tags, and both Janus/Ada and Rational Apex support
non-zero tag locations. Asking us to remove functionality (with the
possibility for incompatibilities) is not likely to be looked on kindly.

And, as also noted elsewhere, there are machines out there where a
pointer (and thus a tag) is not 32-bits. How would you suggest we
implement that rule on the U2200 with its 36-bit words (and pointers)??

>> The biggest non-portability is in the ability (or lack thereof) to
put
>> extension components into "holes" in the parent. This is useful, but
can
>> be really hard to implement (it causes problems with the predefined
"="
>> operation, and I believe that there are other problems that I don't
>> remember at the moment).
>>
>That starts sounding a bit extreme. The overwhelming bulk of the time,
I'd
>be trying to use rep-clauses because things are packed tightly
together -
>not overlapping things. Most typically for tagged records, you'd have a
>class called "Message" that included message header info then followed
by a
>variety of message formats - very naturally expressed in OO Design. But
if
>you can't control representation, you can't make it work with what
happens
>on the wire. Short of the base class ending in the middle of a byte
(never
>seen that) and wanting the derived class to pick up in the middle of
that
>byte, I can't think of a case where I'd want derived class parts put
into
>holes in the base class. Maybe it happens, but I think you could
probably
>put on my tombstone "He never packed derived class data into holes in
the
>base class..." :-)

Well, it comes up when you're trying to minimize storage of the types,
and the parent has unused bits. Consider:

     type Root_Type is tagged record
         Int : Some_Int_Subtype;
         Is_Valid : Boolean;
    end record;
    for Root_Type use record
        -- We assume the tag is at 0 and is 32 bits. A real rep. clause
would use a constant instead
        -- of assuming the tag size is 4 below.
        Int at 4 range 0 .. 15;
        Is_Valid at 6 range 0 .. 0;
    end record;

The bits 1 .. 7 in byte 6 are unused, as is byte 7. Now, look at the
extension:

     type Day is (Sunday, Monday, ....);

     type Day_Type is new Root_Type with record
            The_Day : Day;
     end record;
     for Day_Type use record
            -- The_Day at 6 range 1 .. 4; -- No extra space needed. But
fills a hole.
            The_Day at 7 range 0 .. 3; -- Extra byte needed.
            -- The_Day at 8 range 0 .. 3; -- Insisting on alignment
makes it worse. Probably a 4 extra
                                                             -- bytes
when allocated.
     end record;

And you waste even more space if some of the extension components need
alignment.

If there are going to be a lot of these (as there might if these are
used in compiler expression trees, for example), the wasted space can
turn into a lot of extra memory overhead (meaning longer compile times
in this example).

         Randy Brukardt.

Re: calenday (was Re: IBM Acquires Rational Ada

[Larry Kilgallen]

In article <au22gl$hc5$1@slb0.atl.mindspring.net>, "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
> Fine. Same deal with messages or other structures. Place them after the tag
> (exactly represented) and load/store with an offset from the start of the
> record. I suppose it might be a bit easier if the tag appears after
> everything - but that just creates problems if you want to extend the
> record. I can always do overlays or offsets or addresses or something
> similar to get past the tag so long as I know exactly where it is and how
> big it is.
> 
> Would you think the case you cited would be something that would need tagged
> records or would it more appropriately be represented by a plain-vanilla
> record? Where would you want to put the tag if not at offset 0?
> 
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>     "I'd trade it all for just a little more"
>         --  Charles Montgomery Burns, [4F10]
> ======================================================================
> 
> Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message
> news:FxwVAF3i62TM@eisner.encompasserve.org...
>>
>> It depends on whether there are external constraints on the record.
>> VMS kernel data structures, for instance, use the first 64 bits for
>> a doubly-linked list, the next 16 bits for length and the 16 bits
>> after that for a "type" (the closest thing to a constraint or tag).
>>
>> Interoperation with other languages is crucial in this domain, unlike
>> all-Ada environments.

The allocation of these structures must start at the queue link
longwords, since they get allocated and deallocated by non-Ada
components.  I have dealt with this in Ada93 for ordinary variant
records, but it seems to me that tags have the same issue as
discriminants.  The start of the record is _not_ ok.

Randy's answer about leaving a hole seems the best I have read so far.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Fine. Same deal with messages or other structures. Place them after the tag
(exactly represented) and load/store with an offset from the start of the
record. I suppose it might be a bit easier if the tag appears after
everything - but that just creates problems if you want to extend the
record. I can always do overlays or offsets or addresses or something
similar to get past the tag so long as I know exactly where it is and how
big it is.

Would you think the case you cited would be something that would need tagged
records or would it more appropriately be represented by a plain-vanilla
record? Where would you want to put the tag if not at offset 0?

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message
news:FxwVAF3i62TM@eisner.encompasserve.org...
>
> It depends on whether there are external constraints on the record.
> VMS kernel data structures, for instance, use the first 64 bits for
> a doubly-linked list, the next 16 bits for length and the 16 bits
> after that for a "type" (the closest thing to a constraint or tag).
>
> Interoperation with other languages is crucial in this domain, unlike
> all-Ada environments.

Re: calenday (was Re: IBM Acquires Rational Ada

[Marin David Condic]

Not at all true. Many message protocols look very much like an Object
Oriented thing with a base class and many derived classes. It is extremely
natural to represent this as a tagged record. Not so much because you expect
to transmit the tag itself, but because you expect to process your messages
internally with all sorts of dispatching and inheretance and stuff like
that. It is extremely natural to do this in an OO way. What you need to do
though is to control the representation of everything that comes after the
tag. You look at your communication link and once you determine the
appropriate type of message, you're doing an overlay or unchecked conversion
or something similar to get the bytes into the tagged record and then go do
your dispatching from there.

The thing is, without the tagged record, you end up building your own
dispatching and inheritance and things like that anyway. (Big case
statements, similarly named procedures or procedures common to all message
types, etc.) You're either going to do it with a lot of bit-twiddling and
extra work or you can do it with tagged records very cleanly. If you've got
two Ada programs talking to each other and they're built by the same
compiler, representation can become a "don't care" issue - maybe. If its on
a more heterogeneous plane, you've got to be sure you control
representation. So I don't really think the issue is all that abstract or
theoretical - it does occur in the real world often enough and you'd just
like to take advantage of tagged records & representation to make it work
nicely.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Frank J. Lhota <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:zuKM9.66886$4W1.13625@nwrddc02.gnilink.net...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1040410199.497867@master.nyc.kbcfp.com...
> > The whole concept of representation specs on tagged
> > records seems pretty dodgy to me.
>
> I agree. AFAIK, the only reason to use a representation clause is to make
> sure that a type matches some external data layout. Tagged types, by their
> very nature, do not fit into this category. This seems to be one of those
> theoretical issues with no practical consequences.
>
>

Re: calenday (was Re: IBM Acquires Rational Ada

[AG]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:v072u4dmuc809f@corp.supernews.com...

> I agree this isn't likely to be a common use, but it has happened, and I
> understand that Rational finds that they have customers which think

Can you post a link pls? :))

Re: calenday (was Re: IBM Acquires Rational Ada

[AG]

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


"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:5bgM9.78$o24.58@read3.inet.fi...
>
> "Torsten Poulin" <t_usenet_drop@hotmail.com> wrote in message
news:atr20s$1tqm3$1@ID-89913.news.dfncis.de...
> > � Actually, "d�gn" can be used for any 24 hour period, no matter
> > when it begins.
>
> As can "week".

For 24 hours? You sure?

Re: calenday (was Re: IBM Acquires Rational Ada

[Randy Brukardt]

AG wrote in message ...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
>news:v072u4dmuc809f@corp.supernews.com...
>
>> I agree this isn't likely to be a common use, but it has happened,
and I
>> understand that Rational finds that they have customers which think
>
>Can you post a link pls? :))


It came up during an ARG meeting. I believe that the comment itself
appears in the minutes of that meeting, but I don't think that any
details were given. You'd have to ask Pascal Leroy to find out more.

                 Randy Brukardt.