Ideas for Ada 200X

Ideas for Ada 200X

[Tony Gair]

How about, since we know client server and the internet are here to
stay, integrating the distributed annex into Ada.

Perhaps Glade would not have so many problems with having two
s-straat.adb files then.

Re: Ideas for Ada 200X

[Preben Randhol]

Tony Gair wrote:
> How about, since we know client server and the internet are here to
> stay, integrating the distributed annex into Ada.
> 
> Perhaps Glade would not have so many problems with having two
> s-straat.adb files then.

What about sockets?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[chris.danx]

Preben Randhol wrote:
> 
> What about sockets?

Yep, sockets!  Also what about XML parsing facilities and better unicode 
support?  They'd just be nice, but sockets would be great.

Re: Ideas for Ada 200X

[Wesley Groleau]

Frank wrote:
> What about the possibility of commenting several lines like /* ...... */?

Booo !!!!
Hisss !!!

Re: Ideas for Ada 200X

[Gautier Write-only]

Frank:

> What about the possibility of commenting several lines like /* ...... */?

Hey cool! I would add the possibility of nesting several of
such comments, or not, and why not also the { } and (* *) of Pascal.
A pragma would allow ending a { by a *) or */, or not, and ignoring
or not the rest of a line inside a "/*" after a -- (even if it has a */).
Did you understand ? I mean, it's simple.
And what about including chuncks of code - it would be so cool to
just insert "c:\...\mytools.inc" at some place instead of these packages.
Another idea: make some names implicitly type. E.g. I, J5, InJm
and so on are always integers, so why declare them ?
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Ideas for Ada 200X

[Martin Dowie]

> What about the possibility of commenting several lines like /* ...... */?

no thanks! i'm back using C again on one of my current work projects and
this style of comment is just a pain - why do you thing they improved on it
for C++?!

RE: Ideas for Ada 200X

[Robert C. Leif]

XML has formalized multiline comments.
<annotation><documentation>....................</documentation></annotation>

Therefore by analogy, one could create annotation and documentation types in
Ada. These could be implemented as bounded strings. This would permit the
compiler and tools like ASIS to have knowledge about the documentation. One
other approach, which I do not like, but must be included for completeness,
is to create a means to include XML blocks in Ada sources. This was done
with embedded SQL. A third approach is to create a hyperlink in the Ada
sources that points to sections of XML documents. And a fourth approach,
which I favor, is to recast the Ada sources into XML documents. This last
approach has the advantages of extending the number of editors that can be
used with Ada; permitting the addition of formatting elements, such as bold,
italics, and fonts; and not requiring any changes to the Ada standard.
Bob Leif

-----Original Message-----
From: Frank [mailto:franjoe@frisurf.no] 
Sent: Tuesday, May 27, 2003 8:38 PM
To: comp.lang.ada@ada.eu.org


What about the possibility of commenting several lines like /* ...... */?

Frank


"Tony Gair" <tony_gair@yahoo.co.uk> wrote in message
news:6a90b886.0305262344.1d558079@posting.google.com...
> How about, since we know client server and the internet are here to
> stay, integrating the distributed annex into Ada.
>
> Perhaps Glade would not have so many problems with having two
> s-straat.adb files then.

Re: Ideas for Ada 200X

[Jeffrey Carter]

Frank wrote:
> What about the possibility of commenting several lines like /* ...... */?

This was considered and explicitly rejected by the original Ada design 
team as being too error-prone. Consider

/* Comment all this out

... 100 lines

Something ("Hey, why not */ Cause A Compilation Error /* huh?");

... 100 lines

end of commented out stuff */

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers

Re: Ideas for Ada 200X

[Frank]

What about the possibility of commenting several lines like /* ...... */?

Frank


"Tony Gair" <tony_gair@yahoo.co.uk> wrote in message
news:6a90b886.0305262344.1d558079@posting.google.com...
> How about, since we know client server and the internet are here to
> stay, integrating the distributed annex into Ada.
>
> Perhaps Glade would not have so many problems with having two
> s-straat.adb files then.

Re: Ideas for Ada 200X

[Stuart Palin]

Jeffrey Carter wrote:
> 
> Frank wrote:
> > What about the possibility of commenting several lines like /* ...... */?
> 
> This was considered and explicitly rejected by the original Ada design
> team as being too error-prone.
<snip>

And then they chose '--' as the comment delimiter!  I have
always found this rather odd as it seems to me to be a
potential source of 'difficult to spot' typo errors. 
Consider,

   The_Result := Meaningful_Identifier_1 --
Meaningful_Identifier_2
                 + Meaningful_Identifier_3;

[OK Any decent form of testing should find the mistake - but
surely the intention was to reduce the likelihood of errors
getting through compilation]

I agree with the reasons for not allowing block comments,
but perhaps the choice of comment delimiter could be
considered.

--
Stuart Palin

Re: Ideas for Ada 200X

[Stuart Palin]

Jeffrey Carter wrote:
> 
> Frank wrote:
> > What about the possibility of commenting several lines like /* ...... */?
> 
> This was considered and explicitly rejected by the original Ada design
> team as being too error-prone.
<snip>

And then they chose '--' as the comment delimiter!  I have
always found this rather odd as it seems to me to be a
potential source of 'difficult to spot' typo errors. 
Consider,

   The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
                 + Meaningful_Ident_3;

[OK Any decent form of testing should find the mistake - but
surely the intention was to reduce the likelihood of errors
getting through compilation]

I agree with the reasons for not allowing block comments,
but perhaps the choice of comment delimiter could be
considered.

--
Stuart Palin

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Stuart Palin wrote:

>   The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
>                 + Meaningful_Ident_3;
>
>[OK Any decent form of testing should find the mistake

Mmh. Probably[0] this is one reason I always have any line ending with
the operator when I have to split lines.

Like:

|The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2 +
|              Meaningful_Ident_3;

So this wouldn't compile. :)


Vinzent.

[0] I don't know. I never thought about it.

Re: Ideas for Ada 200X

[domin]

Gautier Write-only wrote:

> Hey cool! I would add the possibility of nesting several of
> such comments, or not, and why not also the { } and (* *) of Pascal.
> A pragma would allow ending a { by a *) or */, or not, and ignoring
> or not the rest of a line inside a "/*" after a -- (even if it has a */).
> Did you understand ? I mean, it's simple.

The idea is simple to understand, but using it will be complicated.
When I see "--" I know it's a comment, without thinking of any
pragmas, comment ending, nesting etc.
I'm using Ada because It's clear & well defined, not because it's handy.

> And what about including chuncks of code - it would be so cool to
> just insert "c:\...\mytools.inc" at some place instead of these packages.

Unclear like in C. 

> Another idea: make some names implicitly type. E.g. I, J5, InJm
> and so on are always integers, so why declare them ?

In some of my code I used first letter to indicate the type
something like Hungarian notation with T. e.g.
i - integers, names like iCount, iMoney etc
s - string
b - boolean
f - float
It gives the code great clearance, but it would be hard to deal this way
with self-defined types.
-- 
Dominik Zab�otny
________________________________________________________________
"the things you own - own you" (c)papa roach

Re: Ideas for Ada 200X

[Vinzent Hoefler]

domin wrote:

>In some of my code I used first letter to indicate the type
>something like Hungarian notation with T. e.g.
>i - integers, names like iCount, iMoney etc
>s - string
>b - boolean
>f - float
>It gives the code great clearance,

I don't think so. This is poor man's typing and absolutely unnecessary
in Ada.

>but it would be hard to deal this way
>with self-defined types.

Self defined types would be ugly, too.


Vinzent.

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Gautier Write-only wrote:

>Hey cool! I would add the possibility of nesting several of
>such comments, or not, and why not also the { } and (* *) of Pascal.
>[some more weird stuff snipped]

You're not serious, are you?


Vinzent.

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <bb22dr$4r4rv$2@ID-175126.news.dfncis.de>, Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
> Gautier Write-only wrote:
> 
>>Hey cool! I would add the possibility of nesting several of
>>such comments, or not, and why not also the { } and (* *) of Pascal.
>>[some more weird stuff snipped]
> 
> You're not serious, are you?

Of course he is not serious.  There was absolutely no poorly-designed
language commenting convention omitted from that paragraph !

Re: Ideas for Ada 200X

[Ian Wild]

Larry Kilgallen wrote:
> 
>...There was absolutely no poorly-designed
> language commenting convention omitted from that paragraph !


SGML.

<!-- This is a comment,
-- but this is not.
-- Here's another comment...
-- ...and here's an unclosed quote eating the rest of your file
>

Re: Ideas for Ada 200X

[Preben Randhol]

domin wrote:
> Gautier Write-only wrote:
> 
>> Hey cool! I would add the possibility of nesting several of
>> such comments, or not, and why not also the { } and (* *) of Pascal.
>> A pragma would allow ending a { by a *) or */, or not, and ignoring
>> or not the rest of a line inside a "/*" after a -- (even if it has a */).
>> Did you understand ? I mean, it's simple.
> 
> The idea is simple to understand, but using it will be complicated.
> When I see "--" I know it's a comment, without thinking of any
> pragmas, comment ending, nesting etc.
> I'm using Ada because It's clear & well defined, not because it's handy.
> 
>> And what about including chuncks of code - it would be so cool to
>> just insert "c:\...\mytools.inc" at some place instead of these packages.
> 
> Unclear like in C. 
> 
>> Another idea: make some names implicitly type. E.g. I, J5, InJm
>> and so on are always integers, so why declare them ?
> 
> In some of my code I used first letter to indicate the type
> something like Hungarian notation with T. e.g.
> i - integers, names like iCount, iMoney etc
> s - string
> b - boolean
> f - float
> It gives the code great clearance, but it would be hard to deal this way
> with self-defined types.

I think Gautier was ironical when he wrote the above :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
: XML has formalized multiline comments.
: <annotation><documentation>....................</documentation></annotation>

No it hasn't, only the schema fans have aggreed on annotation
and documentation element types in Part 0 of the XSD. I think
annotations in a language are a good idea, but this form, IMO, renders
*non-tool-based* document type design, or document type study,
even less feasable by a human. Humans are much more important
when it comes to data descriptionthan omputing machines, 
aren't they? Domain specifics cannot easily be handled by (essentially)
numbers of bits... Luckily, there is RELAX NG.

: Therefore by analogy, one could create annotation and documentation types in
: Ada. These could be implemented as bounded strings. This would permit the
: compiler and tools like ASIS to have knowledge about the documentation.

How about a pragma like

   function foo(bar: String) return Natural;
   pragma Short_Description(foo, "the number of foos in bar");


georg

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <3ED49304.8D22F012@cfmu.eurocontrol.be>, Ian Wild <ian@cfmu.eurocontrol.be> writes:
> Larry Kilgallen wrote:
>> 
>>...There was absolutely no poorly-designed
>> language commenting convention omitted from that paragraph !
> 
> 
> SGML.
> 
> <!-- This is a comment,
> -- but this is not.
> -- Here's another comment...
> -- ...and here's an unclosed quote eating the rest of your file
>>

I stand corrected.

I am also too lazy to look up the TECO commenting convention,
since as an experienced TECO programmer I know that comments
are counter-cultural :-)

Re: Ideas for Ada 200X

[Marin David Condic]

I think a standard Ada sockets package would be A Good Thing. So would 
something like an XML parser be a good thing. (Make it use the OO 
features Ada has so that it closely matches the XML standard. This is 
the only thing I don't like about the XMLAda package currently floating 
about - it uses discriminated records instead of tagged records, which 
would be the natural way to express what is in the XML standard.)

This is another case where having some sort of Conventional Ada Library 
external of the standard would be A Good Thing. Get things like this 
into the library quickly, gain some experience with use and when they 
stabilize discuss the possibility of including them into the standard.

MDC

chris.danx wrote:
> Preben Randhol wrote:
> 
>>
>> What about sockets?
> 
> 
> Yep, sockets!  Also what about XML parsing facilities and better unicode 
> support?  They'd just be nice, but sockets would be great.
> 


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Stephen Leake]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Stuart Palin wrote:
> 
> >   The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
> >                 + Meaningful_Ident_3;
> >
> >[OK Any decent form of testing should find the mistake

Also any decent editor; the comments are in a different color.

> Mmh. Probably[0] this is one reason I always have any line ending
> with the operator when I have to split lines.
> 
> Like:
> 
> |The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2 +
> |              Meaningful_Ident_3;
> 
> So this wouldn't compile. :)

Good point! Maybe I'll add that to the rationale section of my style guide.

-- 
-- Stephe

Re: Ideas for Ada 200X

[Mirko Aigner]

Mark Lorenzen wrote:
> 
> However, I would appreciate the definition of a standard container
> libray with lists, sets, multisets and so on.
> 
> - Mark

me too !!

Mirko

Re: Ideas for Ada 200X

[Mark Lorenzen]

Marin David Condic <nobody@noplace.com> writes:

> I think a standard Ada sockets package would be A Good Thing. So would
> something like an XML parser be a good thing. (Make it use the OO
> features Ada has so that it closely matches the XML standard. This is
> the only thing I don't like about the XMLAda package currently
> floating about - it uses discriminated records instead of tagged
> records, which would be the natural way to express what is in the XML
> standard.)
> 
> This is another case where having some sort of Conventional Ada
> Library external of the standard would be A Good Thing. Get things
> like this into the library quickly, gain some experience with use and
> when they stabilize discuss the possibility of including them into the
> standard.
> 
> MDC

For inter-process communication mechanisms such as sockets, we already
have the ISO/IEC 14519 standard. It defines a *wealth* of usefull
bindings to a POSIX-like operating system.

However, I would appreciate the definition of a standard container
libray with lists, sets, multisets and so on.

- Mark

Re: Ideas for Ada 200X

[Tarjei T. Jensen]

"Marin David Condic" wrote:
> I think a standard Ada sockets package would be A Good Thing.

It is not A Goo Thing. It is A Neccessity. It must be present for Ada to
survive in general computing.

It is time to decide what a programmer should be able to do with Ada right
out of the box. Also called "How things should work". If this is not done,
Ada will continue to struggle.

Currently the main Ada problem is -- as far as general computing is
concerned -- the standard library. We need to re-focus on what is needed
today and not what was moderately useful in 1984.

I still recommend "The Inmates Are Running The Asylum". Read it and then we
can start discussing the persons and what they need in order to do their
job.

greetings,

Re: Ideas for Ada 200X

[Stuart Palin]

Stephen Leake wrote:
> > Stuart Palin wrote:
> >
> > >   The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
> > >                 + Meaningful_Ident_3;
> > >
> > >[OK Any decent form of testing should find the mistake
> 
> Also any decent editor; the comments are in a different color.

The same could be said for comment blocks, and those still
seem to be frowned upon ;-)

Anyhow, 'a decent editor' falls outside the basic language
definition and I don't think that there is an Ada Reference
Manual that governs what an editor 'must' do.

The ultra paranoid will also start wondering what the
failure modes of this 'intelligent' editor might be (if you
are starting to rely on it as part of your safety-case). 
"Will the reviewer always be using a context sensitive
editor?"  [A big "Hi" to all the legacy VAX guys and gals],
"What if the editor gets configured to display key
information as white on a white background!", "How is the
configuration of the editor controlled?", "What if the
reviewer is colour blind?" etc, etc.

Although this is a deliberately extreme view, I believe
there are documented cases of instances where "What you see
is NOT what you've got" leading to problems in a system
(though I think these might have been in more complex
graphic based editors).

In all it comes back to trying to patch up the original
decision (of all the compound delimiters that could have
been chosen, why that one) - and that is very unlikely to
lead to a satisfactory solution.
--
Stuart Palin

RE: Ideas for Ada 200X

[Robert C. Leif]

As much as I like XML, the complete linkage to XML should NOT be included in
Ada 200X. A top level generic could be included in Interfaces. The reason
for this is the instantiation of a generic can have child libraries. This
would permit revision of the detailed parts of the interface durring the
inevitable evolution of XML.
Bob Leif 


-----Original Message-----
From: Marin David Condic [mailto:nobody@noplace.com] 
Sent: Wednesday, May 28, 2003 5:19 AM
To: comp.lang.ada@ada.eu.org

I think a standard Ada sockets package would be A Good Thing. So would
something like an XML parser be a good thing. (Make it use the OO features
Ada has so that it closely matches the XML standard. This is the only thing
I don't like about the XMLAda package currently floating about - it uses
discriminated records instead of tagged records, which would be the natural
way to express what is in the XML standard.)

This is another case where having some sort of Conventional Ada Library
external of the standard would be A Good Thing. Get things like this into
the library quickly, gain some experience with use and when they stabilize
discuss the possibility of including them into the standard.

MDC

chris.danx wrote:
> Preben Randhol wrote:
> 
>>
>> What about sockets?
> 
> 
> Yep, sockets!  Also what about XML parsing facilities and better 
> unicode support?  They'd just be nice, but sockets would be great.
> 


--
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

RE: Ideas for Ada 200X

[Robert C. Leif]

Bounded strings already exist in Ada and do not require any changes to the
standard. If necessary, a selected group of comment types can be included in
an annex; or better yet, the standard can provide a URL for suggested items.

An XML schema for Ada would be the first step for using conventional
document processors to edit both Ada and documentation. It would also
facilitate hyperlinks between the Ada sources and associated documentation.
Bob Leif


-----Original Message-----
From: Georg Bauhaus [mailto:sb463ba@d2-hrz.uni-duisburg.de] 
Sent: Wednesday, May 28, 2003 3:55 AM
To: comp.lang.ada@ada.eu.org

Robert C. Leif <rleif@rleif.com> wrote:
: XML has formalized multiline comments.
:
<annotation><documentation>....................</documentation></annotation>

No it hasn't, only the schema fans have aggreed on annotation and
documentation element types in Part 0 of the XSD. I think annotations in a
language are a good idea, but this form, IMO, renders
*non-tool-based* document type design, or document type study, even less
feasable by a human. Humans are much more important when it comes to data
descriptionthan omputing machines, aren't they? Domain specifics cannot
easily be handled by (essentially) numbers of bits... Luckily, there is
RELAX NG.

: Therefore by analogy, one could create annotation and documentation types
in
: Ada. These could be implemented as bounded strings. This would permit the
: compiler and tools like ASIS to have knowledge about the documentation.

How about a pragma like

   function foo(bar: String) return Natural;
   pragma Short_Description(foo, "the number of foos in bar");


georg

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> "Marin David Condic" wrote:
> 
>>I think a standard Ada sockets package would be A Good Thing.
> 
> 
> It is not A Goo Thing. It is A Neccessity. It must be present for Ada to
> survive in general computing.

I found it interesting that Windows XP (I think), finally now supports
the Berkeley Sockets interface, rather than the terrible winsock
interface of the past.

It would be interesting to know whether they did it because porting
PD/GPL code was a pain for "them", or whether this was seen more as
a progressive thing (more likely, customers kept begging them to do it).

I agree that it is probably time for an Ada standard on this ubiquitous
aspect of "general computing" today.

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

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Wesley Groleau wrote:
> Frank wrote:
> 
>> What about the possibility of commenting several lines like /* ...... */?
> 
> Booo !!!!
> Hisss !!!

Growl!!!
Snarl!!!

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

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Alfred Hilscher wrote:
> Stuart Palin schrieb:
>>Jeffrey Carter wrote:
>>>Frank wrote:
>>>
>>>>What about the possibility of commenting several lines like /* ...... */?
>>>
>>>This was considered and explicitly rejected by the original Ada design
>>>team as being too error-prone.
>>
>><snip>
>>
>>And then they chose '--' as the comment delimiter!  I have
>>always found this rather odd as it seems to me to be a
>>potential source of 'difficult to spot' typo errors.
>>Consider,
>>
>>   The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
>>                 + Meaningful_Ident_3;
> 
> 
> 
> Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
> --i;) 

I disagree that it is "urgent". What is your case for urgency here?
 From what I have seen, most people that promote the idea, are just
"typing challenged" (yes I know ++i is different than i++).

Consider this: the Ada95 language is already large and complex. Is
there really enough justification for complicating it with ++i/i++
issues?  Not to meantion that --i may appear like a comment?!?!? ;-)

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

Re: Ideas for Ada 200X

[Alfred Hilscher]

Why mark the beginning/ending of comments? Isn't the compiler
intelligent enough to see what is meant as code and what should be
interpreted as comment ;-)

...
i : integer; Hey compiler don't read this
Dear compiler, I know, you know this is no code ;-) 
i:=0; And this is a commentar, too.
...

-----------------------------------------------------
To send me mail, please replace "Spam" by "Jedermann"
-----------------------------------------------------



Gautier Write-only schrieb:
> 
> Frank:
> 
> > What about the possibility of commenting several lines like /* ...... */?
> 
> Hey cool! I would add the possibility of nesting several of
> such comments, or not, and why not also the { } and (* *) of Pascal.
> A pragma would allow ending a { by a *) or */, or not, and ignoring
> or not the rest of a line inside a "/*" after a -- (even if it has a */).
> Did you understand ? I mean, it's simple.
> And what about including chuncks of code - it would be so cool to
> just insert "c:\...\mytools.inc" at some place instead of these packages.
> Another idea: make some names implicitly type. E.g. I, J5, InJm
> and so on are always integers, so why declare them ?
> ________________________________________________________
> Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm
> 
> NB: For a direct answer, e-mail address on the Web site!

Re: Ideas for Ada 200X

[Alfred Hilscher]

Stuart Palin schrieb:
> 
> Jeffrey Carter wrote:
> >
> > Frank wrote:
> > > What about the possibility of commenting several lines like /* ...... */?
> >
> > This was considered and explicitly rejected by the original Ada design
> > team as being too error-prone.
> <snip>
> 
> And then they chose '--' as the comment delimiter!  I have
> always found this rather odd as it seems to me to be a
> potential source of 'difficult to spot' typo errors.
> Consider,
> 
>    The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
>                  + Meaningful_Ident_3;


Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
--i;) 

-----------------------------------------------------
To send me mail, please replace "Spam" by "Jedermann"
-----------------------------------------------------

Re: Ideas for Ada 200X

[Robert A Duff]

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

> I disagree that it is "urgent". What is your case for urgency here?
>  From what I have seen, most people that promote the idea, are just
> "typing challenged" (yes I know ++i is different than i++).

Well, I like the idea of an increment operation, and my reasoning has
nothing to do with typing.  The problem is code duplication: you have to
write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
could be a complicated name, so the reader has to careful compare the
text, and also worry about whether the name has side effects.

> Consider this: the Ada95 language is already large and complex. Is
> there really enough justification for complicating it with ++i/i++
> issues?  Not to meantion that --i may appear like a comment?!?!? ;-)

Of course, if Ada had such a thing, it shouldn't be called "--".
If I were the boss, it would be called Incr and Decr.  They would be
procedures, not functions, because I don't like to encourage that sort
of side effect in the middle of expressions.  So in that regard, it
would be different from C's ++ and --.  There's no pre-increment
vs. post-increment issue.

Note that an earlier version of Ada 9X allowed untagged class-wide
types.  That feature, plus giving a true name to root_integer, would
have allowed such things to be written *in the language*:

    procedure Incr(X: in out Root_Integer'Class; By: Root_Integer'Class);

    Incr(A[I].X);
    Incr(A[I].X, By => 2);

Of course, you can define such a procedure in Ada 95, but you have to do
it for every integer type, and it's just not worth the trouble.  If you
could do it once, for all integer types, it would be worth it.

- Bob

Re: Ideas for Ada 200X (Ada.Sockets)

[Larry Kilgallen]

In article <3ED4EB4E.6050108@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> I agree that it is probably time for an Ada standard on this ubiquitous
> aspect of "general computing" today.

Standard, as in required of all compilers ?

That would be totally bogus in some embedded environments.

Re: Ideas for Ada 200X

[Marin David Condic]

Well, getting a "Necessity" is "A Good Thing." ;-)

Perhaps we're in violent agreement. I've argued here in the past that 
getting some kind of "Conventional" library of stuff is highly important 
to Ada. Without it, developers look at things like Java and MSVC++ and 
say "I don't care if Ada is theoretically better. I get huge leverage 
using Language X and that gets me to market quicker..." Hence, as you 
observe, without some reasonably extensive library, Ada can continue to 
remain in the shadows.

I have suggested that the vested interests in Ada (compiler vendors, 
SIGAda and any big-time users) charter some group to come up with a 
library that would be agreed upon as "The Conventional Ada Library" and 
make a reference implementation to be distributed with all compilers. It 
would need to be easily updated and should cover a wide range of 
interests (Data structures, networking, OS interfacing, math, business, 
graphics, GUIs, whatever. Its easy to make a list and prioritize.) So 
far, aside from a few fellow zealots and gadflies, there doesn't seem to 
be much noise comimg from the players who would matter. Hence, I assume 
that without much interest or support from the key participants, Ada 
will continue to lack a "Conventional Ada Library" for some time to come 
and numerous projects will continue to go to Java and MSVC++.

MDC


Tarjei T. Jensen wrote:
> "Marin David Condic" wrote:
> 
>>I think a standard Ada sockets package would be A Good Thing.
> 
> 
> It is not A Goo Thing. It is A Neccessity. It must be present for Ada to
> survive in general computing.
> 
> It is time to decide what a programmer should be able to do with Ada right
> out of the box. Also called "How things should work". If this is not done,
> Ada will continue to struggle.
> 
> Currently the main Ada problem is -- as far as general computing is
> concerned -- the standard library. We need to re-focus on what is needed
> today and not what was moderately useful in 1984.
> 
> I still recommend "The Inmates Are Running The Asylum". Read it and then we
> can start discussing the persons and what they need in order to do their
> job.


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X (Ada.Sockets)

[Jano]

Larry Kilgallen dice...
> In article <3ED4EB4E.6050108@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
> > I agree that it is probably time for an Ada standard on this ubiquitous
> > aspect of "general computing" today.
> 
> Standard, as in required of all compilers ?
> 
> That would be totally bogus in some embedded environments.

And as an annex?

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Robert A Duff wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>> I disagree that it is "urgent". What is your case for urgency here?
>>  From what I have seen, most people that promote the idea, are just
>> "typing challenged" (yes I know ++i is different than i++).
>
> Well, I like the idea of an increment operation, and my reasoning has
> nothing to do with typing.  The problem is code duplication: you have to
> write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
> could be a complicated name, so the reader has to careful compare the
> text, and also worry about whether the name has side effects.

Approach 1:
  generic
     type XT is (<>);
  procedure Inc(x : in out XT);
  procedure Inc(x : in out XT) is
  begin
     x := XT'Succ(x);
  end Inc;

Approach 2:
  declare
     x : XT renames complex.express(ion);
  begin
     x := x + 1;
  end;

> Of course, if Ada had such a thing, it shouldn't be called "--".
> If I were the boss, it would be called Incr and Decr.

Why not 'Succ and 'Pred?

Re: Ideas for Ada 200X

[Pascal Obry]

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

> "typing challenged" (yes I know ++i is different than i++).

No it is not... it is just context dependant ;) Great feature !

Pascal.

-- 

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

Re: Ideas for Ada 200X

[Robert A Duff]

Lutz Donnerhacke <lutz@iks-jena.de> writes:

> * Robert A Duff wrote:
> > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> >> I disagree that it is "urgent". What is your case for urgency here?
> >>  From what I have seen, most people that promote the idea, are just
> >> "typing challenged" (yes I know ++i is different than i++).
> >
> > Well, I like the idea of an increment operation, and my reasoning has
> > nothing to do with typing.  The problem is code duplication: you have to
> > write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
> > could be a complicated name, so the reader has to careful compare the
> > text, and also worry about whether the name has side effects.
> 
> Approach 1:
>   generic
>      type XT is (<>);
>   procedure Inc(x : in out XT);
>   procedure Inc(x : in out XT) is
>   begin
>      x := XT'Succ(x);
>   end Inc;

Yuck.  This is the sort of thing that makes C programmers laugh at Ada!
You're telling me that to increment a variable I have to instantiate a
generic.  The verbosity simply is not worth it.

> Approach 2:
>   declare
>      x : XT renames complex.express(ion);
>   begin
>      x := x + 1;
>   end;

Yuck again.  Five lines of code to do an increment?!

I'm not complaining about typing it in, I'm complaining about having to
read a whole lot of code that doesn't do much of anything.

> > Of course, if Ada had such a thing, it shouldn't be called "--".
> > If I were the boss, it would be called Incr and Decr.
> 
> Why not 'Succ and 'Pred?

The existing 'Succ and 'Pred are functions, and require writing the
variable name twice, which is the problem.  We could define attributes
that increment, but then 'Succ and 'Pred would be inappropriate names.
You want a verb, like "increment".

- Bob

Re: Ideas for Ada 200X (Ada.Sockets)

[chris.danx]

Larry Kilgallen wrote:

> Standard, as in required of all compilers ?
> 
> That would be totally bogus in some embedded environments.

Can't you say "the provision of sockets is compulsory, except for 
environments where such provision makes no sense"?  i.e. it's not 
optional for compilers on networked systems, but not mandatory on 
embedded targets?

Re: Ideas for Ada 200X

[chris.danx]

Robert C. Leif wrote:
> As much as I like XML, the complete linkage to XML should NOT be included in
> Ada 200X. A top level generic could be included in Interfaces. The reason
> for this is the instantiation of a generic can have child libraries. This
> would permit revision of the detailed parts of the interface durring the
> inevitable evolution of XML.

Good point.  I hadn't thought about XML and its supporting technologies 
evolution.

Re: Ideas for Ada 200X (Ada.Sockets)

[Larry Kilgallen]

In article <MPG.193f19de3e9385698970d@News.CIS.DFN.DE>, Jano <nono@celes.unizar.es> writes:
> Larry Kilgallen dice...
>> In article <3ED4EB4E.6050108@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>> 
>> > I agree that it is probably time for an Ada standard on this ubiquitous
>> > aspect of "general computing" today.
>> 
>> Standard, as in required of all compilers ?
>> 
>> That would be totally bogus in some embedded environments.
> 
> And as an annex?

Having a TCP/IP Annex would be a bit worse than Marin's library proposal,
but not harmful to those without TCP/IP needs.

Remember that other networking mechanisms may not be suited to what
serves TCP/IP well.

Re: Ideas for Ada 200X (Ada.Sockets)

[Martin Dowie]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:S9qicyCF6aHW@eisner.encompasserve.org...
> In article <3ED4EB4E.6050108@cogeco.ca>, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> writes:
>
> > I agree that it is probably time for an Ada standard on this ubiquitous
> > aspect of "general computing" today.
>
> Standard, as in required of all compilers ?
>
> That would be totally bogus in some embedded environments.

Not necessarily - we use DY4 COTS boards for our embedded
boxes. I can't imagine not using sockets with them (though granted
they are not used in flight). Even systems-on-a-chip have tcp/ip
stacks these days. May even be useful when developing that smart-
toaster :-)

Re: Ideas for Ada 200X

[Martin Dowie]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccof1msy08.fsf@shell01.TheWorld.com...
> > Approach 2:
> >   declare
> >      x : XT renames complex.express(ion);
> >   begin
> >      x := x + 1;
> >   end;
>
> Yuck again.  Five lines of code to do an increment?!
>
> I'm not complaining about typing it in, I'm complaining about having to
> read a whole lot of code that doesn't do much of anything.

And doesn't work if there is a variant record (I think...)

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <3ED4EB4E.6050108@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
>>I agree that it is probably time for an Ada standard on this ubiquitous
>>aspect of "general computing" today.
> 
> Standard, as in required of all compilers ?
> 
> That would be totally bogus in some embedded environments.

There is a difficulty there. However, Ada.Text_IO is not necessarily
something that I would say all embedded environments would want or
need (for example, I doubt that a VCR would support a concept of "Files").
Yet it is there. Not all embedded devices care about dates and times.
Yet Ada.Calendar is there.

Despite that, I do see your point.

But I think that this bites at the root of the problem with Ada's
lack of popularity.

If everyone/most insists that the only "standard" components are those for
embedded systems, then Ada is truly doomed from the general purpose
computing sense. This is perhaps why the Ada.Calendar facilities never
foresaw the need to calculate the day of the week(!)

Yet, most people on this group seem to be interested in promoting the
language in a more general sense (not just for embedded systems).

A more balanced approach may to be to insist on two levels of conformance.
One for embedded systems where critical safety is required (SPARC?). And
another level of conformance for the language and libraries as a whole,
for general purpose computing.  Optional annexes is another way, but at
least it is _standardized_ when present.

I think the approach that "no don't provide sockets because embedded
doesn't always require it", is totally the wrong approach in the larger
scheme of things.

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

Re: Ideas for Ada 200X (Ada.Sockets)

[Robert A Duff]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> Larry Kilgallen wrote:
> 
> > Standard, as in required of all compilers ?
> > That would be totally bogus in some embedded environments.
> 
> Can't you say "the provision of sockets is compulsory, except for
> environments where such provision makes no sense"?  i.e. it's not
> optional for compilers on networked systems, but not mandatory on
> embedded targets?

It seems better to say "here's the standard way to do it, but it's
optional".  That's what the SN Annexes are for.  Then implementers
can choose whether to implement it based on the needs of their
customers.  After all, the purpose of standards is to encourage
uniformity -- not to encourage implementers to provide functionality
to their customers (the market is supposed to do the latter).

To say "compulsory except where it doesn't make sense" gets standards
bodies embroiled in judging what "makes sense" in various environments,
and that's not what they are good at.

Of course, there's some of that anyway -- *every* feature in the
standard is optional if it's impossible or impractical to implement
in a given environment, and validation authorities sometimes need
to make judgement calls.  For example, one of our (SofCheck's) embedded
Ada targets does not support file I/O, because our customers don't want
it -- their chips are not attached to disk drives.  That did not prevent
validation.

Another alternative is just to have a de-facto standard for sockets.

I use the GNAT sockets packages, even when I'm using non-GNAT compilers,
and that seems to work OK for me.

- Bob

Re: Ideas for Ada 200X

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <3ED49304.8D22F012@cfmu.eurocontrol.be>, Ian Wild <ian@cfmu.eurocontrol.be> writes:
> > Larry Kilgallen wrote:
> >> 
> >>...There was absolutely no poorly-designed
> >> language commenting convention omitted from that paragraph !
> > 
> > SGML.
> > 
> > <!-- This is a comment,
> > -- but this is not.
> > -- Here's another comment...
> > -- ...and here's an unclosed quote eating the rest of your file
> >>

Could somebody please explain the above?  (I don't know SGML.)

> I stand corrected.

;-)

Here's an even worse commenting convention: the one in Unix 'make'.
A comment goes from # to end-of-line (OK so far).  I had a make file
written in GNU make, and it had something like:

    MACRO=<expand-wildcard *.ada>

or something like that, where "<expand-wildcard *.ada>" is some
GNU-make-supported thing for getting a list of files in the current
directory.  I can't remember the syntax -- some arcane incantation, no
doubt.

Anyway, once in a while, cvs puts a file in the directory called
.#mumble, so the MACRO would expand to something with a # in it, and the
rest of the macro would be "commented out".  I wasted an hour debugging
this!  And Unix doesn't help by having the "ls" command fail to display
files starting with "." (grr).

To have comment processing happen after macro expansion would be like an
Ada program that happens to read in the text "--" from a file (at run
time), and having that somehow cause the rest of the input file to be
ignored!

- Bob

Re: Ideas for Ada 200X (Ada.Sockets)

[Robert A Duff]

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

> If everyone/most insists that the only "standard" components are those for
> embedded systems, then Ada is truly doomed from the general purpose
> computing sense.

Right, and people need to learn a language in a "general purpose"
environment before they start writing hard real-time embedded systems in
it.  To be successful in the embedded market, a language needs to be
useful for normal desk-top applications, too.

- Bob

Re: Ideas for Ada 200X

[Hyman Rosen]

Robert A Duff wrote:
 > If you could do it once, for all integer types, it would be worth it.

Aren't folks looking into some form of automatically instantiated
generics for Ada0Y? If you had that, then you could just do it once.
Or rather, if this feature is added to Ada, it should be in a form
that would allow for this.

Re: Ideas for Ada 200X

[Jeffrey Carter]

Stuart Palin wrote:
> 
> And then they chose '--' as the comment delimiter!  I have
> always found this rather odd as it seems to me to be a
> potential source of 'difficult to spot' typo errors. 
> Consider,
> 
>    The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
>                  + Meaningful_Ident_3;

This is why I always end a line in such a statement with an operator!

"--" was chosen because it is (was?) the standard way to represent an 
em-dash with a typewriter. In the good old days when Ada was originally 
being designed it was fairly common to write code on paper by hand and 
put periferal comments to the right after a dash, so that may be why 
this was chosen.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: Ideas for Ada 200X

[Wesley Groleau]

> Well, I like the idea of an increment operation, and my reasoning has
> nothing to do with typing.  The problem is code duplication: you have to
> write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
> could be a complicated name, so the reader has to careful compare the
> text, and also worry about whether the name has side effects.

What kind of entity is able to have side-effects AND to be incremented?

Re: Ideas for Ada 200X

[Steve]

"Alfred Hilscher" <Spam@alfred-hilscher.de> wrote in message
news:3ED4F3FD.A0EF7079@alfred-hilscher.de...
>
>
[snip]
>
>
> Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
> --i;)

Personally I don't see much value in the "++" and "--" operators... but I do
like the +=, -=, *=, /= operators.

Occasionally I run into code that looks something like:

production_total( total_class ).shift( shift_index ) :=
  production_total( total_class ).shift( shift_index ) + count;

That would read a lot cleaner as:

  production_total( total_class ).shift( shift_index ) += count;

Yeah, you can write a function to do the same thing, but it is more work
than just writing the code in the first form.

BTW: It also turns that simple case of:

  i := i + 1;
to
  i += 1;

In my experience in C/C++ programming I have never encountered bugs due to
the use of these operators.  Your mileage may vary.

Steve
(The Duck)

> -----------------------------------------------------
> To send me mail, please replace "Spam" by "Jedermann"
> -----------------------------------------------------

Re: Ideas for Ada 200X

[Wesley Groleau]

 > In some of my code I used first letter to indicate the type
 > something like Hungarian notation with T. e.g.
 > i - integers, names like iCount, iMoney etc
 > s - string
 > b - boolean
 > f - float
 > It gives the code great clearance, but it would be hard to deal this way
 > with self-defined types.

This is just as offensive as HTML newsposts.
(Or stupid newsreaders that answer posts in HTML when I don't want them to!)

Anyway, you discover a variable needs to be a float instead of an integer,
so you have to search and replace through all the clients?
Ada is a high-order language--that means it should express the abstraction,
NOT the implementation.

Re: Ideas for Ada 200X

[Martin Krischik]

Alfred Hilscher wrote:

> Stuart Palin schrieb:
> Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
> --i;)

No. it Ada does not. Thats what optimizers are for. That C has such
operators only shows how capable K&R had been as compiler designers and
developers.

With Regards

Martin

PS: For those who don't understand sarcasm: Im my opinion K&R hadn't been
very capable at all.

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

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Note that an earlier version of Ada 9X allowed untagged class-wide
> types.  That feature, plus giving a true name to root_integer, would
> have allowed such things to be written *in the language*:
>
>     procedure Incr(X: in out Root_Integer'Class; By: Root_Integer'Class);
> 
>     Incr(A[I].X);
>     Incr(A[I].X, By => 2);
> 
> Of course, you can define such a procedure in Ada 95, but you have to do
> it for every integer type, and it's just not worth the trouble.  If you
> could do it once, for all integer types, it would be worth it.

So, let's make all types "tagged"! I think it could be done little or no 
compatibility impact.

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

Re: Ideas for Ada 200X

[Alfred Hilscher]

Sorry, it should be a joke (the --i, because the original poster
suggested a new "comment").

"Warren W. Gay VE3WWG" schrieb:
> 
> Alfred Hilscher wrote:
> > Stuart Palin schrieb:
> >>Jeffrey Carter wrote:
> >>>Frank wrote:
> >>>
> >>>>What about the possibility of commenting several lines like /* ...... */?
> >>>
> >>>This was considered and explicitly rejected by the original Ada design
> >>>team as being too error-prone.
> >>
> >><snip>
> >>
> >>And then they chose '--' as the comment delimiter!  I have
> >>always found this rather odd as it seems to me to be a
> >>potential source of 'difficult to spot' typo errors.
> >>Consider,
> >>
> >>   The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
> >>                 + Meaningful_Ident_3;
> >
> >
> >
> > Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
> > --i;)
> 
> I disagree that it is "urgent". What is your case for urgency here?
>  From what I have seen, most people that promote the idea, are just
> "typing challenged" (yes I know ++i is different than i++).
> 
> Consider this: the Ada95 language is already large and complex. Is
> there really enough justification for complicating it with ++i/i++
> issues?  Not to meantion that --i may appear like a comment?!?!? ;-)
> 
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

Larry Kilgallen wrote:
> Standard, as in required of all compilers ?

You should notice that the previous two posters used the term "general
computing". "general computing" is not an embedded environment. General
computing means environments like MS Windows, VMS, various Unixes, etc.

Regardless: A standard interface for various services is needed.

greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

Robert A Duff  wrote:
> It seems better to say "here's the standard way to do it, but it's
> optional".  That's what the SN Annexes are for.  Then implementers
> can choose whether to implement it based on the needs of their
> customers.  After all, the purpose of standards is to encourage
> uniformity -- not to encourage implementers to provide functionality
> to their customers (the market is supposed to do the latter).

That is what is needed.

> Another alternative is just to have a de-facto standard for sockets.
>
> I use the GNAT sockets packages, even when I'm using non-GNAT compilers,
> and that seems to work OK for me.

If everybody used that, it would be perfectly OK. The point is that there
must be a reasonably sensible and agreed standard.

One could also add a layer to the socket library in order to simplify socket
programming for ordinary mortals. e.g. add a tcp client and server library.
This is not supposed to be something fancy; just something that hides the
ugly stuff and works reasonably well and with no surprises.

How simple should such a library be? Just four procedures: open_tcp_client,
open_tcp_server, read_tcp, write_tcp. That's it. The latter should ideally
be just aliases for more general read and write procedures/functions.

Regardless: There is an urgent need to decide what should be easy to do in
Ada in a general computing environment.

Som suggestions for improvement:
- strings. Let's get at least one type of strings that works like strings
are supposed to do.
- standardized file I/O library (at least a superset of text_io). This is
the stuff that breaks programming languages.
- a *simple* console I/O package (text terminal). These days one can assume
at least a vt100. Preferably something that works seamlessly with both 7 and
8 bit escape sequences.
- standardized socket library. Ideally two layers; raw - C-like and a simple
binding.

In addition one could create soft standards which includes freely available
software. e.g. AWS, GNADE

The softness might just be that the package is documented and examples
provided.

greetings,



greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

Warren W. Gay wrote:
> I think the approach that "no don't provide sockets because embedded
> doesn't always require it", is totally the wrong approach in the larger
> scheme of things.

That attitude got us Ada95, but it did nothing to promote Ada to the general
public.


greetings,

Re: Ideas for Ada 200X

[Tarjei T. Jensen]

Marin David Condic  wrote:
> I have suggested that the vested interests in Ada (compiler vendors,
> SIGAda and any big-time users) charter some group to come up with a
> library that would be agreed upon as "The Conventional Ada Library" and
> make a reference implementation to be distributed with all compilers. It
> would need to be easily updated and should cover a wide range of
> interests (Data structures, networking, OS interfacing, math, business,
> graphics, GUIs, whatever. Its easy to make a list and prioritize.)

That is a perfectly good plan.

BTW I think that the idea proposed by Tucker Taft in a presentation on
concentrating on developing the language as a server programming language is
an excellent idea. It should be easier to get a concensus on what is needed.

> So
> far, aside from a few fellow zealots and gadflies, there doesn't seem to
> be much noise comimg from the players who would matter. Hence, I assume
> that without much interest or support from the key participants, Ada
> will continue to lack a "Conventional Ada Library" for some time to come
> and numerous projects will continue to go to Java and MSVC++.

That is what landed Ada95 in trouble as far as popularity is concerned last
time.

greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> Warren W. Gay wrote:
> 
>>I think the approach that "no don't provide sockets because embedded
>>doesn't always require it", is totally the wrong approach in the larger
>>scheme of things.
> 
> That attitude got us Ada95, but it did nothing to promote Ada to the general
> public.
> 
> greetings,

Looking backwards to '95, I think it can be fairly stated that things
were a bit different than today. For one, Linux was in its infancy,
and Windoze was still discovering the inet. GNAT was still in its
infancy. I believe has done a much to promote the "general purpose"
usefulness of Ada. This is certainly true at least of the open sourced
community (which may be a small subset of Ada users worldwide).

Now Linux is maturing, as is the GPL GNAT, and people are applying
Ada to more applications, where compiler cost would have been a barrier
in the past.  The compiler size is less of a factor now. Running GNAT
on a laptop with a 1.x Ghz CPU is truly refreshing. The bulk of the
compiler becomes less of an issue with each passing year.

If Ada95/Ada0X is ever going to become ubiquitous, it must overcome
many many barriers, and having general purpose facilities (like sockets)
is very important. </SOAP-BOX>

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

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> Robert A Duff  wrote:
...
> One could also add a layer to the socket library in order to simplify socket
> programming for ordinary mortals. e.g. add a tcp client and server library.
> This is not supposed to be something fancy; just something that hides the
> ugly stuff and works reasonably well and with no surprises.
> 
> How simple should such a library be? Just four procedures: open_tcp_client,
> open_tcp_server, read_tcp, write_tcp. That's it. The latter should ideally
> be just aliases for more general read and write procedures/functions.

In fairness, there is more to sockets than just that. Consider:

- What about UNIX sockets?
- On UNIX sockets:
    - what about sending/receiving user credentials?
    - what about sending/receiving open file descriptors?
    - what about other out-of-band data?
- What are the name services APIs provided?
- How are name services choices and errors handled?
- Do you support Ada streams on the socket(s)?
- Are Ada streams buffered for better performance (note earlier threads
   about the abysmal performance of some T'Write() operations).
- Does Ada streams I/O convert to endian neutral network formats
   (a la XDR routines for RPC?)
- What about UDP and lower level IP services?
- What about raw socket services?
- What about authentication?  SSL? Kerberos?  <This is a biggy>

I am not saying it shouldn't be done, but I think you've overly
trivialized it. 8-)

I think most people would settle for a good TCP
level API for applications. But this would need to include naming
services at a minimum, and ideally Ada streams with
endian neutral I/O to be truly useful.

It would also be useful for Ada0X to include some extensions to the
distributed annex to consider standard ways to authenticate. This is
perhaps one of the biggest thorn patches for distributed computing in
hostile environments. I would love to see SSL (perhaps) as a builtin
selectable option for the channel filter for example.

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

Re: Ideas for Ada 200X (Ada.Sockets)

[tmoran]

>One could also add a layer to the socket library in order to simplify socket
>programming for ordinary mortals. e.g. add a tcp client and server library.
>...
>How simple should such a library be? Just four procedures: open_tcp_client,
>open_tcp_server, read_tcp, write_tcp. That's it. The latter should ideally
  I sent a socket library to www.adapower.com recently, and had previously
posted there a SMTP and HTTP client and HTTP server (the latter using
Claw, but the change being trivial).  A call to Open and one to Write
is the minimum needed for a client (initialization, closing, and
finalization being handled internally by controlled types).  A server
needs Open and Greet (accept an incoming client and hand it off to
a worker).

Re: Ideas for Ada 200X

[Robert A Duff]

Wesley Groleau <wesgroleau@despammed.com> writes:

> > Well, I like the idea of an increment operation, and my reasoning has
> > nothing to do with typing.  The problem is code duplication: you have to
> > write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
> > could be a complicated name, so the reader has to careful compare the
> > text, and also worry about whether the name has side effects.
> 
> What kind of entity is able to have side-effects AND to be incremented?

I'm thinking of something like:

Some_Array[Get_Next_Position] := Some_Array[Get_Next_Position] + 1;

where Get_Next_Position is a function that increments the current
position and returns it.  You can say "so don't do that", but it's
allowed in Ada, and when I read the code, I have to think about whether
this sort of thing is going on.

- Bob

Re: Ideas for Ada 200X

[Robert A Duff]

Wesley Groleau <wesgroleau@despammed.com> writes:

>  > In some of my code I used first letter to indicate the type
>  > something like Hungarian notation with T. e.g.
>  > i - integers, names like iCount, iMoney etc
>  > s - string
>  > b - boolean
>  > f - float
>  > It gives the code great clearance, but it would be hard to deal this way
>  > with self-defined types.
> 
> This is just as offensive as HTML newsposts.
> (Or stupid newsreaders that answer posts in HTML when I don't want them to!)
> 
> Anyway, you discover a variable needs to be a float instead of an integer,
> so you have to search and replace through all the clients?
> Ada is a high-order language--that means it should express the abstraction,
> NOT the implementation.

More importantly, a typical Ada program has hundreds of integer types,
so putting "i" at the front of variable names doesn't tell you much of
anything interesting.

- Bob

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Robert A Duff wrote:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>In article <3ED49304.8D22F012@cfmu.eurocontrol.be>, Ian Wild <ian@cfmu.eurocontrol.be> writes:
>>>Larry Kilgallen wrote:
>>>>...There was absolutely no poorly-designed
>>>>language commenting convention omitted from that paragraph !
>>>
>>>SGML.
...
> Here's an even worse commenting convention: the one in Unix 'make'.
> A comment goes from # to end-of-line (OK so far).  I had a make file
> written in GNU make, and it had something like:
> 
>     MACRO=<expand-wildcard *.ada>
> 
> or something like that, where "<expand-wildcard *.ada>" is some
> GNU-make-supported thing for getting a list of files in the current
> directory.  I can't remember the syntax -- some arcane incantation, no
> doubt.
> 
> Anyway, once in a while, cvs puts a file in the directory called
> ..#mumble, so the MACRO would expand to something with a # in it, and the
> rest of the macro would be "commented out".  I wasted an hour debugging
> this!  And Unix doesn't help by having the "ls" command fail to display
> files starting with "." (grr).
> 
> To have comment processing happen after macro expansion would be like an
> Ada program that happens to read in the text "--" from a file (at run
> time), and having that somehow cause the rest of the input file to be
> ignored!
> 
> - Bob

(!!)  I think I have run into this, but can't recall the details (it
       wasn't with ada, but some o.s. package that used all the geewhiz
       gmake features).  I probably deleted the directory and then
       checked out the code again, and then unwittingly fixed it.

I'll have to remember that one!  Very sneaky indeed.

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

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Alfred Hilscher wrote:
> Sorry, it should be a joke (the --i, because the original poster
> suggested a new "comment").
> "Warren W. Gay VE3WWG" schrieb:
>>Alfred Hilscher wrote:
>>>Stuart Palin schrieb:
>>>>Jeffrey Carter wrote:
>>>>>Frank wrote:
>>>>>>What about the possibility of commenting several lines like /* ...... */?
>>>>>
>>>>>This was considered and explicitly rejected by the original Ada design
>>>>>team as being too error-prone.
>>>><snip>
>>>>
>>>>And then they chose '--' as the comment delimiter!  I have
>>>>always found this rather odd as it seems to me to be a
>>>>potential source of 'difficult to spot' typo errors.
>>>>Consider,
>>>>
>>>>  The_Result := Meaningful_Ident_1 -- Meaningful_Ident_2
>>>>                + Meaningful_Ident_3;
>>>
>>>
>>>
>>>Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
>>>--i;)
>>
>>I disagree that it is "urgent". What is your case for urgency here?
>> From what I have seen, most people that promote the idea, are just
>>"typing challenged" (yes I know ++i is different than i++).
>>
>>Consider this: the Ada95 language is already large and complex. Is
>>there really enough justification for complicating it with ++i/i++
>>issues?  Not to meantion that --i may appear like a comment?!?!? ;-)

Let's just --idea here. I don't think it fits the "Ada way". ;-)

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

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Steve wrote:
> "Alfred Hilscher" <Spam@alfred-hilscher.de> wrote in message
> news:3ED4F3FD.A0EF7079@alfred-hilscher.de...
> [snip]
> 
>>Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
>>--i;)
> Personally I don't see much value in the "++" and "--" operators... but I do
> like the +=, -=, *=, /= operators.
> 
> Occasionally I run into code that looks something like:
> 
> production_total( total_class ).shift( shift_index ) :=
>   production_total( total_class ).shift( shift_index ) + count;
> 
> That would read a lot cleaner as:
> 
>   production_total( total_class ).shift( shift_index ) += count;
> 
> Yeah, you can write a function to do the same thing, but it is more work
> than just writing the code in the first form.
> 
> BTW: It also turns that simple case of:
> 
>   i := i + 1;
> to
>   i += 1;
> 
> In my experience in C/C++ programming I have never encountered bugs due to
> the use of these operators.  Your mileage may vary.
> 
> Steve
> (The Duck)

I've tried both sides (more on the C/C++ side). I cannot honestly say
that I miss those operators in Ada. I can say, that the compactness
of C and C++ works against it's readability in a big way.  I would
not trade readability for ++i convenience.

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

Re: Ideas for Ada 200X

[Hyman Rosen]

Martin Krischik wrote:
 > Thats what optimizers are for. Im my opinion K&R hadn't been
> very capable at all.

Optimizers are for denying programmers the ability to express
their intent? Even in COBOL you could say 'ADD 1 TO I.' It
sounds like Ada is one of those stores in Lake Wobegone -
     If We Don't Have It, You Don't Need It.

Re: Ideas for Ada 200X (CONSOLE_IO)

[Richard Riehle]

"Tarjei T. Jensen" wrote:

> - a *simple* console I/O package (text terminal). These days one can assume
> at least a vt100. Preferably something that works seamlessly with both 7 and
> 8 bit escape sequences.

I realize it is MS-specific, at present, but the Jerry Van Dijk Console_IO
package turns out to be pretty good.   My students at NPS use if for some
of their programming problems.

Richard Riehle

Re: Ideas for Ada 200X

[Richard Riehle]

Marin David Condic wrote:

> This is another case where having some sort of Conventional Ada Library
> external of the standard would be A Good Thing. Get things like this
> into the library quickly, gain some experience with use and when they
> stabilize discuss the possibility of including them into the standard.

The two most important features of Java are the libraries and the JVM.
The language is rather pedestrian and of would be of little consequence
if it were not for the libraries.

We have never been able to agree on the format of nor the functionality
of standard libraries for Ada (with the exception of a conservative few
that made it into the Ada 95 Annexes).   As a  consequence, newcomers
find themselves prowling around the Web to locate something they can
use  for graphics, GUI's, data structures, etc.  Java has a corporate sponsor
and is not an ISO standard (nor will it be for a while).   C++ has the
STL,  but it interfaces  well to MFC and other GUI environments.

Sadly, there is no corporate or governmental sponsor for Ada so most of
the effort is either a "labor of love" (Charles, GWindows, CLAW, etc.),
or produce for a specific need as needed.  It is a big mistake for the DoD
to discontinue funding for Ada since it is still used for a lot of projects.
In fact, some of those organizations that charged off in the direction of
C++ have discovered the folly of that decision.  Unfortunately, instead
of returning to Ada, as they should, they are attempting to use even more
inappropriate tools such as Java, largely because of hype, but also because
of the libraries.

This could be fixed, but it will required money.  Where will that money come
from?  What company with deep pockets is willing to fund Ada?

The recent discussion about JSF developers deciding to use Ada because,
even though it is a better language for the purpose than C, it is not popular
enough, should be a good lesson.  They, in effect, have said, we are picking
the less effective set of tools because more people know how to use
them.  While this is an emminently stupid line of reasoning, it illustrates
the prevailing rationale for language selection.   The availability of good
libaries will not cure anyone of congenital stupidity, but it might make some
potential users of Ada more amenable to helping it become more popular.

Richard Riehle

Re: Ideas for Ada 200X

[Mark A. Biggar]

Robert A Duff wrote:
> Wesley Groleau <wesgroleau@despammed.com> writes:
> 
> 
>>>Well, I like the idea of an increment operation, and my reasoning has
>>>nothing to do with typing.  The problem is code duplication: you have to
>>>write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
>>>could be a complicated name, so the reader has to careful compare the
>>>text, and also worry about whether the name has side effects.
>>
>>What kind of entity is able to have side-effects AND to be incremented?
> 
> 
> I'm thinking of something like:
> 
> Some_Array[Get_Next_Position] := Some_Array[Get_Next_Position] + 1;
> 
> where Get_Next_Position is a function that increments the current
> position and returns it.  You can say "so don't do that", but it's
> allowed in Ada, and when I read the code, I have to think about whether
> this sort of thing is going on.

Even that case isn't too bad, but if you have a really long expression
you can always use (using your example):

declare
	x: same_as_Some_Array_element_type
		renames Some_Array[Get_Next_Position];
begin
	x := x + 1;
end;

This of course doesn't work if your expression has side-effects or
contains the exaluation of a non-pure function (like your example).
But note that even the += assignment operator in C++ doesn't work
correctly in that case either.

Re: Ideas for Ada 200X

[Martin Krischik]

Hyman Rosen wrote:

> Martin Krischik wrote:
>  > Thats what optimizers are for. Im my opinion K&R hadn't been
>> very capable at all.
> 
> Optimizers are for denying programmers the ability to express
> their intent? Even in COBOL you could say 'ADD 1 TO I.' It
> sounds like Ada is one of those stores in Lake Wobegone -
>      If We Don't Have It, You Don't Need It.

I use far more C++ then Ada in my live and the "++" and "+=" operator is
somthing I can live without. I := I + 1 expreses my intend just as well. Of
course if one would add a 'Inc Attribute or an "inc" operator (similar to
the "not" operator) then this would be quite Ok by me. But it is syntatic
shugar and not relay needed.

And the point about K&R is that they considered it essential to have a "++"
operator. Not as syntatic shugar but as an essential part of generating
better code.

On the other hand I am missing a lot of Ada features in C++.

With Regards

Martin

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

Re: Ideas for Ada 200X

[Preben Randhol]

Alfred Hilscher wrote:
> 
> Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
> --i;) 

No, this is something it doesn not need.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> 
> Consider this: the Ada95 language is already large and complex. Is

Yes, and it does not need to get into a C++ "beauty" contest. What I
find great is that the language is clear, not ambigiuos (at least not
compared to other languages), well defined syntax. So even if it *is* a
huge language, this is not a problem. I didn't understand why the "Ada
is a huge language" was presented by others as a bad thing, until I
thought that what if C was as large as Adar? In that case I think it
would be a problem, but for Ada's case it is a strength. However we do
not need to make Ada into a huge C by adding a lot of ambigious
syntactic sugar because it makes for better make-up when standing next
to other, at the moment, more popular languages. It is better to iron
out the quirks and make improvements where it matters and to introduce
real and useful additions to the language to keep up with time. However,
I do not think the initial design goals/requirements should be tossed.

I didn't start to like Ada because it looked like C or C++, but because
it made things more clear and safe. That's when the joy came back.

-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Ideas for Ada 200X

[Preben Randhol]

Robert A Duff wrote:
> More importantly, a typical Ada program has hundreds of integer types,
> so putting "i" at the front of variable names doesn't tell you much of
> anything interesting.

And what do you call the variables that has these types:

   type Apple is ...
   type Voltage is ...

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

Richard Riehle wrote:
> The recent discussion about JSF developers deciding to use Ada because,
> even though it is a better language for the purpose than C, it is not popular
> enough, should be a good lesson.  

I take it you meant: JSF developers deciding *not* to use Ada because ?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Russ]

"Steve" <nospam_steved94@attbi.com> wrote in message news:<xIeBa.1017346$3D1.597085@sccrnsc01>...
> "Alfred Hilscher" <Spam@alfred-hilscher.de> wrote in message
> news:3ED4F3FD.A0EF7079@alfred-hilscher.de...
> >
> >
>  [snip]
> >
> >
> > Yeah, but Ada urgently needs some operators like "++" and "--" (i++;
> > --i;)
> 
> Personally I don't see much value in the "++" and "--" operators... but I do
> like the +=, -=, *=, /= operators.

Bingo! Please forget about ++ and --.

> Occasionally I run into code that looks something like:
> 
> production_total( total_class ).shift( shift_index ) :=
>   production_total( total_class ).shift( shift_index ) + count;
> 
> That would read a lot cleaner as:
> 
>   production_total( total_class ).shift( shift_index ) += count;

Couldn't have said it better myself.

And let's not forget that +=, -=, etc. also allow for more efficient
in-place vector/matrix operations because they avoid the need for a
temporary. If you don't understand this, that's OK, but please don't
argue with me because you will be wrong.

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Martin Krischik wrote:

> Hyman Rosen wrote:
> 
>> Martin Krischik wrote:
>>  > Thats what optimizers are for. Im my opinion K&R hadn't been
>>> very capable at all.
>> 
>> Optimizers are for denying programmers the ability to express
>> their intent? Even in COBOL you could say 'ADD 1 TO I.' It
>> sounds like Ada is one of those stores in Lake Wobegone -
>>      If We Don't Have It, You Don't Need It.
> 
> I use far more C++ then Ada in my live and the "++" and "+=" operator is
> somthing I can live without. I := I + 1 expreses my intend just as well.
> Of course if one would add a 'Inc Attribute or an "inc" operator (similar
> to the "not" operator) then this would be quite Ok by me. But it is
> syntatic shugar and not relay needed.

I am not so sure that a compiler would be capable to optimize each possible 
case of X := X @ Y. Especially if all operations in the expression are 
user-defined and types are controlled.

On the other hand, very often in C++ to implement all that ++, +=, *= etc + 
by value vs. by reference variations becomes a heavy burden when an 
abstract type is defined. It is also difficult to ensure that the semantics 
of all operations is compatible.

The outcome is undecided, I would say.

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

Re: Ideas for Ada 200X (Ada.Sockets)

[Dmitry A. Kazakov]

Tarjei T. Jensen wrote:

> - a *simple* console I/O package (text terminal). These days one can
> assume at least a vt100. Preferably something that works seamlessly with
> both 7 and 8 bit escape sequences.

Huh. I tested about 10 different implementations of telnet under Windows. 
None of them properly simulated vt100!

However, your point is valid.

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

Re: Ideas for Ada 200X

[Preben Randhol]

Martin Krischik wrote:

[..]
> somthing I can live without. I := I + 1 expreses my intend just as well. Of
> course if one would add a 'Inc Attribute or an "inc" operator (similar to
> the "not" operator) then this would be quite Ok by me. But it is syntatic
> shugar and not relay needed.

I agree.

[..]

> On the other hand I am missing a lot of Ada features in C++.

... features in C'Inc. You meant? ;-) The pronounciation of C'Inc fits
better too ;-p

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

Warren W. Gay  wrote:
> I am not saying it shouldn't be done, but I think you've overly
> trivialized it. 8-)

No I haven't. I have made something 99,95 percent of Ada ordinary users
could use. Successfully.The issues you raise complicates matters and creates
confusion. It is the stuff you put in a specialized library. It is NOT
something for the unwashed masses.

PLEASE read "The Inmates Are Running The Asylum". Less is more! Focus on
something to do well.


> I think most people would settle for a good TCP
> level API for applications. But this would need to include naming
> services at a minimum, and ideally Ada streams with
> endian neutral I/O to be truly useful.

That is extras!

> It would also be useful for Ada0X to include some extensions to the
> distributed annex to consider standard ways to authenticate. This is
> perhaps one of the biggest thorn patches for distributed computing in
> hostile environments. I would love to see SSL (perhaps) as a builtin
> selectable option for the channel filter for example.

I would not mind having that, but it is still extras.


greetings,

Re: Ideas for Ada 200X (CONSOLE_IO)

[Tarjei T. Jensen]

Richard Riehle wrote:
> I realize it is MS-specific, at present, but the Jerry Van Dijk Console_IO
> package turns out to be pretty good.   My students at NPS use if for some
> of their programming problems.

I think that is a big step in the right direction. I seem to remember that
he did a re-implementation of professor Feldmans console I/O packeage.

But above all: It must be keept simple. It must not be overburden with
special features. It may well be advanced, but keep that from the
programmer.

greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

tmoran@acm.org wrote
>   I sent a socket library to www.adapower.com recently, and had previously
> posted there a SMTP and HTTP client and HTTP server (the latter using
> Claw, but the change being trivial).  A call to Open and one to Write
> is the minimum needed for a client (initialization, closing, and
> finalization being handled internally by controlled types).  A server
> needs Open and Greet (accept an incoming client and hand it off to
> a worker).

Very good! I will look into it.


greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

"Warren W. Gay wrote:
> Looking backwards to '95, I think it can be fairly stated that things
> were a bit different than today. For one, Linux was in its infancy,
> and Windoze was still discovering the inet. GNAT was still in its
> infancy. I believe has done a much to promote the "general purpose"
> usefulness of Ada. This is certainly true at least of the open sourced
> community (which may be a small subset of Ada users worldwide).

Windows discovered the internet before '95. And Linux was even then very
much network focused at the time.

> If Ada95/Ada0X is ever going to become ubiquitous, it must overcome
> many many barriers, and having general purpose facilities (like sockets)
> is very important. </SOAP-BOX>

Agreed.


greetings,

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> So, let's make all types "tagged"! I think it could be done little or no
> compatibility impact.

What about the representation clauses? If you do not use Ada for system
programming, don't try to make Ada200x unusable for this purpose.

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <slrnbdec1h.nq.lutz@taranis.iks-jena.de>, Lutz Donnerhacke <lutz@iks-jena.de> writes:
> * Dmitry A. Kazakov wrote:
>> So, let's make all types "tagged"! I think it could be done little or no
>> compatibility impact.
> 
> What about the representation clauses? If you do not use Ada for system
> programming, don't try to make Ada200x unusable for this purpose.

Let's allow representation clause support for the tags and tagged types !

(That is _not_ a comment in support of making all types tagged.)

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Larry Kilgallen wrote:
> In article <slrnbdec1h.nq.lutz@taranis.iks-jena.de>, Lutz Donnerhacke <lutz@iks-jena.de> writes:
>> * Dmitry A. Kazakov wrote:
>>> So, let's make all types "tagged"! I think it could be done little or no
>>> compatibility impact.
>>
>> What about the representation clauses? If you do not use Ada for system
>> programming, don't try to make Ada200x unusable for this purpose.
>
> Let's allow representation clause support for the tags and tagged types !

Please show me a representation clause which leave out the tag completely.

Re: Ideas for Ada 200X

[Marin David Condic]

Well, realistically at this point Ada doesn't have much to lose by being 
bold and striving for something new and refreshing. On one level, it 
simply needs to "catch up" to other languages by providing some kind of 
libraries similar to what you can get elsewhere. On another level, it 
needs to *exceed* what other languages are doing if it hopes to capture 
market share away from them. So if Ada doesn't aim high, it is just 
going to remain off in its own little nich and slowly strangle.

Trying to incorporate every possible good idea into the language 
standard is just not going to work. Providing some kind of forum whereby 
the vendors and other vested interests can come up with extensions to 
the language's capabilities that are not part of the formal standard 
would be a good route to go because it would allow for rapid reaction to 
changing circumstances. We just don't seem to see much interest in doing 
something like that coming from the vendors. Without them, it fails.

MDC

Tarjei T. Jensen wrote:

> 
> 
> That is what landed Ada95 in trouble as far as popularity is concerned last
> time.
> 



-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Marin David Condic]

Well, given that we can't correct the past to be what we want it to be, 
how would we go about trying to fix the situation now? Is there a 
credible "going forward" plan that might have enough support from 
interested Ada parties that it might conceivably work?

I would think it might be possible to get some sort of small team 
together that could do work to extend the capabilities of Ada, but it 
would require a) some amount of funding and b) some agreement on the 
part of vendors, et alia, to accept and use the result. I'm sure there 
are many folks who would volunteer *some* time and effort to produce 
something, but most folks have day jobs and can't devote sufficient time 
to it unless there is some remuneration involved. If funding could be 
found to support a team of 3 to 4 people for a year or two and the rest 
was fleshed out by volunteer efforts, we might be able to come up with 
some collection of libraries that the vendors might be willing to 
package with their products (Or at least point to as "The Conventional 
Ada Library")

Ideas? Suggestions? Or is it doomed to fail?

MDC

Richard Riehle wrote:
> 
> The two most important features of Java are the libraries and the JVM.
> The language is rather pedestrian and of would be of little consequence
> if it were not for the libraries.
> 
> We have never been able to agree on the format of nor the functionality
> of standard libraries for Ada (with the exception of a conservative few
> that made it into the Ada 95 Annexes).   As a  consequence, newcomers
> find themselves prowling around the Web to locate something they can
> use  for graphics, GUI's, data structures, etc.  Java has a corporate sponsor
> and is not an ISO standard (nor will it be for a while).   C++ has the
> STL,  but it interfaces  well to MFC and other GUI environments.
> 
> Sadly, there is no corporate or governmental sponsor for Ada so most of
> the effort is either a "labor of love" (Charles, GWindows, CLAW, etc.),
> or produce for a specific need as needed.  It is a big mistake for the DoD
> to discontinue funding for Ada since it is still used for a lot of projects.
> In fact, some of those organizations that charged off in the direction of
> C++ have discovered the folly of that decision.  Unfortunately, instead
> of returning to Ada, as they should, they are attempting to use even more
> inappropriate tools such as Java, largely because of hype, but also because
> of the libraries.
> 
> This could be fixed, but it will required money.  Where will that money come
> from?  What company with deep pockets is willing to fund Ada?
> 
> The recent discussion about JSF developers deciding to use Ada because,
> even though it is a better language for the purpose than C, it is not popular
> enough, should be a good lesson.  They, in effect, have said, we are picking
> the less effective set of tools because more people know how to use
> them.  While this is an emminently stupid line of reasoning, it illustrates
> the prevailing rationale for language selection.   The availability of good
> libaries will not cure anyone of congenital stupidity, but it might make some
> potential users of Ada more amenable to helping it become more popular.
> 
> Richard Riehle
> 


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Robert A Duff]

"Mark A. Biggar" <mark@biggar.org> writes:

> Robert A Duff wrote:
> > Wesley Groleau <wesgroleau@despammed.com> writes:
> >
> >>>Well, I like the idea of an increment operation, and my reasoning has
> >>>nothing to do with typing.  The problem is code duplication: you have to
> >>>write "I" twice in "I := I + 1;".  No big deal if it's just "I", but it
> >>>could be a complicated name, so the reader has to careful compare the
> >>>text, and also worry about whether the name has side effects.
> >>
> >>What kind of entity is able to have side-effects AND to be incremented?
> > I'm thinking of something like:
> > Some_Array[Get_Next_Position] := Some_Array[Get_Next_Position] + 1;
> > where Get_Next_Position is a function that increments the current
> > position and returns it.  You can say "so don't do that", but it's
> > allowed in Ada, and when I read the code, I have to think about whether
> > this sort of thing is going on.
> 
> Even that case isn't too bad, but if you have a really long expression
> you can always use (using your example):
> 
> declare
> 	x: same_as_Some_Array_element_type
> 		renames Some_Array[Get_Next_Position];
> begin
> 	x := x + 1;
> end;
> 
> This of course doesn't work if your expression has side-effects or
> contains the exaluation of a non-pure function (like your example).
> But note that even the += assignment operator in C++ doesn't work
> correctly in that case either.

Correctly?  I guess it depends on what you want it to do.
My example:

    Some_Array[Get_Next_Position] := Some_Array[Get_Next_Position] + 1;

is highly unlikely to be correct, since it evaluates Get_Next_Position
twice (which is probably not what you want) and it does it in either
order (which is almost certainly not what you want).  More likely, it's
just a mistake, and the programmer wanted the semantics provided by your
renaming above (or, more concisely and readably, C's += operator).

- Bob

Re: Ideas for Ada 200X

[Robert A Duff]

Lutz Donnerhacke <lutz@iks-jena.de> writes:

> * Larry Kilgallen wrote:
> > In article <slrnbdec1h.nq.lutz@taranis.iks-jena.de>, Lutz Donnerhacke <lutz@iks-jena.de> writes:
> >> * Dmitry A. Kazakov wrote:
> >>> So, let's make all types "tagged"! I think it could be done little or no
> >>> compatibility impact.
> >>
> >> What about the representation clauses? If you do not use Ada for system
> >> programming, don't try to make Ada200x unusable for this purpose.
> >
> > Let's allow representation clause support for the tags and tagged types !
> 
> Please show me a representation clause which leave out the tag completely.

Tags are not needed for tagged objects.  Tags are needed for class-wide
objects.  If all types were tagged, then a reasonable run-time model
would *not* store the tag in every (tagged) object, but only in
pointer-to-classwide and the like.  Or, one could give the programmer a
choice of whether to store the tag with the object -- it's more
efficient if you're going to use class-wide types a lot, and less
efficient if you're not.

- Bob

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Robert A Duff wrote:
> Correctly?  I guess it depends on what you want it to do.
> My example:
> 
>     Some_Array[Get_Next_Position] := Some_Array[Get_Next_Position] + 1;
> 
> is highly unlikely to be correct, since it evaluates Get_Next_Position
> twice (which is probably not what you want) and it does it in either
> order (which is almost certainly not what you want).  More likely, it's
> just a mistake, and the programmer wanted the semantics provided by your
> renaming above (or, more concisely and readably, C's += operator).

Ack.

with Ada.Text_IO;

procedure t is
   type offset is range 1 .. 9;
   type base is range 1 .. 19;
   type field is array(offset) of base;
   
   f : field := (1, 2, 3, 4, 5, 6, 7, 8, 9);
   o : offset := f'First;
   t : offset;

   function getnext return offset is
   begin
      o := o + 1;
      return o;
   end getnext;
   
   procedure print is
   begin
      Ada.Text_IO.Put_Line("f(" & offset'Image(o) & " ) =" & base'Image(f(o)));
   end print;
   procedure printall is
   begin
      for i in f'Range loop
	 Ada.Text_IO.Put(base'Image(f(i)));
      end loop;
      Ada.Text_IO.New_Line;
   end printall;
begin
   printall;
   
   t := getnext;
   print;
   
   f(getnext) := f(getnext) + 10;
   print; printall;
   
   declare
      x : base renames f(getnext);
   begin
      x := x + 10;
   end;
   print; printall;
   
   declare
      procedure Inc(x : in out base) is
      begin
	 x := x + 10;
      end Inc;
   begin
      Inc(f(getnext));
   end;
   print; printall;
end;
\f
Results in:
 1 2 3 4 5 6 7 8 9
f( 2 ) = 2
f( 4 ) = 4
 1 2 14 4 5 6 7 8 9
f( 5 ) = 15
 1 2 14 4 15 6 7 8 9
f( 6 ) = 16
 1 2 14 4 15 16 7 8 9

Renaming and Procedural Increment has the required behavior. Doubling the
side effect argument does not.

The corresponding C-Source is:
#include <stdio.h>

int o = 0, f[10] = {1,2,3,4,5,6,7,8,9};

int getnext(void) {
   return ++o;
}

void print(void) {
   printf("f(%d) = %d\n", o, f[o]);
}

void printall(void) {
   int i;
   for(i = 0; i < sizeof(f)/sizeof(*f); i++) {
      printf("%d ", f[i]);
   }
   puts("");
}

void inc(int * x) {
   *x = *x + 10;
}

int main(void) {
   int t;
   printall();
   
   t = getnext();
   print();
   
   f[getnext()] = f[getnext()] + 10;
   print(); printall();
   
   f[getnext()] += 10;
   print(); printall();
   
   inc(&f[getnext()]);
   print(); printall();
}

You find it ugly to pass an "in out" parameter using a pointer?
You find it ugly to rename a expression in order to prevent reevaluation?

Yes. Either language has some common idioms you will find ugly.

Re: Ideas for Ada 200X

[Tarjei T. Jensen]

Marin David Condic wrote:
> Well, given that we can't correct the past to be what we want it to be,
> how would we go about trying to fix the situation now? Is there a
> credible "going forward" plan that might have enough support from
> interested Ada parties that it might conceivably work?

The only workable plan I know of involves me having an job in academia and
farming out projects to students. Since I'm not in academia the plan sinks
(or stinks).

> I would think it might be possible to get some sort of small team
> together that could do work to extend the capabilities of Ada, but it
> would require a) some amount of funding and b) some agreement on the
> part of vendors, et alia, to accept and use the result. I'm sure there
> are many folks who would volunteer *some* time and effort to produce
> something, but most folks have day jobs and can't devote sufficient time
> to it unless there is some remuneration involved. If funding could be
> found to support a team of 3 to 4 people for a year or two and the rest
> was fleshed out by volunteer efforts, we might be able to come up with
> some collection of libraries that the vendors might be willing to
> package with their products (Or at least point to as "The Conventional
> Ada Library")

It is workable, but I doubt that the vendors will get involved unless there
is a hard specification involved.

It might work if a group consisting of people in academia and commercial
companies got together and created specifications for student (and madman)
projects as part of a library. The idea is that these people would be
available (at least in the evenings) when the students need help or
guidance.

> Ideas? Suggestions? Or is it doomed to fail?

Probably, but not because it is a bad idea. Just because the vendors seems
to be uninterested in general computing.

greetings,

Re: Ideas for Ada 200X

[Hyman Rosen]

Martin Krischik wrote:
> I use far more C++ then Ada in my live and the "++" and "+=" operator is
> somthing I can live without. I := I + 1 expreses my intend just as well.

Only if you never use iterators other than random access ones.
That means no stream iterators, no maps, no sets, etc. Unless
you think that these operators are just for numbers?

Re: Ideas for Ada 200X

[Richard Riehle]

Preben Randhol wrote:

> Richard Riehle wrote:
> > The recent discussion about JSF developers deciding to use Ada because,
> > even though it is a better language for the purpose than C, it is not popular
> > enough, should be a good lesson.
>
> I take it you meant: JSF developers deciding *not* to use Ada because ?

Preben,

Thanks.  Sometimes I mistake my left hand for my right,  compose a
negative phrase with its binary complement, and pick up the wrong
water glass at a formal dinner.   I am standing on the threshold
of senility,  so I should more carefully edit my love letters to Ada before
sending them across the electronic meadow for all to read.

Richard

Re: Ideas for Ada 200X

[Richard Riehle]

"Tarjei T. Jensen" wrote:

> The only workable plan I know of involves me having an job in academia and
> farming out projects to students. Since I'm not in academia the plan sinks
> (or stinks).

Even in academia, a professor is too often dependent on outside funding for
support.   Also, students are not so compliant unless the work they are doing
is related to a pre-stated  reward.   Such rewards are more difficult to
confer unless they are related to either an on-going class or funded research.
Since we are having more difficulty, in recent times, getting a fully-formed
Ada class populated by students, and since funding is notably scarce, most
professors find themselves with little motivation to do work related to
Ada.   If such funding were available, I would be happy to encourage more
of my own students to pursue more Ada projects, including the development
of more libraries.

The unconscionable position of the current DoD management regarding
funding for Ada support and research is much to the detriment of our
continued superiority in military software systems.   At present, there
seems to be no avenue leading to a more enlightened DoD policy.

Richard Riehle

Re: Ideas for Ada 200X

[Tarjei T. Jensen]

Richard Riehle wrote:
> Even in academia, a professor is too often dependent on outside funding
for
> support.   Also, students are not so compliant unless the work they are
doing
> is related to a pre-stated  reward.   Such rewards are more difficult to
> confer unless they are related to either an on-going class or funded
research.

I'm not convinced that this is neccessarily Ph.D. stuff. Exploring might
just as well be done on the B.Sc. level. Especially if the person who owns
the project has a good understanding of what is needed and is willing to
help out on interface issues.

E.g. a basic buffered streams I/O package will probably not need rocket
science if the project owner is willing to provide advice. The stuff on top
such a package -- like how to render numbers efficiently is of course a more
advanced topic.

In my opinion, once such a system has been created and the interfaces
defined, it is easy to develop it further and make the implementation more
effective.

If one assumes that there is several projects and that they depend on each
other, the students should get valuable experience in project work. At
least, the process should be quite interesting.

greetings,

Re: Ideas for Ada 200X

[Stephen Leake]

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

> I am not so sure that a compiler would be capable to optimize each
> possible case of X := X @ Y. Especially if all operations in the
> expression are user-defined and types are controlled.
> 
> On the other hand, very often in C++ to implement all that ++, +=,
> *= etc + by value vs. by reference variations becomes a heavy burden
> when an abstract type is defined. It is also difficult to ensure
> that the semantics of all operations is compatible.

Exactly. If you can't expect a compiler to get it right, why would you
expect a programmer to get it right?

Clearly for scalar types (reals, integers, enumerations),
Foo_type'Inc(by : in Foo_type) is simple to define and implement; not
that different from 'Succ. That would be a trivial addition to the
language, and I'd like to see it (if only to end this thread :).

But for user-defined component types (records, protected, array
types), the semantics can get too complex. What would Array_Type'Inc
(By : in Array_Type) mean? "Add By to each element" comes to mind, but
that's probably not very useful. 

Users can always write their own Inc function, anyway, so there is no
need to allow user-defined 'Inc.

-- 
-- Stephe

Re: Ideas for Ada 200X

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Martin Krischik wrote:
> > I use far more C++ then Ada in my live and the "++" and "+=" operator is
> > somthing I can live without. I := I + 1 expreses my intend just as well.
> 
> Only if you never use iterators other than random access ones.
> That means no stream iterators, no maps, no sets, etc. Unless
> you think that these operators are just for numbers?

You seem to be implying that "foo++" means something other than "foo =
foo + 1" in C++. Hmm. Quoting "The C++ Programming Language, Special
Edition" by Stroustrup, section 6.2.5:

    By definition, "++lvalue" means "lvalue += 1", which again means
    "lvalue = lvalue + 1", provided "lvalue" has no side effects.

We've already agreed there is a difference between "I := I + 1" and
Inc (I) when "I" has side effects; what other differences are you
talking about here? Or is the side effects what you mean?

-- 
-- Stephe

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> > Occasionally I run into code that looks something like:
> > 
> > production_total( total_class ).shift( shift_index ) :=
> >   production_total( total_class ).shift( shift_index ) + count;
> > 
> > That would read a lot cleaner as:
> > 
> >   production_total( total_class ).shift( shift_index ) += count;
> 
> Couldn't have said it better myself.

What is wrong with having a style guide that says:

"If you have statements like 
   production_total( total_class ).shift( shift_index ) :=
      production_total( total_class ).shift( shift_index ) + count;

you must write an appropriate Increment function, and use it instead"

Problem solved; no need for language change or compiler support.

> And let's not forget that +=, -=, etc. also allow for more efficient
> in-place vector/matrix operations because they avoid the need for a
> temporary. If you don't understand this, that's OK, but please don't
> argue with me because you will be wrong.

Same argument; a package that provides vector/matrix math must provide
an appropriate in-place Increment function.

Ada is about ease of reading, _not_ about ease of writing.

-- 
-- Stephe

Re: Ideas for Ada 200X

[Wesley Groleau]

> On the other hand, very often in C++ to implement all that ++, +=, *= etc + 
> by value vs. by reference variations becomes a heavy burden when an 
> abstract type is defined. It is also difficult to ensure that the semantics 
> of all operations is compatible.

Without actually endorsing the proposal,
I think it would be quite simple to do.

++  The effect of X'Inc is indistinguishable
     from the result of
          X := X + 1; return X;
     including that if the above won't compile,
     then X'Inc won't compile.

SAME paragraph, with the following substitutions:

X'Inc => X += Y  (same as)  X := X + Y;
X'Inc => X /= Y  (same as)  X := X / Y;

etc.

No burden at all--if a compiler knows how to
compile a construct, then it knows how to compile
the shorthand for the construct.

Now, whether the shorthand should exist is another story.....

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <u4r3co12f.fsf@nasa.gov>, Stephen Leake <Stephe.Leake@nasa.gov> writes:
> 18k11tm001@sneakemail.com (Russ) writes:
> 
>> > Occasionally I run into code that looks something like:
>> > 
>> > production_total( total_class ).shift( shift_index ) :=
>> >   production_total( total_class ).shift( shift_index ) + count;
>> > 
>> > That would read a lot cleaner as:
>> > 
>> >   production_total( total_class ).shift( shift_index ) += count;
>> 
>> Couldn't have said it better myself.
> 
> What is wrong with having a style guide that says:
> 
> "If you have statements like 
>    production_total( total_class ).shift( shift_index ) :=
>       production_total( total_class ).shift( shift_index ) + count;
> 
> you must write an appropriate Increment function, and use it instead"
> 
> Problem solved; no need for language change or compiler support.

Alternatively, would a renaming declaration work ?

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> Warren W. Gay  wrote:
> 
>>I am not saying it shouldn't be done, but I think you've overly
>>trivialized it. 8-)
> 
> No I haven't. I have made something 99,95 percent of Ada ordinary users
> could use. Successfully.The issues you raise complicates matters and creates
> confusion. It is the stuff you put in a specialized library. It is NOT
> something for the unwashed masses.

I have already conceded that the "TCP basics" would be a "Good Thing" (TM).

But going from being a "Good Thing" to "the only thing we need" is
an entirely different matter.  If you only plan for TCP in your
socket support, you will have an "unwashed mess of package(s)"
which will be ugly or difficult to extend for other important
network functionality. Some of which, may not be well understood or
anticipated at this time.

BTW, you _will_ want Naming services support. Without them, you'll
not connect to anything, except explicity by IP number. ;-)

> PLEASE read "The Inmates Are Running The Asylum". Less is more! Focus on
> something to do well.
> 
>>I think most people would settle for a good TCP
>>level API for applications. But this would need to include naming
>>services at a minimum, and ideally Ada streams with
>>endian neutral I/O to be truly useful.
> 
> That is extras!

Oh?  How are going to connect to http://adapower.com from your
Ada socket program?  Are you going to code that it must connect
to 216.92.66.46 instead? What if their IP number changes with time
as it would with PPP/DHCP? Trust me -- you _will_ want the naming
services. 8-P  "They is not extra!"

Ada streams and endian issues are also important. Write a program
that uses a socket between two endian different machines and the
endian issue becomes painfully important.  This also shows up
in the strangest places. My APQ PostgreSQL package lets you use
Ada streams to write blobs to the database. Well, guess what. If
you have machines of a different endian persuation trying to read
back those blobs written by a different endian persuation (with
Ada streams), then "they ain't right". Right now, I live with that
limitation because there is no elegant way to fix this.

Since Ada streams was important for the designers to allow programs
to read/write Ada objects to/from files, I think it is consistent to
say the same "need" exists with sockets. Mix in sockets, and endian
issues also come into play.

>>It would also be useful for Ada0X to include some extensions to the
>>distributed annex to consider standard ways to authenticate. This is
>>perhaps one of the biggest thorn patches for distributed computing in
>>hostile environments. I would love to see SSL (perhaps) as a builtin
>>selectable option for the channel filter for example.
> 
> I would not mind having that, but it is still extras.

I would agree that this is "extra", but there still exists a "need"
there. As soon as you write a distributed program that must communicate
with a 3rd party, this becomes a difficult issue.  Or if the communication
path is over the hostile inet.

If someone/group were to solve this as a "standard", and that
standard stood the test of time (security wise), a great deal
of effort would be saved by many by having this accomplished.
And then we can all reap the benefits in services that this
could make safely available.

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

Re: Ideas for Ada 200X

[Wesley Groleau]

> And let's not forget that +=, -=, etc. also allow for more efficient
> in-place vector/matrix operations because they avoid the need for a
> temporary. If you don't understand this, that's OK, but please don't
> argue with me because you will be wrong.

Neither
    A := A + B;
nor
    A += B; -- if it existed in Ada

would need a temporary except when required by checking rules
and exception rules.  If one needs a temporary, the other does.
After all, they are the same, are they not?

The use of a temporary has NOTHING to do with which format
you choose to write the SAME operation in.

Re: Ideas for Ada 200X

[Hyman Rosen]

Stephen Leake wrote:
> You seem to be implying that "foo++" means something other than "foo =
> foo + 1" in C++. Hmm. Quoting "The C++ Programming Language, Special
> Edition" by Stroustrup, section 6.2.5:

He's talking about the effect of these operators on built-in types.
But you are permitted to define ++ and -- operators for your own
types as well, and then the semantics are what you want.

The C++ standard library defines ++ and -- operators for its
iterators, with the natural meaning of move to the next or
previous item. It also defines adding integers to iterators,
but only for random access iterators where the addition takes
constant time. For iterators which would take linear time,
these operations are not defined.

Re: Ideas for Ada 200X

[Preben Randhol]

Wesley Groleau wrote:
> X'Inc => X += Y  (same as)  X := X + Y;
> X'Inc => X /= Y  (same as)  X := X / Y;

Changing the meaning of X /= Y would break most programs.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> "Warren W. Gay wrote:
>>Looking backwards to '95, I think it can be fairly stated that things
>>were a bit different than today. For one, Linux was in its infancy,
>>and Windoze was still discovering the inet. GNAT was still in its
>>infancy. I believe has done a much to promote the "general purpose"
>>usefulness of Ada. This is certainly true at least of the open sourced
>>community (which may be a small subset of Ada users worldwide).
> 
> Windows discovered the internet before '95. And Linux was even then very
> much network focused at the time.

I'll disagree with you on this, at least in terms of the semantics
of what "discovered" means. In fact, Microsoft is _still_ learning that
security must come before features. They are still stuck in the model
that existed before they met the inet where they could ignore the
threat of hacks because PCs were standalone, or were local area
nets at best.

Recall that for the longest time, WinSock was their "add on"
to address TCP/IP. It wasn't even part of the O/S for a long
time. Linux had it _almost_ from the start.

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

Re: Ideas for Ada 200X

[Wesley Groleau]

> professors find themselves with little motivation to do work related to
> Ada.   If such funding were available, I would be happy to encourage more
> of my own students to pursue more Ada projects, including the development
> of more libraries.

Is the Ada Resource Association still a viable group?
If they are truly interested in the future of Ada, perhaps
they would look at grant proposals for new Ada annexes
and award grants to those that seem to be of particular
value.

"New" annexes might include bindings and/or all-Ada packages
that implement existing standards, or alternate ways to
provide functionality available in other languages, or something
entirely new.

Presumably the award committee would include in their
evaluation criteria ensuring that the project includes
some mechanism to ensure wide-spread acceptance of the
result, i.e., plans for some sort of review by someone
other than just the designers/coders.

Re: Ideas for Ada 200X (GNAT.IO_Aux.Get_Line)

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
...
> Trying to incorporate every possible good idea into the language 
> standard is just not going to work. Providing some kind of forum whereby 
> the vendors and other vested interests can come up with extensions to 
> the language's capabilities that are not part of the formal standard 
> would be a good route to go because it would allow for rapid reaction to 
> changing circumstances. We just don't seem to see much interest in doing 
> something like that coming from the vendors. Without them, it fails.
> 
> MDC

While there are undoubtedly some language issues being worked out (judging
by the number of AIs at least), for my part, I think the best bang for
the buck for Ada0Y effort is in its standard library support improvement.
This will be contraversial to the embedded crowd, but important none
the less.

Sure there are some language "warts" that get in the way from time to
time. But for most of my experience in the language, the wall I keep hitting
is the lack of library/binding support for things that are taken for
granted everywhere else (sockets is one example). It is not the language
that discourages so much, but the number of things that you end up
having to DO YOURSELF. This re-invent the wheel every time thing
needs to go away.

If you have to blaze trails for mundane things, then surely this
discourages many people that lack the intenstinal fortitude to
continue.  I would strongly encourage that the "standard library"
be greatly expanded for Ada0Y, to eliminate this type of
uphill battle for the masses. For GENERAL use of Ada, this is
essential.

Another example: Include a standard version of GNAT.IO_Aux.Get_Line
as part of Ada.Text_IO for Ada0Y. Why should people have to keep
rolling their own, or relying on GNAT code for this?

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

Re: Ideas for Ada 200X

[Hyman Rosen]

Wesley Groleau wrote:
> After all, they are the same, are they not?

They are not, in the case of user-defined overloads
of the operators. Or at least they shouldn't be.

Re: Ideas for Ada 200X

[Wesley Groleau]

>> After all, they are the same, are they not?
> 
> They are not, in the case of user-defined overloads
> of the operators. Or at least they shouldn't be.

In that situation, the conclusion is the same--no problem.
The user can only define the operators in terms the compiler
already supports.  Therefore, the compiler must merely do
what the user defined.

Re: Ideas for Ada 200X

[Wesley Groleau]

Preben Randhol wrote:
> Wesley Groleau wrote:
> 
>>X'Inc => X += Y  (same as)  X := X + Y;
>>X'Inc => X /= Y  (same as)  X := X / Y;
> 
> Changing the meaning of X /= Y would break most programs.

!  :-)  One more argument _against_ cluttering up
         Ada's list of operators.

Re: Ideas for Ada 200X (Ada.Sockets)

[Wesley Groleau]

> BTW, you _will_ want Naming services support. Without them, you'll
> not connect to anything, except explicity by IP number. ;-)

I agree that TCP/IP without DNS is _severely_ crippled.
Nevertheless, I'd prefer they be in separate packages
with minimal coupling between them.

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <mB-cnRBpHp4qCUqjXTWcpQ@gbronline.com>, Wesley Groleau <wesgroleau@despammed.com> writes:
> 
>> professors find themselves with little motivation to do work related to
>> Ada.   If such funding were available, I would be happy to encourage more
>> of my own students to pursue more Ada projects, including the development
>> of more libraries.
> 
> Is the Ada Resource Association still a viable group?
> If they are truly interested in the future of Ada, perhaps
> they would look at grant proposals for new Ada annexes
> and award grants to those that seem to be of particular
> value.

I would draw a distinction between viable and wealthy.

Re: Ideas for Ada 200X

[chris.danx]

Marin David Condic wrote:
> I think a standard Ada sockets package would be A Good Thing. So would 
> something like an XML parser be a good thing. (Make it use the OO 
> features Ada has so that it closely matches the XML standard. This is 
> the only thing I don't like about the XMLAda package currently floating 
> about - it uses discriminated records instead of tagged records, which 
> would be the natural way to express what is in the XML standard.)

I started on this, but ran into problems and think I understand why in 
XMLAda, variant records are used.  The DOM standard contains some 
cirular dependancies.

interface Node {

...

   readonly attribute Document        ownerDocument;

...
}

interface Document : Node {
...
}

hmm, it could be easier than I thought since Document is mainly routines.

At the time I looked at it I wasn't sure how to resolve the problem, but 
then I'm not experienced with software in any major way so the problem 
might be trivial and I just can't see it.

I am going to return to it post exams...

Chris

Re: Ideas for Ada 200X

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> And let's not forget that +=, -=, etc. also allow for more efficient
> in-place vector/matrix operations because they avoid the need for a
> temporary. If you don't understand this, that's OK, but please don't
> argue with me because you will be wrong.

I can't let *that* slip by...  ;-)

Calling the procedure += instead of, say, Add_Matrix will not make it
faster!  The += notation is purely syntactic sugar, and has nothing
to do with efficiency.

- Bob

Re: Ideas for Ada 200X

[Wesley Groleau]

>>Is the Ada Resource Association still a viable group?
>>If they are truly interested in the future of Ada, perhaps
>>they would look at grant proposals for new Ada annexes
>>and award grants to those that seem to be of particular
>>value.
> 
> I would draw a distinction between viable and wealthy.

Well, maybe _small_ grants.  But is there _anyone_ else
who has _any_ interest in producing _any_ kind of Ada library?

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Wesley Groleau wrote:
>> BTW, you _will_ want Naming services support. Without them, you'll
>> not connect to anything, except explicity by IP number. ;-)
> 
> I agree that TCP/IP without DNS is _severely_ crippled.
> Nevertheless, I'd prefer they be in separate packages
> with minimal coupling between them.

I was very careful to not suggest a package hierarchy (no, not
even a name ;-)

This needs to be part of an overall "solution" to be proposed. As
you suggested, it may best be "decoupled" according to best
practices.

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

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Well, given that we can't correct the past to be what we want it to be, 
> how would we go about trying to fix the situation now? Is there a 
> credible "going forward" plan that might have enough support from 
> interested Ada parties that it might conceivably work?

Yes, let's just march "forward". Debating about the past, is ok for
lunchtime amusement on comp.lang.ada, but it won't accomplish much ;-)

> I would think it might be possible to get some sort of small team 
> together that could do work to extend the capabilities of Ada, but it 
> would require a) some amount of funding and b) some agreement on the 
> part of vendors, et alia, to accept and use the result.

I don't entirely agree with point "a)" as being absolutely
necessary. It of course helps encourage enthusiasm, but that
is not a foregone conclusion.

The "b)" part might be acceptable to vendors if "a work" was
done that they found agreeable. I am not certain vendor agreement
is _necessary_ at this stage, or even possible.

> I'm sure there 
> are many folks who would volunteer *some* time and effort to produce 
> something, but most folks have day jobs and can't devote sufficient time 
> to it unless there is some remuneration involved. 

Not entirely untrue, but not necessarily a show stopper.  Sure there
are some that simply cannot contribute, or not at this time.

> If funding could be 
> found to support a team of 3 to 4 people for a year or two and the rest 
> was fleshed out by volunteer efforts, we might be able to come up with 
> some collection of libraries that the vendors might be willing to 
> package with their products (Or at least point to as "The Conventional 
> Ada Library")
> 
> Ideas? Suggestions? Or is it doomed to fail?
> 
> MDC

Here is some of my thinking out loud (not necessarily sensible ;-)

Get 1 person to organize, and perhaps the same person to "moderate"
any initial discussions :

- Create a special "mailing list/newsgroup" (a mailing list can
   be made available on gmane.org's newsgroup server, for those
   that prefer a nntp interface). Yahoo groups are pesky, but free.

   I believe this is essential, because comp.lang.ada is like
   inviting everyone to a meeting, and never getting consencous.

- Solicit volunteers.
- Get some agreement on scope
- Subdivide scope and
   - determine package hierarchies
   - determine naming conventions to be used
   - subdivide volunteers to portions of the heirarchy
     - the smaller divisions the better, or perhaps
       in reasonable scopable swaths
- solicit volunteers (repeat as necessary ;-)

- do some code/design work
- meet
- iterate until well "baked"

As a volunteer effort, there is a number of sources that we can look
at and learn from.

I will contribute my time, to clearly defined portions of this project,
but only to something considerably smaller than Florist ;-)  But I would
prefer not to steer it, because I have other pet projects on the run. ;-)

Ideally (maybe), the person steering this should be more familiar with
what's up with Ada0Y, the industry etc. But hey, I think zeal is the
most important attribute here.

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

Re: Ideas for Ada 200X

[Simon Wright]

"Tarjei T. Jensen" <tarjei.jensen@akerkvaerner.com> writes:

> Richard Riehle wrote:
> > Even in academia, a professor is too often dependent on outside funding
> for
> > support.   Also, students are not so compliant unless the work they are
> doing
> > is related to a pre-stated  reward.   Such rewards are more difficult to
> > confer unless they are related to either an on-going class or funded
> research.
> 
> I'm not convinced that this is neccessarily Ph.D. stuff. Exploring might
> just as well be done on the B.Sc. level. Especially if the person who owns
> the project has a good understanding of what is needed and is willing to
> help out on interface issues.
> 
> E.g. a basic buffered streams I/O package will probably not need rocket
> science if the project owner is willing to provide advice. The stuff on top
> such a package -- like how to render numbers efficiently is of course a more
> advanced topic.

The need for a standard library/libraries isn't that it be clever,
just that it be _there_! In fact I suspect that simple might be
better.

The most difficult part is getting agreement as to what should be in
the standard. Look at the trouble container libraries make; task-safe
or not, is iteration like C++'s STL or not, are maps sorted, ...

The trouble with an individual doing this sort of work (obviously as a
member of a team) is that you can't do it in your evenings/weekends
and have a life; it really needs employer support for daytime work
(not to mention travelling to face to face meetings in far flung
places). Not too easy to come by nowadays.

Re: Ideas for Ada 200X (Ada.Sockets)

[Simon Wright]

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

> Ada streams and endian issues are also important. Write a program
> that uses a socket between two endian different machines and the
> endian issue becomes painfully important.  This also shows up
> in the strangest places. My APQ PostgreSQL package lets you use
> Ada streams to write blobs to the database. Well, guess what. If
> you have machines of a different endian persuation trying to read
> back those blobs written by a different endian persuation (with
> Ada streams), then "they ain't right". Right now, I live with that
> limitation because there is no elegant way to fix this.

The GLADE (GNAT Annex E support) contains an implementation of
System.Stream_Attributes, in s-stratt.adb,  that magically makes streams
endian-independent (uses XDR formatting).

You do need to use the gnatmake flag (-a ?) that says "recompile
everything".

Re: Ideas for Ada 200X

[Russ]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<u4r3co12f.fsf@nasa.gov>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > > Occasionally I run into code that looks something like:
> > > 
> > > production_total( total_class ).shift( shift_index ) :=
> > >   production_total( total_class ).shift( shift_index ) + count;
> > > 
> > > That would read a lot cleaner as:
> > > 
> > >   production_total( total_class ).shift( shift_index ) += count;
> > 
> > Couldn't have said it better myself.
> 
> What is wrong with having a style guide that says:
> 
> "If you have statements like 
>    production_total( total_class ).shift( shift_index ) :=
>       production_total( total_class ).shift( shift_index ) + count;
> 
> you must write an appropriate Increment function, and use it instead"

Because it's one hell of a lot easier, not to mention less
error-prone, to just use +=. That's what Ada is all about.

I don't blame anyone for disliking ++, but += should be your friend.

> Problem solved; no need for language change or compiler support.

Yes, but it's far from the best and simplest solution.

> > And let's not forget that +=, -=, etc. also allow for more efficient
> > in-place vector/matrix operations because they avoid the need for a
> > temporary. If you don't understand this, that's OK, but please don't
> > argue with me because you will be wrong.
> 
> Same argument; a package that provides vector/matrix math must provide
> an appropriate in-place Increment function.
> 
> Ada is about ease of reading, _not_ about ease of writing.

+= improves readability too! Which is clearer,

	A += B

or

	Add(A,B)

The latter doesn't make clear what exactly is being done. Is the
result ending up in A or B? Yes, you can write something that would be
a bit clearer, like

	Add ( Into=>A, Add=>B )

but it still would not be as clear or as elegant as A += B.

In-place operations on a variables are so fundamental that they
deserves their own syntax. If you can't handle that, what kind of
"programmer" are you?

Re: Ideas for Ada 200X

[Marin David Condic]

I would suggest that we not lobby for new annexes. The instant we say 
that the only way for Ada to have a "standard" library is to include it 
in the annexes, you'll have two insurmountable problems that will kill 
the whole thing: 1) The language standard is only going to get updated 
every ten years or so and 2) writing a specification of sufficient 
detail to make it acceptable for standards validation for a library of 
any appreciable size is going to asymptotically approach "impossible".

If we want a library - one that is bigger than near trivial and covering 
more than just containers - it had better exist outside of the standard 
in some manner. If the vendors were interested in getting one, they 
ought to talk about forming up a consortium or an R&D company or working 
with SIGAda or some academic body or nearly *anything* except the total 
inaction we see, to get a group together to build a library that would 
be accepted as part of Ada, but external to the standard. Its not 
impossible to figure out a way to get it done, but my lone voice crying 
out in the wilderness isn't what will cause it to happen. If ACT, Aonix 
and whoever else is still interested in selling Ada want it to happen 
and start voicing that desire, chances are they'd find a way to do it. I 
just don't see them chomping at the bit trying to find a way to get a 
group together to build a library for Ada.

MDC

Wesley Groleau wrote:
> 
> "New" annexes might include bindings and/or all-Ada packages
> that implement existing standards, or alternate ways to
> provide functionality available in other languages, or something
> entirely new.


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Marin David Condic]

Well, I won't say it *can't* work - just that it has been tried in a few 
different ways and guess what? We don't have a Conventional Ada Library.

If the thing has zero interest from the vendors it will become Just 
Another Ada Library like the half-dozen or so that are already out 
there. A small teem of developers might be able to do a good job of 
building a library - even if they were volunteers - but it would need 
some direction from those who have to adopt it as "The Right Thing". 
Think "Requirements" - someone has to impose some. Don't believe me? 
Lets toss this turd into the pool: Should a Standard Ada Container 
Library be based on generics or based on tagged types? Let's start that 
debate here and see how far it goes! (Less filling! Tastes great!!!)

A group of enthusiasts sounds plausable, but I believe that unless it 
has some cloak of "officialness" to it, some acceptance on the part of 
the vendors and some sort of charter/requirements to work to, it will 
either fall apart or produce Just Another Ada Library.

MDC

Warren W. Gay VE3WWG wrote:
> 
> 
> Here is some of my thinking out loud (not necessarily sensible ;-)
> 
> Get 1 person to organize, and perhaps the same person to "moderate"
> any initial discussions :
> 
> - Create a special "mailing list/newsgroup" (a mailing list can
>   be made available on gmane.org's newsgroup server, for those
>   that prefer a nntp interface). Yahoo groups are pesky, but free.
> 
>   I believe this is essential, because comp.lang.ada is like
>   inviting everyone to a meeting, and never getting consencous.
> 
> - Solicit volunteers.
> - Get some agreement on scope
> - Subdivide scope and
>   - determine package hierarchies
>   - determine naming conventions to be used
>   - subdivide volunteers to portions of the heirarchy
>     - the smaller divisions the better, or perhaps
>       in reasonable scopable swaths
> - solicit volunteers (repeat as necessary ;-)
> 
> - do some code/design work
> - meet
> - iterate until well "baked"
> 
> As a volunteer effort, there is a number of sources that we can look
> at and learn from.
> 
> I will contribute my time, to clearly defined portions of this project,
> but only to something considerably smaller than Florist ;-)  But I would
> prefer not to steer it, because I have other pet projects on the run. ;-)
> 
> Ideally (maybe), the person steering this should be more familiar with
> what's up with Ada0Y, the industry etc. But hey, I think zeal is the
> most important attribute here.
> 


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc65ns9pix.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > And let's not forget that +=, -=, etc. also allow for more efficient
> > in-place vector/matrix operations because they avoid the need for a
> > temporary. If you don't understand this, that's OK, but please don't
> > argue with me because you will be wrong.
> 
> I can't let *that* slip by...  ;-)
> 
> Calling the procedure += instead of, say, Add_Matrix will not make it
> faster!  The += notation is purely syntactic sugar, and has nothing
> to do with efficiency.
> 
> - Bob

OK, I guess I wasn't clear enough. I meant that A += B is (if properly
implemented) much more efficient than A := A + B. For anyone who
doesn't understand why, it is because the latter requires the
construction of a temporary to hold the sum, then a copy of the sum
back over to A.

Yes, you can always define Add_Matrix(A,B), or even
Add_Matrix(Into=>A,From=>B), but if that appeals to you ... oh, forget
about it.

Yes, += is syntactic sugar. So is +, for that matter. After all, you
can always write a function called Plus(A,B). Do you therefore
recommend we dump +?

Come to think of it, programming languages in general really boil down
to "syntactic sugar," don't they. We could just use machine language.

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

Warren W. Gay wrote:
> But going from being a "Good Thing" to "the only thing we need" is
> an entirely different matter.  If you only plan for TCP in your
> socket support, you will have an "unwashed mess of package(s)"
> which will be ugly or difficult to extend for other important
> network functionality. Some of which, may not be well understood or
> anticipated at this time.

I don't want to extend it. I or sombody else may want to make its interface
a subset of a more complete socket library. Or possibly make the simple
socket library an interface to a more complete library.

> BTW, you _will_ want Naming services support. Without them, you'll
> not connect to anything, except explicity by IP number. ;-)

There is no problem using DNS under the hood in such a library, but there is
no need to give the job of handling DNS resolution to the user.(S)he don't
want to know.

> Ada streams and endian issues are also important. Write a program
> that uses a socket between two endian different machines and the
> endian issue becomes painfully important.  This also shows up
> in the strangest places. My APQ PostgreSQL package lets you use
> Ada streams to write blobs to the database. Well, guess what. If
> you have machines of a different endian persuation trying to read
> back those blobs written by a different endian persuation (with
> Ada streams), then "they ain't right". Right now, I live with that
> limitation because there is no elegant way to fix this.

You will create confusion by adding things the user does not need. A simple
library is most likely to be used to echanging textual messages. Once the
user starts doing binary stuff (s)he will know more or simply work around
the problem.

By starting to add features you shoot down in glorious techicolour flames
the concept of a simple library that does one thing well. You obliterate the
ability for an ordinary user to understand and use the library. You drown
userful information in useless gobbledegoook.

The road to hell is paved with good intentions and creeping featurism.
Resist!!!!

Keep it simple!

greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Tarjei T. Jensen]

"Warren W. Gay wrote:
> I was very careful to not suggest a package hierarchy (no, not
> even a name ;-)

I'd be happy to suggest that a standard Ada library should include a
hierarchy with simple as the topmost member for simple libraries.

e.g.
simple.socklib
simple.fileio
simple.console

I suppose raw stuff would either go into the system hierarchy or one could
add a new hierarchy. I assume that such a hierarchy would conain all the
gory details. I would name such a hierarchy raw.

Other parts of the library would use the information in the raw hierarchy
and perhaps export a sanitized interface to the user.

e.g.
raw.ctypes
raw.sockets
raw.fileio



greetings,

Re: Ideas for Ada 200X

[Pascal Obry]

18k11tm001@sneakemail.com (Russ) writes:

> I don't blame anyone for disliking ++, but += should be your friend.

Agreed "++" is really ugly (especially when semantic is different depending on
the position of the operator) but the += style constructions are nice. Of
course this will be difficult to integrate into Ada now as /= is already
used...

Pascal.

-- 

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

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Russ wrote:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote in message
> news:<u4r3co12f.fsf@nasa.gov>...
>> 18k11tm001@sneakemail.com (Russ) writes:
>> 
>> > > Occasionally I run into code that looks something like:
>> > > 
>> > > production_total( total_class ).shift( shift_index ) :=
>> > >   production_total( total_class ).shift( shift_index ) + count;
>> > > 
>> > > That would read a lot cleaner as:
>> > > 
>> > >   production_total( total_class ).shift( shift_index ) += count;
>> > 
>> > Couldn't have said it better myself.
>> 
>> What is wrong with having a style guide that says:
>> 
>> "If you have statements like
>>    production_total( total_class ).shift( shift_index ) :=
>>       production_total( total_class ).shift( shift_index ) + count;
>> 
>> you must write an appropriate Increment function, and use it instead"
> 
> Because it's one hell of a lot easier, not to mention less
> error-prone, to just use +=. That's what Ada is all about.
> 
> I don't blame anyone for disliking ++, but += should be your friend.
> 
>> Problem solved; no need for language change or compiler support.
> 
> Yes, but it's far from the best and simplest solution.
> 
>> > And let's not forget that +=, -=, etc. also allow for more efficient
>> > in-place vector/matrix operations because they avoid the need for a
>> > temporary. If you don't understand this, that's OK, but please don't
>> > argue with me because you will be wrong.
>> 
>> Same argument; a package that provides vector/matrix math must provide
>> an appropriate in-place Increment function.
>> 
>> Ada is about ease of reading, _not_ about ease of writing.
> 
> += improves readability too! Which is clearer,
> 
> A += B
> 
> or
> 
> Add(A,B)
> 
> The latter doesn't make clear what exactly is being done. Is the
> result ending up in A or B? Yes, you can write something that would be
> a bit clearer, like
> 
> Add ( Into=>A, Add=>B )
> 
> but it still would not be as clear or as elegant as A += B.
> 
> In-place operations on a variables are so fundamental that they
> deserves their own syntax. If you can't handle that, what kind of
> "programmer" are you?

Maybe yes, maybe not. Consider generics. If you have several kinds of 
operations, you have to pass all of them as the parameters of a generic. 
You never know what would be useful in the next implementation of the 
generic body. So

generic
   type Matrix is private;
   function "+" (L, R : Matrix) return Matrix;
   function "++" (L : Matrix) return Matrix;
   procedure "+=" (L : in out Matrix; R : Matrix);
   ...

If you add here two additional types Element, and Vector, you will spend the 
rest of your life just completing this specification! (:-))

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

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Wesley Groleau wrote:

>> On the other hand, very often in C++ to implement all that ++, +=, *= etc
>> + by value vs. by reference variations becomes a heavy burden when an
>> abstract type is defined. It is also difficult to ensure that the
>> semantics of all operations is compatible.
> 
> Without actually endorsing the proposal,
> I think it would be quite simple to do.
> 
> ++  The effect of X'Inc is indistinguishable
>      from the result of
>           X := X + 1; return X;
>      including that if the above won't compile,
>      then X'Inc won't compile.
> 
> SAME paragraph, with the following substitutions:
> 
> X'Inc => X += Y  (same as)  X := X + Y;
> X'Inc => X /= Y  (same as)  X := X / Y;
> 
> etc.
> 
> No burden at all--if a compiler knows how to
> compile a construct, then it knows how to compile
> the shorthand for the construct.
> 
> Now, whether the shorthand should exist is another story.....

Sort of macro? Let me play Hyman Rosen for a while:

template <class T> void Inc (T X) { X = X + 1; } //! (:-))

OK, you have a shorthand, but it is no more effective than X := X + 1; as 
long the compiler does not know how to increment in-place. You have to go 
further:

template <class T> void Inc (T X) { X += 1; } //!! (:-))

Now you have the semantic problem back.

Maybe one could solve this from other side:

function Inc (X : in out T; By : T);
function "+" (X, Y : T) return T;
for "+" use Inc;

or better:

for "+" use Inc (X => X, By => Y);

   -- An equivalent to inlined
function "+" (X, Y : T) return T is
   Result : T := X;
begin
   Inc (Result, Y);
   return Result;
end "+";

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

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Lutz Donnerhacke <lutz@iks-jena.de> writes:
> 
>> * Larry Kilgallen wrote:
>> > In article <slrnbdec1h.nq.lutz@taranis.iks-jena.de>, Lutz Donnerhacke
>> > <lutz@iks-jena.de> writes:
>> >> * Dmitry A. Kazakov wrote:
>> >>> So, let's make all types "tagged"! I think it could be done little or
>> >>> no compatibility impact.
>> >>
>> >> What about the representation clauses? If you do not use Ada for
>> >> system programming, don't try to make Ada200x unusable for this
>> >> purpose.
>> >
>> > Let's allow representation clause support for the tags and tagged types
>> > !
>> 
>> Please show me a representation clause which leave out the tag
>> completely.
> 
> Tags are not needed for tagged objects.  Tags are needed for class-wide
> objects.  If all types were tagged, then a reasonable run-time model
> would *not* store the tag in every (tagged) object, but only in
> pointer-to-classwide and the like.  Or, one could give the programmer a
> choice of whether to store the tag with the object -- it's more
> efficient if you're going to use class-wide types a lot, and less
> efficient if you're not.

Exactly.

I would also like to have this dope-strategy (presently used for array 
types) for discriminants as well. Actually, type tag is a specialized 
discriminant. I wish that we could ensure (for some types) that 
discriminants do not contaminate the value if statically known. The most 
interesting cases are:

1. Dimensioned values:

   type Dimensioned (Unit : SI) is record
      Value : Float;
   end record;
   subtype Speed is Dimensioned (Velocity); -- Discriminant removed

   type Vector (Unit : SI) is array (...) of Dimensioned (Unit);

2. Interval arithmetics:

   type Interval (From : Integer, To : Integer) is null record;

3. Dynamically constrained numerics:

   type My_Word (Range : Integer) is mod Range;
   type My_Integer (Min, Max : Integer) is range Min..Max;
   subtype Int_8 is My_Integer (-128, 127);
   procedure Get (X : in out My_Integer) is
   begin
      Put ("Enter a value in [");
      Put (Integer'Image (X.Min) & ".." & Integer'Image (X.Max));
      Put ("]");
      ...

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

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Pascal Obry wrote:

> 18k11tm001@sneakemail.com (Russ) writes:
> 
>> I don't blame anyone for disliking ++, but += should be your friend.
> 
> Agreed "++" is really ugly (especially when semantic is different
> depending on the position of the operator) but the += style constructions
> are nice. Of course this will be difficult to integrate into Ada now as /=
> is already used...

Do not forget our precious colon! It should be :/= or /:= or :/:=, I 
suppose.

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

Re: Ideas for Ada 200X

[Pascal Obry]

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

> Do not forget our precious colon! It should be :/= or /:= or :/:=, I 
> suppose.

Right! I must be a bit tired to forget that :) So I think it could be
/:= *:= +:= and -:= (operators before the :=).

Pascal.

-- 

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

Re: Ideas for Ada 200X

[Dale Stanbrough]

Marin David Condic <nobody@noplace.com> wrote:

> Lets toss this turd into the pool:[...]
> (Less filling! Tastes great!!!)

I do wish you hadn't put those in the same paragraph!

Dale

Re: Ideas for Ada 200X

[Marin David Condic]

You have a point. :-) I'll try not to mix the two together in the future....

MDC

Dale Stanbrough wrote:
> 
> 
> I do wish you hadn't put those in the same paragraph!
> 



-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Simon Wright]

Marin David Condic <nobody@noplace.com> writes:

>                                                Should a Standard Ada
> Container Library be based on generics or based on tagged types? Let's
> start that debate here and see how far it goes! (Less filling! Tastes
> great!!!)

Only one possible answer there - BOTH!! (which of course is what the
BCs do, and is therefore a Good Thing).

Re: Ideas for Ada 200X

[Preben Randhol]

Wesley Groleau wrote:
>> Changing the meaning of X /= Y would break most programs.
> 
> !  :-)  One more argument _against_ cluttering up
>          Ada's list of operators.

Exactly.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Bill Findlay]

On 31/5/03 12:42, in article uisrrnxzk.fsf@wanadoo.fr, "Pascal Obry"
<p.obry@wanadoo.fr> wrote:
> 
> Right! I must be a bit tired to forget that :) So I think it could be
> /:= *:= +:= and -:= (operators before the :=).

What about and, or, xor, rem and mod? "mod:=" ? I hope not!

I find this proliferation of special notations revolting.

An "idem" feature, meaning, "the same as the destination" and used thus:

1.  I := (idem + 1);  -- or perhaps: (<> + 1); or maybe: (all + 1);

2.  I := (1 - idem);  -- N.B. not possible using any ?:= operator

3.  X := 0.5*(idem + a/idem);

gives a lot more expressive power than update-in-place operations, but
allows the latter to be implemented very easily in most cases that
significant efficiency gains are possible (though not, admittedly,
arithmetic operations overloaded on matrices and other structures for which
conventional, if slightly heavier, procedural notations remain).

The idem notation also documents the programmer's intention more clearly in
the cases (such as 3) in which the RHS subexpression is necessarily the same
as the LHS, but which do not fit the limitations of a ?:= operation.

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

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> 
> += improves readability too! Which is clearer,
> 
> 	A += B

Why? Just because you know the meaning from C++?

If you read the A += B it becomes:

   A plus equals B

> Add(A,B)

Add (To => A, Value => B);

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Bill Findlay]

On 31/5/03 14:42, in article BAFE6FC5.2ECD%yaldnifw@blueyonder.co.uk, "Bill
Findlay" <yaldnifw@blueyonder.co.uk> wrote:
> 
> 3.  X := 0.5*(idem + a/idem);
>
> gives a lot more expressive power than update-in-place operations, but
> allows the latter to be implemented very easily in most cases that
> significant efficiency gains are possible ...
> 
> The idem notation also documents the programmer's intention more clearly in
> the cases (such as 3) in which the RHS subexpression is necessarily the same
> as the LHS, but which do not fit the limitations of a ?:= operation.

It occurs to me that if I had given the example:

4. X = idem * (2.0 - a*idem);

then at least one computer would be able to implement it in a single
instruction ! 8-)

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

Re: Ideas for Ada 200X

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 31 May 2003 10:36:23 -0500 (CDT)
NNTP-Posting-Host: !ZEsB1k-XZg.PFo (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
news:BAFE6FC5.2ECD%yaldnifw@blueyonder.co.uk...
> On 31/5/03 12:42, in article uisrrnxzk.fsf@wanadoo.fr, "Pascal Obry"
> <p.obry@wanadoo.fr> wrote:
> >
> > Right! I must be a bit tired to forget that :) So I think it could be
> > /:= *:= +:= and -:= (operators before the :=).
>
> What about and, or, xor, rem and mod? "mod:=" ? I hope not!
>
> I find this proliferation of special notations revolting.
>
> An "idem" feature, meaning, "the same as the destination" and used thus:
>
> 1.  I := (idem + 1);  -- or perhaps: (<> + 1); or maybe: (all + 1);
>
> 2.  I := (1 - idem);  -- N.B. not possible using any ?:= operator
>
> 3.  X := 0.5*(idem + a/idem);
>
> gives a lot more expressive power than update-in-place operations, but
> allows the latter to be implemented very easily in most cases that
> significant efficiency gains are possible (though not, admittedly,
> arithmetic operations overloaded on matrices and other structures for
which
> conventional, if slightly heavier, procedural notations remain).
>
> The idem notation also documents the programmer's intention more clearly
in
> the cases (such as 3) in which the RHS subexpression is necessarily the
same
> as the LHS, but which do not fit the limitations of a ?:= operation.

Bletch.

Part of the problem is that you insist on the assignment statement paradigm.

The problem with your proposed "idem" construct is that it creates
opportunity for error.

Consider: I := idem + 1; vs. I := item + 1; vs. I := idep + 1;

Now consider the equivalent Oberon:  INC(I);

The programmer's intention in Oberon is unmistakable.

FURTHERMORE, under your "idem" proposal, the semantic interpretation of the
RHS is *UNKNOWN* until the LHS is parsed and translated.  Consider:

  p.all.left.all.right.next.refcnt := idem + 1;

Re: Ideas for Ada 200X

[Bill Findlay]

On 31/5/03 16:31, in article bbai5n$6hm@library1.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

> Bletch.
> Part of the problem is that you insist on the assignment statement paradigm.
> The problem with your proposed "idem" construct is that it creates
> opportunity for error.
> Consider: I := idem + 1; vs. I := item + 1; vs. I := idep + 1;

Consider: item := item  + 1;  vs. item := iter + 1;
Why are your examples any more of a problem?

Anyway, 'idem' is just a placeholder. The alternative syntaxes I suggested
are not subject to these (rather trivial) errors, so I can't take this
objection very seriously.

> Now consider the equivalent Oberon:  INC(I);
> The programmer's intention in Oberon is unmistakable.

Really? FSVO 'unmistakable' perhaps.
Does Oberon make adding 2, multiplying by 10, etc, equally concise and
'unmistakable'?

> FURTHERMORE, under your "idem" proposal, the semantic interpretation of the
> RHS is *UNKNOWN* until the LHS is parsed and translated.  Consider:
> p.all.left.all.right.next.refcnt := idem + 1;

Why is that a disadvantage?
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Bill Findlay wrote:

> On 31/5/03 12:42, in article uisrrnxzk.fsf@wanadoo.fr, "Pascal Obry"
> <p.obry@wanadoo.fr> wrote:
>> 
>> Right! I must be a bit tired to forget that :) So I think it could be
>> /:= *:= +:= and -:= (operators before the :=).
> 
> What about and, or, xor, rem and mod? "mod:=" ? I hope not!

You forgot :**= and unary :+=, :-=, :not=. For example:

X :not=; -- C people will envious! (:-))

> I find this proliferation of special notations revolting.

Rather tasteless, I would better allow:

   procedure "+" (L in out T; R : T);

then one could write:

declare
   X : T := ...;
begin
   X + 1;

> An "idem" feature, meaning, "the same as the destination" and used thus:
> 
> 1.  I := (idem + 1);  -- or perhaps: (<> + 1); or maybe: (all + 1);
>
> 2.  I := (1 - idem);  -- N.B. not possible using any ?:= operator
> 
> 3.  X := 0.5*(idem + a/idem);

And crowning:

4.  I : Integer := idem + 1;  -- OK, just a joke

> gives a lot more expressive power than update-in-place operations, but
> allows the latter to be implemented very easily in most cases that
> significant efficiency gains are possible (though not, admittedly,
> arithmetic operations overloaded on matrices and other structures for
> which conventional, if slightly heavier, procedural notations remain).

I have an alternative / additional proposal. The programmer declares 
in-place operations and instructs the compiler to deduce unary and infix 
operators from them. 

For example:

procedure Inc (X : in out T; By : T);
function "+" (X, Y : T) return T;
for "+" use Inc (X => X, By => Y);

> The idem notation also documents the programmer's intention more clearly
> in the cases (such as 3) in which the RHS subexpression is necessarily the
> same as the LHS, but which do not fit the limitations of a ?:= operation.

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

Re: Ideas for Ada 200X

[Bill Findlay]

On 31/5/03 18:18, in article bbao0u$7icu0$1@ID-77047.news.dfncis.de, "Dmitry
A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> Bill Findlay wrote:
> 
>> On 31/5/03 12:42, in article uisrrnxzk.fsf@wanadoo.fr, "Pascal Obry"
>> <p.obry@wanadoo.fr> wrote:
>>> 
>>> Right! I must be a bit tired to forget that :) So I think it could be
>>> /:= *:= +:= and -:= (operators before the :=).
>> 
>> What about and, or, xor, rem and mod? "mod:=" ? I hope not!
> 
> You forgot :**= and unary :+=, :-=, :not=. For example:
> 
> X :not=; -- C people will envious! (:-))

It was Freudian repression of the unacceptable. 8-)

> Rather tasteless, I would better allow:
> 
>  procedure "+" (L in out T; R : T);
> 
> then one could write:
> 
> declare
>  X : T := ...;
> begin
>  X + 1;

I think this *is* a bit error-prone.
We have a perfectly good syntax for changing a variable, namely assignment.
The fewer notations there are for the same thing, the better, surely.
 
> 
> And crowning:
> 
> 4.  I : Integer := idem + 1;  -- OK, just a joke

8-)

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

Re: Ideas for Ada 200X (GNAT.IO_Aux.Get_Line)

[Richard Riehle]

"Warren W. Gay VE3WWG" wrote:

> Another example: Include a standard version of GNAT.IO_Aux.Get_Line
> as part of Ada.Text_IO for Ada0Y. Why should people have to keep
> rolling their own, or relying on GNAT code for this?

While we're  making suggestions about Text_IO, why not change
the Get operations to functions for Scalar types.   This is one of
the important changes Jerry Van Dijk made in CONSOLE_IO.  It
works great.

Richard Riehle

Re: Ideas for Ada 200X

[Richard Riehle]

Gautier Write-only wrote:

> Frank:
>
> > What about the possibility of commenting several lines like /* ...... */?
>
> Hey cool! I would add the possibility of nesting several of
> such comments, ... [ snipped several other ideas ] ...

Right.  Perhaps we could even return to the good old days
of Fortran and COBOL and permit line numbers in some
specified locations at the end of each line.   :-)

Richard Riehle

Re: Ideas for Ada 200X

[Russ]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<6vWcnTWjF83bD0qjXTWcpA@gbronline.com>...
> > And let's not forget that +=, -=, etc. also allow for more efficient
> > in-place vector/matrix operations because they avoid the need for a
> > temporary. If you don't understand this, that's OK, but please don't
> > argue with me because you will be wrong.
> 
> Neither
>     A := A + B;
> nor
>     A += B; -- if it existed in Ada
> 
> would need a temporary except when required by checking rules
> and exception rules.  If one needs a temporary, the other does.
> After all, they are the same, are they not?

No, they aren't the same. The result is the same, but the second form
can be implemented much more efficiently. The first form requires the
construction of a temporary object to hold the sum, then it must copy
the temp back over to A. The latter can be implemented without a temp
and without the extra copy operation.

You would be correct if += were implemented in terms of +, but that
would be the wrong way.

Re: Ideas for Ada 200X

[Richard Riehle]

Robert A Duff wrote:

> More importantly, a typical Ada program has hundreds of integer types,
> so putting "i" at the front of variable names doesn't tell you much of
> anything interesting.

In fact, we can put the type in front of a value using attribute notation
for disambiguation.   For example,

               type Signal is (Red, Yellow, Green);
               type Color is (Red, Orange, Yellow, Green, Blue, Indigo, Violet);

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

               for I in Red..Green loop ... end loop;

will be ambiguous when Red through Green are both directly visible.   Instead,
we might code,

               for I in Signal'Red .. Signal'Green   ...    end loop;

The language does not prevent me from using this notation even when it
is unnecessary.   So, if you really want to do something equivalent to
Hungarian notation, go ahead.   However, it is usually quite superfluous.

Richard Riehle

                       Oh, and I do realize there are better ways to
                       lay out the code in my example, but the example
                       is intended to illustrate a different point than good
                       coding practice.         RR

Re: Ideas for Ada 200X

[Richard Riehle]

Pascal Obry wrote:

> Agreed "++" is really ugly  ...

But if we had it, we could call Ada 200X, Ada ++.   :-)

Richard Riehle

Re: Ideas for Ada 200X

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 31 May 2003 14:21:44 -0500 (CDT)
NNTP-Posting-Host: !aga/1k-VNTCkL\ (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
news:BAFE9115.2EDC%yaldnifw@blueyonder.co.uk...
> On 31/5/03 16:31, in article bbai5n$6hm@library1.airnews.net, "John R.
> Strohm" <strohm@airmail.net> wrote:
>
> > Bletch.
> > Part of the problem is that you insist on the assignment statement
paradigm.
> > The problem with your proposed "idem" construct is that it creates
> > opportunity for error.
> > Consider: I := idem + 1; vs. I := item + 1; vs. I := idep + 1;
>
> Consider: item := item  + 1;  vs. item := iter + 1;
> Why are your examples any more of a problem?
>
> Anyway, 'idem' is just a placeholder. The alternative syntaxes I suggested
> are not subject to these (rather trivial) errors, so I can't take this
> objection very seriously.
>
> > Now consider the equivalent Oberon:  INC(I);
> > The programmer's intention in Oberon is unmistakable.
>
> Really? FSVO 'unmistakable' perhaps.
> Does Oberon make adding 2, multiplying by 10, etc, equally concise and
> 'unmistakable'?

Empirically, those operations do not happen nearly as often as the canonical
I = I + 1.  See Knuth, "An Empirical Study of FORTRAN Programs", ca. 1970,
and various follow-on papers in the decades since.

> > FURTHERMORE, under your "idem" proposal, the semantic interpretation of
the
> > RHS is *UNKNOWN* until the LHS is parsed and translated.  Consider:
> > p.all.left.all.right.next.refcnt := idem + 1;
>
> Why is that a disadvantage?

Preference, to a fair extent.  If I have to change

<some_lvalue_expr> := idem op expr;

to

shadow := idem op expr;
<some_lvalue_expr> := shadow; -- This happens ALL THE TIME in device
drivers.

I'd rather not have to worry about the implications of not doing fetch *AND*
store on the device register.  I've gotten burned on this kind of thing
enough times to be wary.

Re: Ideas for Ada 200X

[Robert A Duff]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> An "idem" feature, meaning, "the same as the destination" and used thus:
> 
> 1.  I := (idem + 1);  -- or perhaps: (<> + 1); or maybe: (all + 1);
> 
> 2.  I := (1 - idem);  -- N.B. not possible using any ?:= operator
> 
> 3.  X := 0.5*(idem + a/idem);

I like it.  I'm not sure I like the word "idem", but I like the concept.
It serves the same purpose as pronouns in English (not that English is
a good example of a "safe" language).

- Bob

Re: Ideas for Ada 200X

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Sat, 31 May 2003 16:47:11 -0500 (CDT)
NNTP-Posting-Host: ![E:B1k-VXj8[M6 (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccbrxic21e.fsf@shell01.TheWorld.com...
> Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
>
> > An "idem" feature, meaning, "the same as the destination" and used thus:
> >
> > 1.  I := (idem + 1);  -- or perhaps: (<> + 1); or maybe: (all + 1);
> >
> > 2.  I := (1 - idem);  -- N.B. not possible using any ?:= operator
> >
> > 3.  X := 0.5*(idem + a/idem);
>
> I like it.  I'm not sure I like the word "idem", but I like the concept.
> It serves the same purpose as pronouns in English (not that English is
> a good example of a "safe" language).

OK, so what are the implications for parsing expressions?

For example:

What does
  I := idem + idem;
mean?

How about

  do_some_proc(foo, baz, idem);

Does "idem" refer back to foo, baz, or do_some_proc?

Should we allow, or not allow,

  J := idem;

Why or why not?  What are the semantics?

In particular, consider:

DEVICE_DATA_REGISTER : BYTE;
for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
   ...
DEVICE_DATA_REGISTER := 16#40#;
DEVICE_DATA_REGISTER := idem;
DEVICE_DATA_REGISTER := idem + 1;

How many times should DEVICE_DATA_REGISTER be *read* by the above code
fragment?  Why?

Re: Ideas for Ada 200X

[Bill Findlay]

On 31/5/03 18:18, in article bbao0u$7icu0$1@ID-77047.news.dfncis.de, "Dmitry
A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> And crowning:
> 
> 4.  I : Integer := idem + 1;  -- OK, just a joke

Of course:

   type PT is access PT;
...
   P : PT := idem;

is just fine! 8-)

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

Re: Ideas for Ada 200X

[Marin David Condic]

O.K. Now, should they be static or dynamic allocation? ;-)

You see the point? We can keep specifying "A vs B" design constraints 
and the answer "A" will make the "B" crowd unhappy, "B" makes the "A" 
crowd unhappy and "Both" will double the implementation work, create 
endless confusion for the user, increases the cost of support, etc. The 
end result? We get "Neither".

Look at it this way: If it was Microsoft that was building it, you'd get 
some design team together, tell them "This is what Marketing says people 
want..." and get them to pick one (that would be "1" with a capital "1") 
design and go off and build it. You then bundle it into everything you 
sell, advertise to the developer community that "This is all the rage 
and the best answer to everything" and then sit back and watch it make 
you money. Hence, MSVC++ has a de facto "standard" library chock full of 
all sorts of wonderful stuff that makes development get done faster and 
Ada stands on the sidelines saying "Well you can always go build your 
own or use one of several dozen packages you can go find on the Internet 
somewhere or go write bindings to the MFC library...."

Ada can't possibly please every conceivable user, so it has to pick a 
direction and go there. If you had some sort of vendor-agreed-to forum 
that was willing to say "Our marketing indicates that if we had a 
library containing X and Y and Z done within design constraints A and B 
and C, our customers would like that. So here's your requirements. Go 
build something that looks like that." you might get a usable result. 
Nobody has the deep pockets to be able to say "Lets build one of 
everything and let the market decide." Even if you did, it would only be 
confusing for the end user and they'd retreat to what they know in order 
to achieve freedom from choice.

MDC


Simon Wright wrote:
> Marin David Condic <nobody@noplace.com> writes:
> 
> 
>>                                               Should a Standard Ada
>>Container Library be based on generics or based on tagged types? Let's
>>start that debate here and see how far it goes! (Less filling! Tastes
>>great!!!)
> 
> 
> Only one possible answer there - BOTH!! (which of course is what the
> BCs do, and is therefore a Good Thing).


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Bill Findlay]

On 31/5/03 20:18, in article bbavc7$ns8@library1.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

>> Does Oberon make adding 2, multiplying by 10, etc, equally concise and
>> 'unmistakable'?
> 
> Empirically, those operations do not happen nearly as often as the canonical
> I = I + 1.  See Knuth, "An Empirical Study of FORTRAN Programs", ca. 1970,
> and various follow-on papers in the decades since.

Agreed. But we are discussing ?:= operators here, not just increment.
As I said in another post, "We have a perfectly good syntax for changing a
variable, namely assignment. The fewer notations there are for the same
thing, the better, surely."

> ...  If I have to change
> 
> <some_lvalue_expr> := idem op expr;
> 
> to
> 
> shadow := idem op expr;
> <some_lvalue_expr> := shadow; -- This happens ALL THE TIME in device drivers.
>
> I'd rather not have to worry about the implications of not doing fetch *AND*
> store on the device register.  I've gotten burned on this kind of thing
> enough times to be wary.

You seem to be making major assumptions about the target architecture and
about the semantics of "INC(<some_lvalue_expr>)"  or "<some_lvalue_expr>++"

On many (if not most) ISPs, the fetch and store would be unavoidable, even
for apparently update-in-place operations. On other, regrettably popular,
ISPs there might well be no fetch. So what?

Constraining a high-level language to get architecture-dependent effects is
not the way to go IMO. That's what machine-code inserts are for.
(Or, better, abstracted operations that might use either the latter, or
language-defined operations, *if* the compiler *happens* to give what you
need.)

Further,

On 31/5/03 22:38, in article bbb7sv$8s2@library2.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

> OK, so what are the implications for parsing expressions?

I don't see any significant implications for *parsing* as such.
'idem' or equivalent refers to the variable on the LHS of an assignment.
It is meaningless elsewhere.

> For example:
> What does
>   I := idem + idem;
> mean?

What it seems to.
 
> How about
> 
> do_some_proc(foo, baz, idem);
> 
> Does "idem" refer back to foo, baz, or do_some_proc?

No.
 
> Should we allow, or not allow,
> 
> J := idem;
> 
> Why or why not?  What are the semantics?

The precise semantics are up for discussion, but hardly seem difficult.
I can immediately think of two reasonable definitions.

1. For the assignment:
   V := f(idem);
We set
   A := V'access; 
and V and 'idem' in the assignment are replaced by A.all, passim:
   A.all := f(A.all);

2. We define the anonymous procedure:
   procedure assign_f_to_V (V : in out T) is
   begin V := f(V); end;
and replace the assignment by the call:
   assign_f_to_V(V);

In each case all reasonable optimizations would be permitted, nay
encouraged. 

I'm sure these first cuts would need to be refined, and I'm sure there are
other approaches.

> In particular, consider:
> 
> DEVICE_DATA_REGISTER : BYTE;
> for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
>  ...
> DEVICE_DATA_REGISTER := 16#40#;
> DEVICE_DATA_REGISTER := idem;
> DEVICE_DATA_REGISTER := idem + 1;
> 
> How many times should DEVICE_DATA_REGISTER be *read* by the above code
> fragment?  Why?

I note that DEVICE_DATA_REGISTER  is not declared volatile.
How many times would it be read by:

DEVICE_DATA_REGISTER := 16#40#;
DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER;
DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER + 1;

?

The answers 2, 1 and 0 all seem reasonable to me.
Why do you think the language *should* define this?

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

Re: Ideas for Ada 200X

[Preben Randhol]

Richard Riehle wrote:
> Pascal Obry wrote:
> 
>> Agreed "++" is really ugly  ...
> 
> But if we had it, we could call Ada 200X, Ada ++.   :-)

What's wrong with Ada'Inc ? ;-)

Today there was a documentary on Ada Byron. I didn't get to see it, but
my VCR was kind enough to tape it so I will ASAP :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

John R. Strohm wrote:
> 
> What does
>   I := idem + idem;
> mean?

I := Idem*2;

;-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Robert A Duff]

"John R. Strohm" <strohm@airmail.net> writes:

> Should we allow, or not allow,
> 
>   J := idem;
> 
> Why or why not?  What are the semantics?

Should we allow:

    J := J;

?  The correct answer is "Who cares?".  ;-)

In any case there doesn't seem to be any big semantic difficulty here.

> In particular, consider:
> 
> DEVICE_DATA_REGISTER : BYTE;
> for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
>    ...
> DEVICE_DATA_REGISTER := 16#40#;
> DEVICE_DATA_REGISTER := idem;
> DEVICE_DATA_REGISTER := idem + 1;
> 
> How many times should DEVICE_DATA_REGISTER be *read* by the above code
> fragment?  Why?

Well, there's no pragma Atomic or Volatile, so...

If there were, I would say "twice".

- Bob

Re: Ideas for Ada 200X

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 31 May 2003 19:17:47 -0500 (CDT)
NNTP-Posting-Host: !_Ga)1k-XoM*B/H (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
news:BAFEF028.2F2D%yaldnifw@blueyonder.co.uk...
> On 31/5/03 20:18, in article bbavc7$ns8@library1.airnews.net, "John R.
> Strohm" <strohm@airmail.net> wrote:
>
> >> Does Oberon make adding 2, multiplying by 10, etc, equally concise and
> >> 'unmistakable'?
> >
> > Empirically, those operations do not happen nearly as often as the
canonical
> > I = I + 1.  See Knuth, "An Empirical Study of FORTRAN Programs", ca.
1970,
> > and various follow-on papers in the decades since.
>
> Agreed. But we are discussing ?:= operators here, not just increment.
> As I said in another post, "We have a perfectly good syntax for changing a
> variable, namely assignment. The fewer notations there are for the same
> thing, the better, surely."
>
> > ...  If I have to change
> >
> > <some_lvalue_expr> := idem op expr;
> >
> > to
> >
> > shadow := idem op expr;
> > <some_lvalue_expr> := shadow; -- This happens ALL THE TIME in device
drivers.
> >
> > I'd rather not have to worry about the implications of not doing fetch
*AND*
> > store on the device register.  I've gotten burned on this kind of thing
> > enough times to be wary.
>
> You seem to be making major assumptions about the target architecture and
> about the semantics of "INC(<some_lvalue_expr>)"  or
"<some_lvalue_expr>++"
>
> On many (if not most) ISPs, the fetch and store would be unavoidable, even
> for apparently update-in-place operations. On other, regrettably popular,
> ISPs there might well be no fetch. So what?
>
> Constraining a high-level language to get architecture-dependent effects
is
> not the way to go IMO. That's what machine-code inserts are for.
> (Or, better, abstracted operations that might use either the latter, or
> language-defined operations, *if* the compiler *happens* to give what you
> need.)
>
> Further,
>
> On 31/5/03 22:38, in article bbb7sv$8s2@library2.airnews.net, "John R.
> Strohm" <strohm@airmail.net> wrote:
>
> > OK, so what are the implications for parsing expressions?
>
> I don't see any significant implications for *parsing* as such.
> 'idem' or equivalent refers to the variable on the LHS of an assignment.
> It is meaningless elsewhere.
>
> > For example:
> > What does
> >   I := idem + idem;
> > mean?
>
> What it seems to.
>
> > How about
> >
> > do_some_proc(foo, baz, idem);
> >
> > Does "idem" refer back to foo, baz, or do_some_proc?
>
> No.
>
> > Should we allow, or not allow,
> >
> > J := idem;
> >
> > Why or why not?  What are the semantics?
>
> The precise semantics are up for discussion, but hardly seem difficult.
> I can immediately think of two reasonable definitions.
>
> 1. For the assignment:
>    V := f(idem);
> We set
>    A := V'access;
> and V and 'idem' in the assignment are replaced by A.all, passim:
>    A.all := f(A.all);
>
> 2. We define the anonymous procedure:
>    procedure assign_f_to_V (V : in out T) is
>    begin V := f(V); end;
> and replace the assignment by the call:
>    assign_f_to_V(V);
>
> In each case all reasonable optimizations would be permitted, nay
> encouraged.
>
> I'm sure these first cuts would need to be refined, and I'm sure there are
> other approaches.
>
> > In particular, consider:
> >
> > DEVICE_DATA_REGISTER : BYTE;
> > for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
> >  ...
> > DEVICE_DATA_REGISTER := 16#40#;
> > DEVICE_DATA_REGISTER := idem;
> > DEVICE_DATA_REGISTER := idem + 1;
> >
> > How many times should DEVICE_DATA_REGISTER be *read* by the above code
> > fragment?  Why?
>
> I note that DEVICE_DATA_REGISTER  is not declared volatile.

You are correct.  I am an old Ada programmer, and I am not up to speed on
Ada95.

On the other hand, I also did not bother to say whether DEVICE_DATA_REGISTER
was even readable at all.  I do device drivers often enough that write-only
registers, that physically cannot be read, that hang the bus if any attempt
is made to read them, are not unusual to me.

> How many times would it be read by:
>
> DEVICE_DATA_REGISTER := 16#40#;
> DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER;
> DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER + 1;
>
> ?
>
> The answers 2, 1 and 0 all seem reasonable to me.
> Why do you think the language *should* define this?

Predictability and portability.

Recall that Ada was intended for broad use across a certain very critical
domain: military embedded systems programming.  The intention was that there
would be ONE language that worked the SAME way EVERYWHERE.  The Department
of Defense already knew what would happen if the language was allowed to be
different, or have different semantics, on different implementations.  (They
only had to look at CMS-2 for a good reminder.)

If the language does not define the semantics of that particular
pathological case, then the risk occurs that a toolset update down the road
would break the existing code.  That scenario, in my personal opinion, is
100% bad.

Now, an argument can be made for machine code insertions and/or explicit
assembly language for this kind of thing.  However, the trend on modern
processor design is to make the hardware very unpredictable, to the point
that the programmer, OR THE COMPILER, may issue the instructions in one
order, and the hardware actually execute them in a different order, and,
worse, that order may vary from run to run.  This can be VERY DANGEROUS when
you are doing device drivers.  You usually don't want to apply the defib
pulse until AFTER you have disconnected the EKG leads (unless your EKG
buffer amps are VERY robust indeed!).

Re: Ideas for Ada 200X

[Bill Findlay]

On 1/6/03 01:15, in article bbbgnb$ia3@library1.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

>>> In particular, consider:
>>> 
>>> DEVICE_DATA_REGISTER : BYTE;
>>> for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
>>>  ...
>>> DEVICE_DATA_REGISTER := 16#40#;
>>> DEVICE_DATA_REGISTER := idem;
>>> DEVICE_DATA_REGISTER := idem + 1;
>>> 
>>> How many times should DEVICE_DATA_REGISTER be *read* by the above code
>>> fragment?  Why?
>> 
>> I note that DEVICE_DATA_REGISTER  is not declared volatile.
> 
> You are correct.  I am an old Ada programmer, and I am not up to speed on
> Ada95.

Does Ada 83 define this number? I'd be surprised!
If you declare it volatile in Ada 95 then you get 2 read accesses (assuming
the equivalent code below). What more certainty do you need?
 
> On the other hand, I also did not bother to say whether DEVICE_DATA_REGISTER
> was even readable at all.  I do device drivers often enough that write-only
> registers, that physically cannot be read, that hang the bus if any attempt
> is made to read them, are not unusual to me.

If your location is write-only, why are you trying to read from it?
Either the h/w location supports update-in-place or it does not.
Either it supports writes or not.
Either it supports reads or not.

So what?

If an Ada implementation presently lets you control the way that location is
accessed, using necessarily implementation-dependent knowledge to get the
code you need, then it could do so for any new constructs too.

>> How many times would it be read by:
>> 
>> DEVICE_DATA_REGISTER := 16#40#;
>> DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER;
>> DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER + 1;
>> 
>> ?
>> 
>> The answers 2, 1 and 0 all seem reasonable to me.
>> Why do you think the language *should* define this?
> 
> Predictability and portability.

Well, it is predictable and portable if you ensure that it has that
property, and it isn't if you don't. How could things be otherwise?
 
> If the language does not define the semantics of that particular
> pathological case, then the risk occurs that a toolset update down the road
> would break the existing code.  That scenario, in my personal opinion, is
> 100% bad.

You seem to be asking, not just that the semantics be defined, but that they
be defined in a particular, invariable way. Not the same thing.
I'm all for predictability and portability, but I think that modern hardware
and modern software environments make what you seem to be asking for
unachievable, unless the language is so encumbered with restrictions as to
verge on the crippled.

> Now, an argument can be made for machine code insertions and/or explicit
> assembly language for this kind of thing.  However, the trend on modern
> processor design is to make the hardware very unpredictable, to the point
> that the programmer, OR THE COMPILER, may issue the instructions in one
> order, and the hardware actually execute them in a different order, and,
> worse, that order may vary from run to run.  This can be VERY DANGEROUS when
> you are doing device drivers.  You usually don't want to apply the defib
> pulse until AFTER you have disconnected the EKG leads (unless your EKG
> buffer amps are VERY robust indeed!).

Quite so. 
You have to write your code so these indeterminacies provably do not matter.
In the example you gave that is easy. In general it is hard.

What do you want the semantics of Ada to do about this?

It can do little more than it does now, AFAIKS, and that is: not much.

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

RE: Ideas for Ada 200X

[Robert C. Leif]

Why not make a combination consisting of a tagged type inside of a generic?
Most of the types and objects of the tagged type are generic. These
Metaclasses are a good model of the real world.
Bob Leif

-----Original Message-----
From: Marin David Condic [mailto:nobody@noplace.com] 
Sent: Saturday, May 31, 2003 3:10 PM
To: comp.lang.ada@ada.eu.org

O.K. Now, should they be static or dynamic allocation? ;-)

You see the point? We can keep specifying "A vs B" design constraints 
and the answer "A" will make the "B" crowd unhappy, "B" makes the "A" 
crowd unhappy and "Both" will double the implementation work, create 
endless confusion for the user, increases the cost of support, etc. The 
end result? We get "Neither".

Look at it this way: If it was Microsoft that was building it, you'd get 
some design team together, tell them "This is what Marketing says people 
want..." and get them to pick one (that would be "1" with a capital "1") 
design and go off and build it. You then bundle it into everything you 
sell, advertise to the developer community that "This is all the rage 
and the best answer to everything" and then sit back and watch it make 
you money. Hence, MSVC++ has a de facto "standard" library chock full of 
all sorts of wonderful stuff that makes development get done faster and 
Ada stands on the sidelines saying "Well you can always go build your 
own or use one of several dozen packages you can go find on the Internet 
somewhere or go write bindings to the MFC library...."

Ada can't possibly please every conceivable user, so it has to pick a 
direction and go there. If you had some sort of vendor-agreed-to forum 
that was willing to say "Our marketing indicates that if we had a 
library containing X and Y and Z done within design constraints A and B 
and C, our customers would like that. So here's your requirements. Go 
build something that looks like that." you might get a usable result. 
Nobody has the deep pockets to be able to say "Lets build one of 
everything and let the market decide." Even if you did, it would only be 
confusing for the end user and they'd retreat to what they know in order 
to achieve freedom from choice.

MDC


Simon Wright wrote:
> Marin David Condic <nobody@noplace.com> writes:
> 
> 
>>                                               Should a Standard Ada
>>Container Library be based on generics or based on tagged types? Let's
>>start that debate here and see how far it goes! (Less filling! Tastes
>>great!!!)
> 
> 
> Only one possible answer there - BOTH!! (which of course is what the
> BCs do, and is therefore a Good Thing).


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

RE: Ideas for Ada 200X

[Dmitry A. Kazakov]

Robert C. Leif wrote:

> Why not make a combination consisting of a tagged type inside of a
> generic? Most of the types and objects of the tagged type are generic.
> These Metaclasses are a good model of the real world.

What do you mean? Unlike C++, Ada has no generic types.

The problem is whether the [generic] library has to be based on static vs. 
dynamic polymorphism.

A. Static polymorphism stands for generics (sometimes also for overloading). 
A generic subroutine is polymorphic in the sense that its body is 
parametrized by the formal parameters.

B. Dynamic polymorphism stands for tagged types (also discriminated types). 
A dispatching subroutine is polymorphic because it may have different 
bodies (for different types)

Thus you have to choose either A or B. Both approaches have advantages and 
disadvantages. Theoretically B contains A, but practically it is either 
impossible or less effective than A in many *very* important cases. 
Therefore one should clearly inderstand the consequences of any decision 
made. Especially because neither A nor B have not yet finished their 
evolution in Ada (and other languages).

So any wrong decision for a such important thing as the library which will 
be used practically everywhere, might freeze present, rather unfortunate, 
state of OO in Ada (in other languages it is not better).

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

Re: Ideas for Ada 200X (GNAT.IO_Aux.Get_Line)

[Warren W. Gay VE3WWG]

Richard Riehle wrote:
> "Warren W. Gay VE3WWG" wrote:
>>Another example: Include a standard version of GNAT.IO_Aux.Get_Line
>>as part of Ada.Text_IO for Ada0Y. Why should people have to keep
>>rolling their own, or relying on GNAT code for this?
> 
> While we're  making suggestions about Text_IO, why not change
> the Get operations to functions for Scalar types.   This is one of
> the important changes Jerry Van Dijk made in CONSOLE_IO.  It
> works great.
> 
> Richard Riehle

This kinda gets back to the functions and side-effects argument (the
object that File_Type points to is undergoing state changes). I think
many would be happy to break that rule for GNAT.IO_Aux.Get_Line, since
there is no other way to read in a Ada string without knowing in
advance its size. But extending this to scalars might be going farther
down that road than is "comfortable".

For my $0.02 worth, the scalars don't matter. The string is the problem
child that needs a solution.

Warren.

RE: Ideas for Ada 200X

[Robert C. Leif]

Below is a fragment of source for what I hope is an improvement on bounded
strings. It is to be extensible and have the functionality of XML strings.
Three different packages are needed to cover 8, 16, and 32 bit characters,
because common parents do not exist for Ada characters, strings, and bounded
strings.

I had a similar structure in R. C. Leif and S. B. Leif, "Ada in Embedded
Boards for Scientific and Medical Instruments", Proceedings, ACM SIGAda
Annual International Conference (SIGAda '98), S. Carlson, Proceedings Chair,
M. Feldman, Program Chair, pp. 114-120, 1998.

Bob Leif 
------------------------------------------------------------------
with Ada.Strings.Wide_Bounded; --For 8 bits similar with 
     --Ada.Strings.Bounded;
with Pattern16_Pkg;
with Ada.Strings;
with Character_Sets16;
with Strings8_16_32_Pkg;
with Ada.Characters;
with  Ada.Characters.Wide_Latin_1;
generic
   Max_Bd_Length   : Positive;  
   Min_Bd_Length   : Positive                              := 1;  
   Character16_Set : Character_Sets16.Character16_Set_Type :=
Character_Sets16.Latin_1_16_Char_Set;  
   Pattern         : Pattern16_Pkg.Pattern_Bd16_Type       :=
Pattern16_Pkg.Null_Pattern_Bd16;



type Generic_Bd16_W_Char_Set_Type is tagged private;

private

   type Generic_Bd16_W_Char_Set_Type is tagged
      record
      Generic_Bd16_Part    : Generic_Bd16_Type    := Null_Generic_Bd;
      Character16_Set_Part : Character16_Set_Type := Character16_Set;
      Min_Bd_Length_Part : Positive           := Min_Bd_Length;
      Pattern_Part       : Pattern_Bd16_Type    := Null_Pattern_Bd16;
      --This permits the Character16_Set to be specified at instantiation
      --and defaults to Latin_1.
   end record;
-------------------------------------------------------------------

"The Generic_Port package contains Port_Representation_Type, which is tagged
private. This record after instantiation and the subsequent addition of the
actual layout of the register, creates a record which describes the port and
the data it inputs or outputs."

type Port_Representation_Type is tagged
record

Port_Part: Port_Type := Port_Value;
Register_Address_Part : Register_Address_Type := Register_Address;
Data_Direction_Part : Data_Direction_Type := Data_Direction;
Port_Object_Name_Part : Port_Object_Name_Type
     := Port_Object_Name;
end record;

Since Port_Type, Port_Value, Register_Address_Type, Register_Address,
Data_Direction_Type Data_Direction, and Port_Object_Name are all generic,
all types of computer ports can be modeled and manipulated by the
subprograms contained in the generic. The actual modeling of the port
content occurs after the instantiation. The use of generic type, permits
the Port_Value to be 8, 16, 32, etc. bits wide. Similarly, the
Register_Address can be a memory or port location. The procedure
Write_Port_Representation stores the contents of the tagged record
in the Log_File; and the procedure Create_Port is employed when the second
port of the same type needs to be created.
--------------------------------------------------------------------------

-----Original Message-----
From: Dmitry A. Kazakov [mailto:mailbox@dmitry-kazakov.de] 
Sent: Sunday, June 01, 2003 2:19 AM
To: comp.lang.ada@ada.eu.org

Robert C. Leif wrote:

> Why not make a combination consisting of a tagged type inside of a
> generic? Most of the types and objects of the tagged type are generic.
> These Metaclasses are a good model of the real world.

What do you mean? Unlike C++, Ada has no generic types.

The problem is whether the [generic] library has to be based on static vs. 
dynamic polymorphism.

A. Static polymorphism stands for generics (sometimes also for overloading).

A generic subroutine is polymorphic in the sense that its body is 
parametrized by the formal parameters.

B. Dynamic polymorphism stands for tagged types (also discriminated types). 
A dispatching subroutine is polymorphic because it may have different 
bodies (for different types)

Thus you have to choose either A or B. Both approaches have advantages and 
disadvantages. Theoretically B contains A, but practically it is either 
impossible or less effective than A in many *very* important cases. 
Therefore one should clearly inderstand the consequences of any decision 
made. Especially because neither A nor B have not yet finished their 
evolution in Ada (and other languages).

So any wrong decision for a such important thing as the library which will 
be used practically everywhere, might freeze present, rather unfortunate, 
state of OO in Ada (in other languages it is not better).

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

Re: Ideas for Ada 200X (Ada.Sockets, enlightened)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> Warren W. Gay wrote:
> 
>>But going from being a "Good Thing" to "the only thing we need" is
>>an entirely different matter.  If you only plan for TCP in your
>>socket support, you will have an "unwashed mess of package(s)"
>>which will be ugly or difficult to extend for other important
>>network functionality. Some of which, may not be well understood or
>>anticipated at this time.
> 
> I don't want to extend it. 

But this is the problem isn't it?  Your needs may be simple, but
others needs are definitely not.

 > I or sombody else may want to make its interface
> a subset of a more complete socket library. Or possibly make the simple
> socket library an interface to a more complete library.

It is easier to provide a "simpler interface" from a more complete
(and thus more complicated interface). I sense that you've not been
using Ada very long. Ada has very strict rules, including package
visibility rules. If you get your package hierarchy wrong, you'll
paint yourself into a corner. You'll see ;-)

>>BTW, you _will_ want Naming services support. Without them, you'll
>>not connect to anything, except explicity by IP number. ;-)
> 
> There is no problem using DNS under the hood in such a library, but there is
> no need to give the job of handling DNS resolution to the user.(S)he don't
> want to know.

They might not "want to know", but there often is no choice in that.
Yes, for TCP/IP, you can make assumptions about what a string represents
and do the necessary lookups on their behalf (IIRC, Java does this). But 
there are a number of situations where things are much more complicated 
than that.

Here's one: You want to connect to a web server, but you're not
getting any response (the web server is down). Yet, if you were to
use the name server in a more advanced way, you could find out that 
there are alternative web servers (all having the same name, but 
possessing different IP numbers).

Doing a lookup today on www.yahoo.com, I saw 9(!) different IP#'s that
can be used to reach a web server. An application exploiting that 
information could bypass the one server that is down, but trying one of 
the other 8. Your "simplified" application would have to report a 
failure to connect.

So your needs might be simple, but simplified libraries don't help 
everyone else that are solving more difficult problems.

>>Ada streams and endian issues are also important. Write a program
>>that uses a socket between two endian different machines and the
>>endian issue becomes painfully important.  This also shows up
>>in the strangest places. My APQ PostgreSQL package lets you use
>>Ada streams to write blobs to the database. Well, guess what. If
>>you have machines of a different endian persuation trying to read
>>back those blobs written by a different endian persuation (with
>>Ada streams), then "they ain't right". Right now, I live with that
>>limitation because there is no elegant way to fix this.
> 
> You will create confusion by adding things the user does not need.

But there are _many_ users, with _many_ different needs. What you want
is something real simple. This serves only a small portion of the
overall community.

Part of the challenge for standards and library writers is striking
a comfortable balance between simplicity (elegance) and general
utility (functionality). And it does require careful planning and
compromise. But beware: if you compromise too much towards a simple
library, you will only be able to address simple needs. Additionally,
in Ada, this can be difficult to extend later (more on that later).

> A simple
> library is most likely to be used to echanging textual messages. Once the
> user starts doing binary stuff (s)he will know more or simply work around
> the problem.

This is the kind of problem that people want to solve. They don't want 
to have to write Ada bindings to "work around the problem". The problem 
is that the library doesn't exist in standard form. You may only want to 
exchange text, but many here need to much more than that.

With no attempt to offend here, but if you want a simple environment to 
learn in, then there are other environments like BASIC. For networking, 
Java has a simple network model, but for more difficult problem spaces, 
it too has "problems".

> By starting to add features you shoot down in glorious techicolour flames
> the concept of a simple library that does one thing well.

There are many computing problems that are anything but simple. 
Networking, is one of them. Yes, you can do simple networking, but 
simple networking only solves simple network problems. If your
problems are always simple, then good for you.

I am not interested in "adding features". I am interested however, in a 
complete solution. Microsoft sells features (flying folders and animated 
paperclips etc.). We in comp.lang.ada are interested in serious 
solutions to programming problems. Some programming problems are very 
serious, and have a bearing on the safety of human lives.

You're obviously fond of the simplicity argument so let's review 
Einstein's statement that "things should be simple, but not simpler":

You've focused on the phrase "things should be simple". But Einstein was 
very careful to add "but not simpler". This means that if the solution 
is too simple, then it does not solve the problem (in the case of 
physics, this means that the theory does not map to reality). A simple 
but _complete_ solution is elegant. A simple but incomplete solution is 
not only ugly, but is by definition "incomplete".

The "earth is in the center of the universe" theory was very attractive 
  because of its simplicity. Yet today, you don't think that way, 
because you have been trained to know that the universe is more 
complicated than that. To go back to that kind of thinking with what you 
know, would be regressive.

Let's not regress in what we've learned about networking to date.

 > You obliterate the
> ability for an ordinary user to understand and use the library. You drown
> userful information in useless gobbledegoook.

"Gobbledegook" may be the way you see it now. After your apprenticeship
is over, you will see it in a different light. I had very little respect 
for Calculus before I learned how to handle differentials and perform 
integrations. Before I was trained in these things, calculus looked like 
a bunch of "Greek stuff". After I learned what it was about, it became a 
powerful tool in my hands. You too can eventually reach
"enlightenment". ;-)

> The road to hell is paved with good intentions and creeping featurism.
> Resist!!!!
> 
> Keep it simple!

Your "good intentions" or mine? You have good intentions, but they will
paint you into a corner if you focus on simplicity only. The solution 
must also be complete, or at least allow it to be complete someday. With
the strict Ada visibility rules of child packages, and the danger of 
circular package references (which won't compile), you really do have to 
"plan ahead". Anyone that has written Ada libraries as a set of packages 
learns this lesson (sometimes we continue to re-learn it ;-)

If you only plan for the simple, you'll be stuck there. The only way out 
will be to tick people off by making wholesale package changes later. 
NOBODY wants those kinds of changes. What we decide today, we will be 
stuck with for another 10 years. Probably very much longer than that.

I hope that helps to enlighten. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

RE: Ideas for Ada 200X

[Robert C. Leif]

Since Ada lacks the ultimate parent types of some its types, such as numbers
and characters, would it be possible to create generic versions of these
types. For instance, a new package Generic_Types could contain Number,
Character, and String. Obviously, it would be utterly inadvisable to
overload the names of any existing types. 
Generic_Types.Number would be a place holder for any type of number
including all of the versions of integers, floats, fixed points, and
decimals.  Generic_Types.Character would be a place holder for 8, 16, and 32
bit character or, as I would prefer, any size character with the present 8
and 16 and future 32 bit versions being instantiations. A generic string,
unbounded, or bounded string could be instantiated with any of these
characters or eventually with a character set consisting of a specified
group of character with all having the same number of bits.

I have a special interest in 4 bit characters, since they can efficiently
encode DNA and other nucleic acid sequences. In terms of numbers, it might
be possible to create a generic saturated math package and other tools of
similar interest.

Bob Leif  

Re: Ideas for Ada 200X

[Wesley Groleau]

> Nobody has the deep pockets to be able to say "Lets build one of 
> everything and let the market decide." Even if you did, it would only be 
> confusing for the end user and they'd retreat to what they know in order 
> to achieve freedom from choice.

I learned a similar lesson from watching a relative "sell"
real estate.  She'd take the customer to a promising site,
but then she'd overwhelm them with all the options.

"You may need _____, which would imply a place with _____.
But if you have ______, you'd of course want to minimize _____.
(etc.) ...."

When she got done with her college-level lecture on
how to figure out what you need, they'd go buy from
who _tells_ them, "This is what you need.  Sign here."

Re: Ideas for Ada 200X

[Wesley Groleau]

> OK, I guess I wasn't clear enough. I meant that A += B is (if properly
> implemented) much more efficient than A := A + B. For anyone who
> doesn't understand why, it is because the latter requires the
> construction of a temporary to hold the sum, then a copy of the sum
> back over to A.

Still nope.  Under certain conditions, neither requires
a temporary.  Under other conditions, both do.  Rarely
(if ever) are they not identical.

[off-topic] format request

[Wesley Groleau]

John R. Strohm wrote:
> X-A-Notice: References line has been trimed due to 512 byte limitation
> Abuse-Reports-To: abuse at airmail.net to report improper postings
> NNTP-Proxy-Relay: library1-aux.airnews.net
> NNTP-Posting-Time: Sat, 31 May 2003 10:36:23 -0500 (CDT)
> NNTP-Posting-Host: !ZEsB1k-XZg.PFo (Encoded at Airnews!)
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Would you consider properly configuring OE to not make
other people's headers part of your message body when you
are not complaining about spam?

Re: Ideas for Ada 200X

[Wesley Groleau]

> No, they aren't the same. The result is the same, but the second form
> can be implemented much more efficiently. The first form requires the

Oh, good grief.  If the language specification says
they have the same result, then they can be implemented
the same way.  _I_ certainly will never specify "these
must have the same result, but you must do extra work
on that one."

Re: [off-topic] format request

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Mon, 02 Jun 2003 01:59:17 -0500 (CDT)
NNTP-Posting-Host: !aMNH1k-VrSCn%6 (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Wesley, it appears on brief investigation that SOME of those lines are being
generated by Outlook Express, in the message HEADER.  The X-A-Notice
apparently is being generated by the Internet America (airmail.net) outgoing
News server when it truncates the References line, and that is causing
subsequent things to become part of the message body.  The X-A-Notice line,
in particular, is NOT present in my outgoing message.

The exact header on THIS message, as it sat in the outgoing box was:

From: "John R. Strohm" <strohm@airmail.net>
Newsgroups: comp.lang.ada
References: <6a90b886.0305262344.1d558079@posting.google.com>
<3ED41344.7090105@spam.com> <3ED46D81.FF62C34F@0.0> <3ED46E07.4340CABC@0.0>
<3ED4F3FD.A0EF7079@alfred-hilscher.de> <xIeBa.1017346$3D1.597085@sccrnsc01>
<bebbba07.0305292326.75f5fbef@posting.google.com> <u4r3co12f.fsf@nasa.gov>
<bebbba07.0305301649.45b78d8c@posting.google.com> <uvfvrobrb.fsf@wanadoo.fr>
<bb9vp8$7bkb8$3@ID-77047.news.dfncis.de> <uisrrnxzk.fsf@wanadoo.fr>
<BAFE6FC5.2ECD%yaldnifw@blueyonder.co.uk> <bbai5n$6hm@library1.airnews.net>
<KvydnWJin-kiQ0ej4p2dnA@gbronline.com>
Subject: Re: [off-topic] format request
Date: Mon, 2 Jun 2003 01:53:14 -0500
Lines: 39
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

What appears to be happening is that the Internet America outgoing news
server is putting in a blank line before the X-A-Notice line, then
generating the Abuse-Reports-To and NNTP-* lines.  The blank line forces the
remainder of the header into the body.

I have a query in to Internet America, to see if I can do anything about it.
There does NOT appear to be an Outlook Express setting to "fix the problem",
but I admittedly am not an Outlook Express user.  Any assistance you can
provide on this would be appreciated.

And I would have sent this to you as a private reply, but you didn't provide
an email address.

----- Original Message -----
From: "Wesley Groleau" <wesgroleau@despammed.com>
Newsgroups: comp.lang.ada
Sent: Monday, June 02, 2003 12:20 AM
Subject: [off-topic] format request


> John R. Strohm wrote:
> > X-A-Notice: References line has been trimed due to 512 byte limitation
> > Abuse-Reports-To: abuse at airmail.net to report improper postings
> > NNTP-Proxy-Relay: library1-aux.airnews.net
> > NNTP-Posting-Time: Sat, 31 May 2003 10:36:23 -0500 (CDT)
> > NNTP-Posting-Host: !ZEsB1k-XZg.PFo (Encoded at Airnews!)
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>
> Would you consider properly configuring OE to not make
> other people's headers part of your message body when you
> are not complaining about spam?
>

Re: [off-topic] format request

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Mon, 02 Jun 2003 02:00:07 -0500 (CDT)
NNTP-Posting-Host: !aHKd1k-X:S8/6= (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Wesley, it appears on brief investigation that SOME of those lines are being
generated by Outlook Express, in the message HEADER.  The X-A-Notice
apparently is being generated by the Internet America (airmail.net) outgoing
News server when it truncates the References line, and that is causing
subsequent things to become part of the message body.  The X-A-Notice line,
in particular, is NOT present in my outgoing message.

The exact header on THIS message, as it sat in the outgoing box was:

From: "John R. Strohm" <strohm@airmail.net>
Newsgroups: comp.lang.ada
References: <6a90b886.0305262344.1d558079@posting.google.com>
<3ED41344.7090105@spam.com> <3ED46D81.FF62C34F@0.0> <3ED46E07.4340CABC@0.0>
<3ED4F3FD.A0EF7079@alfred-hilscher.de> <xIeBa.1017346$3D1.597085@sccrnsc01>
<bebbba07.0305292326.75f5fbef@posting.google.com> <u4r3co12f.fsf@nasa.gov>
<bebbba07.0305301649.45b78d8c@posting.google.com> <uvfvrobrb.fsf@wanadoo.fr>
<bb9vp8$7bkb8$3@ID-77047.news.dfncis.de> <uisrrnxzk.fsf@wanadoo.fr>
<BAFE6FC5.2ECD%yaldnifw@blueyonder.co.uk> <bbai5n$6hm@library1.airnews.net>
<KvydnWJin-kiQ0ej4p2dnA@gbronline.com>
Subject: Re: [off-topic] format request
Date: Mon, 2 Jun 2003 01:53:14 -0500
Lines: 39
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

What appears to be happening is that the Internet America outgoing news
server is putting in a blank line before the X-A-Notice line, then
generating the Abuse-Reports-To and NNTP-* lines.  The blank line forces the
remainder of the header into the body.

I have a query in to Internet America, to see if I can do anything about it.
There does NOT appear to be an Outlook Express setting to "fix the problem",
but I admittedly am not an Outlook Express user.  Any assistance you can
provide on this would be appreciated.

And I would have sent this to you as a private reply, but you didn't provide
an email address.

----- Original Message -----
From: "Wesley Groleau" <wesgroleau@despammed.com>
Newsgroups: comp.lang.ada
Sent: Monday, June 02, 2003 12:20 AM
Subject: [off-topic] format request


> John R. Strohm wrote:
> > X-A-Notice: References line has been trimed due to 512 byte limitation
> > Abuse-Reports-To: abuse at airmail.net to report improper postings
> > NNTP-Proxy-Relay: library1-aux.airnews.net
> > NNTP-Posting-Time: Sat, 31 May 2003 10:36:23 -0500 (CDT)
> > NNTP-Posting-Host: !ZEsB1k-XZg.PFo (Encoded at Airnews!)
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>
> Would you consider properly configuring OE to not make
> other people's headers part of your message body when you
> are not complaining about spam?
>

Re: Ideas for Ada 200X (Ada.Sockets, enlightened)

[Tarjei T. Jensen]

Warren W. Gay wrote:
> But this is the problem isn't it?  Your needs may be simple, but
> others needs are definitely not.

But we are talking about a simple library for simple needs. Simple as
opposed to all singing, all dancing.

> Here's one: You want to connect to a web server, but you're not
> getting any response (the web server is down). Yet, if you were to
> use the name server in a more advanced way, you could find out that
> there are alternative web servers (all having the same name, but
> possessing different IP numbers).

It is still beyond the scope of the library to expose the user to those sort
of worries.

> Doing a lookup today on www.yahoo.com, I saw 9(!) different IP#'s that
> can be used to reach a web server. An application exploiting that
> information could bypass the one server that is down, but trying one of
> the other 8. Your "simplified" application would have to report a
> failure to connect.

Yes. Does it worry me? No.

> But there are _many_ users, with _many_ different needs. What you want
> is something real simple. This serves only a small portion of the
> overall community.

Quite the opposite. A simple library serves the needs of the vast majority
of the community.

You keep forgetting that we are talking about the simple library. It does
not preclude a more complicated library for people with more complex needs.

Let me repeat myself: We are talking about a simple user level socket
library which allows user to write simple applications.

> Part of the challenge for standards and library writers is striking
> a comfortable balance between simplicity (elegance) and general
> utility (functionality). And it does require careful planning and
> compromise. But beware: if you compromise too much towards a simple
> library, you will only be able to address simple needs. Additionally,
> in Ada, this can be difficult to extend later (more on that later).

We do NOT want to extend that library. We want deliberately keep it simple.

> This is the kind of problem that people want to solve. They don't want
> to have to write Ada bindings to "work around the problem". The problem
> is that the library doesn't exist in standard form. You may only want to
> exchange text, but many here need to much more than that.

But this is a libarary for those who have SIMPLE needs. It is not for those
who need complete control.

> I am not interested in "adding features". I am interested however, in a
> complete solution. Microsoft sells features (flying folders and animated
> paperclips etc.). We in comp.lang.ada are interested in serious
> solutions to programming problems. Some programming problems are very
> serious, and have a bearing on the safety of human lives.

You are trying to turn something which is intended to be simple and easy to
understand into something so complex that there is NO WAY a novice might try
to use it.

> You've focused on the phrase "things should be simple". But Einstein was
> very careful to add "but not simpler". This means that if the solution
> is too simple, then it does not solve the problem (in the case of
> physics, this means that the theory does not map to reality). A simple
> but _complete_ solution is elegant. A simple but incomplete solution is
> not only ugly, but is by definition "incomplete".

When we learn about physics, most of us will get by with Newtonian physics.
Only a selected few have any use for quantum mechanics.

We get by with a gross simplification.

> If you only plan for the simple, you'll be stuck there. The only way out
> will be to tick people off by making wholesale package changes later.
> NOBODY wants those kinds of changes. What we decide today, we will be
> stuck with for another 10 years. Probably very much longer than that.

Which is perfectly sensible. Because we are intentionally designing
something that is simple. Simple to use. Simple to understand.

We want something which have a reasonable chance of being standardized.
Because there is not much to quarrel about. We don't need 5 years of work to
make sure every little detail is in the specification.

That is why I proposed that these libraries should reside in their own
hierarchy. With the top node being "simple".

greetings,

Re: Ideas for Ada 200X (Ada.Sockets)

[Ole-Hjalmar Kristensen]

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

> "chris.danx" <spamoff.danx@ntlworld.com> writes:
> 
> > Larry Kilgallen wrote:
> > 
> > > Standard, as in required of all compilers ?
> > > That would be totally bogus in some embedded environments.
> > 
> > Can't you say "the provision of sockets is compulsory, except for
> > environments where such provision makes no sense"?  i.e. it's not
> > optional for compilers on networked systems, but not mandatory on
> > embedded targets?
> 
> It seems better to say "here's the standard way to do it, but it's
> optional".  That's what the SN Annexes are for.  Then implementers
> can choose whether to implement it based on the needs of their
> customers.  After all, the purpose of standards is to encourage
> uniformity -- not to encourage implementers to provide functionality
> to their customers (the market is supposed to do the latter).
> 

Sounds logical, but look what's happened to garbage collection. No one
implements it, ergo the user cannot count on it even though it's in the
standard.

<snip>

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Georg Bauhaus]

Richard Riehle <richard@adaworks.com> wrote:
: will be ambiguous when Red through Green are both directly visible.   Instead,
: we might code,
: 
:               for I in Signal'Red .. Signal'Green   ...    end loop;

Wouldn't that have to be
               for I in Signal'(Red) .. Signal'(Green)   ...    end loop;



-- Georg

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Larry Kilgallen wrote:
> In article <u4r3co12f.fsf@nasa.gov>, Stephen Leake <Stephe.Leake@nasa.gov> writes:
>> What is wrong with having a style guide that says:
>> 
>> "If you have statements like 
>>    production_total( total_class ).shift( shift_index ) :=
>>       production_total( total_class ).shift( shift_index ) + count;
>> 
>> you must write an appropriate Increment function, and use it instead"
>> 
>> Problem solved; no need for language change or compiler support.
> 
> Alternatively, would a renaming declaration work ?

Yes.

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Preben Randhol wrote:
> What's wrong with Ada'Inc ? ;-)

Ada'Succ is correct.

Re: Ideas for Ada 200X

[Ian Wild]

Robert A Duff wrote:
> 
> > > <!-- This is a comment,
> > > -- but this is not.
> > > -- Here's another comment...
> > > -- ...and here's an unclosed quote eating the rest of your file
> > >>
> 
> Could somebody please explain the above?  (I don't know SGML.)

Within a markup declaration (stuff starting "<!") comments
are delimted AT EACH END with "--".  Outside comments, of
course, apostophes can be used to quote strings, including
strings containing "--" and ">".  Much fun ensues.

Re: Ideas for Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:
> * Preben Randhol wrote:
>> What's wrong with Ada'Inc ? ;-)
> 
> Ada'Succ is correct.

A bit ambivalent meaning isn't it?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <slrnbdm69r.nt.lutz@taranis.iks-jena.de>, Lutz Donnerhacke <lutz@iks-jena.de> writes:
> * Larry Kilgallen wrote:
>> In article <u4r3co12f.fsf@nasa.gov>, Stephen Leake <Stephe.Leake@nasa.gov> writes:
>>> What is wrong with having a style guide that says:
>>> 
>>> "If you have statements like 
>>>    production_total( total_class ).shift( shift_index ) :=
>>>       production_total( total_class ).shift( shift_index ) + count;
>>> 
>>> you must write an appropriate Increment function, and use it instead"
>>> 
>>> Problem solved; no need for language change or compiler support.
>> 
>> Alternatively, would a renaming declaration work ?
> 
> Yes.

I thought I had done that in the past, but the source is off-line.

Renaming seems the best to me:

	Current_shift_total := Current_shift_total + count;

since the name Current_shift_total gives local _meaning_ to

	production_total( total_class ).shift( shift_index )

Re: Ideas for Ada 200X

[Marin David Condic]

Yup. That's why I think the vendors could establish what the best 
direction is. They have some clue as to what their customers would want. 
(Generic focus? Object oriented focus? General applications? Realtime 
applications?) If they said "Go make a general application library that 
is object oriented and looked kind of like the MFC, but with an Ada 
flavor..." a design team could go work with that and get somewhere. If 
the vendors based that on some kind of discussions with their customers, 
then it would probably be something that would satisfy a large 
percentage of the Ada users out there.

The key here is to get *something* built that would be accepted by the 
vendors as the library of convention for Ada. It has to ship with their 
products - possibly with a disclaimer: "This is version X.Y of the 
Conventional Ada Library. It is unsupported by us. Go see the Ada 
Library Consortium's web page for the latest versions, bug reporting, 
etc." Most people would use what they got out of the box and accept it 
as being "Ada" That might start Ada down the path of at least catching 
up to Java and C++. Ultimately, it needs to do more, but it has to at 
least take that first step.

MDC

Wesley Groleau wrote:
> 
> I learned a similar lesson from watching a relative "sell"
> real estate.  She'd take the customer to a promising site,
> but then she'd overwhelm them with all the options.
> 
> "You may need _____, which would imply a place with _____.
> But if you have ______, you'd of course want to minimize _____.
> (etc.) ...."
> 
> When she got done with her college-level lecture on
> how to figure out what you need, they'd go buy from
> who _tells_ them, "This is what you need.  Sign here."
> 


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Bill Findlay]

On 2/6/03 10:30, in article slrnbdm69r.nt.lutz@taranis.iks-jena.de, "Lutz
Donnerhacke" <lutz@iks-jena.de> wrote:

> * Larry Kilgallen wrote:
>> In article <u4r3co12f.fsf@nasa.gov>, Stephen Leake <Stephe.Leake@nasa.gov>
>> writes:
>>> What is wrong with having a style guide that says:
>>> 
>>> "If you have statements like
>>>    production_total( total_class ).shift( shift_index ) :=
>>>       production_total( total_class ).shift( shift_index ) + count;
>>> 
>>> you must write an appropriate Increment function, and use it instead"
>>> 
>>> Problem solved; no need for language change or compiler support.
>> 
>> Alternatively, would a renaming declaration work ?
> 
> Yes.

Not always, unfortunately.
There are restrictions on the lvalues that can be renamed,
e.g. objects of anonymous type and some discriminated type components
(I can't remember the details, but I'm sure someone can 8-).

The 'idem, <>, all' proposal adds real power here.

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

BTW The UK Beagle 2 Mars probe is sitting atop a Soyuz rocket at Baikonur
waiting for a launch this evening. It is controlled by an open-source
(ERC32) computer programmed in Ada 95 using an open-source (GNAT) compiler.
Let's wish it luck, and hope it suffers no unbounded priority inversions (or
Constraint_Errors 8-) !

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

>BTW The UK Beagle 2 Mars probe is sitting atop a Soyuz rocket at Baikonur
>waiting for a launch this evening. It is controlled by an open-source
>(ERC32) computer

What do you mean by that? Aren't you confusing that with the
Leon2-processor from <http://www.gaisler.com>? Or is the ERC32 based
on that design?

>programmed in Ada 95 using an open-source (GNAT) compiler.

Ah, I guess, you mean that:

<http://www.estec.esa.nl/wsmwww/erc32/freesoft.html>

Neat.

>Let's wish it luck, and hope it suffers no unbounded priority inversions (or
>Constraint_Errors 8-) !

Well, good luck then.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X (Ada.Sockets)

[Robert I. Eachus]

Ole-Hjalmar Kristensen wrote:

> Sounds logical, but look what's happened to garbage collection. No one
> implements it, ergo the user cannot count on it even though it's in the
> standard.

First, I think this should be fixed in Ada0Y.  Not necessarily full 
garbage collection, but...

Ada95 has a requirement that Unbounded_Strings not leak storage.  This 
can be done by reference counting or whatever, but it has to be there. 
I have a nice little package that uses Unchecked_Conversion to put 
arbitrary objects in Strings.  Obiously pointers "hidden" this way will 
break the abstraction.  But I find it is a very useful language extension.

Second, and this is again something that puts no burden on compiler 
vendors, there should be a standard generic garbage collection package 
which uses a named storage pool.  Write it, propose it, and Ada0Y will 
have a standard Ada.Garbage_Collection package.

Re: Ideas for Ada 200X

[Bill Findlay]

On 2/6/03 14:57, in article bbfl7c$9472d$1@ID-175126.news.dfncis.de,
"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:

> Bill Findlay wrote:
> 
>> BTW The UK Beagle 2 Mars probe is sitting atop a Soyuz rocket at Baikonur
>> waiting for a launch this evening. It is controlled by an open-source
>> (ERC32) computer
> 
> What do you mean by that? Aren't you confusing that with the
> Leon2-processor from <http://www.gaisler.com>? Or is the ERC32 based
> on that design?

Perhaps my memory deceives me, but I thought it was the other way around:
that the Leon product was based on ESA's ERC32 design, which the ESA
open-sourced.

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

>Perhaps my memory deceives me, but I thought it was the other way around:
>that the Leon product was based on ESA's ERC32 design, which the ESA
>open-sourced.

You might be right, I just found
<http://www.estec.esa.nl/wsmwww/leon/>. So at least it's design is
originally something the ESA has GPLed.

But the ERC32 seems to be based on the SPARC V7 architecture, whilst
the Leon is based on SPARC V8... well, doesn't matter. It's cool,
anyway. :-)


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Bill Findlay wrote:
> On 2/6/03 10:30, in article slrnbdm69r.nt.lutz@taranis.iks-jena.de, "Lutz
> Donnerhacke" <lutz@iks-jena.de> wrote:
>> * Larry Kilgallen wrote:
>>> Alternatively, would a renaming declaration work ?
>>
>> Yes.
>
> Not always, unfortunately.
> There are restrictions on the lvalues that can be renamed,
> e.g. objects of anonymous type and some discriminated type components
> (I can't remember the details, but I'm sure someone can 8-).

Oops.

> The 'idem, <>, all' proposal adds real power here.

Yes. <> is my favorite.

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote in message
> news:<u4r3co12f.fsf@nasa.gov>... 
> > What is wrong with having a style guide that says:
> > 
> > "If you have statements like 
> >    production_total( total_class ).shift( shift_index ) :=
> >       production_total( total_class ).shift( shift_index ) + count;
> > 
> > you must write an appropriate Increment function, and use it instead"
> 
> Because it's one hell of a lot easier, not to mention less
> error-prone, to just use +=. That's what Ada is all about.

But you have only stated your opinion, not given a reason. Hmm, I
guess by "easier", you mean "it's already written for me; I don't have
to write it". That's true, but I object to the qualification "a hell
of a lot"; it's a minor effort. 

On the other hand, modifying the language in any way is a _major_
effort. So we have to talk about costs and benefits, not just whether
something is good at all.

> I don't blame anyone for disliking ++, but += should be your friend.

Many people disagree with you; it helps to give actual reasons, or
just say "in my opinion".

> > Problem solved; no need for language change or compiler support.
> 
> Yes, but it's far from the best and simplest solution.

How far? 42 microns, no doubt :). (Extra points for identifying the
cultural origions of that number :). Obviously, I think it is
_precisely_ the "best and simplest" solution; that's why I stated it. 

It's "best", because it gives the most control to the user. It's
"simplest", because it requires no changes to the existing language.

If we were designing a language from scratch, the second point would
be moot. But we're not.

> > > And let's not forget that +=, -=, etc. also allow for more
> > > efficient in-place vector/matrix operations because they avoid
> > > the need for a temporary. If you don't understand this, that's
> > > OK, but please don't argue with me because you will be wrong.
> > 
> > Same argument; a package that provides vector/matrix math must provide
> > an appropriate in-place Increment function.
> > 
> > Ada is about ease of reading, _not_ about ease of writing.
> 
> += improves readability too! Which is clearer,
> 
> 	A += B
> 
> or
> 
> 	Add(A,B)
> 
> The latter doesn't make clear what exactly is being done. Is the
> result ending up in A or B? Yes, you can write something that would be
> a bit clearer, like
> 
> 	Add ( Into=>A, Add=>B )

This is obviously the clearest; it has the most words in it.

> but it still would not be as clear or as elegant as A += B.

Elegant, I'll grant you. Clear, I won't. You may know what += means,
but there will be more people who know what "Add ( Into=>A, Add=>B )"
means. Remember, we hope to get to a place where everyone learns Ada
first, and never learns C :).

> In-place operations on a variables are so fundamental that they
> deserves their own syntax. 

"deserve" implies a cost benfit ratio. You are ignoring the costs, so
of course it seems like a good idea.

> If you can't handle that, what kind of "programmer" are you?

I can handle it, and I'm a great programmer :).

-- 
-- Stephe

Re: Ideas for Ada 200X (Ada.Sockets, enlightened)

[Warren W. Gay VE3WWG]

Tarjei T. Jensen wrote:
> Warren W. Gay wrote:
> 
>>But this is the problem isn't it?  Your needs may be simple, but
>>others needs are definitely not.
> 
> But we are talking about a simple library for simple needs. Simple as
> opposed to all singing, all dancing.

OK, we'll just disagree here. Not that I need an "all dancing",
library.

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

Re: Ideas for Ada 200X

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Well, I won't say it *can't* work - just that it has been tried in a few 
> different ways and guess what? We don't have a Conventional Ada Library.

I don't disagree with you on this.

> If the thing has zero interest from the vendors it will become Just 
> Another Ada Library like the half-dozen or so that are already out 
> there. A small teem of developers might be able to do a good job of 
> building a library - even if they were volunteers - but it would need 
> some direction from those who have to adopt it as "The Right Thing". 
> Think "Requirements" - someone has to impose some. Don't believe me? 
> Lets toss this turd into the pool: Should a Standard Ada Container 
> Library be based on generics or based on tagged types? Let's start that 
> debate here and see how far it goes! (Less filling! Tastes great!!!)

Yes, I watched with interest some of that debate. ;-)

> A group of enthusiasts sounds plausable, but I believe that unless it 
> has some cloak of "officialness" to it, some acceptance on the part of 
> the vendors and some sort of charter/requirements to work to, it will 
> either fall apart or produce Just Another Ada Library.
> 
> MDC

Well, maybe this is just part of the problem. Perhaps "some" things are
meant to exist outside of the standard as "defacto" standards. Certainly
one problem you mentioned is the 10-year cycle thing. That is a long time
to live with limitations. At the same time, it is also a very difficult
job to carefully review and revise a language, based upon my own worm's
eye knowledge of the process.

But, I am an optimistic person (perhaps to a fault).  I like to think
that there is still a way. Perhaps the *best* approach has not been
used yet, not that I have the "answers" to this. Or perhaps it has, but
it just needs to be handled a little differently.

There are perhaps 4 general approaches that one could take (maybe more):

  1 - The official ARG route
  2 - SigAda
  3 - A coordinated volunteer approach
  4 - the "go it alone" Source Forge type of approach, and hope that
      the project is later well received and generally used.

I can probably only participate in the last 2 (as I expect many other
hobbiests). For me, the #3 approach makes the most sense.

If some coordinated center (maybe adapower.com) existed for potential
standards potential projects, then perhaps these efforts can be nurtured
into standards someday (adapower can provide links to these efforts
in other places like Source Forge etc., if necessary)

I can't really speak for the years prior to my start in Ada, but it
seems to me what has happened generally is perhaps "oh gee! A new
standard is about to come out, and let's rush to get something in!"
I am guilty of this also.

The reality is, I suspect, that you need several years of planning
to get there from here. I foolishly thought for a moment that we
had time to propose a networking standard for ada. Time for a
"reality check". ;-)

However, I do believe that there is time for the next standard. That
doesn't sound encouraging, but it need not be a defeat.
If everyone found your Ada1z.Grace_Components to be useful in the
meantime, there is a great chance that it could be submitted as
a standard when the time comes. You would certainly have time to
refine it and define the language of the standards document.

One observation I made about the GRACE deliberations that I followed,
was that there seemed to be two entirely different camps that
it seemed to be trying to please. The embedded and the general
purpose camp. I could be wrong, but I don't see both camps
being satisfied by one implementation. Their needs are so different.

If you pursue to please the "general purpose" camp, I would say
that Simon Wright's Booch Components seem to be the most complete
library, and it works well. What it could use is an easier way
to instantiate what you need (wrapper packages). With the Ada0Y
standard coming soon, perhaps it makes sense to use the new
language features to provide a more ideal interface to that
collection.

Just my $0.02 worth (and the Cdn $ is picking up!)

Warren.

> Warren W. Gay VE3WWG wrote:
> 
>>
>>
>> Here is some of my thinking out loud (not necessarily sensible ;-)
>>
>> Get 1 person to organize, and perhaps the same person to "moderate"
>> any initial discussions :
>>
>> - Create a special "mailing list/newsgroup" (a mailing list can
>>   be made available on gmane.org's newsgroup server, for those
>>   that prefer a nntp interface). Yahoo groups are pesky, but free.
>>
>>   I believe this is essential, because comp.lang.ada is like
>>   inviting everyone to a meeting, and never getting consencous.
>>
>> - Solicit volunteers.
>> - Get some agreement on scope
>> - Subdivide scope and
>>   - determine package hierarchies
>>   - determine naming conventions to be used
>>   - subdivide volunteers to portions of the heirarchy
>>     - the smaller divisions the better, or perhaps
>>       in reasonable scopable swaths
>> - solicit volunteers (repeat as necessary ;-)
>>
>> - do some code/design work
>> - meet
>> - iterate until well "baked"
>>
>> As a volunteer effort, there is a number of sources that we can look
>> at and learn from.
>>
>> I will contribute my time, to clearly defined portions of this project,
>> but only to something considerably smaller than Florist ;-)  But I would
>> prefer not to steer it, because I have other pet projects on the run. ;-)
>>
>> Ideally (maybe), the person steering this should be more familiar with
>> what's up with Ada0Y, the industry etc. But hey, I think zeal is the
>> most important attribute here.
>>
> 
> 


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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Stephen Leake wrote:

>18k11tm001@sneakemail.com (Russ) writes:
>
>> Yes, but it's far from the best and simplest solution.
>
>How far? 42 microns, no doubt :).

Just to mention that: Probably someone should define "far" here. In my
business this 42 microns would be *way* too far (more than an order of
magnitude). And I'm just talking about printing "Playboy" and such
stuff. ;-)

>(Extra points for identifying the
>cultural origions of that number :).

This one is easy. :-)

The answer to the Ultimate Question of Life, the Universe and
Everything. "Hitchhiker's Guide through the Galaxy" from Douglas Adams
(1952-2001).


Vinzent.

-- 
Marvin: "I talked to the computer at great length and explained my
         view of the Univers to it."
Ford:   "And what happened?"
Marvin: "It committed suicide."

Re: Ideas for Ada 200X

[Wesley Groleau]

> The key here is to get *something* built that would be accepted by the 
> vendors as the library of convention for Ada. It has to ship with their 
> products - possibly with a disclaimer: "This is version X.Y of the 
> Conventional Ada Library. It is unsupported by us. Go see the Ada 
> Library Consortium's web page for the latest versions, bug reporting, 
> etc." Most people would use what they got out of the box and accept it 
> as being "Ada" That might start Ada down the path of at least catching 
> up to Java and C++. Ultimately, it needs to do more, but it has to at 

Yes.  Look at all the COTS stuff being wedged into
military programs not because it fits well, but
merely because it exists.

Re: [off-topic] format request

[Wesley Groleau]

John R. Strohm wrote:

> What appears to be happening is that the Internet America outgoing news
> server is putting in a blank line before the X-A-Notice line, then
> generating the Abuse-Reports-To and NNTP-* lines.  The blank line forces the
> remainder of the header into the body.

I'll buy that.  A blank line would do it.  So they are
at fault, not your installation.  And thus, nothing you
can do about it but complain to them.  Thanks for the reply.

Re: Ideas for Ada 200X

[Stephen Leake]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Stephen Leake wrote:
> 
> >18k11tm001@sneakemail.com (Russ) writes:
> >
> >> Yes, but it's far from the best and simplest solution.
> >
> >How far? 42 microns, no doubt :).
> 
> Just to mention that: Probably someone should define "far" here. In my
> business this 42 microns would be *way* too far (more than an order of
> magnitude). And I'm just talking about printing "Playboy" and such
> stuff. ;-)
> 
> >(Extra points for identifying the
> >cultural origions of that number :).
> 
> This one is easy. :-)
> 
> The answer to the Ultimate Question of Life, the Universe and
> Everything. "Hitchhiker's Guide through the Galaxy" from Douglas Adams
> (1952-2001).

Yes, but that's just the "42". Where did "micron" come to mean "some
imaginary unit of measure"?

-- 
-- Stephe

Re: Ideas for Ada 200X (Ada.Sockets)

[Warren W. Gay VE3WWG]

Simon Wright wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>Ada streams and endian issues are also important. Write a program
>>that uses a socket between two endian different machines and the
>>endian issue becomes painfully important.  This also shows up
>>in the strangest places. My APQ PostgreSQL package lets you use
>>Ada streams to write blobs to the database. Well, guess what. If
>>you have machines of a different endian persuation trying to read
>>back those blobs written by a different endian persuation (with
>>Ada streams), then "they ain't right". Right now, I live with that
>>limitation because there is no elegant way to fix this.
> 
> The GLADE (GNAT Annex E support) contains an implementation of
> System.Stream_Attributes, in s-stratt.adb,  that magically makes streams
> endian-independent (uses XDR formatting).
> 
> You do need to use the gnatmake flag (-a ?) that says "recompile
> everything".

I know that the code is there as part of GLADE, and certainly if you
use GLADE, this works great. While most of my stuff is GNAT specific,
I prefer however to make it unecessarily so. The difficulty is, do I
make my packages insist on GLADE? If I do, I can immediately rule out
support for FreeBSD for example.

However, if you decide that GNAT only is good enough, then there is
still the issue of whether or not ACT will leave
"System.Stream_Attributes, in s-stratt.adb" alone. Or will it change?

Certainly there is a lot of flexibility when it comes to your own
personal pet project(s) that the world never sees. I see a larger
issue with code I want to publish however.

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Stephen Leake wrote:

>Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
>
>> Stephen Leake wrote:
>> 
[42 microns]
>> >(Extra points for identifying the
>> >cultural origions of that number :).
>> 
>> This one is easy. :-)
>> 
>> The answer to the Ultimate Question of Life, the Universe and
>> Everything. "Hitchhiker's Guide through the Galaxy" from Douglas Adams
>> (1952-2001).
>
>Yes, but that's just the "42". Where did "micron" come to mean "some
>imaginary unit of measure"?

Mmh, to my knowledge micron is originated from the Greek word "micros"
for little, small, tiny. Used to mean one out of a thousand
[millimeter] since I am able to speak. Ok, probably it was used
earlier already... ;-)

So you have a different story?

At work we are just too lazy to say micrometer each time because we
would have to say it too often. Especially if a customer would
complain about a small 42 micron disalignment. ;->


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X (GNAT.IO_Aux.Get_Line)

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3EDA5648.9030709@cogeco.ca>...
>Richard Riehle wrote:
>> "Warren W. Gay VE3WWG" wrote:
>>>Another example: Include a standard version of GNAT.IO_Aux.Get_Line
>>>as part of Ada.Text_IO for Ada0Y. Why should people have to keep
>>>rolling their own, or relying on GNAT code for this?
>>
>> While we're  making suggestions about Text_IO, why not change
>> the Get operations to functions for Scalar types.   This is one of
>> the important changes Jerry Van Dijk made in CONSOLE_IO.  It
>> works great.
>>
>> Richard Riehle
>
>This kinda gets back to the functions and side-effects argument (the
>object that File_Type points to is undergoing state changes). I think
>many would be happy to break that rule for GNAT.IO_Aux.Get_Line, since
>there is no other way to read in a Ada string without knowing in
>advance its size. But extending this to scalars might be going farther
>down that road than is "comfortable".
>
>For my $0.02 worth, the scalars don't matter. The string is the problem
>child that needs a solution.


Moreover, Richard said "change", which is an immediate non-starter.
"Add", perhaps, but we're not going to make incompatible changes without
lots of justification, and this would come close.

                Randy.

Re: [off-topic] format request

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Mon, 02 Jun 2003 19:55:15 -0500 (CDT)
NNTP-Posting-Host: !Zf]71k-WSh61EM (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:npOdnTZpppV9AUaj4p2dnA@gbronline.com...
> John R. Strohm wrote:
>
> > What appears to be happening is that the Internet America outgoing news
> > server is putting in a blank line before the X-A-Notice line, then
> > generating the Abuse-Reports-To and NNTP-* lines.  The blank line forces
the
> > remainder of the header into the body.
>
> I'll buy that.  A blank line would do it.  So they are
> at fault, not your installation.  And thus, nothing you
> can do about it but complain to them.  Thanks for the reply.

I've squawked to the ISP, and given them before-and-after messages to show
the problem.  Who knows, they might actually fix something.

Re: Ideas for Ada 200X

[Steve]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:uof1gxx22.fsf@nasa.gov...
> 18k11tm001@sneakemail.com (Russ) writes:
>
> > Stephen Leake <Stephe.Leake@nasa.gov> wrote in message
> > news:<u4r3co12f.fsf@nasa.gov>...
> > > What is wrong with having a style guide that says:
> > >
> > > "If you have statements like
> > >    production_total( total_class ).shift( shift_index ) :=
> > >       production_total( total_class ).shift( shift_index ) + count;
> > >
> > > you must write an appropriate Increment function, and use it instead"
> >
> > Because it's one hell of a lot easier, not to mention less
> > error-prone, to just use +=. That's what Ada is all about.
>
> But you have only stated your opinion, not given a reason. Hmm, I
> guess by "easier", you mean "it's already written for me; I don't have
> to write it". That's true, but I object to the qualification "a hell
> of a lot"; it's a minor effort.
>

The reason I prefer Ada over the other choices I have readily available is
because it is easier to produce code that works right the first time.

A "+=" operation (or equivalent) would improve the chances of producing code
for certain expressions right the first time.  Over the years I have found
myself carefully scanning both sides of an assignment statement similar to
the "production_total" example above to make sure the two expressions are
identical in order to make sure I am correctly interpreting the meaning of
the statement.

I am not in love with the "+=" syntax and think another syntax that did the
same thing would be just as good.  But having you say "write an Add routine"
sounds just like hearing a C++ programmer say "you can do array bounds
checking in C++".  If it isn't easy or automatic, it seldom gets done.

Steve
(The Duck)

> --
> -- Stephe

Re: Ideas for Ada 200X

[Russ]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<KvydnZ2dnunHfUej4p2dnA@gbronline.com>...
> > No, they aren't the same. The result is the same, but the second form
> > can be implemented much more efficiently. The first form requires the
> 
> Oh, good grief.  If the language specification says
> they have the same result, then they can be implemented
> the same way.  _I_ certainly will never specify "these
> must have the same result, but you must do extra work
> on that one."

Oh, good grief yourself.

If A and B are matrices, then

    A := A + B
and
    A += B

give the same result, but the latter, if properly implemented, is
indeed substantially more efficient than the former.

Once again, I will explain why. The first form requires the creation
of a temporary matrix to hold the sum, then a copy from the temporary
back to A. The second form, on the other hand, can do the addition in
place in A on an element by element basis, eliminating the need for
the temporary matrix and the copy operation.

And no, the first form cannot be implemented the same as the second.
When you use the first form, you are indeed telling the compiler "you
must do extra work on that one," as you put it. In some small programs
the more natural first form may be perfectly adequate, but certainly
not in computationally intensive numerical programs.

If you still don't get it, think about how you would implement A := B
+ C + D. Each intermediate sum needs its own temporary. The more
efficient form would be

    A := B
    A += C
    A += D

I don't care whether the operator is called += or something else, but
Ada needs it badly, along with -=, *=, and /= (or equivalent, I
realize that symbol is taken). Their absence is a glaring omission in
Ada.

Re: Ideas for Ada 200X

[Richard Riehle]

Georg Bauhaus wrote:

> Richard Riehle <richard@adaworks.com> wrote:
> : will be ambiguous when Red through Green are both directly visible.   Instead,
> : we might code,
> :
> :               for I in Signal'Red .. Signal'Green   ...    end loop;
>
> Wouldn't that have to be
>                for I in Signal'(Red) .. Signal'(Green)   ...    end loop;
>
> -- Georg

Yes.  In my haste to post, I forgot my parentheses.  Thanks.

Richard Riehle

Re: Ideas for Ada 200X

[Jean-Pierre Rosen]

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


"Russ" <18k11tm001@sneakemail.com> a �crit dans le message news:
bebbba07.0306022127.46f6c998@posting.google.com...
> Wesley Groleau <wesgroleau@despammed.com> wrote in message
news:<KvydnZ2dnunHfUej4p2dnA@gbronline.com>...
> > > No, they aren't the same. The result is the same, but the second form
> > > can be implemented much more efficiently. The first form requires the
> >
> > Oh, good grief.  If the language specification says
> > they have the same result, then they can be implemented
> > the same way.  _I_ certainly will never specify "these
> > must have the same result, but you must do extra work
> > on that one."
>
> Oh, good grief yourself.
>
> If A and B are matrices, then
>
>     A := A + B
> and
>     A += B
>
> give the same result, but the latter, if properly implemented, is
> indeed substantially more efficient than the former.
>
> Once again, I will explain why. The first form requires the creation
> of a temporary matrix to hold the sum, then a copy from the temporary
> back to A. The second form, on the other hand, can do the addition in
> place in A on an element by element basis, eliminating the need for
> the temporary matrix and the copy operation.
>
My usual answer to things dealing with efficiency:
Did you try to measure which one is faster, before asserting that?
If no, do the measurement and come again.

It is absolutely not obvious that the extra copy is more costly (and yes, I
did the measurement).
Remember that when accessing an array passed by reference, you need an extra
dereference to
access each element, compared with a local variable. OTOH, copying can be
quite fast (block copy).
On big matrices, having a local copy can be faster. Depends on many things,
including the size of
the matrix.

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

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

18k11tm001@sneakemail.com (Russ) writes:

> Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<KvydnZ2dnunHfUej4p2dnA@gbronline.com>...
> > > No, they aren't the same. The result is the same, but the second form
> > > can be implemented much more efficiently. The first form requires the
> > 
> > Oh, good grief.  If the language specification says
> > they have the same result, then they can be implemented
> > the same way.  _I_ certainly will never specify "these
> > must have the same result, but you must do extra work
> > on that one."
> 
> Oh, good grief yourself.
> 
> If A and B are matrices, then
> 
>     A := A + B
> and
>     A += B
> 
> give the same result, but the latter, if properly implemented, is
> indeed substantially more efficient than the former.
> 
> Once again, I will explain why. The first form requires the creation
> of a temporary matrix to hold the sum, then a copy from the temporary
> back to A. The second form, on the other hand, can do the addition in
> place in A on an element by element basis, eliminating the need for
> the temporary matrix and the copy operation.
> 

Where in the standard is this temporary matrix required? Look at it
this way: you are telling the computer to assign the sum of A and B to
A. Why isn't the compiler free to do the addition in place, unless you
have got an overloaded "+" with strange side effects?

> And no, the first form cannot be implemented the same as the second.
> When you use the first form, you are indeed telling the compiler "you
> must do extra work on that one," as you put it. In some small programs
> the more natural first form may be perfectly adequate, but certainly
> not in computationally intensive numerical programs.
> 

<snip>

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X (Ada.Sockets)

[Ole-Hjalmar Kristensen]

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

> Ole-Hjalmar Kristensen wrote:
> 
> > Sounds logical, but look what's happened to garbage collection. No one
> > implements it, ergo the user cannot count on it even though it's in the
> > standard.
> 
> First, I think this should be fixed in Ada0Y.  Not necessarily full
> garbage collection, but...
> 
> Ada95 has a requirement that Unbounded_Strings not leak storage.  This
> can be done by reference counting or whatever, but it has to be
> there. I have a nice little package that uses Unchecked_Conversion to
> put arbitrary objects in Strings.  Obiously pointers "hidden" this way
> will break the abstraction.  But I find it is a very useful language
> extension.
> 
> Second, and this is again something that puts no burden on compiler
> vendors, there should be a standard generic garbage collection package
> which uses a named storage pool.  Write it, propose it, and Ada0Y will
> have a standard Ada.Garbage_Collection package.
> 
> 

Yes, I like the idea of having a separate pool with garbage
coolection. Modula-3 has exactly the same approach, and it works just
fine.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> 
> I don't care whether the operator is called += or something else, but
> Ada needs it badly, along with -=, *=, and /= (or equivalent, I
> realize that symbol is taken). Their absence is a glaring omission in

As I understand what you are saying it can be written like this:

A := A + B; equals

   function Add (A : Some_Type; B : Some_Type) return Some_Type;

while A += B; equals:

   procedure Add (A : in out Some_Type; B : in Some_Type);

Isn't this correct?

If so I think using a procedure is more clean (syntaxwise) than to use
+= which looks like a function IMHO.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Preben Randhol wrote:
> As I understand what you are saying it can be written like this:
> 
> A := A + B; equals
> 
>    function Add (A : Some_Type; B : Some_Type) return Some_Type;
> 
> while A += B; equals:
> 
>    procedure Add (A : in out Some_Type; B : in Some_Type);
> 
> Isn't this correct?
> 
> If so I think using a procedure is more clean (syntaxwise) than to use
> += which looks like a function IMHO.

Yes, that's the Ada way. But for a lot of simple functions over simple data
types, defining such procedures is a pain.

Re: Ideas for Ada 200X

[Marin David Condic]

A question comes to mind: Is there any reason why a compiler cannot 
recognize "A := A + B;" as a special case and create an optimized 
solution equivalent to "A += B;"? A second question is: If they can 
detect and optimize this, are there any compilers that do so? A third 
question is: Supposing the syntax were added - would any compilers start 
generating the optimized answer? It isn't at all clear to me that adding 
such syntax is going to get compilers to do a better job than they might 
already be doing.

It might be interesting to see of Gnat generates substantially different 
code for the Ada expression than it does for the C expression.

MDC

Lutz Donnerhacke wrote:
> 
> 
> Yes, that's the Ada way. But for a lot of simple functions over simple data
> types, defining such procedures is a pain.


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ideas for Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:
> 
> Yes, that's the Ada way. But for a lot of simple functions over simple data
> types, defining such procedures is a pain.

But if the data types are simple do you really need the optimisation?

If you are adding two matrixes you need to do a lot of other things
like check if they are of same dimentions etc. and you need to define
the addition so you might as well do it as a procedure over a "+"
function.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Marin David Condic wrote:
> Lutz Donnerhacke wrote:
>> Yes, that's the Ada way. But for a lot of simple functions over simple data
>> types, defining such procedures is a pain.
>
> A question comes to mind: Is there any reason why a compiler cannot
> recognize "A := A + B;" as a special case and create an optimized
> solution equivalent to "A += B;"? A second question is: If they can
> detect and optimize this, are there any compilers that do so?

There are compilers which detect and optimize this.

> A third question is: Supposing the syntax were added - would any
> compilers start generating the optimized answer? It isn't at all clear to
> me that adding such syntax is going to get compilers to do a better job
> than they might already be doing.

The real question is not about optimizing.
The real question is about readablility and clear expression.

This is especially important, if X is an expression with side effects.
So evaluating X twice results in different variables. This is clearly not
the intent of the programmer and cause of errors, Ada is not famous for.

> It might be interesting to see of Gnat generates substantially different
> code for the Ada expression than it does for the C expression.

Try out an iterator access to see, what's interesting here.

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Lutz Donnerhacke wrote:
>> Yes, that's the Ada way. But for a lot of simple functions over simple data
>> types, defining such procedures is a pain.
>
> But if the data types are simple do you really need the optimisation?

Let X in "X := X + 4;" be an complicated expression.
Yes, evaluating this expression once or twice is an considerably optimisation.

> If you are adding two matrixes you need to do a lot of other things
> like check if they are of same dimentions etc. and you need to define
> the addition so you might as well do it as a procedure over a "+"
> function.

We are talking about a complex expression used twice in order to perform a
simple one. The function "+" itself is done on simple data types.

The proposal:

  "<>" in the RHS of an assignment is the same as the LHS of this assignment.
  So the LHS determines the type and the location of each occurence of the
  "<>" token in the RHS expression. The process to determine the LHS for every
  use in this statement runs only once.
  So the statement:
    LHS := <> + any_function(<>, ...);
  is equivalent to:
    declare
       X : LHS'Type renames LHS;
    begin
       X := X + any_function(X, ...);
    end;

does not aim to optimization of any simple operation on the RHS, but on the
uniquess of the evaluation of the LHS for the use in the right hand
expression.

Re: Ideas for Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:
> The real question is not about optimizing.
> The real question is about readablility and clear expression.

Please explain how A plus equals B is clear?

Add (To => A, Element => B);

nuff said ;-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Lutz Donnerhacke wrote:
>> The real question is not about optimizing.
>> The real question is about readablility and clear expression.
>
> Please explain how A plus equals B is clear?
>
> Add (To => A, Element => B);
>
> nuff said ;-)

Please to instantiate it for every countable type A, you use and any
universal_integer B. Thank you.

A local renaming declaration is the method of choice, but's ugly. The common
idiom X := X + Y; is error prone, because X might be evaluated twice without
notice.

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <slrnbdp59t.583.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> Lutz Donnerhacke wrote:
>> The real question is not about optimizing.
>> The real question is about readablility and clear expression.
> 
> Please explain how A plus equals B is clear?
> 
> Add (To => A, Element => B);
> 
> nuff said ;-)

I think Lutz was looking for someone to prove clarity, whereas your
example proves obscurity.

Re: Ideas for Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:

> Please to instantiate it for every countable type A, you use and any
> universal_integer B. Thank you.

Ok I can agree. But at least I would rather have

   A :=+ B

or

   A +:= B

whichever is more clear. 

Because in my view A += B will mess up Ada as we have:

   if A = B then 
   A := B 

and do not use 

   if (A == B) 
   A = B

as C and C++ do.

But that means one would need to limit this operator to procedures?

   procedure ":=+" (Left: in out T; Right: in T);


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Lutz Donnerhacke wrote:
> > 
> > Yes, that's the Ada way. But for a lot of simple functions over simple data
> > types, defining such procedures is a pain.
> 
> But if the data types are simple do you really need the optimisation?
> 

If the data types are simple, I would expect the optimizer to
eliminate the unneded copies.

> If you are adding two matrixes you need to do a lot of other things
> like check if they are of same dimentions etc. and you need to define
> the addition so you might as well do it as a procedure over a "+"
> function.
> 
> -- 
> Preben Randhol                    http://www.pvv.org/~randhol/

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Lutz Donnerhacke wrote:
>> Please to instantiate it for every countable type A, you use and any
>> universal_integer B. Thank you.
> 
> Ok I can agree. But at least I would rather have
>
>    A :=+ B
> or
>    A +:= B
>
> whichever is more clear.

It's more clear, because you know this limited idiom from an other language.

> Because in my view A += B will mess up Ada as we have:

A /= B already has a defined meaning so this approach will always fail.

> But that means one would need to limit this operator to procedures?
>    procedure ":=+" (Left: in out T; Right: in T);

No, it's a too limited approach. Much more flexible is the suggestion to use
a special symbol to reference the LHS on the RHS expression.

So you can write:
  A(i).dispaching_call(get_next_position) := <> - y / (2*<>);

Re: Ideas for Ada 200X

[Bill Findlay]

As I see it there are several arguments in favour of the 'idem' proposal:

1. It lets the programmer indicate that the occurrences of the LHS in the
RHS are *necessarily* the same, and not contingently so, which makes the
code more self-documenting.

2. It removes a source of error in transcribing the LHS multiple times.

3. It allows more concisely readable code when the LHS is lengthy.

4. It provides functionality that it only partially available by means of
much clumsier renaming declarations, because not all objects can be renamed.

5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
that lvalue as often as needed to evaluate the RHS. This has three potential
benefits: shorter code, faster execution, and once-only invocation of any
side effects.

6. It might make it somewhat easier for the compiler to generate
update-in-place object code, where the target architecture allows that and
where it offers a performance advantage.

7. It provides all the utility of C's multitude of combined assignment
operators with one small, compatible change to the syntax of operands.
(I specify C, rather than C++, to avoid getting into a argument about
overloading assignment).

8. It allows the expression of useful forms that C's combined assignment
operators cannot achieve (e.g. X := 1 - idem;).

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

BTW I would like to emphasize that I am not wedded to the concrete syntax of
'idem', '<>', 'all' or whatever - I regard that as a minor matter to be
determined, and hope that aesthetic preferences do not cloud the wider
issue.

Re: Ideas for Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:
> * Preben Randhol wrote:
>> Lutz Donnerhacke wrote:
>>> Please to instantiate it for every countable type A, you use and any
>>> universal_integer B. Thank you.
>> 
>> Ok I can agree. But at least I would rather have
>>
>>    A :=+ B
>> or
>>    A +:= B
>>
>> whichever is more clear.
> 
> It's more clear, because you know this limited idiom from an other language.

What is more clear?

> So you can write:
>   A(i).dispaching_call(get_next_position) := <> - y / (2*<>);

Wouldn't <> be confusing as it is already used?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Georg Bauhaus]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:

:  The common
: idiom X := X + Y; is error prone, because X might be evaluated twice without
: notice.

Still, in
  X +:= Y;
X might be evaluated during evaluation of Y, without notice.
Same in Add(Using => X, Adding => Y).

What about X +:= g(X) + f(X);

Is it really more clear to break this into a few statements
with augmented assignment, if at all possible?  Or should we
just be aware that Ada programs do have assignment, and not
referential transparancy everywhere?

Isn't memory/time-efficient implementation(!) a detail that deserves
its own descriptive names tailored to the special case?

my 2c (EUR. Hey, has it dropped after the recent USA/Euro meeting?)
-- Georg

Re: Ideas for Ada 200X

[Preben Randhol]

Lutz Donnerhacke wrote:
> 
> No, it's a too limited approach. Much more flexible is the suggestion to use
> a special symbol to reference the LHS on the RHS expression.
> 
> So you can write:
>   A(i).dispaching_call(get_next_position) := <> - y / (2*<>);

Ok, but this is not for optimisation only for removing the side effect
of get_next_position increasing? Or am I misunderstanding you?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Adrian Knoth]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:

> No, it's a too limited approach. Much more flexible is the suggestion to use
> a special symbol to reference the LHS on the RHS expression.
 
> So you can write:
>   A(i).dispaching_call(get_next_position) := <> - y / (2*<>);


<Captain Picard-Mode>
[x] make it so
</mode>

:) SCNR

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Wie "Tippfehler !?" Mein Modem hat doch Fehlerkorrektur...

Re: Ideas for Ada 200X

[Bill Findlay]

On 3/6/03 15:22, in article bbiav9$4np$1@a1-hrz.uni-duisburg.de, "Georg
Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote:

> Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> 
> :  The common
> : idiom X := X + Y; is error prone, because X might be evaluated twice without
> : notice.
> 
> Still, in
> X +:= Y;
> X might be evaluated during evaluation of Y, without notice.
> Same in Add(Using => X, Adding => Y).
> 
> What about X +:= g(X) + f(X);

The 'idem' proposal allows the programmer to state precisely how these
issues are to be resolved in any particular case.

E.g. If Y above if a a function f(X), I can write:

    X := idem + f(idem);
or:
    X := idem + f(X);
or:
    X := X + f(idem);
or:
    X := X + f(X);

depending on what I want.

The C-style ?= operators couple evaluation and assignment.
As we all know, unnecessary coupling is a Bad Thing. 8-)

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

Re: Ideas for Ada 200X

[Robert I. Eachus]

Russ wrote:

> Once again, I will explain why. The first form requires the creation
> of a temporary matrix to hold the sum, then a copy from the temporary
> back to A. The second form, on the other hand, can do the addition in
> place in A on an element by element basis, eliminating the need for
> the temporary matrix and the copy operation.

Give it a rest.  You keep trying to "explain" things like this to a 
newsgroup where there are several compiler experts who regularly post. 
Bob, Randy, Tucker and I could probably spend hours discussing where Ada 
requires that the intermediates be materialized.  We have had such 
discussions, one of the results of those discussions is the Ada 95 
Reference Manual.

If Ada does require an intermediate value to be materialized, it does so 
with good reason.  Let's take a look at your matrix example.  Ada 
requires that in

     A := A + B;

The value of A be unchanged if Constraint_Error is raised, in other 
words if there is an overflow when adding one of the elements of A to 
one of the elements of B.  If the type of A and B is modular, then no 
intermediate is required or used.  A better example might be:

    A := A and B;

Where A and B are boolean vectors.  This can be done in place.

What if Ada did allow:

     A += B; ?

Then the Ada rules would still require that A be unchanged if 
Constraint_Error was raised, so there would be an intermediate.  Of 
course, a compiler could 'unwind' the partial addition by subtraction to 
produce the required result.  It would be an interesting optimization, 
but AFAIK, no Ada compiler does it.

Re: Ideas for Ada 200X

[Larry Kilgallen]

In article <slrnbdp84f.ns.lutz@taranis.iks-jena.de>, Lutz Donnerhacke <lutz@iks-jena.de> writes:
> * Preben Randhol wrote:
>> Lutz Donnerhacke wrote:
>>> Please to instantiate it for every countable type A, you use and any
>>> universal_integer B. Thank you.
>> 
>> Ok I can agree. But at least I would rather have
>>
>>    A :=+ B
>> or
>>    A +:= B
>>
>> whichever is more clear.
> 
> It's more clear, because you know this limited idiom from an other language.

I don't.   Is that other language a prerequisite to learning Ada ?

Word origins

[Stephen Leake]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Stephen Leake wrote:
> 
> >Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
> >
> >> Stephen Leake wrote:
> >> 
> [42 microns]
> >> >(Extra points for identifying the
> >> >cultural origions of that number :).
> >> 
> >> This one is easy. :-)
> >> 
> >> The answer to the Ultimate Question of Life, the Universe and
> >> Everything. "Hitchhiker's Guide through the Galaxy" from Douglas Adams
> >> (1952-2001).
> >
> >Yes, but that's just the "42". Where did "micron" come to mean "some
> >imaginary unit of measure"?
> 
> Mmh, to my knowledge micron is originated from the Greek word "micros"
> for little, small, tiny. Used to mean one out of a thousand
> [millimeter] since I am able to speak. Ok, probably it was used
> earlier already... ;-)
> 
> So you have a different story?

Back in 1978 or so, there was a bad Science Fiction TV show
"Battle Star Galactica". Every time they measured something, it was
expressed in "microns"; distance to the nearest star, time till the
bomb blew up, size of a molecule, anything.

So now, whenever I'm not sure of the right units or scale, I just say
"microns" :).

-- 
-- Stephe

Re: Word origins

[Preben Randhol]

Stephen Leake wrote:
> Back in 1978 or so, there was a bad Science Fiction TV show
> "Battle Star Galactica". Every time they measured something, it was
> expressed in "microns"; distance to the nearest star, time till the
> bomb blew up, size of a molecule, anything.
> 

I don't know. Could be micro parsecs ?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Robert A Duff]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> E.g. If Y above if a a function f(X), I can write:
> 
>     X := idem + f(idem);
> or:
>     X := idem + f(X);
> or:
>     X := X + f(idem);
> or:
>     X := X + f(X);
> 
> depending on what I want.

The last three are almost certainly wrong, or are the same as the first
one, depending on whether the name X has side effects.

- Bob

Re: Ideas for Ada 200X

[Bill Findlay]

On 3/6/03 17:33, in article wcc8ysjktnv.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@shell01.TheWorld.com> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
> 
>> E.g. If Y above if a a function f(X), I can write:
>> 
>>     X := idem + f(idem);
>> or:
>>     X := idem + f(X);
>> or:
>>     X := X + f(idem);
>> or:
>>     X := X + f(X);
>> 
>> depending on what I want.
> 
> The last three are almost certainly wrong, or are the same as the first
> one, depending on whether the name X has side effects.

I agree. 8-)

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

Re: Ideas for Ada 200X

[Robert A Duff]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> As I see it there are several arguments in favour of the 'idem' proposal:
> 
> 1. It lets the programmer indicate that the occurrences of the LHS in the
> RHS are *necessarily* the same, and not contingently so, which makes the
> code more self-documenting.
> 
> 2. It removes a source of error in transcribing the LHS multiple times.
> 
> 3. It allows more concisely readable code when the LHS is lengthy.
> 
> 4. It provides functionality that it only partially available by means of
> much clumsier renaming declarations, because not all objects can be renamed.
> 
> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
> that lvalue as often as needed to evaluate the RHS. This has three potential
> benefits: shorter code, faster execution, and once-only invocation of any
> side effects.
> 
> 6. It might make it somewhat easier for the compiler to generate
> update-in-place object code, where the target architecture allows that and
> where it offers a performance advantage.
> 
> 7. It provides all the utility of C's multitude of combined assignment
> operators with one small, compatible change to the syntax of operands.
> (I specify C, rather than C++, to avoid getting into a argument about
> overloading assignment).
> 
> 8. It allows the expression of useful forms that C's combined assignment
> operators cannot achieve (e.g. X := 1 - idem;).

Well said.

Number 6 applies only if there are non-inlined calls involved.
They presumably don't normally have side effects (because that
would usually be wrong), but the compiler doesn't *know* that.

That is, currently the compiler can avoid evaluating X twice in
"X := X + 1;" only if "X" contains no out-of-line function calls.

Number 5 doesn't say anything that 1 and 6 don't say.

Anyway, I doubt if this feature will make it into any future version of
Ada.  It's just not important enough.  But it's fun talking about it...

> -- 
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
> 
> BTW I would like to emphasize that I am not wedded to the concrete syntax of
> 'idem', '<>', 'all' or whatever - I regard that as a minor matter to be
> determined, and hope that aesthetic preferences do not cloud the wider
> issue.

- Bob

Re: Ideas for Ada 200X

[Hyman Rosen]

Robert A Duff wrote:
> That is, currently the compiler can avoid evaluating X twice in
> "X := X + 1;" only if "X" contains no out-of-line function calls.

Given overloading, is it necessarily the case that the two Xs
refer to the same object?

Re: Ideas for Ada 200X

[Russ]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7vfzmr60r5.fsf@vlinux.voxelvision.no>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<KvydnZ2dnunHfUej4p2dnA@gbronline.com>...
> > > > No, they aren't the same. The result is the same, but the second form
> > > > can be implemented much more efficiently. The first form requires the
> > > 
> > > Oh, good grief.  If the language specification says
> > > they have the same result, then they can be implemented
> > > the same way.  _I_ certainly will never specify "these
> > > must have the same result, but you must do extra work
> > > on that one."
> > 
> > Oh, good grief yourself.
> > 
> > If A and B are matrices, then
> > 
> >     A := A + B
> > and
> >     A += B
> > 
> > give the same result, but the latter, if properly implemented, is
> > indeed substantially more efficient than the former.
> > 
> > Once again, I will explain why. The first form requires the creation
> > of a temporary matrix to hold the sum, then a copy from the temporary
> > back to A. The second form, on the other hand, can do the addition in
> > place in A on an element by element basis, eliminating the need for
> > the temporary matrix and the copy operation.
> > 
> 
> Where in the standard is this temporary matrix required? Look at it
> this way: you are telling the computer to assign the sum of A and B to
> A. Why isn't the compiler free to do the addition in place, unless you
> have got an overloaded "+" with strange side effects?

How would that work? Remember, my overloaded "+" operator could do
anything. For example, I could be using it for quaternion "addition,"
which follows very different rules from conventional matrix addition.
Think also of how it would deal with chained addition, e.g., A := B +
C + D + E.

Your suggestion would require some sort of advanced artificial
intelligence to be built in to the compiler. The AI system would need
to perform a very complex analysis of the overloaded "+" operator and
decide how to deal with it. The only other alternative would be to
have the "+" operator automatically defined for arrays. Either
approach would constitute a major change in philosophy for Ada.

Re: Ideas for Ada 200X

[Bill Findlay]

On 3/6/03 17:44, in article wcc4r37kt5s.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@shell01.TheWorld.com> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
>> As I see it there are several arguments in favour of the 'idem' proposal:
>> 1. It lets the programmer indicate that the occurrences of the LHS in the
>> RHS are *necessarily* the same, and not contingently so, which makes the
>> code more self-documenting.
...
>> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
>> that lvalue as often as needed to evaluate the RHS. This has three potential
>> benefits: shorter code, faster execution, and once-only invocation of any
>> side effects.
>> 6. It might make it somewhat easier for the compiler to generate
>> update-in-place object code, where the target architecture allows that and
>> where it offers a performance advantage.
>> 
... 
> Number 6 applies only if there are non-inlined calls involved.
> They presumably don't normally have side effects (because that
> would usually be wrong), but the compiler doesn't *know* that.
> That is, currently the compiler can avoid evaluating X twice in
> "X := X + 1;" only if "X" contains no out-of-line function calls.

Do volatile variables not come into play in defining eliminable CSEs
(probably not the right language-lawyer language, but YKWIM)?

> Number 5 doesn't say anything that 1 and 6 don't say.

I was going to quibble with that, saying that 5 requires an optimization
that is only allowed at the moment, but I see that is covered by your take
on "necessarily" in point 1.

How would you see the semantics being explicated?  The implicit access all
method, or the implicit in out parameter method, or something else?

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

Re: Ideas for Ada 200X

[Russ]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message news:<tsihbb.ljd.ln@skymaster>...
> "Russ" <18k11tm001@sneakemail.com> a �crit dans le message news:
> bebbba07.0306022127.46f6c998@posting.google.com...
> > Wesley Groleau <wesgroleau@despammed.com> wrote in message
>  news:<KvydnZ2dnunHfUej4p2dnA@gbronline.com>...
> > > > No, they aren't the same. The result is the same, but the second form
> > > > can be implemented much more efficiently. The first form requires the
> > >
> > > Oh, good grief.  If the language specification says
> > > they have the same result, then they can be implemented
> > > the same way.  _I_ certainly will never specify "these
> > > must have the same result, but you must do extra work
> > > on that one."
> >
> > Oh, good grief yourself.
> >
> > If A and B are matrices, then
> >
> >     A := A + B
> > and
> >     A += B
> >
> > give the same result, but the latter, if properly implemented, is
> > indeed substantially more efficient than the former.
> >
> > Once again, I will explain why. The first form requires the creation
> > of a temporary matrix to hold the sum, then a copy from the temporary
> > back to A. The second form, on the other hand, can do the addition in
> > place in A on an element by element basis, eliminating the need for
> > the temporary matrix and the copy operation.
> >
> My usual answer to things dealing with efficiency:
> Did you try to measure which one is faster, before asserting that?
> If no, do the measurement and come again.

I actually did this test in C++ several years ago. The "+=" form was
about three to four times faster. If you're telling me that is not
true for Ada, I can only conclude that either 1) you did not implement
it properly, or 2) Ada itself does not implement the procedure
equivalent to "+=" very efficiently.

Perhaps I'll try it myself in Ada when I get a chance. Since you've
already done it in Ada, I suggest you try the two forms in C++ and see
how it compares with Ada. If your claim is true, then the C++ "+="
form should be substantially faster than the equivalent form in Ada.

> It is absolutely not obvious that the extra copy is more costly (and yes, I
> did the measurement).
> Remember that when accessing an array passed by reference, you need an extra
> dereference to
> access each element, compared with a local variable. OTOH, copying can be
> quite fast (block copy).
> On big matrices, having a local copy can be faster. Depends on many things,
> including the size of
> the matrix.

Think of it this way:

    A := A + B

is equivalent to

    temp := A -- create temp and copy into it
    temp += B -- perform addition
    A := temp -- copy back over to A

How could that possibly be more efficient that simply A += B?

In C++, passing by reference is very efficient. If I understand it
correctly, aside from passing the address, it's essentially as
efficient as accessing the passed array inline or as a global. In the
"+=" form, both matrices are passed by reference (at least in C++), so
I don't see how this could be inefficient in any way. Aside from
passing the addresses of the arrays, it's as efficient as doing it
inline. I assume the same is true for Ada. Am I wrong?

Re: Ideas for Ada 200X

[Robert A Duff]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> > Number 6 applies only if there are non-inlined calls involved.
> > They presumably don't normally have side effects (because that
> > would usually be wrong), but the compiler doesn't *know* that.
> > That is, currently the compiler can avoid evaluating X twice in
> > "X := X + 1;" only if "X" contains no out-of-line function calls.
> 
> Do volatile variables not come into play in defining eliminable CSEs
> (probably not the right language-lawyer language, but YKWIM)?

Yes, volatile and atomic come into play.  Note that I said, "only if",
not "if and only if".  In order to do an optimization, the compiler has
to prove that it doesn't matter.  All kinds of things enter into that
proof.

> > Number 5 doesn't say anything that 1 and 6 don't say.
> 
> I was going to quibble with that, saying that 5 requires an optimization
> that is only allowed at the moment, but I see that is covered by your take
> on "necessarily" in point 1.

OK.

> How would you see the semantics being explicated?  The implicit access all
> method, or the implicit in out parameter method, or something else?

I suggest that 'in out' params are the closest things to the semantics
you want.

- Bob

Re: Ideas for Ada 200X

[Russ]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB0262E3.3059%yaldnifw@blueyonder.co.uk>...
> As I see it there are several arguments in favour of the 'idem' proposal:
> 
> 1. It lets the programmer indicate that the occurrences of the LHS in the
> RHS are *necessarily* the same, and not contingently so, which makes the
> code more self-documenting.

If there is any question about that, the programmer can (and should)
just use an explicit intermediate variable to make it clear.

> 2. It removes a source of error in transcribing the LHS multiple times.

So does "+=", "-=", etc.

> 3. It allows more concisely readable code when the LHS is lengthy.

So does "+=", "-=", etc.

> 4. It provides functionality that it only partially available by means of
> much clumsier renaming declarations, because not all objects can be renamed.

So does "+=", "-=", etc.

> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
> that lvalue as often as needed to evaluate the RHS. This has three potential
> benefits: shorter code, faster execution, and once-only invocation of any
> side effects.

See 1.

> 6. It might make it somewhat easier for the compiler to generate
> update-in-place object code, where the target architecture allows that and
> where it offers a performance advantage.

Might? "+=" definitely does. Once you have that ":=" in there, all
bets for efficiency are off. Barring some very complicated form of
artificial intelligence, ":=" pretty much rules out in-place
operations (except perhaps for certain very restricted cases).

> 7. It provides all the utility of C's multitude of combined assignment
> operators with one small, compatible change to the syntax of operands.
> (I specify C, rather than C++, to avoid getting into a argument about
> overloading assignment).

But does it provide the same potential efficiency?

> 8. It allows the expression of useful forms that C's combined assignment
> operators cannot achieve (e.g. X := 1 - idem;).

I think we're getting wrapped around the axle here, folks. No, the
"assignment operators" do not handle all cases, but they do not need
to. They are simply a nice shorthand notation for certain very common
cases. The cases where they don't apply can be handled by other
conventional methods. As for X := 1 - idem, one could simply write X
:= 1 - X. What's the big deal? Sure, if X had a longer name, then a
shorter alias might be handy. I'm not completely opposed to this idea,
but if it is adopted it should be adopted in *addition* to, not in
lieu of, the assignment operators that have already proven their
usefullness in several other very popular languages.

Re: Ideas for Ada 200X

[Bill Findlay]

On 3/6/03 20:39, in article bebbba07.0306031139.21306c32@posting.google.com,
"Russ" <18k11tm001@sneakemail.com> wrote:

>> 1. It lets the programmer indicate that the occurrences of the LHS in the
>> RHS are *necessarily* the same, and not contingently so, which makes the
>> code more self-documenting.
> 
> If there is any question about that, the programmer can (and should)
> just use an explicit intermediate variable to make it clear. ...

Sorry, I don't get this. Can you give an example?
How can 'X := X + 1;' be clarified by introducing an intermediate variable?

>> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
>> that lvalue as often as needed to evaluate the RHS. This has three potential
>> benefits: shorter code, faster execution, and once-only invocation of any
>> side effects.
> 
> See 1.

You've lost me.
 
>> 6. It might make it somewhat easier for the compiler to generate
>> update-in-place object code, where the target architecture allows that and
>> where it offers a performance advantage.
> 
> Might? "+=" definitely does. Once you have that ":=" in there, all
> bets for efficiency are off. Barring some very complicated form of
> artificial intelligence, ":=" pretty much rules out in-place
> operations (except perhaps for certain very restricted cases).

The only difference between the 'idem' proposal and the use of ?=, *in the
context of my assumptions*, is syntactic (i.e. 'idem' is syntactically much
more general). There is no semantic difference, and therefore no potential
performance difference whatsoever (for the subset that is covered by ?=).

>> 7. It provides all the utility of C's multitude of combined assignment
>> operators with one small, compatible change to the syntax of operands.
>> (I specify C, rather than C++, to avoid getting into a argument about
>> overloading assignment).
> 
> But does it provide the same potential efficiency?

Yes, since it means exactly the same thing, in the context I explicitly set
out here. You want to make a different case, involving overloaded
assignment; but I chose not to take part in that argument.

>> 8. It allows the expression of useful forms that C's combined assignment
>> operators cannot achieve (e.g. X := 1 - idem;).
> 
> I think we're getting wrapped around the axle here, folks. ...

Speak for your own position. 8-)

> "assignment operators" do not handle all cases, but they do not need
> to. They are simply a nice shorthand notation for certain very common
> cases. The cases where they don't apply can be handled by other
> conventional methods. As for X := 1 - idem, one could simply write X
> := 1 - X. What's the big deal?

The big deal is (1) you lose all the advantages I listed; and (2) 'idem'
handles easily the cases that assignment operators fail to handle. General
solutions are better than special-case fixups.

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

Re: Ideas for Ada 200X

[tmoran]

> A += B
  I may have missed something here - is the compiler supposed to
know that A and B are matrices, and generate code to add elements,
or is it just supposed to generate a call to
  procedure "+="(Left : in out Matrices; Right : in Matrices)
If the former, what if the elements of the matrices are themselves,
say, vectors, or complex numbers in polar form?  If the former,
would you want to translate 'A <string> B' as <string>(A,B)
for arbitrary <string>, or is this only for += and -= ?
  BTW, how often does "A := A+B;" occur in actual high performance
matrix arithmetic code?

Re: Ideas for Ada 200X

[Russ]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EDCBDF4.1050900@attbi.com>...
> Russ wrote:
> 
> > Once again, I will explain why. The first form requires the creation
> > of a temporary matrix to hold the sum, then a copy from the temporary
> > back to A. The second form, on the other hand, can do the addition in
> > place in A on an element by element basis, eliminating the need for
> > the temporary matrix and the copy operation.
> 
> Give it a rest.  You keep trying to "explain" things like this to a 
> newsgroup where there are several compiler experts who regularly post. 
> Bob, Randy, Tucker and I could probably spend hours discussing where Ada 
> requires that the intermediates be materialized.  We have had such 
> discussions, one of the results of those discussions is the Ada 95 
> Reference Manual.

But since there are more than four participants out there in this
newsgroup, I assume that some of them are NOT compiler experts. So
please don't take my posts so personally.

> If Ada does require an intermediate value to be materialized, it does so 
> with good reason.  Let's take a look at your matrix example.  Ada 
> requires that in
> 
>      A := A + B;
> 
> The value of A be unchanged if Constraint_Error is raised, in other 
> words if there is an overflow when adding one of the elements of A to 
> one of the elements of B.  If the type of A and B is modular, then no 
> intermediate is required or used.  A better example might be:

Suppose the elements of A and B *are* modular, and I write

    A := A + B + C

Are you telling me no temporaries are needed? And suppose I define "+"
for quaternion arithmetic. Still no temporaries needed?

>     A := A and B;
> 
> Where A and B are boolean vectors.  This can be done in place.

Again, how about A := A and B and C? No temps needed?

> What if Ada did allow:
> 
>      A += B; ?
> 
> Then the Ada rules would still require that A be unchanged if 
> Constraint_Error was raised, so there would be an intermediate.  Of 
> course, a compiler could 'unwind' the partial addition by subtraction to 
> produce the required result.  It would be an interesting optimization, 
> but AFAIK, no Ada compiler does it.

Well, it seems to me that such an "interesting optimization" might be
well worth doing. Then again, the "unwind" operation would obviously
depend on the definition of the "+=" operation, which could be
different for each type, so I don't see how it could be done in
general.

In any case, the performance hit taken to keep A unchanged when a
Constraint_Error is raised seems rather expensive to me. If it were up
to me, I would take the factor of four better efficiency over
preserving A in the rare case of an overflow. And I'll bet most
programmers doing heavy-duty number crunching for simulation would
too.

I know that Ada is preferable for safety-critical applications, but
based on what you are telling me, it sure seems to be a poor choice
for non-safety-critical simulation with heavy number crunching. Thanks
for clarifying that. I guess C++ is good for something after all, eh?

Re: Ideas for Ada 200X

[Bill Findlay]

On 3/6/03 23:20, in article bebbba07.0306031420.69c20f71@posting.google.com,
"Russ" <18k11tm001@sneakemail.com> wrote:

> I know that Ada is preferable for safety-critical applications, but
> based on what you are telling me, it sure seems to be a poor choice
> for non-safety-critical simulation with heavy number crunching. Thanks
> for clarifying that. I guess C++ is good for something after all, eh?

Only if getting results *fast* is more important than getting them *right*.
8-)

(And let's not forget that Ada *can* compute the result matrix in-place,
just not using the notation you prefer. It's a strange performance-oriented
programmer who gives up a factor of 4 for aesthetic reasons.)

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

Re: Ideas for Ada 200X

[tmoran]

>I actually did this test in C++ several years ago. The "+=" form was
>about three to four times faster. If you're telling me that is not

Using
   subtype ns is integer range 1 .. 100;  -- or 1 .. 5 or 1 .. 50
   type matrices is array(ns,ns) of integer;
   procedure add_to(left : in out matrices; right : in matrices) is ...
   function "+"(left, right : matrices) return matrices is ...

and compiling with -O3 -gnato on Windows gnat 3.15p, I find
function "+=" takes about 12% longer than procedure add_to

inserting "pragma suppress(all_checks)",
function "+=" takes about 35% longer than procedure add_to

Running a comparison with a program compiled with MSVC++ 5.0
  10K iterations on a 100x100 matrix the "+=" vs add_to take
1.17 vs .88 seconds with Ada, 5.3 vs 2.7 seconds with C++
(It's been a while, and my C is rusty.  Please ask tmoran@acm.org
if you would like my code to check or improve or run with your system.)

Re: Ideas for Ada 200X

[Russ]

tmoran@acm.org wrote in message news:<Z28Da.560059$Si4.511313@rwcrnsc51.ops.asp.att.net>...
> > A += B
>   I may have missed something here - is the compiler supposed to
> know that A and B are matrices, and generate code to add elements,

No.

> or is it just supposed to generate a call to
>   procedure "+="(Left : in out Matrices; Right : in Matrices)

Yes. It would be user defined.

> If the former, what if the elements of the matrices are themselves,
> say, vectors, or complex numbers in polar form?  If the former,
> would you want to translate 'A <string> B' as <string>(A,B)
> for arbitrary <string>, or is this only for += and -= ?

N/A

>   BTW, how often does "A := A+B;" occur in actual high performance
> matrix arithmetic code?

I think matrix addition comes up quite a bit. Take a look at the
Kalman filter equations, for example.

Re: Ideas for Ada 200X

[Russ]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB02E370.30D1%yaldnifw@blueyonder.co.uk>...
> On 3/6/03 23:20, in article bebbba07.0306031420.69c20f71@posting.google.com,
> "Russ" <18k11tm001@sneakemail.com> wrote:
> 
> > I know that Ada is preferable for safety-critical applications, but
> > based on what you are telling me, it sure seems to be a poor choice
> > for non-safety-critical simulation with heavy number crunching. Thanks
> > for clarifying that. I guess C++ is good for something after all, eh?
> 
> Only if getting results *fast* is more important than getting them *right*.
> 8-)

I prefer to get my results both fast *and* right. :^) Seriously, we
are currently doing some "fast-time" sims that take something like 8
hours of clock time. Two hours would be a lot more convenient, but 32
would be a lot less.

> (And let's not forget that Ada *can* compute the result matrix in-place,
> just not using the notation you prefer. It's a strange performance-oriented
> programmer who gives up a factor of 4 for aesthetic reasons.)

But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"
and Mr. Eachus says "+=" needs a temporary to preserve A in the case
of a Constraint_Error. So, as far as efficiency is concerned, we're
screwed either way, aren't we?

Re: Word origins

[Vinzent Hoefler]

Stephen Leake wrote:

[Micron]
>Back in 1978 or so, there was a bad Science Fiction TV show
>"Battle Star Galactica".

Oh yeah, I heard of that. Probably is so well known for the worst
series eber or such... ;)

>Every time they measured something, it was
>expressed in "microns"; distance to the nearest star, time till the
>bomb blew up, size of a molecule, anything.

So that's it.

>So now, whenever I'm not sure of the right units or scale, I just say
>"microns" :).

Well now you know it actually means one micrometer. :)


Vinzent.

Re: Word origins

[Vinzent Hoefler]

Preben Randhol wrote:

>Stephen Leake wrote:
>> Back in 1978 or so, there was a bad Science Fiction TV show
>> "Battle Star Galactica". Every time they measured something, it was
>> expressed in "microns"; distance to the nearest star, time till the
>> bomb blew up, size of a molecule, anything.
>
>I don't know. Could be micro parsecs ?

Reminds me on the joke that attoparsec per microfortnight is a good
approximation for inch per second. :)


Vinzent.

Re: Ideas for Ada 200X

[Jean-Pierre Rosen]

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


"Russ" <18k11tm001@sneakemail.com> a �crit dans le message news:
bebbba07.0306031101.6ca6a8d6@posting.google.com...
> I actually did this test in C++ several years ago. The "+=" form was
> about three to four times faster. If you're telling me that is not
> true for Ada, I can only conclude that either 1) you did not implement
> it properly, or 2) Ada itself does not implement the procedure
> equivalent to "+=" very efficiently.
Tests in other languages are irrelevant.
Since C++ has the += operator, it will not try to optimize A = A+B

Similarly, translation of FORTRAN benchmarks in Ada give awfull results.
The reason is that there are lots of checks to verify that:
     DO 10 I = 1, N
10   A(I) = B(I)
is correctly optimized into a block copy. Ada compilers don't do that
optimization, since people would rather write:
   A := B.

> Think of it this way:
>
>     A := A + B
>
> is equivalent to
>
>     temp := A -- create temp and copy into it
>     temp += B -- perform addition
>     A := temp -- copy back over to A
>
> How could that possibly be more efficient that simply A += B?
>
As I mentioned, we are talking about big arrays passed as parameters.
If you use a temp, the temp is in the stack. If you access the variable
directly, the address of the variable is in the stack. Therefore, any
reference
to an array element will need an extra dereferencing. That can make a
difference.


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

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

18k11tm001@sneakemail.com (Russ) writes:

<snip>

> Well, it seems to me that such an "interesting optimization" might be
> well worth doing. Then again, the "unwind" operation would obviously
> depend on the definition of the "+=" operation, which could be
> different for each type, so I don't see how it could be done in
> general.

It's done all the time in DB systems with a log. Probably not an
efficient solution for a programming language, but certainly generally
doable :-)

> 
> In any case, the performance hit taken to keep A unchanged when a
> Constraint_Error is raised seems rather expensive to me. If it were up
> to me, I would take the factor of four better efficiency over
> preserving A in the rare case of an overflow. And I'll bet most
> programmers doing heavy-duty number crunching for simulation would
> too.
> 

Just turn off the checking if you are certain that your cruncher works
correctly. If you are paranoid about the use of temporaries, just
write an inlined "add" procedure which does the addition in place.

> I know that Ada is preferable for safety-critical applications, but
> based on what you are telling me, it sure seems to be a poor choice
> for non-safety-critical simulation with heavy number crunching. Thanks
> for clarifying that. I guess C++ is good for something after all, eh?

C++ is OK for many purposes, and the C++ templates are certainly fun
and flexible.  For heavy number crunching I would still use Fortran
because of the excellent vectorizing compilers available. For
multithreaded applications Ada wins hands down.

-- 
Ole-Hj. Kristensen

******************************************************************************
* "Premature optimization is the root of all evil"
*  Donald Knuth
******************************************************************************

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

18k11tm001@sneakemail.com (Russ) writes:

> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB02E370.30D1%yaldnifw@blueyonder.co.uk>...
> > On 3/6/03 23:20, in article bebbba07.0306031420.69c20f71@posting.google.com,
> > "Russ" <18k11tm001@sneakemail.com> wrote:
> > 
> > > I know that Ada is preferable for safety-critical applications, but
> > > based on what you are telling me, it sure seems to be a poor choice
> > > for non-safety-critical simulation with heavy number crunching. Thanks
> > > for clarifying that. I guess C++ is good for something after all, eh?
> > 
> > Only if getting results *fast* is more important than getting them *right*.
> > 8-)
> 
> I prefer to get my results both fast *and* right. :^) Seriously, we
> are currently doing some "fast-time" sims that take something like 8
> hours of clock time. Two hours would be a lot more convenient, but 32
> would be a lot less.
> 
> > (And let's not forget that Ada *can* compute the result matrix in-place,
> > just not using the notation you prefer. It's a strange performance-oriented
> > programmer who gives up a factor of 4 for aesthetic reasons.)
> 
> But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"
> and Mr. Eachus says "+=" needs a temporary to preserve A in the case
> of a Constraint_Error. So, as far as efficiency is concerned, we're
> screwed either way, aren't we?

Not if you explicitly turn off the constraint checking.  If you really
want performance for matrix operations, consider rewriting the matrix
operations in assembler using SSE or equivalent instructions. A
speedup with a factor of 4 is realistic on Intel platforms.
Gnat has excellent assembler facilites, btw.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

tmoran@acm.org writes:

> >I actually did this test in C++ several years ago. The "+=" form was
> >about three to four times faster. If you're telling me that is not
> 
> Using
>    subtype ns is integer range 1 .. 100;  -- or 1 .. 5 or 1 .. 50
>    type matrices is array(ns,ns) of integer;
>    procedure add_to(left : in out matrices; right : in matrices) is ...
>    function "+"(left, right : matrices) return matrices is ...
> 
> and compiling with -O3 -gnato on Windows gnat 3.15p, I find
> function "+=" takes about 12% longer than procedure add_to
> 

You mean function "+" ?

> inserting "pragma suppress(all_checks)",
> function "+=" takes about 35% longer than procedure add_to
> 
> Running a comparison with a program compiled with MSVC++ 5.0
>   10K iterations on a 100x100 matrix the "+=" vs add_to take
> 1.17 vs .88 seconds with Ada, 5.3 vs 2.7 seconds with C++
> (It's been a while, and my C is rusty.  Please ask tmoran@acm.org
> if you would like my code to check or improve or run with your system.)

I think the difference between C++ and Ada is the compiler. I run both
through gcc, and got identical results.  The function "+" is about
three times slower on my system, as you can see.  This is a bit
disappointing, I'll run it through gcc 3.2 later and see if it does
any better.

procedure Matrix_proc is subtype M_Index is Integer range
1..100; type Matrices is array(M_Index,M_Index) of Integer;
   
   procedure add(M1 : in out Matrices; M2: Matrices) is
   begin
      for I in M1'Range(2) loop
         for J in M1'Range(1) loop
            M1(I,J) := M1(I,J) + M2(I,J);
         end loop;
      end loop;
   end add;
   pragma Inline(Add);
   
   M1 : Matrices ;
   M2: Matrices ;
begin
   for I in 1..10000 loop
      Add(M1,M2);
   end loop;
end Matrix_proc;

procedure Matrix_fun is
   subtype M_Index is Integer range 1..100;
   type Matrices is array(M_Index,M_Index) of Integer;

   function "+"(M1,M2: Matrices) return Matrices is
      Tmp : Matrices := M1;
   begin
      for I in M1'Range(2) loop
         for J in M1'Range(1) loop
            Tmp(I,J) := M1(I,J) + M2(I,J);
         end loop;
      end loop;
      return Tmp;
   end "+";
   pragma Inline("+");

   M1 : Matrices ;
   M2: Matrices ;
begin
   for I in 1..10000 loop
      M1 := M1 + M2;
   end loop;
end Matrix_fun;

   
inline void add(int m1[100][100], int m2[100][100])
{
  for(int i = 0; i < 100; i++){
    for(int j = 0; j < 100; j++){
      m1[i][j] = m1[i][j] + m2[i][j];
    }
  }
}   

int main()
{
  int m1[100][100];
  int m2[100][100];
  for(int i = 0; i < 10000; i++){
      add(m1,m2);
  }
}

oleh@VOLGA /cygdrive/c/div
$ gnatmake -s -gnatp -O3 -funroll-loops matrix_fun
gcc -c -gnatp -O3 -funroll-loops matrix_fun.adb
matrix_fun.adb:19:04: warning: "M2" is never assigned a value
matrix_fun.adb:22:13: warning: "M1" may be referenced before it has a value
gnatbind -x matrix_fun.ali
gnatlink matrix_fun.ali

oleh@VOLGA /cygdrive/c/div
$ gnatmake -s -gnatp -O3 -funroll-loops matrix_proc
gcc -c -gnatp -O3 -funroll-loops matrix_proc.adb
matrix_proc.adb:16:04: warning: "M2" is never assigned a value
gnatbind -x matrix_proc.ali
gnatlink matrix_proc.ali

oleh@VOLGA /cygdrive/c/div
$ !g++
g++ -O3 -funroll-loops -o matrix_c matrix_c.cpp

oleh@VOLGA /cygdrive/c/div
$ time matrix_c

real    0m0.221s
user    0m0.200s
sys     0m0.020s

oleh@VOLGA /cygdrive/c/div
$ time matrix_proc

real    0m0.215s
user    0m0.010s
sys     0m0.010s

oleh@VOLGA /cygdrive/c/div
$ time matrix_fun

real    0m0.622s
user    0m0.030s
sys     0m0.000s

oleh@VOLGA /cygdrive/c/div
$

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Preben Randhol]

tmoran@acm.org wrote:
>>I actually did this test in C++ several years ago. The "+=" form was
>>about three to four times faster. If you're telling me that is not
> 
> Using
>    subtype ns is integer range 1 .. 100;  -- or 1 .. 5 or 1 .. 50
>    type matrices is array(ns,ns) of integer;
>    procedure add_to(left : in out matrices; right : in matrices) is ...
>    function "+"(left, right : matrices) return matrices is ...
> 
> and compiling with -O3 -gnato on Windows gnat 3.15p, I find
> function "+=" takes about 12% longer than procedure add_to
> 
> inserting "pragma suppress(all_checks)",
> function "+=" takes about 35% longer than procedure add_to

I take it you meant: function "+" takes about 35% longer than procedure
add_to.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"
> and Mr. Eachus says "+=" needs a temporary to preserve A in the case
> of a Constraint_Error. So, as far as efficiency is concerned, we're
> screwed either way, aren't we?

No because "Add(A,B)" wouldn't need a temporary.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"
> and Mr. Eachus says "+=" needs a temporary to preserve A in the case
> of a Constraint_Error. So, as far as efficiency is concerned, we're
> screwed either way, aren't we?

Robert Eachus and I have had that argument before, and I don't really
feel like having it again, but for the record: I disagree with Robert.
I believe the wording of RM-11.6 allows the left-hand side of an
assignment to be destroyed in the presence of Constraint_Error.
I also believe that was the *intent* of 11.6.  (I know something about
the intent, I think, since Tucker and I spent days wrestling with
the wording.)

For example:

    type T is range 1..10;
    X: T := 10;

    X := X + 1;

If X is in register R1, then the compiler can generate machine code
like:

    Add R1+1, putting the result in R1.
    Check that R1 in 1..10, and raise C_E if not.

thus leaving the junk value 11 in X (i.e. R1).
This is true even if an exception handler can see X.

The semantics described by Robert Eachus is correct for Ada 83,
but it was deliberately changed for Ada 95, to make the language
more competitive with other languages in terms of efficiency.

The moral of the story is: If you handle predefined exceptions,
you are playing with fire.

- Bob

Re: Ideas for Ada 200X

[Bill Findlay]

On 4/6/03 11:10, in article 7vu1b640gf.fsf@vlinux.voxelvision.no,
"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:

> I think the difference between C++ and Ada is the compiler. I run both
> through gcc, and got identical results.

They are far from identical, AFAICS.
You show the Ada code as being 10 times faster, at 0.200s user-mode CPU time
for C++ matrix_c, 0.030s for Ada matrix_fun, and 0.010s for matrix_proc :

> $ gnatmake -s -gnatp -O3 -funroll-loops matrix_fun
> $ gnatmake -s -gnatp -O3 -funroll-loops matrix_proc
> g++ -O3 -funroll-loops -o matrix_c matrix_c.cpp
> 
> $ time matrix_c
> user    0m0.200s

> $ time matrix_proc
> user    0m0.010s

> $ time matrix_fun
> user    0m0.030s

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

Re: Ideas for Ada 200X

[Bill Findlay]

On 4/6/03 11:10, in article 7vu1b640gf.fsf@vlinux.voxelvision.no,
"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:

> I think the difference between C++ and Ada is the compiler. I run both
> through gcc, and got identical results.  The function "+" is about
> three times slower on my system, as you can see.  This is a bit
> disappointing, I'll run it through gcc 3.2 later and see if it does
> any better.
...
> procedure Matrix_fun is
>  subtype M_Index is Integer range 1..100;
>  type Matrices is array(M_Index,M_Index) of Integer;
> 
>  function "+"(M1,M2: Matrices) return Matrices is
>     Tmp : Matrices := M1;
Why the redundant copy? ^

>  begin
>     for I in M1'Range(2) loop
>        for J in M1'Range(1) loop
>           Tmp(I,J) := M1(I,J) + M2(I,J);
N.B. Not Tmp............^

>        end loop;
>     end loop;
>     return Tmp;
>  end "+";
>  pragma Inline("+");

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> On 4/6/03 11:10, in article 7vu1b640gf.fsf@vlinux.voxelvision.no,
> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:
> 
> > I think the difference between C++ and Ada is the compiler. I run both
> > through gcc, and got identical results.
> 
> They are far from identical, AFAICS.
> You show the Ada code as being 10 times faster, at 0.200s user-mode CPU time
> for C++ matrix_c, 0.030s for Ada matrix_fun, and 0.010s for matrix_proc :
> 
> > $ gnatmake -s -gnatp -O3 -funroll-loops matrix_fun
> > $ gnatmake -s -gnatp -O3 -funroll-loops matrix_proc
> > g++ -O3 -funroll-loops -o matrix_c matrix_c.cpp
> > 
> > $ time matrix_c
> > user    0m0.200s
> 
> > $ time matrix_proc
> > user    0m0.010s
> 
> > $ time matrix_fun
> > user    0m0.030s
> 
> -- 
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
> 
> 

Well, yes, but the clock time is the same. It's an otherwise unloaded
system, and I get repeatable results, so I suspect there's something
funny going on with the user time measurements. Besides, a user time
of 0.01 seconds would indicate 10**10 additions per second, and I
don't believe my computer is quite as fast as that.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> On 4/6/03 11:10, in article 7vu1b640gf.fsf@vlinux.voxelvision.no,
> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:
> 
> > I think the difference between C++ and Ada is the compiler. I run both
> > through gcc, and got identical results.  The function "+" is about
> > three times slower on my system, as you can see.  This is a bit
> > disappointing, I'll run it through gcc 3.2 later and see if it does
> > any better.
> ...
> > procedure Matrix_fun is
> >  subtype M_Index is Integer range 1..100;
> >  type Matrices is array(M_Index,M_Index) of Integer;
> > 
> >  function "+"(M1,M2: Matrices) return Matrices is
> >     Tmp : Matrices := M1;
> Why the redundant copy? ^
> 
> >  begin
> >     for I in M1'Range(2) loop
> >        for J in M1'Range(1) loop
> >           Tmp(I,J) := M1(I,J) + M2(I,J);
> N.B. Not Tmp............^

Just shows that even Ada cannot protect you completely from brain
farts.  However, even if I remove the assignment, I get essentially
the same results.

Keeping the tmp := M1 assignment and substituting 

Tmp(I,J) := Tmp(I,J) + M2(I,J);

actually reduces the average time to .600 seconds.
Optimizers are strange animals.

> 
> >        end loop;
> >     end loop;
> >     return Tmp;
> >  end "+";
> >  pragma Inline("+");
> 

I managed to get it to run in .393 seconds (clock time) by the following hack:

Tmp : matrices;
for Tmp'Address use M1'address; ......

Now we are down to only 100% increase in time.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EDCBDF4.1050900@attbi.com>...
> > What if Ada did allow:
> > 
> >      A += B; ?
> > 
> > Then the Ada rules would still require that A be unchanged if 
> > Constraint_Error was raised, so there would be an intermediate.  Of 
> > course, a compiler could 'unwind' the partial addition by subtraction to 
> > produce the required result.  It would be an interesting optimization, 
> > but AFAIK, no Ada compiler does it.
> 
> Well, it seems to me that such an "interesting optimization" might be
> well worth doing. Then again, the "unwind" operation would obviously
> depend on the definition of the "+=" operation, which could be
> different for each type, so I don't see how it could be done in
> general.

That is the point; since it can't be done in general, it's not a good
idea to put it in the language in the hope that it will be done for
some particular cases.

> In any case, the performance hit taken to keep A unchanged when a
> Constraint_Error is raised seems rather expensive to me. If it were
> up to me, I would take the factor of four better efficiency over
> preserving A in the rare case of an overflow. And I'll bet most
> programmers doing heavy-duty number crunching for simulation would
> too.

Yes. And they will write a matrix library that does it.

> I know that Ada is preferable for safety-critical applications, but
> based on what you are telling me, it sure seems to be a poor choice
> for non-safety-critical simulation with heavy number crunching.

That's nonsense. Clearly an efficient matrix library can be written in
Ada. We are only talking about whether the syntax

Matrix_Add (To => A, Add => B);

is "better" in some sense than the syntax

A += B;

Ignoring the Constraint_Error handling discussed above, these two
statements have identical run-time behavior; they both call the same
routine. You are arguing that is what Ada should do. Then it is only
when writing and reading the code that there is a difference.

Someone doing heavy-duty number crunching shouldn't care about this
level of syntax choice. In fact, they will even use Fortran, if that
is the only compiler available for the fastest machine they have.
(Hmm. Does Fortran now have += ?).

The designers of Ada (and many users of Ada) think Matrix_Add is
better, partly because they placed emphasis on reading, partly because
it is clear that the programmer decides the semantics with respect to
Constraint_Error etc.

You (and many others) think += is better, partly because you
mistakenly believe it allows the code to be more run-time efficient,
and partly because you are familiar with it in C and C++.

> Thanks for clarifying that. I guess C++ is good for something after
> all, eh?

Apparently it's good for generating endless discussions on
comp.lang.ada :).

-- 
-- Stephe

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> > (And let's not forget that Ada *can* compute the result matrix in-place,
> > just not using the notation you prefer. It's a strange performance-oriented
> > programmer who gives up a factor of 4 for aesthetic reasons.)
> 
> But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"

Mr. Duff forgot about the Constraint_Error issues.

> and Mr. Eachus says "+=" needs a temporary to preserve A in the case
> of a Constraint_Error. 

He's right, since the language defines that behavior. But since _you_
write "Add", you get to decide what happens for Constraint_Error, so
you _don't_ need a temporary.

> So, as far as efficiency is concerned, we're screwed either way,
> aren't we?

No.

-- 
-- Stephe

Re: Ideas for Ada 200X

[tmoran]

>> function "+=" takes about 12% longer than procedure add_to
>You mean function "+" ?
  Yes, sorry.  It would be nice to have a word-processing tool that
checked grammar, spelling, and code-legitimacy in various languages. ;)

Re: Ideas for Ada 200X

[Bill Findlay]

On 4/6/03 15:21, in article 7vllwh53ei.fsf@vlinux.voxelvision.no,
"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
> 
>> On 4/6/03 11:10, in article 7vu1b640gf.fsf@vlinux.voxelvision.no,
>> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:
>> 
>>> I think the difference between C++ and Ada is the compiler. I run both
>>> through gcc, and got identical results.
>> 
>> They are far from identical, AFAICS.
>> You show the Ada code as being 10 times faster, at 0.200s user-mode CPU time
>> for C++ matrix_c, 0.030s for Ada matrix_fun, and 0.010s for matrix_proc :
>> 

> 
> Well, yes, but the clock time is the same. It's an otherwise unloaded
> system, and I get repeatable results, so I suspect there's something
> funny going on with the user time measurements. Besides, a user time
> of 0.01 seconds would indicate 10**10 additions per second, and I
> don't believe my computer is quite as fast as that.

Even the 0.2s real time indicates a rate of order 10**9 per second.
Is your computer really that fast, or could the Ada optimizer have turned
most of the additions into zero-time operations? 8-)

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

Re: Ideas for Ada 200X (Ada.Sockets)

[Simon Wright]

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

> However, if you decide that GNAT only is good enough, then there is
> still the issue of whether or not ACT will leave
> "System.Stream_Attributes, in s-stratt.adb" alone. Or will it
> change?

It was possible to use earlier versions (3.14p, I think) with 3.15a1,
no trouble, so it stands a good chance of staying & still being
useful.

> Certainly there is a lot of flexibility when it comes to your own
> personal pet project(s) that the world never sees. I see a larger
> issue with code I want to publish however.

I suppose that's different from use in a project, the people who might
have trouble and end up cursing you when it does fall over are too
widely distributed to take many risks with!

Re: Ideas for Ada 200X

[Russ]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uadcxwzhi.fsf@nasa.gov>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > > (And let's not forget that Ada *can* compute the result matrix in-place,
> > > just not using the notation you prefer. It's a strange performance-oriented
> > > programmer who gives up a factor of 4 for aesthetic reasons.)
> > 
> > But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"
> 
> Mr. Duff forgot about the Constraint_Error issues.
> 
> > and Mr. Eachus says "+=" needs a temporary to preserve A in the case
> > of a Constraint_Error. 
> 
> He's right, since the language defines that behavior. But since _you_
> write "Add", you get to decide what happens for Constraint_Error, so
> you _don't_ need a temporary.

I think you're missing something here. I would write "+=" too.

Re: Ideas for Ada 200X

[Robert I. Eachus]

Russ wrote:

> Your suggestion would require some sort of advanced artificial
> intelligence to be built in to the compiler. The AI system would need
> to perform a very complex analysis of the overloaded "+" operator and
> decide how to deal with it.

Been there, done that, got the coffee mug.  Or didn't you realize that 
the current overload resolution algorithm essentially required for Ada 
compilers to pass the ACATS tests does just that?

>                         The only other alternative would be to
> have the "+" operator automatically defined for arrays. Either
> approach would constitute a major change in philosophy for Ada.

Hmmm.  Predefined operators for two dimensional arrays would be a 
change.  I don't think I'd consider it a major change.  As for one 
dimensional arrays, catenation is defined for all such types, and the 
boolean operations "and", "or", and "not" are predefined for arrays of 
Boolean, or arrays of any type derived from Boolean.  Adding predefined 
"+", "-", "*", "/", "mod", "rem", and "abs" wouldn't be much of a change 
at all.  I don't think it will happen, since the current choices are 
well thought out--but if there was a reason to change things, I'm sure 
it would happen.

The reason that the boolean operations are predefined for arrays is that 
it would be very difficult for a compiler to figure out the 
optimizations to use bit-wise operations on words otherwise.  If the 
same sort of problem was found with using the SSE and SSE2 instructions 
on arrays of small integers, I'm sure the language would change....

Catenation on the other hand, is just too important an abstraction for 
one-dimensional arrays to leave out.  For two dimensional arrays, it is 
a very uncommon operation.

Re: Ideas for Ada 200X

[Robert I. Eachus]

Russ wrote:

> In any case, the performance hit taken to keep A unchanged when a
> Constraint_Error is raised seems rather expensive to me. If it were up
> to me, I would take the factor of four better efficiency over
> preserving A in the rare case of an overflow. And I'll bet most
> programmers doing heavy-duty number crunching for simulation would
> too.

You are mixing up two things here that should be kept separate.  There 
are Ada rule for predefined "+" operators which make a lot of sense in 
those cases.  The effect of other Ada rules is that compilers can't go 
behind the programmers back and change a user defined "+" function to 
break what the programmer has written and expects.  However it is 
actually easier to define a two parameter Add procedure and use it to 
add in place--if that is what you want to do.  Appended is an Ada 
program that runs eight test cases Integer vs. Float, "+" vs. Add, and 
constraint checking on vs. all checks suppressed.  As you can see, in 
this particular case, suppressing checks is a win for Integer, a lose 
for Float.  This is fairly typical.  (If you compile with GNAT remember 
to invoke gnatmake with -gnato, to enable integer constraint checking. 
Of course, the program should let you know if you forgot.)

E:\Ada\Test\New Folder>test_matrix_add
test_matrix_add
  Initialize Generators.
  Initialize Integer Matricies.
  Initialize Float Matrices.
  Initialization Completed.
  Integer "+" operator, checks on,  required 320.349 milliseconds.
  Integer Add operator, checks on,  required 221.992 milliseconds.
  Integer "+" operator, checks off, required 262.464 milliseconds.
  Integer Add operator, checks off, required 170.612 milliseconds.
  Float "+" operator,   checks on,  required 222.519 milliseconds.
  Float Add operator,   checks on,  required 150.401 milliseconds.
  Float "+" operator,   checks off, required 222.297 milliseconds.
  Float Add operator,   checks off, required 171.129 milliseconds.
  All Done.

> I know that Ada is preferable for safety-critical applications, but
> based on what you are telling me, it sure seems to be a poor choice
> for non-safety-critical simulation with heavy number crunching. Thanks
> for clarifying that. I guess C++ is good for something after all, eh?

No, what we are telling you is that in Ada, you have a choice.  If you 
choose safety, the rules are very carefully designed so you get it.  If 
you want to trade safety for speed, Ada lets you do that. Most of the 
Ada safety you get "for free."  There are some areas where you have to 
intelligently decide whether or not you are willing to pay for it.  And 
remember the case here where Float is faster with checks on.  That is 
not all that uncommon.  This is why, if you are going to Suppress 
checks, you should always test to see if there is a benefit.

Cut at line and compile.  One source file.
----------------------------------------------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Calendar; use Ada.Calendar;
with Ada.Numerics.Discrete_Random;
with Ada.Numerics.Float_Random;
procedure Test_Matrix_Add is
   type Matrix is array (1..1000,1..1000) of Integer;
   type Acc_Matrix is access all Matrix;

   type Float_Matrix is array (1..1000,1..1000) of Float;
   type Acc_Float is access all Float_Matrix;

   A, B, C : Acc_Matrix := new Matrix;
   D, E, F : Acc_Float := new Float_Matrix;

   subtype Int is Integer range -100_000_000..100_000_000;
   package Int_Random is new Ada.Numerics.Discrete_Random(Int);
   Int_Gen: Int_Random.Generator;
   package Float_Random renames Ada.Numerics.Float_Random;
   Float_Gen: Float_Random.Generator;
   package Clock_IO is new Ada.Text_IO.Fixed_IO(Duration);
   Start, Stop: Ada.Calendar.Time;

   procedure Init_Matrix(M: in out Matrix) is
   begin
     for I in M'Range(1) loop
       for J in M'Range(2) loop
           M(I,J) := Int_Random.Random(Int_Gen);
       end loop;
     end loop;
   end Init_Matrix;

   procedure Init_Float(M: in out Float_Matrix) is
   begin
     for I in M'Range(1) loop
       for J in M'Range(2) loop
           M(I,J) := Float_Random.Random(Float_Gen);
       end loop;
     end loop;
   end Init_Float;

begin
   Put_Line(" Initialize Generators.");
   Int_Random.Reset(Int_Gen);
   Float_Random.Reset(Float_Gen);

   Put_Line(" Initialize Integer Matricies.");
   Init_Matrix(A.all);
   Init_Matrix(B.all);
   C.all := A.all;
   Put_Line(" Initialize Float Matrices.");
   Init_Float(D.all);
   Init_Float(E.all);
   F.all := D.all;
   Put_Line(" Initialization Completed.");

   declare

     function "+" (Left, Right: Matrix) return Matrix is
       Temp: Matrix := Left;
     begin
       for I in Temp'Range(1) loop
         for J in Temp'Range(2) loop
           Temp(I,J) := Temp(I,J) + Right(I,J);
         end loop;
       end loop;
       return Temp;
     end "+";

     procedure Add (Left: in out Matrix; Right: Matrix) is
     begin
       for I in Left'Range(1) loop
         for J in Left'Range(2) loop
           Left(I,J) := Left(I,J) + Right(I,J);
         end loop;
       end loop;
       return;
     end Add;

   begin

     Start := Clock;
     A.all := A.all + B.all;
     Stop := Clock;
     Put(" Integer ""+"" operator, checks on,  required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");
     Start := Clock;
     Add(C.all,B.all);
     Stop := Clock;
     Put(" Integer Add operator, checks on,  required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");
   Int_Check:
     for K in A'Range(1) loop
       for L in A'Range(2) loop
         if A(K,L) /= C(K,L)
         then
           Put_Line(" Integer results do not match.");
           exit Int_Check;
         end if;
       end loop;
     end loop Int_Check;

   end; -- declare Block Integer Checks on

   declare

     function "+" (Left, Right: Matrix) return Matrix is
       pragma Suppress(All_Checks);
       Temp: Matrix := Left;
     begin
       for I in Temp'Range(1) loop
         for J in Temp'Range(2) loop
           Temp(I,J) := Temp(I,J) + Right(I,J);
         end loop;
       end loop;
       return Temp;
     end "+";

     procedure Add (Left: in out Matrix; Right: Matrix) is
       pragma Suppress(All_Checks);
     begin
       for I in Left'Range(1) loop
         for J in Left'Range(2) loop
           Left(I,J) := Left(I,J) + Right(I,J);
         end loop;
       end loop;
       return;
     end Add;

   begin

     Start := Clock;
     A.all := A.all + B.all;
     Stop := Clock;
     Put(" Integer ""+"" operator, checks off, required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");
     Start := Clock;
     Add(C.all,B.all);
     Stop := Clock;
     Put(" Integer Add operator, checks off, required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");
   Int_Check2:
     for K in A'Range(1) loop
       for L in A'Range(2) loop
         if A(K,L) /= C(K,L)
         then
           Put_Line(" Integer results do not match.");
           exit Int_Check2;
         end if;
       end loop;
     end loop Int_Check2;

   end; -- declare block integer, checks off


   declare

     function "+" (Left, Right: Float_Matrix) return Float_Matrix is
       Temp: Float_Matrix := Left;
     begin
       for I in Temp'Range(1) loop
         for J in Temp'Range(2) loop
           Temp(I,J) := Temp(I,J) + Right(I,J);
         end loop;
       end loop;
       return Temp;
     end "+";

     procedure Add (Left: in out Float_Matrix; Right: Float_Matrix) is
     begin
       for I in Left'Range(1) loop
         for J in Left'Range(2) loop
           Left(I,J) := Left(I,J) + Right(I,J);
         end loop;
       end loop;
       return;
     end Add;

   begin

     Start := Clock;
     D.all := D.all + E.all;
     Stop := Clock;
     Put(" Float ""+"" operator,   checks on,  required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");
     Start := Clock;
     Add(F.all,E.all);
     Stop := Clock;
     Put(" Float Add operator,   checks on,  required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");

   Float_Check:
     for K in D'Range(1) loop
       for L in D'Range(2) loop
         if abs(D(K,L)-F(K,L)) > Float'Epsilon
         then
           Put_Line("Float result differences greater than Float'Epsilon.");
           exit Float_Check;
         end if;
       end loop;
     end loop Float_Check;

   end; -- declare block, Float, checks on

   declare

     function "+" (Left, Right: Float_Matrix) return Float_Matrix is
       pragma Suppress(All_Checks);
       Temp: Float_Matrix := Left;
     begin
       for I in Temp'Range(1) loop
         for J in Temp'Range(2) loop
           Temp(I,J) := Temp(I,J) + Right(I,J);
         end loop;
       end loop;
       return Temp;
     end "+";

     procedure Add (Left: in out Float_Matrix; Right: Float_Matrix) is
       pragma Suppress(All_Checks);
     begin
       for I in Left'Range(1) loop
         for J in Left'Range(2) loop
           Left(I,J) := Left(I,J) + Right(I,J);
         end loop;
       end loop;
       return;
     end Add;

   begin

     Start := Clock;
     D.all := D.all + E.all;
     Stop := Clock;
     Put(" Float ""+"" operator,   checks off, required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");
     Start := Clock;
     Add(F.all,E.all);
     Stop := Clock;
     Put(" Float Add operator,   checks off, required ");
     Clock_IO.Put(1000*(Stop-Start), 2, 3); -- overflow to get natural 
alignment.
     Put_Line(" milliseconds.");

   Float_Check2:
     for K in D'Range(1) loop
       for L in D'Range(2) loop
         if abs(D(K,L)-F(K,L)) > Float'Epsilon
         then
           Put_Line("Float result differences greater than Float'Epsilon.");
           exit Float_Check2;
         end if;
       end loop;
     end loop Float_Check2;

   end; -- declare block; Float checks off.

   Put_Line(" All Done.");

end Test_Matrix_Add;

Re: Ideas for Ada 200X

[Robert I. Eachus]

Robert A Duff wrote:

 > Robert Eachus and I have had that argument before, and I don't really
 >  feel like having it again, but for the record: I disagree with
 > Robert. I believe the wording of RM-11.6 allows the left-hand side of
 > an assignment to be destroyed in the presence of Constraint_Error. I
 > also believe that was the *intent* of 11.6.  (I know something about
 > the intent, I think, since Tucker and I spent days wrestling with the
 > wording.)
 >
 > For example:
 >
 > type T is range 1..10; X: T := 10;
 >
 > X := X + 1;
 >
 > If X is in register R1, then the compiler can generate machine code
 > like:
 >
 > Add R1+1, putting the result in R1. Check that R1 in 1..10, and raise
 > C_E if not.
 >
 > thus leaving the junk value 11 in X (i.e. R1). This is true even if
 > an exception handler can see X.

Agreed.

 > The semantics described by Robert Eachus is correct for Ada 83, but
 > it was deliberately changed for Ada 95, to make the language more
 > competitive with other languages in terms of efficiency.

Again we come to this point, and you and I agree on the language, but
disagree on what it means.  (For those of you who are not language
lawyers, this particular case is an excellent example of what the
argument is all about.)

Look at the code I just posted.  In one case there is a function "+".
(Assume for a second that the definition of "+" is in a different
package from the caller, and does not have a pragma Inline applied to
it.)  If an exception occurs during the execution of "+", the compiler
is not allowed to munge anything outside the scope of the "+" operator.
  If instead you use the Add(A, B) form, then, inside or outside the
scope of the Add operator if Constraint_Error occurs, both the formal
parameter A, and the actual array to which it is bound are trash.

Now on to the subtle issue.  As written, if Constraint_Error occurred in
any of the "+" operators, whether or not they contained pragma Suppress,
  any of the variables in the main program could be munged.  But if the
"+" operators were defined in a separate package, without pragma Inline,
then the variables in the main program would be "safe" in the "+" case,
including the target of the assignment.  (Of course you would have to
wrap the call to "+" in an exception handler.)

 > The moral of the story is: If you handle predefined exceptions, you
 > are playing with fire.

Yes, and if you have to play with fire, the rules in RM 11.6 are
carefully crafted so that you can draw a useful line around the area 
that will burn. Bob Duff is correct when he says that "I believe the 
wording of RM-11.6 allows the left-hand side of an assignment to be 
destroyed in the presence of Constraint_Error." I am right to add:  "But 
not always!"

In practice, the global code movement allowed by 11.6 is at best 
uncommon absent pragma Inline.  But if you absolutely have to have the 
protection, read 11.6(6) carefully, including the definition of 
independent subprograms.  Technically you sometimes have to put in place 
exception handlers whose only function is to define in which library 
unit an exception actually occurs.

Also, when you are writing Ada programs, most cases where exceptions 
will actually occur are pushed into special I/O handlers, and  the use 
of 'Valid instead of depending on predefined exceptions.

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

tmoran@acm.org writes:

> >> function "+=" takes about 12% longer than procedure add_to
> >You mean function "+" ?
>   Yes, sorry.  It would be nice to have a word-processing tool that
> checked grammar, spelling, and code-legitimacy in various languages. ;)

I'm curious about the reason why I got a large difference between "+"
and add, while you did not. Did you notice anything obvious in the
code for my "+" operator except for what has already been discussed?

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> On 4/6/03 15:21, in article 7vllwh53ei.fsf@vlinux.voxelvision.no,
> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:
> 
> > Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
> > 
> >> On 4/6/03 11:10, in article 7vu1b640gf.fsf@vlinux.voxelvision.no,
> >> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote:
> >> 
> >>> I think the difference between C++ and Ada is the compiler. I run both
> >>> through gcc, and got identical results.
> >> 
> >> They are far from identical, AFAICS.
> >> You show the Ada code as being 10 times faster, at 0.200s user-mode CPU time
> >> for C++ matrix_c, 0.030s for Ada matrix_fun, and 0.010s for matrix_proc :
> >> 
> 
> > 
> > Well, yes, but the clock time is the same. It's an otherwise unloaded
> > system, and I get repeatable results, so I suspect there's something
> > funny going on with the user time measurements. Besides, a user time
> > of 0.01 seconds would indicate 10**10 additions per second, and I
> > don't believe my computer is quite as fast as that.
> 
> Even the 0.2s real time indicates a rate of order 10**9 per second.
> Is your computer really that fast, or could the Ada optimizer have turned
> most of the additions into zero-time operations? 8-)
> 
> -- 
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
> 
> 

I suspect that the matrices are small enough that both code and data
are predominantly in the cache, and in that case, it should be that
fast. Here is the assembler listing, and it certainly looks like it's
adding:


	.file	"matrix_proc.adb"
gcc2_compiled.:
___gnu_compiled_ada:
.text
	.align 4
_matrix_proc__add.0:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	pushl %edi
	pushl %esi
	movl $400,%edi
	pushl %ebx
	movl 12(%ebp),%esi
	movl %ecx,-4(%ebp)
	movl $1,-8(%ebp)
	movl 8(%ebp),%ecx
	.align 2,0x90
L6:
	movl $1,%ebx
	leal 4(%edi),%edx
	.align 2,0x90
L10:
	movl -404(%ecx,%edx),%eax
	addl -404(%esi,%edx),%eax
	movl %eax,-404(%ecx,%edx)
	movl -400(%ecx,%edx),%eax
	addl -400(%esi,%edx),%eax
	movl %eax,-400(%ecx,%edx)
	movl -396(%ecx,%edx),%eax
	addl -396(%esi,%edx),%eax
	movl %eax,-396(%ecx,%edx)
	movl -392(%ecx,%edx),%eax
	addl -392(%esi,%edx),%eax
	movl %eax,-392(%ecx,%edx)
	movl -388(%ecx,%edx),%eax
	addl -388(%esi,%edx),%eax
	movl %eax,-388(%ecx,%edx)
	addl $5,%ebx
	addl $20,%edx
	cmpl $100,%ebx
	jle L10
	addl $400,%edi
	incl -8(%ebp)
	cmpl $100,-8(%ebp)
	jle L6
	leal -20(%ebp),%esp
	popl %ebx
	popl %esi
	popl %edi
	movl %ebp,%esp
	popl %ebp
	ret
	.align 4
.globl __ada_matrix_proc
__ada_matrix_proc:
	pushl %ebp
	movl $80008,%eax
	movl %esp,%ebp
	call __alloca
	pushl %edi
	pushl %esi
	pushl %ebx
	leal -40000(%ebp),%edx
	movl $1,-80004(%ebp)
	leal -80000(%ebp),%ebx
	.align 2,0x90
L18:
	movl $1,-80008(%ebp)
	movl $400,%edi
	.align 2,0x90
L21:
	movl $1,%esi
	leal 4(%edi),%ecx
	.align 2,0x90
L24:
	movl -404(%edx,%ecx),%eax
	addl -404(%ebx,%ecx),%eax
	movl %eax,-404(%edx,%ecx)
	movl -400(%edx,%ecx),%eax
	addl -400(%ebx,%ecx),%eax
	movl %eax,-400(%edx,%ecx)
	movl -396(%edx,%ecx),%eax
	addl -396(%ebx,%ecx),%eax
	movl %eax,-396(%edx,%ecx)
	movl -392(%edx,%ecx),%eax
	addl -392(%ebx,%ecx),%eax
	movl %eax,-392(%edx,%ecx)
	movl -388(%edx,%ecx),%eax
	addl -388(%ebx,%ecx),%eax
	movl %eax,-388(%edx,%ecx)
	addl $5,%esi
	addl $20,%ecx
	cmpl $100,%esi
	jle L24
	addl $400,%edi
	incl -80008(%ebp)
	cmpl $100,-80008(%ebp)
	jle L21
	incl -80004(%ebp)
	cmpl $10000,-80004(%ebp)
	jle L18
	leal -80020(%ebp),%esp
	popl %ebx
	popl %esi
	popl %edi
	movl %ebp,%esp
	popl %ebp
	ret

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

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

> add in place--if that is what you want to do.  Appended is an Ada
> program that runs eight test cases Integer vs. Float, "+" vs. Add, and
> constraint checking on vs. all checks suppressed.  As you can see, in
> this particular case, suppressing checks is a win for Integer, a lose
> for Float.  This is fairly typical.  (If you compile with GNAT
> remember to invoke gnatmake with -gnato, to enable integer constraint
> checking. Of course, the program should let you know if you forgot.)
> 
> E:\Ada\Test\New Folder>test_matrix_add
> test_matrix_add
>   Initialize Generators.
>   Initialize Integer Matricies.
>   Initialize Float Matrices.
>   Initialization Completed.
>   Integer "+" operator, checks on,  required 320.349 milliseconds.
>   Integer Add operator, checks on,  required 221.992 milliseconds.
>   Integer "+" operator, checks off, required 262.464 milliseconds.
>   Integer Add operator, checks off, required 170.612 milliseconds.
>   Float "+" operator,   checks on,  required 222.519 milliseconds.
>   Float Add operator,   checks on,  required 150.401 milliseconds.
>   Float "+" operator,   checks off, required 222.297 milliseconds.
>   Float Add operator,   checks off, required 171.129 milliseconds.
>   All Done.
> 
<snip>

As you say, it depends on the system whether or not it pays to turn
off the checks. Here are the results from my system. For Integer
turning off the checks is a win, for Float it does not seem to matter.
One other difference: with checks on, the integer "+" is actually
slightly faster than add.  With checks off, it's 3 times slower.

$ gnatmake -s -gnato -O3 -funroll-loops test_matrix_add
gcc -c -gnato -O3 -funroll-loops test_matrix_add.adb
gnatbind -x test_matrix_add.ali
gnatlink test_matrix_add.ali

oleh@VOLGA /cygdrive/c/div
$ test_matrix_add
 Initialize Generators.
 Initialize Integer Matricies.
 Initialize Float Matrices.
 Initialization Completed.
 Integer "+" operator, checks on,  required 43.795 milliseconds.
 Integer Add operator, checks on,  required 45.960 milliseconds.
 Integer "+" operator, checks off, required 23.682 milliseconds.
 Integer Add operator, checks off, required  8.478 milliseconds.
 Float "+" operator,   checks on,  required 22.506 milliseconds.
 Float Add operator,   checks on,  required 12.920 milliseconds.
 Float "+" operator,   checks off, required 22.491 milliseconds.
 Float Add operator,   checks off, required 12.988 milliseconds.
 All Done.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Jean-Pierre Rosen]

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


"Robert I. Eachus" <rieachus@attbi.com> a �crit dans le message news:
3EDEA840.6020908@attbi.com...
> The reason that the boolean operations are predefined for arrays is that
> it would be very difficult for a compiler to figure out the
> optimizations to use bit-wise operations on words otherwise.

My memory is that boolean array operations are there because
the requirements called for a functionality equivalent to Pascal's sets

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

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> writes:

> "Robert I. Eachus" <rieachus@attbi.com> writes:
> <snip>
> 
> > add in place--if that is what you want to do.  Appended is an Ada
> > program that runs eight test cases Integer vs. Float, "+" vs. Add, and
> > constraint checking on vs. all checks suppressed.  As you can see, in
> > this particular case, suppressing checks is a win for Integer, a lose
> > for Float.  This is fairly typical.  (If you compile with GNAT
> > remember to invoke gnatmake with -gnato, to enable integer constraint
> > checking. Of course, the program should let you know if you forgot.)
> > 
> > E:\Ada\Test\New Folder>test_matrix_add
> > test_matrix_add
> >   Initialize Generators.
> >   Initialize Integer Matricies.
> >   Initialize Float Matrices.
> >   Initialization Completed.
> >   Integer "+" operator, checks on,  required 320.349 milliseconds.
> >   Integer Add operator, checks on,  required 221.992 milliseconds.
> >   Integer "+" operator, checks off, required 262.464 milliseconds.
> >   Integer Add operator, checks off, required 170.612 milliseconds.
> >   Float "+" operator,   checks on,  required 222.519 milliseconds.
> >   Float Add operator,   checks on,  required 150.401 milliseconds.
> >   Float "+" operator,   checks off, required 222.297 milliseconds.
> >   Float Add operator,   checks off, required 171.129 milliseconds.
> >   All Done.
> > 
> <snip>
> 
> As you say, it depends on the system whether or not it pays to turn
> off the checks. Here are the results from my system. For Integer
> turning off the checks is a win, for Float it does not seem to matter.
> One other difference: with checks on, the integer "+" is actually
> slightly faster than add.  With checks off, it's 3 times slower.
> 
> $ gnatmake -s -gnato -O3 -funroll-loops test_matrix_add
> gcc -c -gnato -O3 -funroll-loops test_matrix_add.adb
> gnatbind -x test_matrix_add.ali
> gnatlink test_matrix_add.ali
> 
> oleh@VOLGA /cygdrive/c/div
> $ test_matrix_add
>  Initialize Generators.
>  Initialize Integer Matricies.
>  Initialize Float Matrices.
>  Initialization Completed.
>  Integer "+" operator, checks on,  required 43.795 milliseconds.
>  Integer Add operator, checks on,  required 45.960 milliseconds.
>  Integer "+" operator, checks off, required 23.682 milliseconds.
>  Integer Add operator, checks off, required  8.478 milliseconds.
>  Float "+" operator,   checks on,  required 22.506 milliseconds.
>  Float Add operator,   checks on,  required 12.920 milliseconds.
>  Float "+" operator,   checks off, required 22.491 milliseconds.
>  Float Add operator,   checks off, required 12.988 milliseconds.
>  All Done.
> 
> -- 
> Ole-Hj. Kristensen
> 
> ******************************************************************************
> * You cannot consistently believe this sentence.
> ******************************************************************************

Here is another run with forced loop unrolling. Now there is no
perceptible difference between having the checks enabled and not.

oleh@VOLGA /cygdrive/c/div
$ gnatmake -s -gnatp -O3 -funroll-all-loops test_matrix_add
gcc -c -gnatp -O3 -funroll-all-loops test_matrix_add.adb
gnatbind -x test_matrix_add.ali
gnatlink test_matrix_add.ali

oleh@VOLGA /cygdrive/c/div
$ test_matrix_add
 Initialize Generators.
 Initialize Integer Matricies.
 Initialize Float Matrices.
 Initialization Completed.
 Integer "+" operator, checks on,  required 22.002 milliseconds.
 Integer Add operator, checks on,  required  8.531 milliseconds.
 Integer "+" operator, checks off, required 21.705 milliseconds.
 Integer Add operator, checks off, required  8.384 milliseconds.
 Float "+" operator,   checks on,  required 22.103 milliseconds.
 Float Add operator,   checks on,  required 12.878 milliseconds.
 Float "+" operator,   checks off, required 22.279 milliseconds.
 Float Add operator,   checks off, required 14.311 milliseconds.
 All Done.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Bill Findlay]

On 5/6/03 05:40, in article 3EDEC9A7.9050602@attbi.com, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

> E:\Ada\Test\New Folder>test_matrix_add
> test_matrix_add
> Initialize Generators.
> Initialize Integer Matricies.
> Initialize Float Matrices.
> Initialization Completed.
> Integer "+" operator, checks on,  required 320.349 milliseconds.
> Integer Add operator, checks on,  required 221.992 milliseconds.
> Integer "+" operator, checks off, required 262.464 milliseconds.
> Integer Add operator, checks off, required 170.612 milliseconds.
> Float "+" operator,   checks on,  required 222.519 milliseconds.
> Float Add operator,   checks on,  required 150.401 milliseconds.
> Float "+" operator,   checks off, required 222.297 milliseconds.
> Float Add operator,   checks off, required 171.129 milliseconds.
> All Done.
> 

I got the following typical results on my puny Mac iBook (500Mhz G3 PPC)
running GNAT 5.00w under Mac OS X 10.2.6:

wf% gnatmake -s -gnato -O3 -funroll-loops test_matrix_add
gcc -c -gnato -O3 -funroll-loops test_matrix_add.adb
gnatbind -x test_matrix_add.ali
gnatlink test_matrix_add.ali
wf% time ./test_matrix_add
 Initialize Generators.
 Initialize Integer Matricies.
 Initialize Float Matrices.
 Initialization Completed.
 Integer "+" operator, checks on,  required 699.236 milliseconds.
 Integer Add operator, checks on,  required 246.665 milliseconds.
 Integer "+" operator, checks off, required 251.800 milliseconds.
 Integer Add operator, checks off, required 240.967 milliseconds.
 Float "+" operator,   checks on,  required 256.730 milliseconds.
 Float Add operator,   checks on,  required 236.594 milliseconds.
 Float "+" operator,   checks off, required 259.498 milliseconds.
 Float Add operator,   checks off, required 233.774 milliseconds.
 All Done.
5.740u 0.290s 0:10.02 60.1%     0+0k 0+2io 0pf+0w

Integer "+" is 2.8 times slower than Add with checks on, but essentially the
same with checks off. Float operations are essentially the same whether
checks are on or off. It is clear that no claim of inevitable gross
inefficiency for "+" can be supported.

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

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uadcxwzhi.fsf@nasa.gov>...
> > 18k11tm001@sneakemail.com (Russ) writes:
> > 
> > > > (And let's not forget that Ada *can* compute the result matrix in-place,
> > > > just not using the notation you prefer. It's a strange performance-oriented
> > > > programmer who gives up a factor of 4 for aesthetic reasons.)
> > > 
> > > But Mr. Duff says that "+=" is just "syntactic sugar" for "Add(A,B),"
> > 
> > Mr. Duff forgot about the Constraint_Error issues.
> > 
> > > and Mr. Eachus says "+=" needs a temporary to preserve A in the case
> > > of a Constraint_Error. 
> > 
> > He's right, since the language defines that behavior. But since _you_
> > write "Add", you get to decide what happens for Constraint_Error, so
> > you _don't_ need a temporary.
> 
> I think you're missing something here. I would write "+=" too.

Yes, but the compiler would insert a temporary variable, in order to
follow the language definition of the behavior of += in the presence
of Constraint_Error. So if you write:

procedure Matrix_Add
   (Target : in out Matrix_Type; 
    Addend : in Matrix_type);
procedure "+=" (...) renames Matrix_Add;


A += B;

the compiler actually does:

C = A;
Matrix_Add (C, B);
A = C;

I suppose you could change that rule, but that would be a bigger
change to the language, since "A += B" would no longer be identical to
"A := A + B".

-- 
-- Stephe

Re: Ideas for Ada 200X

[Robert I. Eachus]

Ole-Hjalmar Kristensen wrote:

> As you say, it depends on the system whether or not it pays to turn
> off the checks. Here are the results from my system. For Integer
> turning off the checks is a win, for Float it does not seem to matter.
> One other difference: with checks on, the integer "+" is actually
> slightly faster than add.  With checks off, it's 3 times slower.

And you can see why I provided all eight cases.  (I probably should have 
add four Long_Float cases as well.)  What you will see depends more on 
the actual hardware than aything else.  You can be compute bound, and 
the checks will be a significant penalty, or you can be memory access 
bound, and the checks will add nothing.  Also how much of the implicit 
copy is from cache affects the timing.  (Incidently, I didn't do this 
but if reverse the outside loop in the "+" (for I in reverse...) this 
will speed things up if the whole array doesn't fit in cache.

Re: Ideas for Ada 200X

[Stephen Leake]

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

> <snip>
> As you can see, in
> this particular case, suppressing checks is a win for Integer, a
> lose for Float. This is fairly typical. 

Just out of curiosity, why is turning of checks a lose for Float? How
do checks make the Float code faster?

-- 
-- Stephe

Re: Ideas for Ada 200X

[Wesley Groleau]

Russ wrote:
> I think you're missing something here. I would write "+=" too.

If the _coder_ is going to define Add() and "+" and "+="
then clearly it is misleading to claim that "+=" is
always more efficient.

But if a language standard requires   A += B
to always be equivalent to            A := A + B
then clearly it is misleading to
insist that either one will always
be more efficient.

Re: Ideas for Ada 200X

[Robert I. Eachus]

Stephen Leake wrote:

 > Just out of curiosity, why is turning of checks a lose for Float? How
 >  do checks make the Float code faster?

Let me give you the thirty-thousand foot veiw, then get down and dirty.
  Every compiler generated check has two effects.  The first is that it
costs execution resources to perform a check.  The second is that the
compiler remembers the state of the check if made, and this can simplify
other code, including other (non-suppressed checks). The net cost of
doing the checking is the difference of two quantities, so it can be
positive or negative.

It is also worth noting that suppressing some checks is often the worst 
of both worlds.  Suprressing a check outside a loop can result in 
another check inside the loop needing to be made once for every 
repetition of the loop.  There is a rule which is honored in the spirit 
not for legalistic reasons that says that Ada programs don't page fault. 
     In reality what this means is that even if you suppress bounds 
checking,  indexed writes won't overwrite areas of memory that are not 
data for the Ada program.  In the two dimensional array case in this 
program, this means that the compiler should still do a check of whether 
the writes fall within the object.  Bounds check on reads need not be 
done, and for  a write to Temp(I,J), I and J will not be checked to see 
that they are within bounds, just that the computed offset is within the 
object.

So suppressing all checks is not required to actually suppress all 
checks.  It is guidance to the compiler saying that all but the most 
minimal of checks should be suppressed.  (Could you ask your vendor to 
go ahead and remove some of these minimal checks?  Sure, some can't be 
removed since they are automatically performed by the hardware--writing 
to a read only segment, or on many systems executing an instruction from 
an odd byte address.  The rest can be done away with.  But the compiler 
vendor makes a judgement on what pragma Suppress(All_Checks); should do, 
and they tend to get it pretty close to some optimal definition of right.

Now to get down and dirty.  Most modern CPU chips have multiple 
execution units and are "superscalar" which means that more than one 
assembly language instruction can get dispatched to execution pipes on a 
single clock cycle.  I'll use the Athlon here as an example, because 
that is the CPU I ran the test on.  In a single clock cycle, the CPU 
grabs up to 64 bits of instructions (eight bytes) and decodes at most 
three instructions from the bits it has. (Some of those could be 
carryovers from the previous clock cycle.)  The x86 ISA has some 
one-byte instructions, and worse case instructions can be more than 
eight bytes long.  These instructions are then decoded into micro-ops. 
Most x86 instructions are decoded as one or two micro-ops but what are 
called Vector path instructions are special.  They have to be the only 
instruction decoded on a clock cycle, and they can be translated into an 
unlimited number of micro-ops. For example, a block copy.

The processor then dispatches the instructions to either the integer and 
reordering buffers or to the floating point reordering buffer.  There 
are three queues of micro-ops waiting for dispatch to the three integer 
and three logical pipes.  These can be dispatched out of order, but the 
instructions stay with the pair of execution units they have been 
assigned to. In addition there is a floating point instruction 
reordering buffer.  There are three floating point execution units, a 
floating load store unit which can also execute most MMX instructions, a 
floating multiply divide unit and a floating add and subtract unit.

So for our little test program, all the floating-point arithmetic 
instructions had to be done by the floating point add subtract pipe, but 
that was not the computational bottleneck. For every floating add there 
were at least two floating loads and one floating store. But those are 
still not the bottleneck.  Three load/stores would require 3,000,000 
instructions to be executed, and on a 700 MHz CPU that takes about 4 
milliseconds.

So where did all the "extra" effort go.  Some when into the integer and 
logical micro-ops involved in the loop and the address computations. 
But even if this took three integer and three logical operations per 
floating point load or store, that wouldn't take any more CPU time.  The 
answer is in the memory accesses.  Again we need three million 32-bit 
memory accesses.  This computer has 100 MHz SDRAM DIMMs.  Figure that 
even at 100% efficiency, the main memory accesses will take 15 
milliseconds, and of course 100% efficiency is not going to happen.  But 
it should be possible to get pretty close.  Once my regular CPU is back, 
the memory will be more than twice as fast (PC 2100 DDR) and the CPU 
will be just over twice as fast so the memory to CPU clock ratio will be 
about the same.

As you can see, the "overhead" of doing the bounds and overflow checking 
got lost way back.  On computationally heavy problems where you need to 
spend your time is in optimizing the memory accesses so that as few as 
possible occur, and as many as possible are from L1 or L2 cache.

Re: Ideas for Ada 200X

[Russ]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uznkwflx8.fsf@nasa.gov>...

> procedure Matrix_Add
>    (Target : in out Matrix_Type; 
>     Addend : in Matrix_type);
> procedure "+=" (...) renames Matrix_Add;
> 
> 
> A += B;
> 
> the compiler actually does:
> 
> C = A;
> Matrix_Add (C, B);
> A = C;
> 
> I suppose you could change that rule, but that would be a bigger
> change to the language, since "A += B" would no longer be identical to
> "A := A + B".

You seem to be going around in circles here. The whole idea was that A
+= B can avoid the temporary matrix and the extra copy operation.
That's how it works in C++. Without that benefit, yes you might as
well just use A := A + B.

Ideas for Ada 200X

[Russ]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<CYOdnX4qp9noC0KjXTWcoA@gbronline.com>...
> Russ wrote:
> > I think you're missing something here. I would write "+=" too.
> 
> If the _coder_ is going to define Add() and "+" and "+="
> then clearly it is misleading to claim that "+=" is
> always more efficient.

First of all, I don't know where the idea came from that "+" or "+="
would NOT be written by the programmer (for user-defined types). I
never suggested any such thing, nor has anyone else on this thread as
far as I recall.

Nor did I ever claim that "+=" is "always more efficient." Of course
that would be nonsense -- I could put an infinite loop in the freakin'
thing if I wanted to!

> But if a language standard requires   A += B
> to always be equivalent to            A := A + B
> then clearly it is misleading to
> insist that either one will always
> be more efficient.

Perhaps I erred in my earlier posts in assuming that certain
principles that apply to C++ also apply to Ada, so let me restate my
claim.

In C++, I believe it is true that

    A = A + B

cannot be implemented any more efficiently than

    temp = A
    temp += B
    A = temp

Thus A = A + B could not possibly be as efficient as A += B because
the former requires the construction and destruction of a temporary as
well as an extra copy operation. So although the result is identical
(if properly implemented), the efficiency is certainly not. The point
is that "+=" gets you directly into the left-hand side without having
to "cross the bridge" of an "=".

That much is not controversial, folks. Most good C++ programmers know
it. For a good discussion, see More Effective C++ (1996) by Scott
Meyers, Item 22: Consider using op= instead of stand-alone op.

Now I had assumed, perhaps erroneously, that the same principle
applies to Ada. *If* it does not, I believe it could only be because,
for whatever reason, "+=" cannot be implemented as efficiently in Ada
as it can in C++.

And please, hold your fire on C++. I agree completely that Ada beats
C++ hands down for safety, readability, maintainability, etc. However,
I think you are deluding yourself if you think Ada is more efficient
than C or C++.

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> Perhaps I erred in my earlier posts in assuming that certain
> principles that apply to C++ also apply to Ada, 

Yes, that turns out to be the case.

> so let me restate my claim.
> 
> In C++, I believe it is true that
> 
>     A = A + B
> 
> cannot be implemented any more efficiently than
> 
>     temp = A
>     temp += B
>     A = temp
> 
> Thus A = A + B could not possibly be as efficient as A += B because
> the former requires the construction and destruction of a temporary as
> well as an extra copy operation. So although the result is identical
> (if properly implemented), the efficiency is certainly not. The point
> is that "+=" gets you directly into the left-hand side without having
> to "cross the bridge" of an "=".

Yes, that is clear.
 
> That much is not controversial, folks. Most good C++ programmers know
> it. For a good discussion, see More Effective C++ (1996) by Scott
> Meyers, Item 22: Consider using op= instead of stand-alone op.
> 
> Now I had assumed, perhaps erroneously, that the same principle
> applies to Ada. *If* it does not, I believe it could only be because,
> for whatever reason, "+=" cannot be implemented as efficiently in Ada
> as it can in C++.

Well, you were proposing a new feature in Ada, so you get to define it
however you want. 

However, Robert Eachus pointed out that to be consistent with other
parts of Ada, in particular the way Constraint_Error is handled, it
makes the most sense to simply define

A += B;

to be completely identical to 

A := A + B;

except that A is evaluated only once.

If you don't like that definition, you can just say so, and insist on
proposing the version that allows more efficient implementation, and
therefore allows corrupting A on Constraint_Error.

However, your version is even less likely than Robert's to be accepted
by the Ada standards group (hmm, I'm not sure zero is really less than
nil :).

> And please, hold your fire on C++. I agree completely that Ada beats
> C++ hands down for safety, readability, maintainability, etc.

Ok, good. But remember that part of the reason Ada is safe is that it
carefully defines what happens on Constraint_Error.

> However, I think you are deluding yourself if you think Ada is more
> efficient than C or C++.

Here we have to disagree. Clearly both Ada and C++ can define an
efficient in-place function Add_Matrix. Standard C++ can then map that
to "+=". Standard Ada can't. This affects readability, but not
efficiency.

In general, since the Ada compiler has more type information to work
with, it can be more efficient than C++. 

-- 
-- Stephe

Re: Ideas for Ada 200X

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uznkwflx8.fsf@nasa.gov>...
> 
> > procedure Matrix_Add
> >    (Target : in out Matrix_Type; 
> >     Addend : in Matrix_type);
> > procedure "+=" (...) renames Matrix_Add;
> > 
> > 
> > A += B;
> > 
> > the compiler actually does:
> > 
> > C = A;
> > Matrix_Add (C, B);
> > A = C;
> > 
> > I suppose you could change that rule, but that would be a bigger
> > change to the language, since "A += B" would no longer be identical to
> > "A := A + B".
> 
> You seem to be going around in circles here. The whole idea was that A
> += B can avoid the temporary matrix and the extra copy operation.
> That's how it works in C++. Without that benefit, yes you might as
> well just use A := A + B.

This is all speculation, since Ada does not *have* a +:= operator.
It seems to me that if it did, the semantics should be identical to
any other procedure call with two parameters (one 'in out', and one
'in').  It should *not* be similar to a *function* call, and should not
return a result.  If all that were true, then of course +:= would be
exactly as efficient as Matrix_Add.

Somebody has apparently suggested a different semantics for +:=,
which might have different efficiency properties.

- Bob

Re: Ideas for Ada 200X

[Wesley Groleau]

> Nor did I ever claim that "+=" is "always more efficient." Of course
> that would be nonsense -- I could put an infinite loop in the freakin'
> thing if I wanted to!

But you seemed to say that Ada should have
A += B _because_ it is more efficient than A := A + B

> In C++, I believe it is true that
>     A = A + B
> cannot be implemented any more efficiently than
>     temp = A
>     temp += B
>     A = temp

Ah, now we get to the root of the argument.
C++ allows (or requires?) the two to be implemented
differently.  So indeed, it is conceivable that in
C++ one would be more efficient than the other.

But Ada does not define it at all, and it is highly
unlikely that a new Ada construct defined to have the
same result as another would be _required_ to have a
different implementation.

And it is unlikely, if it is _allowed_ (but not required)
to have a different implementation, that the vendor (or
programmer, as the case may be) would intentionally
design, code, and test two implementations of the same thing.

Re: Ideas for Ada 200X

[Russ]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<URSdnWKkO4E8oHyjXTWcqQ@gbronline.com>...
> > Nor did I ever claim that "+=" is "always more efficient." Of course
> > that would be nonsense -- I could put an infinite loop in the freakin'
> > thing if I wanted to!
> 
> But you seemed to say that Ada should have
> A += B _because_ it is more efficient than A := A + B
> 
> > In C++, I believe it is true that
> >     A = A + B
> > cannot be implemented any more efficiently than
> >     temp = A
> >     temp += B
> >     A = temp
> 
> Ah, now we get to the root of the argument.
> C++ allows (or requires?) the two to be implemented
> differently.  So indeed, it is conceivable that in
> C++ one would be more efficient than the other.
> 
> But Ada does not define it at all, and it is highly
> unlikely that a new Ada construct defined to have the
> same result as another would be _required_ to have a
> different implementation.
> 
> And it is unlikely, if it is _allowed_ (but not required)
> to have a different implementation, that the vendor (or
> programmer, as the case may be) would intentionally
> design, code, and test two implementations of the same thing.

The two CANNOT be implemented the same!

Compare

    A := B + C + D

with

    A := B
    A += C
    A += D

(For the sake of argument, let's ignore the Constraint_Error thing for
now.)

In the latter form, the sums can be done directly in the elements of
A. For element i,j, we would have something like A(i,j) += C(i,j),
etc.

Now consider the first form: A:= B + C + D translates into something
like

    A := Add ( Add(B,C), D )

The first major difference is that "Add" or "+" must RETURN A VALUE,
whereas "+=" did NOT need to return a value. The second major
difference is that "Add" or "+" needs a temporary storage area (even
if we ignore the Constrains_Error thing, which is a separate issue).
The temporary is needed to store the value of Add(B,C) because it has
no name and no home in memory until a temporary is constructed for it!
Then another temporary is needed to store the entire right side,
because it has no name or home either.

The "+=" form needed no temporaries because everything was done in
place in matrices that already had a name and a home in memory.

Are you starting to get the picture? "+=" and "+" just cannot be
implemented the same. They are two different animals. One returns a
value and the other does not. One needs temporary storage and the
other does not. Note, however, that "+" CAN be implemented IN TERMS OF
"+=", which is what good C++ programmers do. That ensures consistency
and eliminates a redundant implementation algorithm.

My apologies to the Ada compiler experts who already know this stuff.

Re: Ideas for Ada 200X

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccsmqnj6ub.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uznkwflx8.fsf@nasa.gov>...
> > You seem to be going around in circles here. The whole idea was that A
> > += B can avoid the temporary matrix and the extra copy operation.
> > That's how it works in C++. Without that benefit, yes you might as
> > well just use A := A + B.
> 
> This is all speculation, since Ada does not *have* a +:= operator.
> It seems to me that if it did, the semantics should be identical to
> any other procedure call with two parameters (one 'in out', and one
> 'in').  It should *not* be similar to a *function* call, and should not
> return a result.  If all that were true, then of course +:= would be
> exactly as efficient as Matrix_Add.

I agree: "+=" would be a procedure, and "+" would be (is) a function.

This brings us full circle, back to the question of aesthetics. I say
that

    A += B

is far more elegant AND readable than

    Matrix_Add ( Into=>A, From=>B )

If you prefer the latter abomination, I think you're nuts.

Yes, "+=" is more familiar to me from C++, but note that Python uses
it too, and Python is known for its readability. I say that anyone who
cannot get used to "+=" (or ":+=" or whatever) is probably someone who
harbors such an irrational hatred of C++ that they will reject even
good ideas just because they came from from C++ (or C).

Re: Ideas for Ada 200X

[tmoran]

>Compare
>
>    A := B + C + D
>
>with
>
>    A := B
>    A += C
>    A += D
  A good Ada programmer would first write a function "+"(Left,Right:Matrices)
and write
  A := B + C + D
and make sure his algorithm worked.
If he then found there were performance problems, and they were in that
part of his code, he would then try implementing
>    A := B
>    A += C
>    A += D
[though he would write it as
 A := B;
 Add(A, C);
 Add(A, D);]
and he would see if that made a worthwhile speedup.  If there were
still problems, he could try
  for row in A'range(1) loop
    for col in A'range(2) loop
       A(row,col) := B(row,col) + C(row,col) + D(row,col);
    end loop;
  end loop;
or he could try using special hardware vector instructions, each time
running timing tests to see whether the new code was indeed usefully faster.

Re: Ideas for Ada 200X

[Russ]

tmoran@acm.org wrote in message news:<CFfEa.48068$d51.104155@sccrnsc01>...
> >Compare
> >
> >    A := B + C + D
> >
> >with
> >
> >    A := B
> >    A += C
> >    A += D
>   A good Ada programmer would first write a function "+"(Left,Right:Matrices)
> and write
>   A := B + C + D
> and make sure his algorithm worked.
> If he then found there were performance problems, and they were in that
> part of his code, he would then try implementing
> >    A := B
> >    A += C
> >    A += D
> [though he would write it as
>  A := B;
>  Add(A, C);
>  Add(A, D);]

And the person reading this code couldn't be sure what was going on in
"Add" without looking at the procedure itself (or perhaps its
declaration). How would the reader know if the sum will end up in the
first or second argument?

Re: Ideas for Ada 200X

[Wesley Groleau]

>>  A good Ada programmer would first write a function "+"(Left,Right:Matrices)
>>[snip]
>>[though he would write it as
>> A := B;
>> Add(A, C);
>> Add(A, D);]
> 
> And the person reading this code couldn't be sure what was going on in
> "Add" without looking at the procedure itself (or perhaps its
> declaration). How would the reader know if the sum will end up in the
> first or second argument?

That's why this Ada programmer (good or bad, I won't say!)
would write it as

    A := B;
    Add (Into => A, C);
    Add (Into => A, D);]

Re: Ideas for Ada 200X

[tmoran]

>>> Add(A, C);
>> And the person reading this code couldn't be sure what was going on in
>> "Add" without looking at the procedure itself (or perhaps its
>> declaration). How would the reader know if the sum will end up in the
>> first or second argument?
  "Come the revolution, comrade, we'll all do it my way, with the
assignee on the left." ;)
  If the reader is in doubt, he will indeed have to look at the spec of
procedure Add to know what it is supposed to do.  If Add is used in only a
very few places, then a good Ada programmer would go to the trouble of
writing it out the long way, with named parameter association.  If
Add is used a lot, it's more reasonable to lessen verbosity and
instead require the reader to look up the definition of procedure Add,
and use positional parameters.
  Of course it may be that Add actually sets its first parameter to all
zeros or something, but that could also happen if a compiler translated
"A += B;" to "Add(A,B);"

> That's why this Ada programmer (good or bad, I won't say!)
> would write it as
>
>     A := B;
>     Add (Into => A, C);
  At which point his compiler would gently point out that once
(from left to right) you've started using named parameters you
can't go back to positional, so he needs to write
      Add (Into => A, Increment => C);
or
      Add (A, Increment => C);

Of course it's also true that once you've changed
A := B+C+D;
to some series of "+=" or "Add"s, you've made things obscure and hard
to read, in favor of the speedup you needed.  Anytime he lessens
readability, the good Ada programmer will put in comments explaining
what he is doing and why he is doing it this non-straightforward way.

Re: Ideas for Ada 200X

[tmoran]

Let's make a small change: A and B are rotations, represented
as matrices.  Then
  A := A+B;
sets A to the result of rotation A followed by rotation B.  If "A+=B"
was a legitimate alternative syntax for "Add(A,Increment=>B)",
then it would in fact be implemented as a matrix multiplication,
complete with intermediate temporary storage.  Interpreting it
as an element-by-element floating point addition would be quite wrong.

Re: Ideas for Ada 200X

[Hyman Rosen]

tmoran@acm.org wrote:
>   A good Ada programmer

Whereas a good C++ programmer would track down one of the
many expression template libraries, then write
     A = B + C + D;
and would still get the equivalent of the for-loop expansion
that the Ada programmr would have to write by hand.

Re: Ideas for Ada 200X

[Wesley Groleau]

>   At which point his compiler would gently point out that once
> (from left to right) you've started using named parameters you
> can't go back to positional, so he needs to write

You know, I must be getting senile.
I first wrote

    Add (B, Into => A);

and then changed it because of that rule--only
I had the rule backward!

Re: Ideas for Ada 200X

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<07yEa.45802$ca5.25203@nwrdny02.gnilink.net>...
> tmoran@acm.org wrote:
> >   A good Ada programmer
> 
> Whereas a good C++ programmer would track down one of the
> many expression template libraries, then write
>      A = B + C + D;
> and would still get the equivalent of the for-loop expansion
> that the Ada programmr would have to write by hand.

Interesting. Where can I learn more about this?

Re: Ideas for Ada 200X

[Hyman Rosen]

Russ wrote:
> Interesting. Where can I learn more about this?

Overall, <http://www.boost.org/> consists of many C++ libraries,
a subset of which are being considered for addition to the next
version of the Standard. (Ada folks, take heed! Something like
this or the fabled Ada0X would be useful.) There is a uBLAS
librray there that does linear algebra.

I think the most elaborate example of this kind of coding is
Todd Veldhuizen's Blitz++, <http://www.oonumerics.org/blitz/>.
If you don't look at any others, you have to see this one. It
makes most C++ compilers sweat, cry, and fall down.

Looking up a bit, <http://www.oonumerics.org/oon> lists a ton
of C++ numerics libraries (although some of the links are dead.)

Then there's POOMA, <http://www.codesourcery.com/pooma/pooma>.
CodeSourcery also works on maintaining and updating GCC, so some
of the same people may be modifying your Ada compiler!

Re: Ideas for Ada 200X

[Hyman Rosen]

Russ wrote:
> Interesting. Where can I learn more about this?

Here's a general explanation of how expression templates
work in C++. The language features used are the ability
to overload the array indexing and function call operators
and automatic type deduction and instantiation of function
templates.

We declare our matrix types, and whatever other types we
need. We define the arithmetic and indexing operators on
these types not to actually do anything except note the
operator and references to the operands, in effect making
a runtime parse tree of the expression. Finally, when an
actual value is required, suc has upon assignment, the
entire structure can be evaluated, with the compiler doing
massive inlining to achieve the efficiency of handwritten
code.

For example, suppose we have the matrix expression C = A + B.
When A + B is evaluated, the result is a special "addition"
object which holds references to A and B. This object has an
overloaded indexing operator, such that when add_obj(i,j) is
requested, it produces a(i,j) + b(i,j), where a and b are the
saved operand references. The Matrix class has an assignment
operator which simply (or complexly, sometimes) iterates,
doing c(i,j) = rhs(i,j). This works for expressions of any
complexity, as long as the compiler is willing to inline. The
iteration pattern itself can be modified to take advantage of
cache coherency; the Blitz++ library includes the ability to
traverse multidimensional matrices using a space-filling curve
to stay local.

Re: Ideas for Ada 200X

[tmoran]

> a runtime parse tree of the expression.
> ..., with the compiler doing massive inlining to achieve the efficiency
> of handwritten
  I'm confused.  You generate a parse tree at runtime, but the compiler
takes this runtime result and generates code?  Is this a two-pass process?

Re: Ideas for Ada 200X

[Hyman Rosen]

tmoran@acm.org wrote:
>   I'm confused.  You generate a parse tree at runtime, but the compiler
> takes this runtime result and generates code?  Is this a two-pass process?

Yes, sort of. The parse tree is generated at runtime, but the
overall type of the result is already known at compile-time.
Then inlining generates the code. Let's see if I can code a
relatively simple example:

     template <typename L, typename R>
     struct add_op
     {
         const L &l;
         const R &r;
         add_op(const L &l, const R &r) : l(l), r(r) { }
         double operator()(int i, int j) const
         { return l(i,j) + r(i,j); }
     };

     template <typename L, typename R>
     add_op<L,R> operator+(const L &l, const R &r)
     { return add_op<L,R>(l,r); }

     template <int N>
     struct Matrix
     {
         double data[N][N];

	template <typename T>
         Matrix &operator=(const T &r)
         {
             for (int i = 0; i < M; ++i)
                 for (int j = 0; j < N; ++j)
                     data[i][j] = r(i,j);
             return *this;
         }

         double operator()(int i, int j) const
         { return data[i][j]; }
     };

Re: Ideas for Ada 200X

[Stephen Leake]

18k11tm001@sneakemail.com (Russ) writes:

> This brings us full circle, back to the question of aesthetics. I say
> that
> 
>     A += B
> 
> is far more elegant AND readable than
> 
>     Matrix_Add ( Into=>A, From=>B )
> 
> If you prefer the latter abomination, I think you're nuts.

Note the hyperbole, and the ad hominem attack.

> Yes, "+=" is more familiar to me from C++, but note that Python uses
> it too, and Python is known for its readability. I say that anyone
> who cannot get used to "+=" (or ":+=" or whatever) is probably
> someone who harbors such an irrational hatred of C++ that they will
> reject even good ideas just because they came from from C++ (or C).

Just as you are rejecting the notion that Matrix_Add might be a good
idea.

None of us said "we can't get used to that". We said "it's an
interesting idea, but not actually worth the cost, in the final
analysis".

Notice that none of us called you nuts.

Now go away and bother someone else, please :).

-- 
-- Stephe

Re: Ideas for Ada 200X

[tmoran]

>Yes, sort of. The parse tree is generated at runtime, but the
>overall type of the result is already known at compile-time.
>Then inlining generates the code. Let's see if I can code a
  Code generation before parsing?  I still don't understand that.
Regardless, given your templates, could you use them to write a
piece of code to "A = A+B;" and a piece to "A += B;" to show us
how those look when you use the templates, and also how fast do
they execute 10**7 times on 3x3 matrices of zeros?

Re: Ideas for Ada 200X

[Hyman Rosen]

tmoran@acm.org wrote:
> Regardless, given your templates, could you use them to write a
> piece of code to "A = A+B;" and a piece to "A += B;" to show us
> how those look when you use the templates, and also how fast do
> they execute 10**7 times on 3x3 matrices of zeros?

I noticed an error in my previous posting; change M to N.

For A += B, we need to add to Matrix

     template <typename T>
     Matrix &operator+=(const T &r)
     {
         for (int i = 0; i < N; ++i)
             for (int j = 0; j < N; ++j)
                 data[i][j] += r(i,j);
         return *this;
     }

Having done that, we can do (warning - this is not exactly the
code that I compiled, so it may have errors)

     #include <time.h>
     #include <iostream>
     #include <ostream>
     int main()
     {
         Matrix<3> A, B;
         int i, j;
         for (i = 0; i < 3; ++i)
            for (j = 0; j < 3; ++j)
               A.data[i][j] = B.data[i][j] = 0;

         long t1b = time(0);
         for (i = 0; i < 100000000; ++i) A = A + B;
         long t1e = time(0);
	std::cout << "+  " << t1e - t1b << '\n';

         long t2b = time(0);
         for (i = 0; i < 100000000; ++i) A += B;
         long t2e = time(0);
	std::cout << "+= " << t2e - t2b << '\n';
     }

On my Sun workstation, using g++.5.8 (GCC) 3.2.2
and compiling with -O6, I get 11 seconds for "+"
and 7 seconds for "+=". Notice that this is for
one hundred million (10**8) iterations.

Re: Ideas for Ada 200X

[Robert A Duff]

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

> Stephen Leake wrote:
> 
>  > Just out of curiosity, why is turning of checks a lose for Float? How
>  >  do checks make the Float code faster?
> 
> Let me give you the thirty-thousand foot veiw, then get down and dirty.
>   Every compiler generated check has two effects.  The first is that it
> costs execution resources to perform a check.  The second is that the
> compiler remembers the state of the check if made, and this can simplify
> other code, including other (non-suppressed checks).

No, sorry, that is not correct.  In code following a check, the compiler
can (and should) assume that the check passed.  Whether or not the check
is suppressed is irrelevant.  This is because the semantics of check
suppression is that if a suppressed check would have failed, program
execution is erroneous (unpredictable).

>... The net cost of
> doing the checking is the difference of two quantities, so it can be
> positive or negative.
> 
> It is also worth noting that suppressing some checks is often the worst
> of both worlds.  Suprressing a check outside a loop can result in
> another check inside the loop needing to be made once for every
> repetition of the loop.

No, suppressing a check outside a loop has no effect on whether checks
inside the loop need to be done.

- Bob

Re: Ideas for Ada 200X

[Russ]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uhe6zw201.fsf@nasa.gov>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > This brings us full circle, back to the question of aesthetics. I say
> > that
> > 
> >     A += B
> > 
> > is far more elegant AND readable than
> > 
> >     Matrix_Add ( Into=>A, From=>B )
> > 
> > If you prefer the latter abomination, I think you're nuts.
> 
> Note the hyperbole, and the ad hominem attack.

I think Mr. Duff is adult enough to recognize a lighthearted figure of
speech and to realize that I was not literally challenging his sanity.
Besides, you are simply *assuming* that he prefers "Matrix_Add" to
"+=", but I don't recall reading his position on the matter.

> > Yes, "+=" is more familiar to me from C++, but note that Python uses
> > it too, and Python is known for its readability. I say that anyone
> > who cannot get used to "+=" (or ":+=" or whatever) is probably
> > someone who harbors such an irrational hatred of C++ that they will
> > reject even good ideas just because they came from from C++ (or C).
> 
> Just as you are rejecting the notion that Matrix_Add might be a good
> idea.

First of all, I never "rejected" Matrix_add. In fact, if I were
programming in Ada, I would use something just like it. I am only
pointing out a cleaner, more concise, and more readable alternative.

Secondly, I'll bet that far more programmers use "+=", when given the
option, than don't. How many C++ or Python programmers do you think
write var1 = var1 + var2 when they can write var1 += var2? Not many
good ones, I'll bet.

> None of us said "we can't get used to that". We said "it's an
> interesting idea, but not actually worth the cost, in the final
> analysis".

Boy, you really know how to dish out the crap, don't you.

First of all, what "cost" are you referring to? The cost of
conciseness and improved readability? Or are you referring to the
stress on mental midgets who are perplexed by a "fancy" operator like
"+="?

Secondly, who appointed you the king of comp.lang.ada and what gives
you the authority to speak for everyone else here?

> Notice that none of us called you nuts.

> Now go away and bother someone else, please :).

Oh, did I hurt your feelings when I pointed out the embarrassing
errors of some of your earlier posts? Oh, you poor little boy. Forgive
me.

By the way, I noticed that you boldly display your actual NASA email
address on every one of your posts. How clueless does one need to be
doing that in the year 2003? You must get boatloads of spam. And I'll
bet you haven't a clue that you're loading down your email server with
spam that needs to be filtered.

And do you realize that NASA doesn't appreciate having your ameteurish
views broadcast to the world, with no disclaimer, as if they were
official NASA policy? Your superiors ought to set you straight.

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Russ wrote:

>Secondly, I'll bet that far more programmers use "+=", when given the
>option, than don't.

I refuse to use that syntax when it is not necessary for performance
reasons. Yes, probably I'm a member of the mentally stressed and
absolutely stupid minority.

>How many C++ or Python programmers do you think
>write var1 = var1 + var2 when they can write var1 += var2?

Probably almost noone. But so what?

>Not many good ones, I'll bet.

This has *nothing* to do with good or bad.

>First of all, what "cost" are you referring to? The cost of
>conciseness and improved readability?

Personally, *I* don't think that

|a+=b;

is an improvement of readability for

|a := a + b;

Generally I like the latter better. Still, that wouldn't stop me to
use the more concise and thus less readable += if it would be
necessary. But in most cases it simply isn't.

>Or are you referring to the
>stress on mental midgets who are perplexed by a "fancy" operator like
>"+="?

Oh thanks. Probably the only reason that "iso646.h" exists is for
supporting the mental midgets also stressed by fancy operators like |=
and such. Funny thing, is it? Even the C-community seems to see the
fact that conciseness almost always has an impact on readability.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

18k11tm001@sneakemail.com (Russ) writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccsmqnj6ub.fsf@shell01.TheWorld.com>...
> > 18k11tm001@sneakemail.com (Russ) writes:
> > 
> > > Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<uznkwflx8.fsf@nasa.gov>...
> > > You seem to be going around in circles here. The whole idea was that A
> > > += B can avoid the temporary matrix and the extra copy operation.
> > > That's how it works in C++. Without that benefit, yes you might as
> > > well just use A := A + B.
> > 
> > This is all speculation, since Ada does not *have* a +:= operator.
> > It seems to me that if it did, the semantics should be identical to
> > any other procedure call with two parameters (one 'in out', and one
> > 'in').  It should *not* be similar to a *function* call, and should not
> > return a result.  If all that were true, then of course +:= would be
> > exactly as efficient as Matrix_Add.
> 
> I agree: "+=" would be a procedure, and "+" would be (is) a function.
> 
> This brings us full circle, back to the question of aesthetics. I say
> that
> 
>     A += B
> 
> is far more elegant AND readable than
> 
>     Matrix_Add ( Into=>A, From=>B )
> 
> If you prefer the latter abomination, I think you're nuts.

You haven't done much LISP programming, I see :-)

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> Secondly, I'll bet that far more programmers use "+=", when given the
> option, than don't. How many C++ or Python programmers do you think
> write var1 = var1 + var2 when they can write var1 += var2? Not many
> good ones, I'll bet.

What about *= and /= ?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Hyman Rosen]

tmoran@acm.org wrote:
 > how fast do they execute 10**7 times on 3x3 matrices of zeros?

Here's the fastest I've gotten so far.
Program output (times are in seconds):
+  8
+= 5
Compiler options:
     g++ -finline-limit=1000 -O3 -funroll-loops
Compiler version:
     g++.5.8 (GCC) 3.2.2
uname -a:
     SunOS 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-880
Code:
#include <time.h>
#include <iostream>
#include <ostream>

template <typename L, typename R>
struct add_op
{
     const L &l;
     const R &r;
     add_op(const L &l, const R &r) : l(l), r(r) { }
     double operator()(int i, int j) const
     { return l(i,j) + r(i,j); }
};

template <typename L, typename R>
inline add_op<L,R> operator+(const L &l, const R &r)
{ return add_op<L,R>(l,r); }

template <int N>
struct Matrix
{
     double data[N][N];

     template <typename T>
     Matrix &operator=(const T &r)
     {
         for (int i = 0; i < N; ++i)
             for (int j = 0; j < N; ++j)
                 data[i][j] = r(i,j);
         return *this;
     }

     template <typename T>
     Matrix &operator+=(const T &r)
     {
         for (int i = 0; i < N; ++i)
             for (int j = 0; j < N; ++j)
                 data[i][j] += r(i,j);
         return *this;
     }

     double operator()(int i, int j) const
     { return data[i][j]; }
};

int main()
{
     Matrix<3> A, B;
     int i, j;
     for (i = 0; i < 3; ++i)
     {
         for (j = 0; j < 3; ++j)
         {
             A.data[i][j] = 0;
             B.data[i][j] = 0;
         }
     }

     long t1b = time(0);
     for (i = 0; i < 100000000; ++i) A = A + B;
     long t1e = time(0);
     long t2b = time(0);
     for (i = 0; i < 100000000; ++i) A += B;
     long t2e = time(0);
     std::cout << "+  " << t1e - t1b << '\n';
     std::cout << "+= " << t2e - t2b << '\n';
}

Re: Ideas for Ada 200X

[Ole Kristensen]

Hyman Rosen <hyrosen@mail.com> writes:

> tmoran@acm.org wrote:
>  > how fast do they execute 10**7 times on 3x3 matrices of zeros?
> 
> Here's the fastest I've gotten so far.
> Program output (times are in seconds):
> +  8
> += 5
> Compiler options:
>      g++ -finline-limit=1000 -O3 -funroll-loops
> Compiler version:
>      g++.5.8 (GCC) 3.2.2
> uname -a:
>      SunOS 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-880

Same compiler, old 266MHz PII:

ole@linux:~> g++ -O3 -finline-limit=1000 -O3 -funroll-loops -o hyman hyman.cc
ole@linux:~> time ./hyman
+  24
+= 10

real    0m34.650s
user    0m27.250s
sys     0m0.010s

Re: Ideas for Ada 200X

[tmoran]

Hyman Rosen said:
> > how fast do they execute 10**7 times on 3x3 matrices of zeros?
>     for (i = 0; i < 100000000; ++i) A = A + B;
>Program output (times are in seconds):
>+  8
>+= 5

That's for 10**8, so 0.8 and 0.5 are the numbers for 10**7, right?
Those numbers are notably faster than your earlier 1.1, 0.7 - is it the
same machine, different compiler, or different machine, or improved
code, or what?

Ole Kristensen said:
> Same compiler, old 266MHz PII:
> +  24
> += 10
 I assume that's also for 10**8 iterations, so 2.4 and 1.0 are the 1E7
numbers?  If that machine is 1/3 the speed of an 866MHz PIII, that
suggests the compiler makes a big difference (or perhaps the compiler's
optimizations).

Returning to the original point, about the relative speed of + with
a (presumed) temporary vs +=, we seem to have a range of ratios
of 1.3 .. 2.9, with 1.6 being a commonly occurring value.

Re: Ideas for Ada 200X

[Russ]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbebc2b.ht.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Russ wrote:
> > Secondly, I'll bet that far more programmers use "+=", when given the
> > option, than don't. How many C++ or Python programmers do you think
> > write var1 = var1 + var2 when they can write var1 += var2? Not many
> > good ones, I'll bet.
> 
> What about *= and /= ?

I think those get used quite a bit too, though probably not as much as
+= and -=.

That applies to C++, Java, Python, and Perl -- four of the most
popular languages around. So I think it is safe to say that the vast
majority of experienced programmers picking up Ada as a "second"
language will have no problem whatsoever with those operators. In
fact, I'll bet a lot of them will wish Ada had those operators.

As for the other more obscure assignment operators, >>=, <<=, &=, ^=,
and |=, they are unnecessary.

Re: Ideas for Ada 200X

[Robert I. Eachus]

Russ wrote:

> Boy, you really know how to dish out the crap, don't you.

Plonk!

May I suggest the rest of you do likewise?

Re: Ideas for Ada 200X

[Hyman Rosen]

tmoran@acm.org wrote:
> That's for 10**8, so 0.8 and 0.5 are the numbers for 10**7, right?

Yes.

> Those numbers are notably faster than your earlier 1.1, 0.7 - is it the
> same machine, different compiler, or different machine, or improved
> code, or what?

Better compilation options, specifically the inlining amount.
I looked at the assembly language for my original code, and
saw that some of the arithmetic calls were not inlined.
Tweaking the parameter fixed that, and led to the improved
speed.

Re: Ideas for Ada 200X

[Hyman Rosen]

Hyman Rosen wrote:
>     const L &l;
>     const R &r;
>     add_op(const L &l, const R &r) : l(l), r(r) { }

Hmm. Vis � vis a certain other thread, look at the names
I used, without even any conscious thought at the irony!

Re: Ideas for Ada 200X

[Hyman Rosen]

Hyman Rosen wrote:
> Better compilation options, specifically the inlining amount.

Oh, and I think requesting unrolling may have helped too.
I'm not sure.

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Russ wrote:

>I think those get used quite a bit too, though probably not as much as
>+= and -=.
>
>That applies to C++, Java, Python, and Perl -- four of the most
>popular languages around.
[...]
>
>As for the other more obscure assignment operators, >>=, <<=, &=, ^=,
>and |=, they are unnecessary.

Oh? Why that? Why should the same crap for bitwise operators be
unnecessary when it is good enough for arithmetic operators?

All or nothing, I'd say. :->


Vinzent.

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbebc2b.ht.randhol+abuse@kiuk0152.chembio.ntnu.no>...
>> Russ wrote:
>> > Secondly, I'll bet that far more programmers use "+=", when given the
>> > option, than don't. How many C++ or Python programmers do you think
>> > write var1 = var1 + var2 when they can write var1 += var2? Not many
>> > good ones, I'll bet.
>> 
>> What about *= and /= ?
> 
> I think those get used quite a bit too, though probably not as much as
> += and -=.

But for multiplication and divition you still need to define your own
procedures.

> That applies to C++, Java, Python, and Perl -- four of the most
> popular languages around. So I think it is safe to say that the vast
> majority of experienced programmers picking up Ada as a "second"
> language will have no problem whatsoever with those operators. In
> fact, I'll bet a lot of them will wish Ada had those operators.

So what? I mean Ada *isn't* a different way to write C++ source.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

tmoran@acm.org writes:

> Hyman Rosen said:
> > > how fast do they execute 10**7 times on 3x3 matrices of zeros?
> >     for (i = 0; i < 100000000; ++i) A = A + B;
> >Program output (times are in seconds):
> >+  8
> >+= 5
> 
> That's for 10**8, so 0.8 and 0.5 are the numbers for 10**7, right?
> Those numbers are notably faster than your earlier 1.1, 0.7 - is it the
> same machine, different compiler, or different machine, or improved
> code, or what?
> 
> Ole Kristensen said:
> > Same compiler, old 266MHz PII:
> > +  24
> > += 10
>  I assume that's also for 10**8 iterations, so 2.4 and 1.0 are the 1E7
> numbers?  If that machine is 1/3 the speed of an 866MHz PIII, that
> suggests the compiler makes a big difference (or perhaps the compiler's
> optimizations).

Yes, it was the code posted together with Hyman's results, so it's
10**8 iterations.

Here are the results from my machine at work, 10**8 iterations:

$ g++ -O3 -funroll-loops -o hyman hyman.cpp

oleh@VOLGA /cygdrive/c/div
$ time hyman
+  3
+= 2

real    0m5.606s
user    0m5.477s
sys     0m0.020s

> 
> Returning to the original point, about the relative speed of + with
> a (presumed) temporary vs +=, we seem to have a range of ratios
> of 1.3 .. 2.9, with 1.6 being a commonly occurring value.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Ole-Hjalmar Kristensen]

tmoran@acm.org writes:

<snip>

> 
> Returning to the original point, about the relative speed of + with
> a (presumed) temporary vs +=, we seem to have a range of ratios
> of 1.3 .. 2.9, with 1.6 being a commonly occurring value.

After increasing the limit for inlining, the program runs slightly
faster, with a ratio of 1.7. I had to increase to 10**9 iterations to get
repeatable results.

oleh@VOLGA /cygdrive/c/div
$ g++ -O3 -finline-limit=1000 -funroll-loops -o hyman hyman.cpp

oleh@VOLGA /cygdrive/c/div
$ time hyman
+  26
+= 15

real    0m41.324s
user    0m40.327s
sys     0m0.110s

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Ideas for Ada 200X

[Frank J. Lhota]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0306101640.19178e81@posting.google.com...
> Preben Randhol <randhol+abuse@pvv.org> wrote in message
news:<slrnbebc2b.ht.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> > Russ wrote:
> > What about *= and /= ?
>
> I think those get used quite a bit too, though probably not as much as
> += and -=.

Agreed.

> That applies to C++, Java, Python, and Perl -- four of the most
> popular languages around. So I think it is safe to say that the vast
> majority of experienced programmers picking up Ada as a "second"
> language will have no problem whatsoever with those operators. In
> fact, I'll bet a lot of them will wish Ada had those operators.

Again, I agree, even if only for readability sake.

> As for the other more obscure assignment operators, >>=, <<=, &=, ^=,
> and |=, they are unnecessary.

Well, when one is working with modular integers, it is not hard to envision
operators such ad "and:=" or "or:=" being useful.

Re: Ideas for Ada 200X

[Richard Riehle]

Russ wrote:

> Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbebc2b.ht.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> > Russ wrote:
> > > Secondly, I'll bet that far more programmers use "+=", when given the
> > > option, than don't. How many C++ or Python programmers do you think
> > > write var1 = var1 + var2 when they can write var1 += var2? Not many
> > > good ones, I'll bet.
> >
> > What about *= and /= ?
>
> I think those get used quite a bit too, though probably not as much as
> += and -=.

I think it is important to consider this proposed addition to the language
in terms of the underlying goal of Ada.  I paraphrase,

             A language design that enables a compiler to detect and report
             on the maximum number of errors as early in the development
             process as possible.

The implications of that design goal include a strong model for confirmability,
a high degree of internal consistency, along with a syntax and a semantics that
supports that goal.

Can this goal be supported with +=,  *=,  /=, and other variations from the
C family of languages?  I submit that it can.   Can there be some underlying
benefit from these variations that might improve optimization of code?  I
think that is still not proven, even though there cases in C and C++ where
there is a difference.

Should we do what can be done simply because it can be done?   We must
ask ourselves, "At what price?"    Will it help make Ada more popular?
Hardly.  Will it make it more readable?  Not likely.   Will it improve support
for the above stated goal?   Probably not.

In the end, the argument boils down to the issue of making one language look
like another, and benefits seem marginal, at best.    I have yet to see anyone
cite the benefits for this addition to the language.

Richard Riehle

Re: Ideas for Ada 200X

[Russ]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EE7CC70.E1FD3A67@adaworks.com>...
> Russ wrote:
> 
> > Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbebc2b.ht.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> > > Russ wrote:
> > > > Secondly, I'll bet that far more programmers use "+=", when given the
> > > > option, than don't. How many C++ or Python programmers do you think
> > > > write var1 = var1 + var2 when they can write var1 += var2? Not many
> > > > good ones, I'll bet.
> > >
> > > What about *= and /= ?
> >
> > I think those get used quite a bit too, though probably not as much as
> > += and -=.
> 
> I think it is important to consider this proposed addition to the language
> in terms of the underlying goal of Ada.  I paraphrase,
> 
>              A language design that enables a compiler to detect and report
>              on the maximum number of errors as early in the development
>              process as possible.
> 
> The implications of that design goal include a strong model for confirmability,
> a high degree of internal consistency, along with a syntax and a semantics that
> supports that goal.
> 
> Can this goal be supported with +=,  *=,  /=, and other variations from the
> C family of languages?  I submit that it can.   Can there be some underlying
> benefit from these variations that might improve optimization of code?  I
> think that is still not proven, even though there cases in C and C++ where
> there is a difference.
> 
> Should we do what can be done simply because it can be done?   We must
> ask ourselves, "At what price?"    Will it help make Ada more popular?
> Hardly.  Will it make it more readable?  Not likely.   Will it improve support
> for the above stated goal?   Probably not.
> 
> In the end, the argument boils down to the issue of making one language look
> like another, and benefits seem marginal, at best.    I have yet to see anyone
> cite the benefits for this addition to the language.

Then apparently you did not read this entire thread, so let me briefly
restate the benefits as I see them.

First, the assignment operators provide a more concise and less
redundant syntax for common math operations. For example, they allow
one to write

    extra_looooong_variable_name_for_count += 1

rather than

    extra_looooong_variable_name_for_count :=
    extra_looooong_variable_name_for_count + 1

I happen to think this is better even for shorter variable names. For
example, I think

    count += 1

is cleaner and more elegant than

    count := count + 1

Why? Because the latter has redundant information. Why repeat the
variable name if you don't need to? With +=, if I decide to change the
name, I only need to change it in one place on that line, for example.
Perhaps I am obsessive minimalist, but the latter construct bothers
me.

Second, the asigmnment operators provide a more concise and clearer
syntax for efficient vector/matrix operations. Why write Add (
Into=>A, From=>B) when I can just write A += B?

Note also that these operators are not exclusive to C and C++. They
are also available -- and widely used -- in Java, Python, and Perl.
Note that C, C++, Java, Python, and Perl are probably the most popular
general purpose languages around today. And each of these languages
has +=, -=, *=, and /=. So I think it is quite misleading to say that
these operators "make one language look like another." What they do is
make Ada look like *all* of the five most popular languages around
today.

If Ada insists on bucking the norm just to be different, I won't be
surprised if it continues to fade away, and that would be a shame.

Re: Ideas for Ada 200X

[Richard Riehle]

Russ wrote:

> Richard Riehle <richard@adaworks.com> wrote in message
> > In the end, the argument boils down to the issue of making one language look
> > like another, and benefits seem marginal, at best.    I have yet to see anyone
> > cite the benefits for this addition to the language.
>
> Then apparently you did not read this entire thread, so let me briefly
> restate the benefits as I see them.

I have read your explanation (below) and I am not fully persuaded
of the virtues of this.   You are suggesting that the += syntax would
make Ada more writeable, and that has never been a goal of Ada.
Rather, Ada's goal has been to more readable, as well as more reliable.

Therefore, we must ask the question, "Does this syntax, however widespead
it may be, achieve anything beyond making the code more writeable?"  We
must examine this question in two parts.

First, "Does the code become more readable?"   For those familiar with
the C family of languages and its derivatives, there is  temptation to answer,
"Yes."   Upon deeper reflection, one finds that these constructs in the
language of origin do not make the code more readable.   I have experienced
many programmers, fluent in C, who find themselves mentally re-phrasing
something such as    "a += 5" as "a = a + 5."    This is even more frequent,
I suspect, with "a *= 5".   So, even though the shortcut is more writeable, it
adds nothing to readability.

Second, "Is the code more reliable?"   This question requires that we revisit
the goals I stated in my earlier post.

             A language design that enables a compiler to detect and report
             on the maximum number of errors as early in the development
             process as possible.

Is there some way this syntax improves the compiler's ability to catch
errors early?  Or, does this syntax make it more difficult for the compiler
to catch errors early?    Another way of asking this is, "Does this syntax
contribute to more errors or less?"

I am not sure  of the answer to that question.   Perhaps others with more
experience using the syntax might be able to say something about it.  I
do wonder whether there are situations  where an accidental misuse
could cause an undetectable error.  Suppose I wrote, "a += 5"  when
I intended, "a := 5".   This is quite easy to do because the + and the =
are both on the same key on my keyboard.  It would be a serious error,
and the compiler would not be able to detect it.  Such errors are one
reason why people writing code in the C family of languages find
themselves so dependent on debuggers.

Ada is designed to limit opportunities for syntactic mistyping, not
to increase those opportunities.   Unless there is some way for the
compiler to unfailingly distinguish between := and +=, I would be
opposed to introducing a potentially ambiguous feature into the
language.

Ada is not intended to be like other languages.  Its syntax, structure,
and semantics are carefully reasoned to support the above stated
goals.  This is not the case with more popular languages.   I think
that adopting  a syntax from those other languages to make Ada
more popular at the expense of the underlying goals of the language
would be a step backward, not forward.

Any new feature in the language must conform to the fundamental
goals of the language.  This language is intended to be used for
software that involves a high degree of safety.   From time to
time I have come up with ideas I thought were brilliant and should
be added to the language only to discover, after dialogue with
my colleagues, that this little flash of brilliance was incompatible
with the underlying goals of the language.   On such occasions, I
simply admit that I was wrong.

A final point with  regard to this syntax.  How often do we use this
in an actual program?   Is the increased danger worth the frequency
of its usage?    I would offer that it is not.

Richard Riehle

>
>
> First, the assignment operators provide a more concise and less
> redundant syntax for common math operations. For example, they allow
> one to write
>
>     extra_looooong_variable_name_for_count += 1
>
> rather than
>
>     extra_looooong_variable_name_for_count :=
>     extra_looooong_variable_name_for_count + 1
>
> I happen to think this is better even for shorter variable names. For
> example, I think
>
>     count += 1
>
> is cleaner and more elegant than
>
>     count := count + 1
>
> Why? Because the latter has redundant information. Why repeat the
> variable name if you don't need to? With +=, if I decide to change the
> name, I only need to change it in one place on that line, for example.
> Perhaps I am obsessive minimalist, but the latter construct bothers
> me.
>
> Second, the asigmnment operators provide a more concise and clearer
> syntax for efficient vector/matrix operations. Why write Add (
> Into=>A, From=>B) when I can just write A += B?
>
> Note also that these operators are not exclusive to C and C++. They
> are also available -- and widely used -- in Java, Python, and Perl.
> Note that C, C++, Java, Python, and Perl are probably the most popular
> general purpose languages around today. And each of these languages
> has +=, -=, *=, and /=. So I think it is quite misleading to say that
> these operators "make one language look like another." What they do is
> make Ada look like *all* of the five most popular languages around
> today.
>
> If Ada insists on bucking the norm just to be different, I won't be
> surprised if it continues to fade away, and that would be a shame.

Re: Ideas for Ada 200X

[Russ]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EE90854.6456A81E@adaworks.com>...
> Russ wrote:
> 
> > Richard Riehle <richard@adaworks.com> wrote in message
> > > In the end, the argument boils down to the issue of making one language look
> > > like another, and benefits seem marginal, at best.    I have yet to see anyone
> > > cite the benefits for this addition to the language.
> >
> > Then apparently you did not read this entire thread, so let me briefly
> > restate the benefits as I see them.
> 
> I have read your explanation (below) and I am not fully persuaded
> of the virtues of this.   You are suggesting that the += syntax would
> make Ada more writeable, and that has never been a goal of Ada.
> Rather, Ada's goal has been to more readable, as well as more reliable.

I appreciate your position, but I respectfully disagree.

> Therefore, we must ask the question, "Does this syntax, however widespead
> it may be, achieve anything beyond making the code more writeable?"  We
> must examine this question in two parts.
> 
> First, "Does the code become more readable?"   For those familiar with
> the C family of languages and its derivatives, there is  temptation to answer,
> "Yes."   Upon deeper reflection, one finds that these constructs in the
> language of origin do not make the code more readable.   I have experienced
> many programmers, fluent in C, who find themselves mentally re-phrasing
> something such as    "a += 5" as "a = a + 5."    This is even more frequent,
> I suspect, with "a *= 5".   So, even though the shortcut is more writeable, it
> adds nothing to readability.

The assignment operators do make a language more easily "writable,"
but I fail to see how they detract from readability. Yes, I understand
that people might find them slightly counterintuitive at first, but
certainly no good programmer will have trouble with them for long. I
don't recall ever having trouble with += myself (but then perhaps I
just forgot). My six-year-old boy still adds with his fingers, but I
certainly hope he is not constrained by that way of thinking for long.

> Second, "Is the code more reliable?"   This question requires that we revisit
> the goals I stated in my earlier post.
> 
>              A language design that enables a compiler to detect and report
>              on the maximum number of errors as early in the development
>              process as possible.
> 
> Is there some way this syntax improves the compiler's ability to catch
> errors early?  Or, does this syntax make it more difficult for the compiler
> to catch errors early?    Another way of asking this is, "Does this syntax
> contribute to more errors or less?"
> 
> I am not sure  of the answer to that question.   Perhaps others with more
> experience using the syntax might be able to say something about it.  I
> do wonder whether there are situations  where an accidental misuse
> could cause an undetectable error.  Suppose I wrote, "a += 5"  when
> I intended, "a := 5".   This is quite easy to do because the + and the =
> are both on the same key on my keyboard.  It would be a serious error,
> and the compiler would not be able to detect it.  Such errors are one
> reason why people writing code in the C family of languages find
> themselves so dependent on debuggers.

Well, ... I think you're reaching a bit on that one. Anyone who can't
readily tell += from := needs a stronger pair of reading glasses. And
it seems to me they could just as easily confuse + with *, l with 1,
or 0 with O.

> Ada is designed to limit opportunities for syntactic mistyping, not
> to increase those opportunities.   Unless there is some way for the
> compiler to unfailingly distinguish between := and +=, I would be
> opposed to introducing a potentially ambiguous feature into the
> language.
> 
> Ada is not intended to be like other languages.  Its syntax, structure,
> and semantics are carefully reasoned to support the above stated
> goals.  This is not the case with more popular languages.   I think
> that adopting  a syntax from those other languages to make Ada
> more popular at the expense of the underlying goals of the language
> would be a step backward, not forward.

But I think it would help the popularity of Ada without any
significant deleterous effect on the underlying goals. And I remind
you that Ada is completely useless when it is not used.

> Any new feature in the language must conform to the fundamental
> goals of the language.  This language is intended to be used for
> software that involves a high degree of safety.   From time to
> time I have come up with ideas I thought were brilliant and should
> be added to the language only to discover, after dialogue with
> my colleagues, that this little flash of brilliance was incompatible
> with the underlying goals of the language.   On such occasions, I
> simply admit that I was wrong.

Admit I'm wrong? That'll be the day. Just ask my wife how often I do
that!

> A final point with  regard to this syntax.  How often do we use this
> in an actual program?   Is the increased danger worth the frequency
> of its usage?    I would offer that it is not.

You didn't even address the issue of overloaded vector/matrix
operations.

I'm sure you're an expert programmer, software engineer, and more, but
I think your intense focus on safety has made you just a bit too
conservative and risk averse. That's just my impression. Then again, I
could be wrong. (How much do you want to bet some smart-ass posts a
reply agreeing with that?)

Re: Ideas for Ada 200X

[tmoran]

>readily tell += from := needs a stronger pair of reading glasses.
  Is there any human being who can do a good job proofreading his own
writings?  It's not a question of what your eyesight + glasses allows
you to see, but of what your brain allows you to notice.

>it seems to me they could just as easily confuse + with *, l with 1,
>or 0 with O.
  Which is why most programmers cringe at code that uses l or O for
variable names (as in the recently posted "const L &l;").

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Russ wrote:

>I happen to think this is better even for shorter variable names. For
>example, I think
>
>    count += 1
>
>is cleaner and more elegant than
>
>    count := count + 1
>
>Why? Because the latter has redundant information.

No. It says where to assign on the left hand side and what to assign
on the right hand side.

>Why repeat the
>variable name if you don't need to?

Because

|count += 1

could easily be parsed as

|count := 1

on the first glance. You have to look harder to see that this is *not*
an assignment.

>With +=, if I decide to change the
>name, I only need to change it in one place on that line, for example.

I don't decide to change a name, I decide to change a construct.

And you probably heard about: Ada is for ease of reading, not writing.

>Perhaps I am obsessive minimalist, but the latter construct bothers
>me.

Well, the former construct is what bothers *me*.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Russ wrote:

> Anyone who can't
>readily tell += from := needs a stronger pair of reading glasses.

:) Perhaps.

Perhaps I'd need a better printer. Or perhaps I just need a clearer
construct that tells me the first millisecond I look at it what it
does.


Vinzent.

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> Richard Riehle <richard@adaworks.com> wrote in message news:<3EE90854.6456A81E@adaworks.com>...
>> Rather, Ada's goal has been to more readable, as well as more reliable.
> 
> I appreciate your position, but I respectfully disagree.

You disagree on the design goals of Ada?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> If Ada insists on bucking the norm just to be different, I won't be
> surprised if it continues to fade away, and that would be a shame.

Ada insists to follow its design goals which is lacking in the other
languages. Just look at Perl. It is a Write-once-Never-Read language.
I'm sure you can find some nice one liners in Perl which does a lot and
say "Hey! writing like we do in Ada is redundant, just look how small
the code can be if we just put in a lot of whitespaces"

You originally wanted A += B because it was more efficient than A = A + B
in your C++ code. Now you have been shown that one cannot make the += in
Ada due to restrictions in the languages, so your road is then to use a
procedure which will solve any efficiency problems (although people have
shown the gain is not big nor is it certain you will have a gain
depending on hardware and software implementation).

However if you just want to add A += B as syntactic sugar for A := A + B
so you don't have to write the whole thing, I think your quest has no
merits.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> Perhaps I am obsessive minimalist, but the latter construct bothers
> me.

A nice cure for that is forcing yourself to write a bigger project in
Perl and then try to debug it a week later to find the errors in the
code. You might even give it to somebody else and ask her/him to
introduce some bugs in your code, and then you do the debugging.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Vinzent Hoefler]

tmoran@acm.org wrote:

>  Is there any human being who can do a good job proofreading his own
>writings?

Well, if we talk about normal writing, from time to time I achieve
that goal... but every now and then I take a closer look then I always
find another typo. :)

>  It's not a question of what your eyesight + glasses allows
>you to see, but of what your brain allows you to notice.

Precisely. The brain is a very funny apparatus, and is sometimes very
fault-tolerant and/or can easily be tricked by seeing things that
aren't really there. This has advantages in reading stuff that is not
perfect (skipping typos without having to think about what it really
means), but in programming where we try to talk to the supposedly
perfect machine it is more than counter-productive. Especially in
languages where a misplaced semicolon alone can have very strange
effects and the worst: it still compiles.

IMO, Ada made a good job in trying to avoid these kind of errors and I
see no point in adding such potentially confusing constructs.

If someone sees a big advantage in allowing constructs such as

|i := <idem> + 1

(like it was proposed, IIRC) for efficiency or possible side effect
reasons, so be it. I think, this one is quite clearly distinguishable
from any other similar construct (and would be more powerful, too).
But please beware of concise notations that can definitely confuse a
reader...


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Hyman Rosen]

tmoran@acm.org wrote:
>   Which is why most programmers cringe at code that uses l or O for
> variable names (as in the recently posted "const L &l;").

Hey, I resemeble that remark! :-)
I also don't know if such concerns apply to obvious one-liners.

Re: Ideas for Ada 200X

[Richard Riehle]

Russ wrote:

> Richard Riehle <richard@adaworks.com> wrote in message news:<3EE90854.6456A81E@adaworks.com>...
>
> > I am not sure  of the answer to that question.   Perhaps others with more
> > experience using the syntax might be able to say something about it.  I
> > do wonder whether there are situations  where an accidental misuse
> > could cause an undetectable error.  Suppose I wrote, "a += 5"  when
> > I intended, "a := 5".   This is quite easy to do because the + and the =
> > are both on the same key on my keyboard.  It would be a serious error,
> > and the compiler would not be able to detect it.  Such errors are one
> > reason why people writing code in the C family of languages find
> > themselves so dependent on debuggers.
>
> Well, ... I think you're reaching a bit on that one. Anyone who can't
> readily tell += from := needs a stronger pair of reading glasses. And
> it seems to me they could just as easily confuse + with *, l with 1,
> or 0 with O.

Good point.  However, the compiler will detect the difference between
0 and O.  The type model will reject this sort of thing.   On the other hand,
the compiler will not be able to discern intent when += is used instead
of :=.   When the compiler cannot detect such a simple error, the proposed
syntax violates the fundamental goals of the language design.

I can imagine the SPARK Examiner having a conniption trying to prove this
construct.

Oh, and yes, I am overly cautious.   Remember the domain for which Ada
code is targeted.   One reason the C family of languages is inappropriate
for safety-critical software, or any kind of software where dependability
is a primary concern, derives from the unprovability of many of the
language constructs.   If there is a potential ambiguity, and anything derived
from C has plenty of potential ambiguities, we must question the value of
including it in Ada.

Richard Riehle

Re: Ideas for Ada 200X

[Russ]

Vinzent Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bcbu9j$hgu5j$2@ID-175126.news.dfncis.de>...
> Russ wrote:
> 
> > Anyone who can't
> >readily tell += from := needs a stronger pair of reading glasses.
>  
> :) Perhaps.
> 
> Perhaps I'd need a better printer. Or perhaps I just need a clearer
> construct that tells me the first millisecond I look at it what it
> does.

+= tells me *instantly* what it does. I'm getting the impression that
the good folks here on comp.lang.ada are getting up in years. Then
again, I'm no spring chicken myself, but I do have a good pair of
reading glasses, and the printers I use cost more than $39.

Re: Ideas for Ada 200X

[Russ]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbejcua.in.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Russ wrote:
> > Richard Riehle <richard@adaworks.com> wrote in message news:<3EE90854.6456A81E@adaworks.com>...
> >> Rather, Ada's goal has been to more readable, as well as more reliable.
> > 
> > I appreciate your position, but I respectfully disagree.
> 
> You disagree on the design goals of Ada?

No, I disagree with his "position," which is exactly what I wrote. His
"position" is that "+=" conflicts with the design goals of Ada. That's
what I disagree with.

Re: Ideas for Ada 200X

[Russ]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbejdfd.in.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Russ wrote:
> > If Ada insists on bucking the norm just to be different, I won't be
> > surprised if it continues to fade away, and that would be a shame.
> 
> Ada insists to follow its design goals which is lacking in the other
> languages. Just look at Perl. It is a Write-once-Never-Read language.
> I'm sure you can find some nice one liners in Perl which does a lot and
> say "Hey! writing like we do in Ada is redundant, just look how small
> the code can be if we just put in a lot of whitespaces"

I agree completely on Perl. I was not suggesting that Perl should be a
model for Ada in any way except its assignment operators. Python, on
the other hand, is known for its readability, and it has assignment
operators.

> You originally wanted A += B because it was more efficient than A = A + B
> in your C++ code. Now you have been shown that one cannot make the += in
> Ada due to restrictions in the languages, so your road is then to use a
> procedure which will solve any efficiency problems (although people have
> shown the gain is not big nor is it certain you will have a gain
> depending on hardware and software implementation).

You have a different interpretation of the facts than I do.

> However if you just want to add A += B as syntactic sugar for A := A + B
> so you don't have to write the whole thing, I think your quest has no
> merits.

I just love you Ada guys. The five most popular general-purpose
languages in the world have it, yet it "has no merit." And you wonder
why your language is fading away!

Just for fun, I'd like to know how many programmers are now currently
using Ada and how many are using C, C++, Java, Python, or Perl. OK,
forget Python and Perl because they are not comparable. What do you
suppose the ratio is of current Ada programmers vs. C, C++, and Java
programmers? 20:1? 50:1? 100:1?

I personally appreciate Ada very much, and I am trying to keep it from
completely disappearing off the radar screen here where I work, but
I'm fighting an uphill battle. As I said before, Ada is completely
useless if it is not used.

Re: Ideas for Ada 200X

[Steve]

"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote in message
news:bcbu9i$hgu5j$1@ID-175126.news.dfncis.de...
[snip]
>
>|count += 1
>
>could easily be parsed as
>
>|count := 1
>
>on the first glance. You have to look harder to see that this is *not*
>an assignment.

Yeah, but after actually spending a lot of time reading code, I've never had
a problem distinguishing '=' from '+=', but I have had problems
distinguishing:

shiftTally(shift)(dayOfWeek(month).tallyIndex)
 .sortTally(s).nbRejects :=
shiftTally(shift)(dayOfWeekmonth).tallyIndex).sortTally(s).nbRejects + 1;

from

shiftTally(shift)(dayOfWeek(month).tallyIndex)
 .sortTally(s).nbRejects :=
shiftTally(shift)(dayOfWeekmonth).tallyIndex).sortTally(t).nbRejects + 1;

You might argue that the code was not written well.  I don't know about you
but I don't generally re-write blocks of code I'm maintaining just because
it doesn't look nice.

[snip]
>
>And you probably heard about: Ada is for ease of reading, not writing.
>

In my opinion the benefit of += has nothing to do with efficiency or ease in
writing.  It's all about readability.

I think we've about discussed this one out.

Steve
(The Duck)

>
> Vinzent.
>
> --
> Parents strongly cautioned  --  this  posting  is  intended for mature
> audiences  over  18.  It  may  contain some material that many parents
> would not find suitable for children and may include intense violence,
> sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Robert I. Eachus]

> A nice cure for that is forcing yourself to write a bigger project in
> Perl and then try to debug it a week later to find the errors in the
> code. You might even give it to somebody else and ask her/him to
> introduce some bugs in your code, and then you do the debugging.

You should try APL for a real write once read never language.  I know of 
  several "large" APL programming projects that had a rule that 
functions had no more than one line of code, and you never documented 
how it did anything, just what it did.  Maintenance programming began by 
reading the comments and throwing the line of code away.

As a good example of this style of programming it takes eighteen 
characters in APL to find all the numbers in a vector of sequential 
integers starting at one that can be represented in exactly two ways as 
the product of two integers.  (In other words find all primes less than 
a given integer value N.)

Or you can use seventeen characters if instead you find all integers 
that are not the product of two integers greater than one.  A slightly 
more complex definition of primes, but easier in APL.

But if you really want to be efficient in generating primes, use 
Wilson's Theorem.  A number P is prime iff (P-1)! mod P is congruent to 
-1 mod P. In APL that only takes sixteen characters.  ;-)

No, the number of characters is not the only measure of efficiency.  But 
if you think about the last algorithm, in a implementation with "bignum" 
integer support, it takes one temporary, and one multiply and one mod 
operation per number tested.

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> += tells me *instantly* what it does. 

But only because you learnt it in some other language. First of all we
cannot have += it must be :=+ or +:=.

Second what does:

   A =~ B

tell you?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> 
> I agree completely on Perl. I was not suggesting that Perl should be a
> model for Ada in any way except its assignment operators. Python, on
> the other hand, is known for its readability, and it has assignment
> operators.

However scripting languages are known for write optimisation. I don't
know how many times I have seens discussions where somebody asks can
somebody help me solve this in perl/bash whatever and then there are 3
good solutions and then a race starts to see who can write the whole
thing in one line obscuring what is done so much that you cannot know
except by testing it.

> 
>> You originally wanted A += B because it was more efficient than A = A + B
>> in your C++ code. Now you have been shown that one cannot make the += in
>> Ada due to restrictions in the languages, so your road is then to use a
>> procedure which will solve any efficiency problems (although people have
>> shown the gain is not big nor is it certain you will have a gain
>> depending on hardware and software implementation).
> 
> You have a different interpretation of the facts than I do.

OK perhaps but as has been said here: If an constraint error is raised
the variable on the left side should not be changed. How do you get
around this?

> I just love you Ada guys. The five most popular general-purpose
> languages in the world have it, yet it "has no merit." And you wonder
> why your language is fading away!

No I said "your quest"

> Just for fun, I'd like to know how many programmers are now currently
> using Ada and how many are using C, C++, Java, Python, or Perl. OK,
> forget Python and Perl because they are not comparable. What do you
> suppose the ratio is of current Ada programmers vs. C, C++, and Java
> programmers? 20:1? 50:1? 100:1?

How many do you expect will run to Ada if one get +:= ?
Perhaps we should get C pointers etc... as well so that everybody comes
running?

> I personally appreciate Ada very much, and I am trying to keep it from
> completely disappearing off the radar screen here where I work, but
> I'm fighting an uphill battle. As I said before, Ada is completely
> useless if it is not used.

Yes, but if your pinning your hopes to adding some syntactic sugar I
think you are barking up the wrong tree.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Ideas for Ada 200X

[James Rogers]

Preben Randhol <randhol+abuse@pvv.org> wrote in 
news:slrnbelvjk.sl.randhol+abuse@kiuk0152.chembio.ntnu.no:

> Russ wrote:
>> += tells me *instantly* what it does. 
> 
[snip]
> Second what does:
> 
>    A =~ B
> 
> tell you?
> 

I guess it depends upon which language you are writing in.
In C this indicates that A is assigned the compliment of B.

What this means for a floating point type has never been
defined.

Jim Rogers

Re: Ideas for Ada 200X

[Preben Randhol]

James Rogers wrote:
> Preben Randhol <randhol+abuse@pvv.org> wrote in 
> news:slrnbelvjk.sl.randhol+abuse@kiuk0152.chembio.ntnu.no:
> 
>> Russ wrote:
>>> += tells me *instantly* what it does. 
>> 
> [snip]
>> Second what does:
>> 
>>    A =~ B
>> 
>> tell you?
>> 
> 
> I guess it depends upon which language you are writing in.
> In C this indicates that A is assigned the compliment of B.

And in Perl it means something else...

Preben
-- 
This is Ada95 land. On quiet nights you can hear C programmers debug.

Re: Ideas for Ada 200X

[Russ]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbelvjk.sl.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Russ wrote:
> > += tells me *instantly* what it does. 
> 
> But only because you learnt it in some other language. First of all we
> cannot have += it must be :=+ or +:=.

Yes, I learned it in "some other language" (actually four others, and
I'm not even a programmer per se). And you didn't? Do you mean to tell
me that you've never learned even the basic syntax of C, C++, Java,
Perl, or Python? I guess that makes you a real language expert, eh?

Who do you think you're kidding?

Re: Ideas for Ada 200X

[Richard Riehle]

Steve wrote:

> In my opinion the benefit of += has nothing to do with efficiency or ease in
> writing.  It's all about readability.

If we adopt this syntax, in Ada, we will need to include some rules in the
language to enable the compiler to discern a clear  difference between
the += and :=.   That is, in Ada's current model, we want to compiler to
be able to tell us when a construct is a mistake or warn us when it will
potentially create an incorrect execution.

What rule can you come up with that will enable the compiler to, at minimum,
warn the programmer that this,

               i :=  1;
               i += 1;

poses no hazard.   It is bad enough that, in many derivates from C,  a legal but

erroneous code can be created when the programmer confuses the = and the = =.
This cannot currently happen in Ada, ever.

So, if there is some approach that will ensure that my i += 1 could not be a
mistake
for i := 1,  that would go a long way toward making it an acceptable construct.

Granted, in C the =  symbol is an assignment.   Therefore, the = = will not be
mistaken
for a +=.  However,  the use of these shortcuts can have interesting results
when used
incorrectly.   Consider the difference between  ++i  and i++.  Often this will
not create
a problem.  Often it will.

The readability we emphasize for Ada is not suggest human readbility.  It also
includes
compiler readability.   We are striving for less ambiguity in the language, not
more.
Therefore, each new feature must be evaulated in terms of its potential
ambiguity, not
just for the human reader, but also for the compiler.

In this regard, Ada is a leader, not a follower.   Leaders are not always
popular.  Ada
may never be popular, but it will continue to be the best language when one
requires
a language with internal consistency, lack of ambiguity, and a focus on
high-iutegrity
software.

It is very easy to become enamoured of a particular syntax.  Many a young man
has
lost his heart to a pretty face only to discover that the underlying personality
was
incompatible with his own.   Ada is not designed to be just another pretty
face.  It
is designed to support a serious set of goals,  consistently, correctly,
confirmably,
and coherently.   We might add, correctly compilable, because that is the
ultimate
test of any new syntactic feature.

Perhaps I am an old fuddy-duddy when it comes to Ada.   However, my programming
experience pre-dates the advent of Ada by some considerable number of years.  I
have made, during my career, as many or more programming mistakes as anyone
alive.  Perhaps that is a function of my cultivating my own stupidity more
effectively than most of my contemporaries.  One reason I appreciate Ada is the
way it helps me look smarter than I really am when creating code.   I rely,
perhaps
too much, on the compiler to trap those silly little mistakes I so often made
when
programming in some earlier languages, including Assembler, COBOL, Fortran,
PL/I, Neat 3, BASIC, C ( and later C++) to name a few.

So, when you can define, using well-formed semantics, how the compiler will
be improved (not the popularity of the language), how error-checking will be
sustained, and how my own stupidity will be mitigated, by the addition of this
feature, I will gladly admit my error and support your proposal.  At this point,

however, the proposal seems to be based largely on the notion that, "If C and
its derivatives has it, it must be good."   That is not good enough for me.  I
need
more carefully reasoned exposition.

Richard Riehle

Re: Ideas for Ada 200X

[Sergey Koshcheyev]

Richard Riehle wrote:
> So, if there is some approach that will ensure that my i += 1 could not be a
> mistake
> for i := 1,  that would go a long way toward making it an acceptable construct.

But is there any approach that can ensure that i := i + 1 could not be 
mistaken for i := i - 1? Why was "+" and "-" included in the language 
then? :-)

Sergey.

Re: Ideas for Ada 200X

[Steve]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3EECA772.4B662024@adaworks.com...
> Steve wrote:
>
> > In my opinion the benefit of += has nothing to do with efficiency or
ease in
> > writing.  It's all about readability.
>
> If we adopt this syntax, in Ada, we will need to include some rules in the
> language to enable the compiler to discern a clear  difference between
> the += and :=.   That is, in Ada's current model, we want to compiler to
> be able to tell us when a construct is a mistake or warn us when it will
> potentially create an incorrect execution.
>
> What rule can you come up with that will enable the compiler to, at
minimum,
> warn the programmer that this,
>
>                i :=  1;
>                i += 1;
>
> poses no hazard.   It is bad enough that, in many derivates from C,  a
legal but
>
> erroneous code can be created when the programmer confuses the = and the =
=.
> This cannot currently happen in Ada, ever.
>
> So, if there is some approach that will ensure that my i += 1 could not be
a
> mistake
> for i := 1,  that would go a long way toward making it an acceptable
construct.
[snip]
> So, when you can define, using well-formed semantics, how the compiler
will
> be improved (not the popularity of the language), how error-checking will
be
> sustained, and how my own stupidity will be mitigated, by the addition of
this
> feature, I will gladly admit my error and support your proposal.  At this
point,
>
> however, the proposal seems to be based largely on the notion that, "If C
and
> its derivatives has it, it must be good."   That is not good enough for
me.  I
> need
> more carefully reasoned exposition.

Quite the contrary.  For the most part I think that if C and C derivatives
have it, it must be carefully scrutinized.

BTW: I don't really like the "+=" syntax, I like the functionality.  I would
prefer something that is easier to distinguish, but has the same function.
I don't have anything I think is a good syntax though.

For "count := count + 3: I've considered:

"+".(count, 3);
count'In_Place( "+", 3 );
Integer'In_Place( count, 3, "+" );

With a good syntax, such functionality would I think be a good thing.

>
> Richard Riehle
>

Re: Ideas for Ada 200X

[Richard Riehle]

Sergey Koshcheyev wrote:

> Richard Riehle wrote:
> > So, if there is some approach that will ensure that my i += 1 could not be a
> > mistake
> > for i := 1,  that would go a long way toward making it an acceptable construct.
>
> But is there any approach that can ensure that i := i + 1 could not be
> mistaken for i := i - 1? Why was "+" and "-" included in the language
> then? :-)

There is no syntactic construct that can remedy faulty logic.   However,  the
issue is not faulty logic but mistaken syntax itself.    That is  why Ada is so
strict about so many syntactic constructs that other languages simply pass by
as unworthy of notice.

From time to time I hear someone complain about what they see as syntactic
sugar in Ada.   What they usually fail to understand is that what they see as
syntactic sugar is important for the compiler to do its job with the rigor we
expect of it.

C compilers are notorious for the number of errors that slip through the compilation
process.   C++, although better, also permits a larger number of errors to pass
compilation than Ada.   Java imposes some additional checking, but still falls
short of Ada.   In each case, languages derived from C permit more leeway in
what kind of code constructs will pass compilation.   This is not evil, but it is
contrary to what we want to  achieve with Ada.

If you want to obtain the benefits of Ada, you must play by the rules of Ada. The
most fundamental rule is that each code construct should be as completely
validated by the compiler as possible.   To accomplish this, Ada deliberately
disallows certain combinations of syntax that might seem otherwise intuitive.
It enforces the most well-formed set of rules for scope and visibility found in
any currently existing language.   It defines a set of legalities and illegalities
that some programmers find annoying, at first.

Ultimately, most programmers, when they come around to accepting the benefits
of what the compiler can do for them, will appreciate Ada.   To reach a point of
appreciation requires that one actually create Ada software.  Most of the time,
the complaints I encounter are from programmers who have little  direct experience
with the language.

Richard Riehle

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Richard Riehle wrote:

> Steve wrote:
> 
>> In my opinion the benefit of += has nothing to do with efficiency or ease
>> in
>> writing.  It's all about readability.
> 
> If we adopt this syntax, in Ada, we will need to include some rules in the
> language to enable the compiler to discern a clear  difference between
> the += and :=.   That is, in Ada's current model, we want to compiler to
> be able to tell us when a construct is a mistake or warn us when it will
> potentially create an incorrect execution.
> 
> What rule can you come up with that will enable the compiler to, at
> minimum, warn the programmer that this,
> 
>                i :=  1;
>                i += 1;
> 
> poses no hazard.   It is bad enough that, in many derivates from C,  a
> legal but
> 
> erroneous code can be created when the programmer confuses the = and the =
> =. This cannot currently happen in Ada, ever.
> 
> So, if there is some approach that will ensure that my i += 1 could not be
> a mistake
> for i := 1,  that would go a long way toward making it an acceptable
> construct.

It could be quite easy in Ada:

i + 1; -- Here "+" is a *procedure* (:-))

procedure "+" (Left : in out Integer; Right : Integer);

> Granted, in C the =  symbol is an assignment.   Therefore, the = = will
> not be mistaken
> for a +=.  However,  the use of these shortcuts can have interesting
> results when used
> incorrectly.   Consider the difference between  ++i  and i++.  Often this
> will not create
> a problem.  Often it will.

Yes, the real pain is to ensure a compatible semantic of all that mess. It 
is often very difficult in C++, which has a plethora of quasi-arithmetic 
operators, plus explicit by-value vs. by-reference semantics, plus various 
forms of construction / initialization, plus distiguishable constant vs. 
non-constant variations. Now imagine a type which has all this stuff, and 
you have to derive from it overriding [which operations?]. Well, then good 
luck!

Should Ada some time have things like "++", "+:=" etc, the compiler shall at 
least imlicitly generate non-overridden operations them from user-defined 
ones, as it does for "/=".

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Russ wrote:

>Vinzent Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bcbu9j$hgu5j$2@ID-175126.news.dfncis.de>...
>> Russ wrote:
>> 
>> > Anyone who can't
>> >readily tell += from := needs a stronger pair of reading glasses.
>>  
>> :) Perhaps.
>> 
>> Perhaps I'd need a better printer. Or perhaps I just need a clearer
>> construct that tells me the first millisecond I look at it what it
>> does.
>
>+= tells me *instantly* what it does.

Sure it does, if you see it as it.

But I'm human[0] and brain is a bitch[1], so it is quite common that
you *see* an assignment when you *expect* to see one instead of seeing
what is *really* going on. So you almost always have to look twice.

>I'm getting the impression that
>the good folks here on comp.lang.ada are getting up in years.

;)

In another group I was just told, I were still almost half a kid. Just
to make this clear, I'm not yet thirty but already my brain is bugging
me sometimes.


Vinzent.

[0] The login screen today said: "You're working under a slight
handicap.  You happen to be human." - Fits perfectly, I think.
[1] At least mine is.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Steve wrote:

>"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote in message
>news:bcbu9i$hgu5j$1@ID-175126.news.dfncis.de...
>[snip]
>>
>Yeah, but after actually spending a lot of time reading code, I've never had
>a problem distinguishing '=' from '+=',

Well, that's probably easier. :)

>but I have had problems
>distinguishing:
>
>shiftTally(shift)(dayOfWeek(month).tallyIndex)
> .sortTally(s).nbRejects :=
>shiftTally(shift)(dayOfWeekmonth).tallyIndex).sortTally(s).nbRejects + 1;
>
>from
>
>shiftTally(shift)(dayOfWeek(month).tallyIndex)
> .sortTally(s).nbRejects :=
>shiftTally(shift)(dayOfWeekmonth).tallyIndex).sortTally(t).nbRejects + 1;
>
>You might argue that the code was not written well.  I don't know about you
>but I don't generally re-write blocks of code I'm maintaining just because
>it doesn't look nice.

I do. :-) I don't want the one who might come after me, going through
the same shit again.

>>And you probably heard about: Ada is for ease of reading, not writing.
>
>In my opinion the benefit of += has nothing to do with efficiency or ease in
>writing.  It's all about readability.

In *some* cases it might be so. In *most* cases it won't. And for your
example: I don't see, why

|shiftTally(shift)(dayOfWeek(month).tallyIndex)
| .sortTally(s).nbRejects += 1;

should be easier to distinguish from

>shiftTally(shift)(dayOfWeek(month).tallyIndex)
> .sortTally(s).nbRejects := 1;

In either case you have to look twice anyway.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 06:10, in article iicHa.1009748$Zo.229290@sccrnsc03, "Steve"
<nospam_steved94@attbi.com> wrote:

> BTW: I don't really like the "+=" syntax, I like the functionality.  I would
> prefer something that is easier to distinguish, but has the same function.
> I don't have anything I think is a good syntax though.
> 
> For "count := count + 3: I've considered:
> 
> "+".(count, 3);
> count'In_Place( "+", 3 );
> Integer'In_Place( count, 3, "+" );
> 
> With a good syntax, such functionality would I think be a good thing.

count := idem + 3;

shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
   idem + 1;

Where "idem" represents a token, to be decided upon, that denotes the
variable on the LHS of the assignment.

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

Re: Ideas for Ada 200X

[Larry Hazel]

Bill Findlay wrote:
> On 16/6/03 06:10, in article iicHa.1009748$Zo.229290@sccrnsc03, "Steve"
> <nospam_steved94@attbi.com> wrote:
> 
> 
>>BTW: I don't really like the "+=" syntax, I like the functionality.  I would
>>prefer something that is easier to distinguish, but has the same function.
>>I don't have anything I think is a good syntax though.
>>
>>For "count := count + 3: I've considered:
>>
>>"+".(count, 3);
>>count'In_Place( "+", 3 );
>>Integer'In_Place( count, 3, "+" );
>>
>>With a good syntax, such functionality would I think be a good thing.
> 
> 
> count := idem + 3;
> 
> shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
>    idem + 1;
> 
> Where "idem" represents a token, to be decided upon, that denotes the
> variable on the LHS of the assignment.
> 
I like it.  Except for a possible conflict with the concatenation 
operator, "&" would be a good choice for people familiar with the 
substitution command in the unix editors .. vi, ed, and sed.

Larry

Re: Ideas for Ada 200X

[Wesley Groleau]

>>You might argue that the code was not written well.  I don't know about you
>>but I don't generally re-write blocks of code I'm maintaining just because
>>it doesn't look nice.
> 
> I do. :-) I don't want the one who might come after me, going through

They always told me, "If it ain't broke, don't fix it."

I replied, "If nobody has a clue what it means, it's broke."

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Wesley Groleau wrote:

>They always told me, "If it ain't broke, don't fix it."
>
>I replied, "If nobody has a clue what it means, it's broke."

I have to remember that. Thanks. :)


Vinzent.

Re: Ideas for Ada 200X

[Georg Bauhaus]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
: 
: shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
:   idem + 1;

Hm. How about renaming and access values?
The following two examples of ad hoc code have given me the
effect of idem.

procedure waiter is

   b: Bill;
begin

   add(b, Soup);
   add(b, Chicken);
   declare
      use type  Prices.Amount;

      p: constant Bill_item := item_at(sort(b), 2);
	-- this would be your long LHS.

   begin
      p.all := p.all + 1.20;  -- only one call on item_at here
   end;

   add(b, Rice);


end waiter;

There is only one call on sort before the left hand side
gets its new value.

	call bills__add
	movl %eax,%ebx
	pushl $2
	pushl %ebx
	call bills__sort
	addl $4,%esp
	pushl %eax
	call bills__item_at
	addw $153,(%eax)
	pushl $4
	pushl %ebx
	call bills__add


Similarly, given a complex data structure, and
some functions for indexing the data structures,

   type Arrow is access all Point;
   type Point_list is array(List_index) of Arrow;

   function make_one return Point_list;
   function rand return List_index;

then from

begin
with_renaming:
    declare
       p: Arrow renames make_one(rand);
    begin
       p.x := p.x + 333;
    end with_renaming;

without_renaming:
    begin
       make_one(rand).x := make_one(rand).x + 555;
    end without_renaming;
end big;

I get a total of 3 calls to make_one and rand, one of
each in the with_renaming block, two of each in the
other block, without renaming.


-- Georg

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 17:19, in article bckqmc$ofm$1@a1-hrz.uni-duisburg.de, "Georg
Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
> : 
> : shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
> :   idem + 1;
> 
> Hm. How about renaming and access values?

Unfortunately, there are significant restrictions on the types of objects
that can be renamed; and explicitly using access values introduces aliasing,
which is better avoided if possible.

I posted the following to a thread with the same title a few weeks ago:

On 3/6/03 14:36, "Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote:

> As I see it there are several arguments in favour of the 'idem' proposal:
> 
> 1. It lets the programmer indicate that the occurrences of the LHS in the RHS
> are *necessarily* the same, and not contingently so, which makes the code more
> self-documenting.
> 
> 2. It removes a source of error in transcribing the LHS multiple times.
> 
> 3. It allows more concisely readable code when the LHS is lengthy.
> 
> 4. It provides functionality that it only partially available by means of much
> clumsier renaming declarations, because not all objects can be renamed.
> 
> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
> that lvalue as often as needed to evaluate the RHS. This has three potential
> benefits: shorter code, faster execution, and once-only invocation of any side
> effects.
> 
> 6. It might make it somewhat easier for the compiler to generate
> update-in-place object code, where the target architecture allows that and
> where it offers a performance advantage.
> 
> 7. It provides all the utility of C's multitude of combined assignment
> operators with one small, compatible change to the syntax of operands.
> (I specify C, rather than C++, to avoid getting into a argument about
> overloading assignment).
> 
> 8. It allows the expression of useful forms that C's combined assignment
> operators cannot achieve (e.g. X := 1 - idem;).

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

Re: Ideas for Ada 200X

[Georg Bauhaus]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
: On 16/6/03 17:19, in article bckqmc$ofm$1@a1-hrz.uni-duisburg.de, "Georg
: Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote:
: 
:> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
:> : 
:> : shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
:> :   idem + 1;
:> 
:> Hm. How about renaming and access values?
: 
: Unfortunately, there are significant restrictions on the types of objects
: that can be renamed; and explicitly using access values introduces aliasing,
: which is better avoided if possible.

(But it doesn't required explicit aliasing.)

:> 4. It provides functionality that it only partially available by means of much
:> clumsier renaming declarations, because not all objects can be renamed.

O.K.



-- Georg

Re: Ideas for Ada 200X

[Tarjei T. Jensen]

Richard Riehle wrote:
> If we adopt this syntax, in Ada, we will need to include some rules in the
> language to enable the compiler to discern a clear  difference between
> the += and :=.   That is, in Ada's current model, we want to compiler to
> be able to tell us when a construct is a mistake or warn us when it will
> potentially create an incorrect execution.

How would you think about
  i := () +1;

Feel free to replace () with {} or []. Or perhaps use (.), {.} or [.].

An advantage would be that you could re-use the value several times.

e.g.
i := () + () / 100;


greetings,

Re: Ideas for Ada 200X

[Russ]

Larry Hazel <lhhazel@otelco.net> wrote in message news:<1akHa.59$Rk4.4201@eagle.america.net>...
> Bill Findlay wrote:
> > On 16/6/03 06:10, in article iicHa.1009748$Zo.229290@sccrnsc03, "Steve"
> > <nospam_steved94@attbi.com> wrote:
> > 
> > 
> >>BTW: I don't really like the "+=" syntax, I like the functionality.  I would
> >>prefer something that is easier to distinguish, but has the same function.
> >>I don't have anything I think is a good syntax though.
> >>
> >>For "count := count + 3: I've considered:
> >>
> >>"+".(count, 3);
> >>count'In_Place( "+", 3 );
> >>Integer'In_Place( count, 3, "+" );
> >>
> >>With a good syntax, such functionality would I think be a good thing.
> > 
> > 
> > count := idem + 3;
> > 
> > shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
> >    idem + 1;
> > 
> > Where "idem" represents a token, to be decided upon, that denotes the
> > variable on the LHS of the assignment.
> > 
> I like it.  Except for a possible conflict with the concatenation 
> operator, "&" would be a good choice for people familiar with the 
> substitution command in the unix editors .. vi, ed, and sed.
> 
> Larry

Given Mr. Riehle's and others' concerns about "+=", I could actually
go along with something like this. How about "@" to represent the
value of the left side?

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 18:09, in article bcktkf$ep$2@a1-hrz.uni-duisburg.de, "Georg
Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote:

> :> : shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
> :> :   idem + 1;
> :> 
> :> Hm. How about renaming and access values?
> : 
> : Unfortunately, there are significant restrictions on the types of objects
> : that can be renamed; and explicitly using access values introduces aliasing,
> : which is better avoided if possible.
> 
> (But it doesn't required explicit aliasing.)

I must be mistaking your meaning. How do you obtain and use an access value
without aliasing the object it references; and explicitly so, if it is a
global or local object?

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

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 18:16, in article hYmHa.6881$Hb.124073@news4.e.nsc.no, "Tarjei T.
Jensen" <tarjei@online.no> wrote:

> Richard Riehle wrote:
>> If we adopt this syntax, in Ada, we will need to include some rules in the
>> language to enable the compiler to discern a clear  difference between
>> the += and :=.   That is, in Ada's current model, we want to compiler to
>> be able to tell us when a construct is a mistake or warn us when it will
>> potentially create an incorrect execution.
> 
> How would you think about
> i := () +1;

I would think: this looks very error-prone.
I think any syntax for an "idem" feature should not easily result from a
simple typographical error in writing a correct expression.

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

>On 16/6/03 18:16, in article hYmHa.6881$Hb.124073@news4.e.nsc.no, "Tarjei T.
>Jensen" <tarjei@online.no> wrote:
>
>> Richard Riehle wrote:
>>> If we adopt this syntax, in Ada, we will need to include some rules in the
>>> language to enable the compiler to discern a clear  difference between
>>> the += and :=.   That is, in Ada's current model, we want to compiler to
>>> be able to tell us when a construct is a mistake or warn us when it will
>>> potentially create an incorrect execution.
>> 
>> How would you think about
>> i := () +1;
>
>I would think: this looks very error-prone.
>I think any syntax for an "idem" feature should not easily result from a
>simple typographical error in writing a correct expression.

I'd say something similar to the the already proposed (or at least
mentioned) "<>" would be good enough for me.

Or perhaps we should think about a longer one to discourage people to
use it everywhere in their code. ;)


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 19:19, in article bcl1pu$jscm4$1@ID-175126.news.dfncis.de,
"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:

>>> How would you think about
>>> i := () +1;
>> 
>> I would think: this looks very error-prone.
>> I think any syntax for an "idem" feature should not easily result from a
>> simple typographical error in writing a correct expression.
> 
> I'd say something similar to the the already proposed (or at least
> mentioned) "<>" would be good enough for me.
> 
> Or perhaps we should think about a longer one to discourage people to
> use it everywhere in their code. ;)

All the proposals so far have their problems:

   idem (or any new reserved word)  but: a new reserved word
   all                              but: could be a typo for "p.all"
   <>                               but: consider "<> < <>+1"
   &                                but: consider "& & &"
   @ (or # or ? or $ or %)          but: wrong associations?

Despite the possibility of suggesting wrong associations, I'm tending to one
of the latter notations (this is about brevity after all), or perhaps "all".
If " were not a string quote, it would be good, being used already as an
abbreviation for 'ditto'. 8-)

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

>On 16/6/03 19:19, in article bcl1pu$jscm4$1@ID-175126.news.dfncis.de,
>"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:
>
>>>> How would you think about
>>>> i := () +1;
>>> 
>>> I would think: this looks very error-prone.
>>> I think any syntax for an "idem" feature should not easily result from a
>>> simple typographical error in writing a correct expression.
>> 
>> I'd say something similar to the the already proposed (or at least
>> mentioned) "<>" would be good enough for me.
>> 
>> Or perhaps we should think about a longer one to discourage people to
>> use it everywhere in their code. ;)
>
>All the proposals so far have their problems:
>
>   idem (or any new reserved word)  but: a new reserved word
>   all                              but: could be a typo for "p.all"
>   <>                               but: consider "<> < <>+1"

Mmh. Well, this sure looks ugly, but its actual use isn't so obvious
to me. I mean, we are talking about some kind of assignment here,
aren't we?

So how would come someone up with something like this:

|x := <> < <> + 1;

On the first glance I can't find any idea where this makes sense. The
result type should fit (so it should be boolean, I'd say) unless
someone has made use of a quite strange overloading of the
"<"-Operator...

What am I missing here?

>   &                                but: consider "& & &"
>   @ (or # or ? or $ or %)          but: wrong associations?
>
>Despite the possibility of suggesting wrong associations, I'm tending to one
>of the latter notations (this is about brevity after all), or perhaps "all".

So simply let's combine these. :-)

I'd say "<idem>" or "<all>" looks reasonable good, is long enough to
not encourage the programmer to overuse it and also should avoid most
if not all of the problems mentioned (it even doesn't have to be a
reserved word then).

Unless, someone comes up with

|Idem := <idem> < ...

or

|<<idem>>
| ...

or so... ;)

<kidding>
A clear and distinct <left_hand_side> would be cool. I'd like that.
Looks more Ada'ish.

And nobody would be crazy enough to name a variable Left_Hand_Side, so
we even could forget about the reserved word issue completely.
</kidding>

>If " were not a string quote, it would be good, being used already as an
>abbreviation for 'ditto'. 8-)

Nice idea, and ... well, % is already a string quote, too, IIRC. :-)


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Georg Bauhaus]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
: On 16/6/03 18:09, in article bcktkf$ep$2@a1-hrz.uni-duisburg.de, "Georg
: Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote:
: 
:> :> : shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects :=
:> :> :   idem + 1;
:> :> 
:> :> Hm. How about renaming and access values?
:> : 
:> : Unfortunately, there are significant restrictions on the types of objects
:> : that can be renamed; and explicitly using access values introduces aliasing,
:> : which is better avoided if possible.
:> 
:> (But it doesn't required explicit aliasing.)
: 
: I must be mistaking your meaning. How do you obtain and use an access value
: without aliasing the object it references; and explicitly so, if it is a
: global or local object?

What I had been thinking of was that there is no need to explicitly
introduce
   bar: aliased Foo;
if bar has been allocated with new, which surely is a restriction.
(f being a function returning an access value to some new record
with a component c, I can write
f.c := f.c + baz;
(and loose the anonymous object in this scope unless it is hooked
somewhere else.) Am I right in thinking that there is an aliased
view here, due to the implicit dereference in f.c, but not explicit
aliasing in the sense described above?)


-- Georg

Re: Ideas for Ada 200X "left hand side" repeater.

[Wesley Groleau]

I'm still not persuaded that the idea is worth
the trouble, but

  - If we go to the trouble of adding a mechanism
    to save re-typing the left hand side, it definitely
    must not have rules about some operators can use it
    and some can't.

  - It must neither be hard to read nor easy to create
    by typo.  Especially not by typo for some other legal
    construct.  An ideal that will never be completely
    reachable, but should always be attempted, is that
    a typo should fail to compile instead of changing
    the behavior.

  - How about
      {}
    Doesn't match anything in the language currently.
    Hard to type by accident.
    If you miss the shift key, you don't get something else
    legal or even that looks like a typo for something legal.
    Mnemonic for it is how it's used in the Unix 'find'

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 20:09, in article bcl4o8$kkj68$1@ID-175126.news.dfncis.de,
"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:

> Bill Findlay wrote:
>> All the proposals so far have their problems:
>> 
>>   idem (or any new reserved word)  but: a new reserved word
>>   all                              but: could be a typo for "p.all"
>>   <>                               but: consider "<> < <>+1"
> 
> Mmh. Well, this sure looks ugly, but its actual use isn't so obvious
> to me. I mean, we are talking about some kind of assignment here,
> aren't we? So how would come someone up with something like this:
> 
> |x := <> < <> + 1;
> 
> On the first glance I can't find any idea where this makes sense. The
> result type should fit (so it should be boolean, I'd say) unless
> someone has made use of a quite strange overloading of the
> "<"-Operator...
> 
> What am I missing here?

Overloading is one possibility, but this expression is feasible as a
*sub*expression of a valid RHS, e.g.

X := Boolean'Pos(<> < <> + 1); -- see how flexible idem notation is? 8-)

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

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 20:14, in article bcl4ul$ibu$1@a1-hrz.uni-duisburg.de, "Georg
Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
> : I must be mistaking your meaning. How do you obtain and use an access value
> : without aliasing the object it references; and explicitly so, if it is a
> : global or local object?
> 
> What I had been thinking of was that there is no need to explicitly
> introduce
>  bar: aliased Foo;
> if bar has been allocated with new, which surely is a restriction.

Oh, right.

> (f being a function returning an access value to some new record
> with a component c, I can write
> f.c := f.c + baz;

OK. But the record has to be on the heap in that case too. A major
restriction.

We really want to be able to refer directly to record fields and array
elements as objects in their own right, not only as a components to be
located within another object:

 prefix.c := idem + baz;

ensures that the location of prefix.c is evaluated only once. This is
valuable even if prefix is a function returning a (heap) pointer.

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

Re: Ideas for Ada 200X "left hand side" repeater.

[Bill Findlay]

On 16/6/03 20:29, in article eIydnQ7dD_77h3OjXTWJiA@gbronline.com, "Wesley
Groleau" <wesgroleau@despammed.com> wrote:

Wes, I recognize your name from comp.sys.mac.
Macs and Ada - you are clearly a man of culture and taste. 8-)

> I'm still not persuaded that the idea is worth
> the trouble, but
> 
> - If we go to the trouble of adding a mechanism
>   to save re-typing the left hand side, it definitely
>   must not have rules about some operators can use it
>   and some can't.

Definitely. 
That is the great benefit of the idem notation - it allows full generality
of expression on the RHS.

> - It must neither be hard to read nor easy to create
>   by typo.  Especially not by typo for some other legal
>   construct.  An ideal that will never be completely
>   reachable, but should always be attempted, is that
>   a typo should fail to compile instead of changing
>   the behavior.

Absolutely.

> - How about
>     {}
>   Doesn't match anything in the language currently.
>   Hard to type by accident.
>   If you miss the shift key, you don't get something else
>   legal or even that looks like a typo for something legal.
>   Mnemonic for it is how it's used in the Unix 'find'

That might be its biggest disadvantage. 8-)

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

>On 16/6/03 20:09, in article bcl4o8$kkj68$1@ID-175126.news.dfncis.de,
>"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:
>
>> |x := <> < <> + 1;
>> 
>> On the first glance I can't find any idea where this makes sense. The
>> result type should fit (so it should be boolean, I'd say) unless
>> someone has made use of a quite strange overloading of the
>> "<"-Operator...
>> 
>> What am I missing here?
>
>Overloading is one possibility, but this expression is feasible as a
>*sub*expression of a valid RHS, e.g.
>
>X := Boolean'Pos(<> < <> + 1); -- see how flexible idem notation is? 8-)

Huh? ... Hmm.

Well, actually it indeed could make sense with a modular integer
type... :-)


Vinzent.

Re: Ideas for Ada 200X

[Preben Randhol]

Bill Findlay wrote:
>    idem (or any new reserved word)  but: a new reserved word

My problem with idem is that I don't understand what it meant. Is it Latin?

So 

   Age := idem + 1;

for me reads that I set the Age to some variable idem + 1. If a reserved
word I would rather one found one that makes it more clear that it
refers to LHS. One could of course use LHS, but I don't know if it is
clear for others etc...

Personally I would rather have:

   Age'Inc (1);

unless this has some sideeffects I don't know of. However one loose
the possibility for:

   Age := idem * 3 + (idem/2 - 1);


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 21:52, in article
slrnbesbfu.1mj.randhol+abuse@kiuk0152.chembio.ntnu.no, "Preben Randhol"
<randhol+abuse@pvv.org> wrote:

> Bill Findlay wrote:
>>    idem (or any new reserved word)  but: a new reserved word
> 
> My problem with idem is that I don't understand what it meant. Is it Latin?

It's (old fashioned) English, meaning "the same (word)".
It derives from Latin "item".

> So 
> 
>  Age := idem + 1;
> 
> for me reads that I set the Age to some variable idem + 1. If a reserved
> word I would rather one found one that makes it more clear that it
> refers to LHS. One could of course use LHS, but I don't know if it is
> clear for others etc...

I have said several times that I regard "idem" purely as a placeholder in
this discussion for a token to be determined.

> Personally I would rather have:
> 
>  Age'Inc (1);
> 
> unless this has some sideeffects I don't know of. However one loose
> the possibility for:
> 
>  Age := idem * 3 + (idem/2 - 1);

Well, you lose everything except addition. Quite a loss.

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

Re: Ideas for Ada 200X

[Preben Randhol]

Bill Findlay wrote:
> 
> I have said several times that I regard "idem" purely as a placeholder in
> this discussion for a token to be determined.
> 

OK fair enough.

>> Personally I would rather have:
>> 
>>  Age'Inc (1);
>> 
>> unless this has some sideeffects I don't know of. However one loose
>> the possibility for:
>> 
>>  Age := idem * 3 + (idem/2 - 1);
> 
> Well, you lose everything except addition. Quite a loss.

Well there are discussions in criss cross here :-) Some want += for
speed-up reasons, some want it for readability and some want a thing
like idem to have the compiler unroll complicated functions if I
understand correctly.

At any rate I wouldn't mind seing Age'Inc (1); in addition to idem as it
would help those who have complicated expressions they only need to
increase by some number.

-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Pascal Obry]

Bill Findlay <yaldnifw@blueyonder.co.uk> writes:

> It's (old fashioned) English, meaning "the same (word)".
> It derives from Latin "item".

I really don't think so. For me Idem is a Latin word, but I'm not a
Latin expert...

Pascal.

-- 

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Pascal Obry wrote:

>Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
>
>> It's (old fashioned) English, meaning "the same (word)".
>> It derives from Latin "item".
>
>I really don't think so. For me Idem is a Latin word, but I'm not a
>Latin expert...

<http://www.m-w.com/cgi-bin/dictionary?idem> says:

|Pronunciation: 'I-"dem, 'E-, 'i-
|Function: pronoun
|Etymology: Middle English, from Latin, same -- more at IDENTITY
|Date: 14th century
|: something previously mentioned : SAME

and then Identity says:

|Etymology: Middle French identité, from Late Latin identitat-,
|identitas, probably from Latin identidem repeatedly, contraction of
|idem et idem, literally, same and same
|Date: 1570

So I'd say, yes, idem seems to be a Latin word. :-)


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 22:24, in article uu1apn2bo.fsf@wanadoo.fr, "Pascal Obry"
<p.obry@wanadoo.fr> wrote:

> 
> Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
> 
>> It's (old fashioned) English, meaning "the same (word)".
>> It derives from Latin "item".
> 
> I really don't think so. For me Idem is a Latin word, but I'm not a
> Latin expert...

Me neither. I was paraphrasing (not too inaccurately, I hope) what the
Concise Oxford English Dictionary says.

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

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 22:13, in article
slrnbescn7.298.randhol+abuse@kiuk0152.chembio.ntnu.no, "Preben Randhol"
<randhol+abuse@pvv.org> wrote:

> Well there are discussions in criss cross here :-) Some want += for
> speed-up reasons, some want it for readability and some want a thing
> like idem to have the compiler unroll complicated functions if I
> understand correctly.

I want all the above.  8-)
"idem" delivers speed, readability and control over evaluation.

> At any rate I wouldn't mind seing Age'Inc (1); in addition to idem as it
> would help those who have complicated expressions they only need to
> increase by some number.

What about Age'Dec(1); ?

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Vinzent Hoefler wrote:

>Mmh, to my knowledge micron is originated from the Greek word "micros"
>for little, small, tiny. Used to mean one out of a thousand
>[millimeter] since I am able to speak. Ok, probably it was used
>earlier already... ;-)

Just for the still curious and because I found a (so I think) reliable
source (<http://www.m-w.com/cgi-bin/dictionary?micron>):

|Main Entry: mi·cron 
|Pronunciation: 'mI-"krän
|Function: noun
|Etymology: New Latin, from Greek mikron, neuter of mikros small -- more at MICR-
|Date: 1885
|: 2MICROMETER

So this word creation is definitely older than me. :-)


Vinzent.

Re: Ideas for Ada 200X

[Bill Findlay]

On 16/6/03 22:30, in article bcld18$k8tkb$1@ID-175126.news.dfncis.de,
"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:

> |Pronunciation: 'I-"dem, 'E-, 'i-
> |Function: pronoun
> |Etymology: Middle English, from Latin, same -- more at IDENTITY
> |Date: 14th century
> |: something previously mentioned : SAME
> 
> and then Identity says:
> 
> |Etymology: Middle French identit�, from Late Latin identitat-,
> |identitas, probably from Latin identidem repeatedly, contraction of
> |idem et idem, literally, same and same
> |Date: 1570
> 
> So I'd say, yes, idem seems to be a Latin word. :-)

Only when one is speaking Latin.
When I speak, it is Middle English. 8-)

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Bill Findlay wrote:

[history of Idem]
>Only when one is speaking Latin.
>When I speak, it is Middle English. 8-)

Ok. You won. ;)


Vinzent.

Re: Ideas for Ada 200X "left hand side" repeater.

[Wesley Groleau]

> Macs and Ada - you are clearly a man of culture and taste. 8-)

What do they have in common?  "It just works"

(Although after my recent network madness,
I'm beginning to wonder!)

Re: Ideas for Ada 200X "left hand side" repeater.

[Chad R. Meiners]

Or how about

[Pixel] Screen.Buffer(i) := Pixel + 1;

where [Pixel] gives an idem name "Pixel" for Screen.Buffer(i) which can be
used (in place of its variable) until it falls out of scope at the
semi-colon.

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:eIydnQ7dD_77h3OjXTWJiA@gbronline.com...
>   - How about
>       {}
>     Doesn't match anything in the language currently.
>     Hard to type by accident.
>     If you miss the shift key, you don't get something else
>     legal or even that looks like a typo for something legal.
>     Mnemonic for it is how it's used in the Unix 'find'
>

Re: Ideas for Ada 200X

[Robert I. Eachus]

Richard Riehle wrote:

> Perhaps I am an old fuddy-duddy when it comes to Ada.   However, my programming
> experience pre-dates the advent of Ada by some considerable number of years.  I
> have made, during my career, as many or more programming mistakes as anyone
> alive.  Perhaps that is a function of my cultivating my own stupidity more
> effectively than most of my contemporaries.  One reason I appreciate Ada is the
> way it helps me look smarter than I really am when creating code.   I rely,
> perhaps too much, on the compiler to trap those silly little mistakes I so often
 > made when programming in some earlier languages, including Assembler, 
COBOL,
 > Fortran, PL/I, Neat 3, BASIC, C ( and later C++) to name a few.

Same goes for me.  Every time I write some new Ada code I am astonished 
at how many things the compiler can find to complain about.  But I would 
be even more astonished if once the code compiled cleanly, it failed to 
pass all the test cases.

This doesn't mean that I don't make mistakes when programming, I do. 
But so many of those errors are caught by the Ada compiler that perhaps 
one error per thousand makes it through into compiled code.  That's why 
I always produce test cases with every unit and run them.  (And none of 
this can be any help if I misunderstand the requirements--that is what 
code reviews are for.)  If I program in C or C++, I probably make 
exactly as many errors as in Ada.  I have much more experience with 
PL/I, and I know that it is true there.  But in PL/I, perhaps 10% of 
errors make it through to compiled code (usually in the form of implicit 
conversions).  Fortran and C are worse, much worse.

In fact, I can unequivocably state that in all my years programming in 
Ada, I have found more bugs in the (writen in assembler, C or PL/I) 
operating systems than I have in my Ada code once it compiled.  That is 
not quite as bad as it sounds, since in some cases, supporting the OS, 
or integrating Ada compiler support into the OS was a part of my job. 
But it has even been true with fielded commercial OSes.  For example, I 
remember a case where Solaris required a constant string parameter--and 
modified the string in the kernel.  Very bad juju.  Of course, the 
workaround in the Ada code was to make the string (I think the choices 
were "UDP" and "TCP") an in out parameter.

Re: Ideas for Ada 200X

[Robert I. Eachus]

Vinzent Hoefler wrote:
> Steve wrote:
>>but I have had problems
>>distinguishing:
>>
>>shiftTally(shift)(dayOfWeek(month).tallyIndex)
>>.sortTally(s).nbRejects :=
>>shiftTally(shift)(dayOfWeekmonth).tallyIndex).sortTally(s).nbRejects + 1;
>>
>>from
>>
>>shiftTally(shift)(dayOfWeek(month).tallyIndex)
>>.sortTally(s).nbRejects :=
>>shiftTally(shift)(dayOfWeekmonth).tallyIndex).sortTally(t).nbRejects + 1;
>>
>>You might argue that the code was not written well.  I don't know about you
>>but I don't generally re-write blocks of code I'm maintaining just because
>>it doesn't look nice.
> 
> I do. :-) I don't want the one who might come after me, going through
> the same shit again.

Amen!  In my case, that code would never even hit the compiler.

Rejects: Integer renames 
shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s).nbRejects;
...
Rejects := Rejects + 1;

might.  Or it might be:

Current: Some_Record_Type renames 
shiftTally(shift)(dayOfWeek(month).tallyIndex).sortTally(s);
...
Current.nbRejects := Current.nbRejects + 1;

or it might be that the operation of incrementing the number of rejects 
gets wrapped in an (inlined) procedure.  It all depends on what makes 
the logic most visible.  In this case the question that jumps out once 
you have done the clean-up should be "Should the increment always be 1?" 
not "What is this mess?"

Re: Ideas for Ada 200X

[Russ]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB13CDB9.3516%yaldnifw@blueyonder.co.uk>...
> On 16/6/03 19:19, in article bcl1pu$jscm4$1@ID-175126.news.dfncis.de,
> "Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:
> 
> >>> How would you think about
> >>> i := () +1;
> >> 
> >> I would think: this looks very error-prone.
> >> I think any syntax for an "idem" feature should not easily result from a
> >> simple typographical error in writing a correct expression.
> > 
> > I'd say something similar to the the already proposed (or at least
> > mentioned) "<>" would be good enough for me.
> > 
> > Or perhaps we should think about a longer one to discourage people to
> > use it everywhere in their code. ;)
> 
> All the proposals so far have their problems:
> 
>    idem (or any new reserved word)  but: a new reserved word
>    all                              but: could be a typo for "p.all"
>    <>                               but: consider "<> < <>+1"
>    &                                but: consider "& & &"
>    @ (or # or ? or $ or %)          but: wrong associations?
> 
> Despite the possibility of suggesting wrong associations, I'm tending to one
> of the latter notations (this is about brevity after all), or perhaps "all".
> If " were not a string quote, it would be good, being used already as an
> abbreviation for 'ditto'. 8-)

If you must go with something other than "+=", I still like "@". As
far as I know, it is not currently used in Ada, and it seems natural
to me because it represents what's currently "at" the location that is
about to be overwritten.

Then again, I don't see how "@" can be used for efficient
vector/matrix procedures because it still requires an explicit
assignment. Unless the compiler can figure out an efficient way around
that, I still vote for "+=".

If you really insist that "+=" looks too much like ":=", then I think
":+=" or some such kludge is the next best thing, but darnit that's
ugly.

I'm trying, but I'm still having trouble seeing "+=" being confused
with ":=".

Re: Ideas for Ada 200X

[Preben Randhol]

Bill Findlay wrote:
> 
> What about Age'Dec(1); ?

hmm, well actually I find: Age'Inc(-1); more readable, but I don't
know...


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> If you really insist that "+=" looks too much like ":=", then I think
> ":+=" or some such kludge is the next best thing, but darnit that's
> ugly.

Yes it is ugly the way you wrote it, but +:= isn't. Remember that
assignment in Ada is := so one shouldn't seperate these two signs.

> I'm trying, but I'm still having trouble seeing "+=" being confused
> with ":=".

What about /= ? The problem is that += doesn't make sense in Ada as = is
not the assignment syntax := is.

-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X "left hand side" repeater.

[Dmitry A. Kazakov]

Chad R. Meiners wrote:

> Or how about
> 
> [Pixel] Screen.Buffer(i) := Pixel + 1;
> 
> where [Pixel] gives an idem name "Pixel" for Screen.Buffer(i) which can be
> used (in place of its variable) until it falls out of scope at the
> semi-colon.

Looks like a label. It could be:

<<Pixel>> Screen.Buffer(i) := Pixel + 1;

however, it gets a bit tricky:

<<Pixel>>
   Screen.Buffer(i) := Pixel + 1;
   ...
   Pixel := Pixel + 1; -- Illegal, Pixel is out of scope
   ...
   goto Pixel; -- OK

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

Re: Ideas for Ada 200X "left hand side" repeater.

[Chad R. Meiners]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:bcminn$kof9m$1@ID-77047.news.dfncis.de...
> Looks like a label. It could be:
>
> <<Pixel>> Screen.Buffer(i) := Pixel + 1;

It was inspired by the label, but I definitely did not want to overload the
label; hence, the []'s instead of <<>>'s

> however, it gets a bit tricky:
>
> <<Pixel>>
>    Screen.Buffer(i) := Pixel + 1;
>    ...
>    Pixel := Pixel + 1; -- Illegal, Pixel is out of scope
>    ...
>    goto Pixel; -- OK

Of course that could look like
<<Write_ith_Pixel>>
  [Pixel] Screen.Buffer(i) := Pixel + 1;
 ...
 Pixel := Pixel + 1; -- Illegal, Pixel is out of scope
 ...
 goto Write_ith_Pixel; -- OK

which appears to me to have a nice balance of verbosity and conciseness.

-CRM

Re: Ideas for Ada 200X "left hand side" repeater.

[Bill Findlay]

On 17/6/03 01:30, in article bclnfn$1ga0$1@msunews.cl.msu.edu, "Chad R.
Meiners" <crmeiners@hotmail.com> wrote:

> Or how about
> 
> [Pixel] Screen.Buffer(i) := Pixel + 1;
> 
> where [Pixel] gives an idem name "Pixel" for Screen.Buffer(i) which can be
> used (in place of its variable) until it falls out of scope at the
> semi-colon.

What about using 'is' to express identity? e.g.:

   Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;

It's not exactly concise, though. Nor is any 'implicit renaming' solution.

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

Re: Ideas for Ada 200X

[Georg Bauhaus]

Vinzent Hoefler <ada.rocks@jlfencey.com> wrote:
: Bill Findlay wrote:
: 
: [history of Idem]
:>Only when one is speaking Latin.
:>When I speak, it is Middle English. 8-)
: 
: Ok. You won. ;)

Wait. There is idem, eadem, idem, English: the very same.
Then there is item: English: likewise.
AFAICT.
See also Words by William Whitaker, which is an Ada program.
http://users.erols.com/whitaker/words.htm
or
http://www.nd.edu/~archives/latin.htm

I remember a US American asking me about a hotel
"zoom reader" in Heidelberg. Back then, I had no
idea to which hotel he was referring. It
is written "Zum Ritter". So much for the letters
d and tt even today ;-)

Georg

Re: Ideas for Ada 200X "left hand side" repeater.

[Bill Findlay]

On 17/6/03 11:59, in article BB14B31A.35B6%yaldnifw@blueyonder.co.uk, "Bill
Findlay" <yaldnifw@blueyonder.co.uk> wrote:

> On 17/6/03 01:30, in article bclnfn$1ga0$1@msunews.cl.msu.edu, "Chad R.
> Meiners" <crmeiners@hotmail.com> wrote:
> 
>> Or how about
>> 
>> [Pixel] Screen.Buffer(i) := Pixel + 1;
>> 
>> where [Pixel] gives an idem name "Pixel" for Screen.Buffer(i) which can be
>> used (in place of its variable) until it falls out of scope at the
>> semi-colon.
> 
> What about using 'is' to express identity? e.g.:
> 
>  Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;
> 
> It's not exactly concise, though. Nor is any 'implicit renaming' solution.

However, it does generalize, to, e.g.:

   V is A_Variable in Perform_Operations_On(V);

The form:

  Screen.Buffer(i) is Pixel := Pixel + 1;

is snappier, but does not read quite so well and does not generalize.

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

Re: Ideas for Ada 200X "left hand side" repeater.

[Preben Randhol]

Bill Findlay wrote:
> The form:
> 
>   Screen.Buffer(i) is Pixel := Pixel + 1;
> 
> is snappier, but does not read quite so well and does not generalize.

It doesn't read.

Why not use : renames


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X "left hand side" repeater.

[Bill Findlay]

On 17/6/03 14:38, in article
slrnbeu6cp.clr.randhol+abuse@kiuk0152.chembio.ntnu.no, "Preben Randhol"
<randhol+abuse@pvv.org> wrote:

> Bill Findlay wrote:
>> The form:
>>   Screen.Buffer(i) is Pixel := Pixel + 1;
>> is snappier, but does not read quite so well and does not generalize.
> 
> It doesn't read.
> 
> Why not use : renames

If you mean:

   Pixel renames Screen.Buffer(i) in Pixel := Pixel + 1;

Or anything like that, then:

1. It is less concise than 'is'.

2. More importantly, renaming declarations do not have all the necessary
functionality and using renames for a different purpose, such as the above,
would be inconsistent.

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

Re: Ideas for Ada 200X "left hand side" repeater.

[Preben Randhol]

Bill Findlay wrote:
> If you mean:
> 
>    Pixel renames Screen.Buffer(i) in Pixel := Pixel + 1;
> 

> Or anything like that, then:
> 
> 1. It is less concise than 'is'.

I don't think so as renames already is used in this way.

If one use "is" I would have thought :

   Screen.Buffer(i) is Pixel in Pixel := Pixel + 1;

but perhaps this is because of that Norwegian is my language and English
only the second?

> 2. More importantly, renaming declarations do not have all the necessary
> functionality and using renames for a different purpose, such as the above,
> would be inconsistent.

That is however true.


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X "left hand side" repeater.

[Francisco Javier Loma Daza]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB14B31A.35B6%yaldnifw@blueyonder.co.uk>...
> On 17/6/03 01:30, in article bclnfn$1ga0$1@msunews.cl.msu.edu, "Chad R.
> Meiners" <crmeiners@hotmail.com> wrote:
> 
> > Or how about
> > 
> > [Pixel] Screen.Buffer(i) := Pixel + 1;
> > 
> > where [Pixel] gives an idem name "Pixel" for Screen.Buffer(i) which can be
> > used (in place of its variable) until it falls out of scope at the
> > semi-colon.
> 
> What about using 'is' to express identity? e.g.:
> 
>    Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;
> 
> It's not exactly concise, though. Nor is any 'implicit renaming' solution.

Another proposal, maybe only useful for some cases, where you don't
want to reevaluate the LHS because it's side effects. For example:

    declare
       -- can't do with a rename clause because of side effets
       item : access Object := item(iterator => it);
    begin
       item.data1 := some_function(item.data2, item.data3);
    end;    

could be like

    item(iterator => it).data1 := some_function(item'LHS.data2, 
                                                item'LHS.data3);

Re: Ideas for Ada 200X "left hand side" repeater.

[Wesley Groleau]

> If one use "is" I would have thought :
> 
>    Screen.Buffer(i) is Pixel in Pixel := Pixel + 1;
> 
> but perhaps this is because of that Norwegian is my language and English
> only the second?

Actually, if one wants to emulate English,

    Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;

would be semantically better.

But it seems to me that renames covers all the "wishes"
so far except two.  And it adds two:

1. With a declare block, one can give the new name as big
    or as small a scope as needed.

2. The new name can be something that logically suits
    the scope it's given.

The two that are not covered:

1. The wish to trim the number of keystrokes to
    an absolute minimum.  As most of us know, that
    is NOT a concern of an Ada fan.

2. The wish to avoid temporaries for a more efficient
    construct.  As has already been said more than once,
    this is a red herring.  It can avoid temporaries
    ONLY if doing so would not break any other language
    rules.  And there is (obviously) no language rule
    requiring the current construct to be less efficient
    than the new one.

3. One point in favor of the new construct is that if
    evaluation had side effects, they would occur once
    instead of twice.  But in that case, instead of
    renames, one would use an initialized variable
    (and copy-back or write-through) or an in out parameter.

Re: Ideas for Ada 200X "left hand side" repeater.

[Bill Findlay]

On 17/6/03 17:59, in article e_GdnRh0ovFS1XKjXTWJkg@gbronline.com, "Wesley
Groleau" <wesgroleau@despammed.com> wrote:

> But it seems to me that renames covers all the "wishes"
> so far except two.  And it adds two:

Sorry Wes, but that is not the case.

I've posted the following twice before, but here goes again:

> As I see it there are several arguments in favour of the 'idem' proposal:
> 
> 1. It lets the programmer indicate that the occurrences of the LHS in the RHS
> are *necessarily* the same, and not contingently so, which makes the code more
> self-documenting.

(Renaming does not achieve that.)

> 2. It removes a source of error in transcribing the LHS multiple times.

(A tie.)

> 3. It allows more concisely readable code when the LHS is lengthy.

(Renaming certainly does not achieve that - it requires me to write a block
to 'simplify' an expression.)

> 4. It provides functionality that it only partially available by means of much
> clumsier renaming declarations, because not all objects can be renamed.

(Obviously, renaming does not achieve that.)

> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
> that lvalue as often as needed to evaluate the RHS. This has three potential
> benefits: shorter code, faster execution, and once-only invocation of any side
> effects.

(A tie.)

> 6. It might make it somewhat easier for the compiler to generate
> update-in-place object code, where the target architecture allows that and
> where it offers a performance advantage.

(A tie?)
 
> 7. It provides all the utility of C's multitude of combined assignment
> operators with one small, compatible change to the syntax of operands.
> (I specify C, rather than C++, to avoid getting into a argument about
> overloading assignment).

(A semantic tie, but renaming is tediously verbose for this purpose.)

> 8. It allows the expression of useful forms that C's combined assignment
> operators cannot achieve (e.g. X := 1 - idem;).

(A semantic tie, but renaming is tediously verbose for this purpose.)

My personal focus is on points 1 and 3; but I see benefits in heading off
+:= and the like (points 7, 8). Renaming simply does not meet these needs.
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Ideas for Ada 200X

[Russ]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbetjlg.ki.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Russ wrote:
> > If you really insist that "+=" looks too much like ":=", then I think
> > ":+=" or some such kludge is the next best thing, but darnit that's
> > ugly.
> 
> Yes it is ugly the way you wrote it, but +:= isn't. Remember that
> assignment in Ada is := so one shouldn't seperate these two signs.

I think "+:=" is ugly too, but if it does the job I can get used to
it.

> > I'm trying, but I'm still having trouble seeing "+=" being confused
> > with ":=".
> 
> What about /= ? The problem is that += doesn't make sense in Ada as = is
> not the assignment syntax := is.

Yes, that is a problem, isn't it. I am tempted to suggest that /=
isn't really needed because you can always take a reciprical and use
*=. But that would be slightly less efficient and, worse, the notation
would be inconsistent. So I guess /:= will do the job.

Re: Ideas for Ada 200X "left hand side" repeater.

[Chad R. Meiners]

"Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
news:BB14D345.35C8%yaldnifw@blueyonder.co.uk...
>>
> > What about using 'is' to express identity? e.g.:
> >
> >  Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;

I think I like this.

> > It's not exactly concise, though. Nor is any 'implicit renaming'
solution.

Perhaps simplified is a better description because it allows the written
format to enhance readability.

Pixel is Screen.Buffer(i) in
    Pixel := Pixel + 1;

It also separates the dual concerns of naming complex expression and having
clear statements while keeping the names in sight of each other. Perhaps the
above sample is too simple how about

Pixel is Screen.Buffer(i) in
    Pixel := To_Red(Get_Green(Pixel)) + To_Green(Get_Blue(Pixel)) +
To_Blue(Get_Red(Pixel));

versus

declare
    Pixel : Buffer_Element renames Screen.Buffer(i);
    Red   : constant Scale := Get_Red(Pixel);
    Green : constant Scale := Get_Green(Pixel);
    Blue  : constant Scale := Get_Blue(Pixel);
begin
    Pixel := To_Red(Green) +  To_Green(Blue) + To_Blue(Red);
end;

or

Screen.Buffer(i) := To_Red(Get_Green(Screen.Buffer(i))) +
                               To_Green(Get_Blue(Screen.Buffer(i))) +
                               To_Blue(Get_Red(Screen.Buffer(i)));

> However, it does generalize, to, e.g.:
>
>    V is A_Variable in Perform_Operations_On(V);

This too I like.

Re: Ideas for Ada 200X

[Russ]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbetjlg.ki.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Russ wrote:
> > If you really insist that "+=" looks too much like ":=", then I think
> > ":+=" or some such kludge is the next best thing, but darnit that's
> > ugly.
> 
> Yes it is ugly the way you wrote it, but +:= isn't. Remember that
> assignment in Ada is := so one shouldn't seperate these two signs.
> 
> > I'm trying, but I'm still having trouble seeing "+=" being confused
> > with ":=".
> 
> What about /= ? The problem is that += doesn't make sense in Ada as = is
> not the assignment syntax := is.

An interesting idea just popped into my head. We've considered "+="
and "+:=", but what about ":+"? Check it out:

    count :+ 1
    A :+ B
    var :/ 2.0

Simple, clear, only two characters, and no conflict with "/=". What do
you think?

Re: Ideas for Ada 200X

[Bill Findlay]

On 17/6/03 23:20, in article
bebbba07.0306171420.2a6cb3d0@posting.google.com, "Russ"
<18k11tm001@sneakemail.com> wrote:
> An interesting idea just popped into my head. We've considered "+="
> and "+:=", but what about ":+"? Check it out:
> 
>   count :+ 1
>   A :+ B
>   var :/ 2.0
> 
> Simple, clear, only two characters, and no conflict with "/=". What do
> you think?

Consider:

   a, b : Boolean;
   --
   a := a = b;
   a := b; -- ??

What would that mean?

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

Re: Ideas for Ada 200X

[Vinzent Hoefler]

Georg Bauhaus wrote:

>I remember a US American asking me about a hotel
>"zoom reader" in Heidelberg. Back then, I had no
>idea to which hotel he was referring. It
>is written "Zum Ritter". So much for the letters
>d and tt even today ;-)

You made my day. :)


Vinzent.

Re: Ideas for Ada 200X "left hand side" repeater.

[Preben Randhol]

Wesley Groleau wrote:
> 
>> If one use "is" I would have thought :
>> 
>>    Screen.Buffer(i) is Pixel in Pixel := Pixel + 1;
>> 
>> but perhaps this is because of that Norwegian is my language and English
>> only the second?
> 
> Actually, if one wants to emulate English,
> 
>     Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;
> 
> would be semantically better.

OK. I was thinking more like: 

   Wesley Groleau is Hamlet in Shakespear's Hamlet.

   and not

   Hamlet is Wesley Groleau in Shakespear's Hamlet.

(Of course one could/should add "playing" and "played by" respectively)

-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X "left hand side" repeater.

[Preben Randhol]

Bill Findlay wrote:
> On 17/6/03 17:59, in article e_GdnRh0ovFS1XKjXTWJkg@gbronline.com, "Wesley
> Groleau" <wesgroleau@despammed.com> wrote:
> 
>> But it seems to me that renames covers all the "wishes"
>> so far except two.  And it adds two:
>> 
>> 1. It lets the programmer indicate that the occurrences of the LHS in the RHS
>> are *necessarily* the same, and not contingently so, which makes the code more
>> self-documenting.
> 
> (Renaming does not achieve that.)

Why doesn't it?

>> 3. It allows more concisely readable code when the LHS is lengthy.
> 
> (Renaming certainly does not achieve that - it requires me to write a block
> to 'simplify' an expression.)

Currently yes, but it doesn't need to.

Preben
-- 
This is Ada95 land. On quiet nights you can hear C programmers debug.

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> 
> I think "+:=" is ugly too, but if it does the job I can get used to
> it.

Well I think C++'s += is ugly in the first place :-)

> Yes, that is a problem, isn't it. I am tempted to suggest that /=
> isn't really needed because you can always take a reciprical and use

No you cannot always do a reciprical without running into rounding
problems. Consider reduction of a matrix.

> *=. But that would be slightly less efficient and, worse, the notation
> would be inconsistent. So I guess /:= will do the job.

How many programmers do you think that wouldn't do:

   A /= B;

and then when the compiler complains they tear their hair out saying why
why why?

   or they are trying to reuse some old code:

      if A /= B then

   and say "Hey! There is bug here."


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Preben Randhol]

Russ wrote:
> Simple, clear, only two characters, and no conflict with "/=". What do
> you think?

No I don't find :+ so clear. It is harder to read as it lacks the :=.
But I find it hopeless to try find a syntax which saves off *one*
whitespace for a 3 whitespace syntax. If you really need to type less
and your editor cannot help you get a better editor.

I use vim and I can do:

   proc<TAB> and it write procedure for me and if I write

   Some_Long_Variable := Some<TAB> it will write Some_Long_Variable or
   give me a chance to cycle through alternatives.

So typing becomes less troublesome. Besides at the moment I'm testing my
Ada macros for Vim which would make it possible for me to write:

   #proc

and then the editor asks me for a procedure name and gives me:

   procedure Some_Name
   is
      
   begin
      <++>
   end Some_Name;

(Where <++> is a point you can jump to by hitting Ctrl-J (<++> is then
removed automatically))


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Preben Randhol]

Preben Randhol wrote:
> Russ wrote:
>> Simple, clear, only two characters, and no conflict with "/=". What do
>> you think?
> 
> No I don't find :+ so clear. It is harder to read as it lacks the :=.
> But I find it hopeless to try find a syntax which saves off *one*
> whitespace for a 3 whitespace syntax.

Arg. The coffee hasn't kicked inn yet I see:

But I find it hopeless to try find a syntax which _shaves_ off *one*
whitespace from a 3 whitespace syntax.

Preben
-- 
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

Re: Ideas for Ada 200X "left hand side" repeater.

[Bill Findlay]

On 18/6/03 08:52, in article
slrnbf06g4.qo.randhol+abuse@kiuk0152.chembio.ntnu.no, "Preben Randhol"
<randhol+abuse@pvv.org> wrote:

>>> 1. [idem[ lets the programmer indicate that the occurrences of the LHS in
>>> the are *necessarily* the same, and not contingently so, which makes the
>>> code more self-documenting.
>> 
>> (Renaming does not achieve that.)
> 
> Why doesn't it?

It is not clear whether the RHS X in X := X + 1; is *essentially* the same
as the LHS X, or contingently so. This logical ambiguity is unaffected by
whether X is introduced by an object declaration or by a renaming.
Idem notation makes the intention crystal-clear.

>>> 3. It allows more concisely readable code when the LHS is lengthy.
>> 
>> (Renaming certainly does not achieve that - it requires me to write a block
>> to 'simplify' an expression.)
> 
> Currently yes, but it doesn't need to.

Could you expand on that?

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

Re: Ideas for Ada 200X

[Alexander Kopilovitch]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB13CDB9.3516%yaldnifw@blueyonder.co.uk>...
>All the proposals so far have their problems:
>
>   idem (or any new reserved word)  but: a new reserved word
>   all                              but: could be a typo for "p.all"
>   <>                               but: consider "<> < <>+1"
>   &                                but: consider "& & &"
>   @ (or # or ? or $ or %)          but: wrong associations?

Here is yet another one: use "~" (Ada.Characters.Latin_1.Tilde). "waver",
but not alone - either double it or use it in conjunction with left-side
identifier (but do not mix these variants in the same statement; also do not
mix them with oriiginal left-side identifier). For example:

  X := ~~ + A;

  X := ~X + A;

  X := ~X + ~~; -- illegal

  X := ~X + X;  -- illegal

  X := ~~ + X;  -- illegal



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

Re: Ideas for Ada 200X

[Brian Gaffney]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0306171420.2a6cb3d0@posting.google.com>...
> Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbetjlg.ki.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> > Russ wrote:
> > > If you really insist that "+=" looks too much like ":=", then I think
> > > ":+=" or some such kludge is the next best thing, but darnit that's
> > > ugly.
> > 
> > Yes it is ugly the way you wrote it, but +:= isn't. Remember that
> > assignment in Ada is := so one shouldn't seperate these two signs.
> > 
> > > I'm trying, but I'm still having trouble seeing "+=" being confused
> > > with ":=".
> > 
> > What about /= ? The problem is that += doesn't make sense in Ada as = is
> > not the assignment syntax := is.
> 
> An interesting idea just popped into my head. We've considered "+="
> and "+:=", but what about ":+"? Check it out:
> 
>     count :+ 1
>     A :+ B
>     var :/ 2.0
> 
> Simple, clear, only two characters, and no conflict with "/=". What do
> you think?

Let me start by saying that I can't believe I'm adding to this thread.
 I really don't see that any of this would be an improvement.

Having said that, let me make my proposal on how to fix this 'problem'
without creating new keywords or operators:  Create procedures such as
the following for the various operators and various types, along with
the existing functions.

   procedure "+" (Left : in out Integer; Right : in Integer);

That way we could have:

   begin
      I := I + 1;
      I + 1;        --equivalent
   end;

{BTW, would that lead to this:  
   procedure "+" (Right : in out Integer);   --the same as i++
?}

Again, let me emphasize that I'm not suggesting this should become
part of Ada!

                   --Brian

Re: Ideas for Ada 200X

[Russ]

Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote in message news:<5e9b8c34.0306181050.3c4cc664@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0306171420.2a6cb3d0@posting.google.com>...
> > Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbetjlg.ki.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> > > Russ wrote:
> > > > If you really insist that "+=" looks too much like ":=", then I think
> > > > ":+=" or some such kludge is the next best thing, but darnit that's
> > > > ugly.
> > > 
> > > Yes it is ugly the way you wrote it, but +:= isn't. Remember that
> > > assignment in Ada is := so one shouldn't seperate these two signs.
> > > 
> > > > I'm trying, but I'm still having trouble seeing "+=" being confused
> > > > with ":=".
> > > 
> > > What about /= ? The problem is that += doesn't make sense in Ada as = is
> > > not the assignment syntax := is.
> > 
> > An interesting idea just popped into my head. We've considered "+="
> > and "+:=", but what about ":+"? Check it out:
> > 
> >     count :+ 1
> >     A :+ B
> >     var :/ 2.0
> > 
> > Simple, clear, only two characters, and no conflict with "/=". What do
> > you think?
> 
> Let me start by saying that I can't believe I'm adding to this thread.
>  I really don't see that any of this would be an improvement.
> 
> Having said that, let me make my proposal on how to fix this 'problem'
> without creating new keywords or operators:  Create procedures such as
> the following for the various operators and various types, along with
> the existing functions.
> 
>    procedure "+" (Left : in out Integer; Right : in Integer);
> 
> That way we could have:
> 
>    begin
>       I := I + 1;
>       I + 1;        --equivalent
>    end;
> 
> {BTW, would that lead to this:  
>    procedure "+" (Right : in out Integer);   --the same as i++
> ?}
> 
> Again, let me emphasize that I'm not suggesting this should become
> part of Ada!
> 
>                    --Brian

"+" is a function that returns the sum of its two arguments without
modifying either of those arguments. How could it also be a procedure
that modifies one of its arguments? You think the same symbol taking
the same argument types can be used for both a procedure and a
function? It's no wonder you put the word "problem" in quotes: you
don't understand the problem.

Re: Ideas for Ada 200X "left hand side" repeater.

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Wed, 18 Jun 2003 17:30:16 -0500 (CDT)
NNTP-Posting-Host: !](H71k-X>o5Ee< (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:bcnvrr$mdg$1@msunews.cl.msu.edu...
>
> "Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
> news:BB14D345.35C8%yaldnifw@blueyonder.co.uk...
> >>
> > > What about using 'is' to express identity? e.g.:
> > >
> > >  Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;
>
> I think I like this.
>
> > > It's not exactly concise, though. Nor is any 'implicit renaming'
> solution.
>
> Perhaps simplified is a better description because it allows the written
> format to enhance readability.
>
> Pixel is Screen.Buffer(i) in
>     Pixel := Pixel + 1;
>
> It also separates the dual concerns of naming complex expression and
having
> clear statements while keeping the names in sight of each other. Perhaps
the
> above sample is too simple how about
>
> Pixel is Screen.Buffer(i) in
>     Pixel := To_Red(Get_Green(Pixel)) + To_Green(Get_Blue(Pixel)) +
> To_Blue(Get_Red(Pixel));
>
> versus
>
> declare
>     Pixel : Buffer_Element renames Screen.Buffer(i);
>     Red   : constant Scale := Get_Red(Pixel);
>     Green : constant Scale := Get_Green(Pixel);
>     Blue  : constant Scale := Get_Blue(Pixel);
> begin
>     Pixel := To_Red(Green) +  To_Green(Blue) + To_Blue(Red);
> end;
>
> or
>
> Screen.Buffer(i) := To_Red(Get_Green(Screen.Buffer(i))) +
>                                To_Green(Get_Blue(Screen.Buffer(i))) +
>                                To_Blue(Get_Red(Screen.Buffer(i)));

Maybe I'm just weird, but I happen to think that
    declare
      Pixel : Buffer_Element renames Screen.Buffer(i);
    begin
      Pixel :=
        To_Red(Get_Green(Pixel)) +
        To_Green(Get_Blue(Pixel)) +
        To_Blue(Get_Red(Pixel));
    end;
is about right.

Further, more to the point, your concept
  <id> is <lhs-expr> in <statement>
is unbracketed.  This is explicitly contrary to Ada practice.

Ada has EVERYWHERE ELSE eschewed single-statement scope limits, preferring
explicitly-bracketed scope instead.  In C, one writes

    if (condition) statement;
    while (condition) statement;
    do statement while (condition);

In PASCAL, one writes:

    if condition then statement else statement;
    while condition do statement;

(In PASCAL, repeat-until is the exception.)

In both of these languages, one frequently gets trampled by the bugs when
one needs to add a second statement to the activity.

By contrast, Ada in all cases intentionally brackets the statement bodies:

    if condition then
      statement;
      [statement; statement;]
    end if;

    while condition loop
      statement;
      [statement; statement;]
    end loop;

One would expect that any such construct as yours should use explicit
bracketing, rather than implicitly bracket to one statement.

Now consider:

    declare
      Pixel : Buffer_Element renames Screen.Buffer(i);
    begin
      Pixel.Color :=
        To_Red(Get_Green(Pixel.Color)) +
        To_Green(Get_Blue(Pixel.Color)) +
        To_Blue(Get_Red(Pixel.Color));
      Pixel.Highlight := 255 - Pixel.Highlight;
    end;

vs. your

      Pixel is Screen.Buffer(i) in
        Pixel.Color :=
          To_Red(Get_Green(Pixel.Color)) +
          To_Green(Get_Blue(Pixel.Color)) +
          To_Blue(Get_Red(Pixel.Color));

      Pixel is Screen.Buffer(i) in
        Pixel.Highlight := 255 - Pixel.Highlight;

This is precisely the kind of thing that Ada design specifically attempts to
avoid.

Re: Ideas for Ada 200X "left hand side" repeater.

[Chad R. Meiners]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:bcqp5o$coi@library2.airnews.net...
>
> Maybe I'm just weird, but I happen to think that
>     declare
>       Pixel : Buffer_Element renames Screen.Buffer(i);
>     begin
>       Pixel :=
>         To_Red(Get_Green(Pixel)) +
>         To_Green(Get_Blue(Pixel)) +
>         To_Blue(Get_Red(Pixel));
>     end;
> is about right.

I would definitely agree given that more than one variable needs to be
declared, exception handling is needed or more than one assignment needs to
be made.  However for one 'rename' with one assignment statement, I have
always found a block statement annoying.

> Further, more to the point, your concept
>   <id> is <lhs-expr> in <statement>
> is unbracketed.  This is explicitly contrary to Ada practice.

Actually the concept is more like
<id> is <variable_name> in <assignment_statement>

> Ada has EVERYWHERE ELSE eschewed single-statement scope limits, preferring
> explicitly-bracketed scope instead.

Scope is ended by the semicolon like many other constructs in Ada.

>In C, one writes

Irrelevant, the form explicitly forbids multiple statements hence the
<id> is <variable_name> in <assignment_statement>
                                                           ^
                                                     an assignment statment
NOT a statement

> One would expect that any such construct as yours should use explicit
> bracketing, rather than implicitly bracket to one statement.

There is no bracketing.  The id is only for the single statement by form.

> Now consider:
>
>     declare
>       Pixel : Buffer_Element renames Screen.Buffer(i);
>     begin
>       Pixel.Color :=
>         To_Red(Get_Green(Pixel.Color)) +
>         To_Green(Get_Blue(Pixel.Color)) +
>         To_Blue(Get_Red(Pixel.Color));
>       Pixel.Highlight := 255 - Pixel.Highlight;
>     end;

Related multiple statements do deserve a block.

> vs. your
>
>       Pixel is Screen.Buffer(i) in
>         Pixel.Color :=
>           To_Red(Get_Green(Pixel.Color)) +
>           To_Green(Get_Blue(Pixel.Color)) +
>           To_Blue(Get_Red(Pixel.Color));
>
>       Pixel is Screen.Buffer(i) in
>         Pixel.Highlight := 255 - Pixel.Highlight;

First let us fix the example

Color is Screen.Buffer(i).Color in
    Color := To_Red(Get_Green(Color)) +
                   To_Green(Get_Blue(Color)) +
                   To_Blue(Get_Red(Color));

Highlight is Screen.Buffer(i).Highlight in
    Highlight := 255 - Highlight;

or

Pixel is Screen.Buffer(i) in
    Pixel := (Color => To_Red(Get_Green(Pixel.Color)) +
                                   To_Green(Get_Blue(Pixel.Color)) +
                                  To_Blue(Get_Red(Pixel.Color)),
                    Highlight => 255 - Pixel.Highlight
                  );

The idea was to simplify certain assignment statements; the syntax should
not be used as a replacement of blocks.  It does not make sense to use
multiple renamed assignment statement for the same variable name.  The block
statement will win out in that case.

I was suggesting an alternative syntax for the

Var := {} + 1;

suggestion in the hopes that if someone wanted to suggest such an addition
to the language that it would encourage a readable syntax in that
suggestion.

Re: Ideas for Ada 200X

[Amir Yantimirov]

aek@vib.usr.pu.ru (Alexander Kopilovitch) wrote in message news:<e2e5731a.0306180700.61b2575f@posting.google.com>...
> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB13CDB9.3516%yaldnifw@blueyonder.co.uk>...
> >All the proposals so far have their problems:
> >
> >   idem (or any new reserved word)  but: a new reserved word
> >   all                              but: could be a typo for "p.all"
> >   <>                               but: consider "<> < <>+1"
> >   &                                but: consider "& & &"
> >   @ (or # or ? or $ or %)          but: wrong associations?
> 
> Here is yet another one: use "~" (Ada.Characters.Latin_1.Tilde). "waver",
> but not alone - either double it or use it in conjunction with left-side
> identifier (but do not mix these variants in the same statement; also do not
> mix them with oriiginal left-side identifier). For example:
> 
>   X := ~~ + A;
> 
>   X := ~X + A;
> 
>   X := ~X + ~~; -- illegal
> 
>   X := ~X + X;  -- illegal
> 
>   X := ~~ + X;  -- illegal
> 
> 
> 
> Alexander Kopilovitch                      aek@vib.usr.pu.ru
> Saint-Petersburg
> Russia

While not omit := at all and use postfix operator in expression:

    X# + A;
    min ( X#, 0 );
    X# + # * 2;
    X#.Next;

Er, too C-ish. (Or C#-ish ?) Then so:

    idem(X) + A;
    min ( idem(X), 0);
    idem( X ) + idem * 2;
    idem( X ).Next;
?

http://www174.pair.com/yamir/programming/syntax.htm
Amir Yantimirov

Re: Ideas for Ada 200X

[Russ]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB15569B.3614%yaldnifw@blueyonder.co.uk>...
> On 17/6/03 23:20, in article
> bebbba07.0306171420.2a6cb3d0@posting.google.com, "Russ"
> <18k11tm001@sneakemail.com> wrote:
> > An interesting idea just popped into my head. We've considered "+="
> > and "+:=", but what about ":+"? Check it out:
> > 
> >   count :+ 1
> >   A :+ B
> >   var :/ 2.0
> > 
> > Simple, clear, only two characters, and no conflict with "/=". What do
> > you think?
> 
> Consider:
> 
>    a, b : Boolean;
>    --
>    a := a = b;
>    a := b; -- ??
> 
> What would that mean?

It would mean the same thing it means now. I don't see how this has
anything to do with what I proposed. Am I missing something?

Re: Ideas for Ada 200X "left hand side" repeater.

[Wesley Groleau]

>>    Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;
>>
>>would be semantically better.
> 
> OK. I was thinking more like: 
> 
>    Wesley Groleau is Hamlet in Shakespear's Hamlet.
> 
>    and not
> 
>    Hamlet is Wesley Groleau in Shakespear's Hamlet.

Hmmm.  It does make sense that way.  Perhaps the ambiguity
is an argument against it.  :-)

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Russ wrote:

> Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote in message
> news:<5e9b8c34.0306181050.3c4cc664@posting.google.com>...
>> 18k11tm001@sneakemail.com (Russ) wrote in message
>> news:<bebbba07.0306171420.2a6cb3d0@posting.google.com>...
>> > Preben Randhol <randhol+abuse@pvv.org> wrote in message
>> > news:<slrnbetjlg.ki.randhol+abuse@kiuk0152.chembio.ntnu.no>...
>> > > Russ wrote:
>> > > > If you really insist that "+=" looks too much like ":=", then I
>> > > > think ":+=" or some such kludge is the next best thing, but darnit
>> > > > that's ugly.
>> > > 
>> > > Yes it is ugly the way you wrote it, but +:= isn't. Remember that
>> > > assignment in Ada is := so one shouldn't seperate these two signs.
>> > > 
>> > > > I'm trying, but I'm still having trouble seeing "+=" being confused
>> > > > with ":=".
>> > > 
>> > > What about /= ? The problem is that += doesn't make sense in Ada as =
>> > > is not the assignment syntax := is.
>> > 
>> > An interesting idea just popped into my head. We've considered "+="
>> > and "+:=", but what about ":+"? Check it out:
>> > 
>> >     count :+ 1
>> >     A :+ B
>> >     var :/ 2.0
>> > 
>> > Simple, clear, only two characters, and no conflict with "/=". What do
>> > you think?
>> 
>> Let me start by saying that I can't believe I'm adding to this thread.
>>  I really don't see that any of this would be an improvement.
>> 
>> Having said that, let me make my proposal on how to fix this 'problem'
>> without creating new keywords or operators:  Create procedures such as
>> the following for the various operators and various types, along with
>> the existing functions.
>> 
>>    procedure "+" (Left : in out Integer; Right : in Integer);
>> 
>> That way we could have:
>> 
>>    begin
>>       I := I + 1;
>>       I + 1;        --equivalent
>>    end;
>> 
>> {BTW, would that lead to this:
>>    procedure "+" (Right : in out Integer);   --the same as i++
>> ?}
>> 
>> Again, let me emphasize that I'm not suggesting this should become
>> part of Ada!
>> 
>>                    --Brian
> 
> "+" is a function that returns the sum of its two arguments without
> modifying either of those arguments.

"+" is a sequence of characters. Period.

> How could it also be a procedure
> that modifies one of its arguments?

That thing is called overloading. BTW, see my example below for a procedure, 
which does *not* modify any of its arguments.

> You think the same symbol taking
> the same argument types can be used for both a procedure and a
> function?

You forgot the result type, which makes the parameter profiles different.

---

I also made this proposal before, so let me now critisize it a bit. What 
about

A + B + C;

where:

type C_Type is ...;
type A_Type is access all C_Type;
type B_Type is new Integer;
...
function "+" (Addr : A_Type; Offs : B_Type) return A_Type;
procedure "+" (Addr : A_Type; Value : C_Type);

So the above means would mean: add C at A plus offset B. That damned C 
again! (:-))

Or:

procedure "=" (L : in out Integer; R : Integer);
...
X = 1;

This would make people really happy! (:-))

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

Re: Ideas for Ada 200X "left hand side" repeater.

[Preben Randhol]

Wesley Groleau wrote:
> 
>>>    Pixel is Screen.Buffer(i) in Pixel := Pixel + 1;
>>>
>>>would be semantically better.
>> 
>> OK. I was thinking more like: 
>> 
>>    Wesley Groleau is Hamlet in Shakespear's Hamlet.
>> 
>>    and not
>> 
>>    Hamlet is Wesley Groleau in Shakespear's Hamlet.
> 
> Hmmm.  It does make sense that way.  Perhaps the ambiguity
> is an argument against it.  :-)

I would think so :-)


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Preben Randhol]

Amir Yantimirov wrote:
> While not omit := at all and use postfix operator in expression:
> 
>     X# + A;
>     min ( X#, 0 );
>     X# + # * 2;
>     X#.Next;
> 
> Er, too C-ish. (Or C#-ish ?) Then so:

I don't know. I only know that I don't understand one of the lines
above. What are they supposed to express?


-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X "left hand side" repeater.

[Chad R. Meiners]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbf3anv.hi.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Wesley Groleau wrote:
> >
> > Hmmm.  It does make sense that way.  Perhaps the ambiguity
> > is an argument against it.  :-)
>
> I would think so :-)
>

So back to

[Pixel] Screen.Buffer(i) := Pixel + 1;

? ;-)

Re: Ideas for Ada 200X

[Russ]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<bcrpc1$mi00f$1@ID-77047.news.dfncis.de>...
> Russ wrote:
> 
> > Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote in message
> > news:<5e9b8c34.0306181050.3c4cc664@posting.google.com>...
> >> 18k11tm001@sneakemail.com (Russ) wrote in message
> >> news:<bebbba07.0306171420.2a6cb3d0@posting.google.com>...
> >> > Preben Randhol <randhol+abuse@pvv.org> wrote in message
> >> > news:<slrnbetjlg.ki.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> >> > > Russ wrote:
> >> > > > If you really insist that "+=" looks too much like ":=", then I
> >> > > > think ":+=" or some such kludge is the next best thing, but darnit
> >> > > > that's ugly.
> >> > > 
> >> > > Yes it is ugly the way you wrote it, but +:= isn't. Remember that
> >> > > assignment in Ada is := so one shouldn't seperate these two signs.
> >> > > 
> >> > > > I'm trying, but I'm still having trouble seeing "+=" being confused
> >> > > > with ":=".
> >> > > 
> >> > > What about /= ? The problem is that += doesn't make sense in Ada as =
> >> > > is not the assignment syntax := is.
> >> > 
> >> > An interesting idea just popped into my head. We've considered "+="
> >> > and "+:=", but what about ":+"? Check it out:
> >> > 
> >> >     count :+ 1
> >> >     A :+ B
> >> >     var :/ 2.0
> >> > 
> >> > Simple, clear, only two characters, and no conflict with "/=". What do
> >> > you think?
> >> 
> >> Let me start by saying that I can't believe I'm adding to this thread.
> >>  I really don't see that any of this would be an improvement.
> >> 
> >> Having said that, let me make my proposal on how to fix this 'problem'
> >> without creating new keywords or operators:  Create procedures such as
> >> the following for the various operators and various types, along with
> >> the existing functions.
> >> 
> >>    procedure "+" (Left : in out Integer; Right : in Integer);
> >> 
> >> That way we could have:
> >> 
> >>    begin
> >>       I := I + 1;
> >>       I + 1;        --equivalent
> >>    end;
> >> 
> >> {BTW, would that lead to this:
> >>    procedure "+" (Right : in out Integer);   --the same as i++
> >> ?}
> >> 
> >> Again, let me emphasize that I'm not suggesting this should become
> >> part of Ada!
> >> 
> >>                    --Brian
> > 
> > "+" is a function that returns the sum of its two arguments without
> > modifying either of those arguments.
> 
> "+" is a sequence of characters. Period.
> 
> > How could it also be a procedure
> > that modifies one of its arguments?
> 
> That thing is called overloading. BTW, see my example below for a procedure, 
> which does *not* modify any of its arguments.

If i := i + 1 is equivalent to i + 1, then what does

    i = i + j + 1

mean? Does j get incremented by 1? Either way, I'd say readability
went out the window.

Re: Ideas for Ada 200X

[Alexander Kopilovitch]

>All the proposals so far have their problems:
>
>   idem (or any new reserved word)  but: a new reserved word
>   all                              but: could be a typo for "p.all"
>   <>                               but: consider "<> < <>+1"
>   &                                but: consider "& & &"
>   @ (or # or ? or $ or %)          but: wrong associations?

In addition to yesterday's "~name or ~~" proposal, here is yet another one:
use triplet (*) - asterisk inside round brackets. This compound symbol is
quite different from others, and nicely associates with "focus".

  X := (*) + A;

  X := (*) + (*);



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

Re: Ideas for Ada 200X

[Brian Gaffney]

18k11tm001@sneakemail.com (Russ) wrote
> Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote
>> 
>>    procedure "+" (Left : in out Integer; Right : in Integer);
>> 
...
>
>"+" is a function that returns the sum of its two arguments without
>modifying either of those arguments. 
In _Ada95_, this is true [actually, to be accurate, in Ada95 "+" is a
function that takes two arguments and returns a result without
modifying either of those arguments (isn't that redundant?), the
default implementation of which returns the sum of the two arguments
-- I'm not sure it is even restricted that much, there is also a
version with one argument].  Is there some fundamental limitation
which makes this different from Get?  I could define these:
    procedure Get (Left : in out Integer; Right : in Integer);
    function  Get (Left : Integer; Right : Integer) return Integer;
and GNAT at least doesn't seem to have any objection to it.
In what way is the notation "+" special (besides the restrictions that
the language puts on it, which is what we're talking about changing)?

>How could it also be a procedure that modifies one of its arguments? 
It's called overloading:
    procedure "+" (Left : in out Integer; Right : in Integer);
    function  "+" (Left : Integer; Right : Integer) return Integer;
would be perfectly reasonable (though I won't comment on its
desirability).

>You think the same symbol taking the same argument types can be 
>used for both a procedure and a function? 
Yes.

>It's no wonder you put the word "problem" in quotes: you
>don't understand the problem.
If the problem is different than: 
"I want a way to duplicate c++/c+=1/c-=1/--c/... in Ada0Y" 
then I must have responded to the wrong thread.
The reason I put in quotes is that I don't see it as anything that
needs to be fixed. You're welcome to disagree.

Ideas for Ada 200X

[Russ]

Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote in message news:<5e9b8c34.0306191222.6c9fd0ec@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote
> > Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote
 
> >How could it also be a procedure that modifies one of its arguments? 
> It's called overloading:
>     procedure "+" (Left : in out Integer; Right : in Integer);
>     function  "+" (Left : Integer; Right : Integer) return Integer;
> would be perfectly reasonable (though I won't comment on its
> desirability).

It would be the goofiest "+" operator around. If I write

    i := i + j + 1

what happens to j?

Re: Ideas for Ada 200X

[Amir Yantimirov]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbf3arb.hi.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Amir Yantimirov wrote:
> > While not omit := at all and use postfix operator in expression:
> > 
> >     X# + A;
> >     min ( X#, 0 );
> >     X# + # * 2;
> >     X#.Next;
> > 
> > Er, too C-ish. (Or C#-ish ?) Then so:
> 
> I don't know. I only know that I don't understand one of the lines
> above. What are they supposed to express?

  X# + A;         --  X := X + A;
  min ( X#, 0 );  --  X := min ( X, 0 );
  X# + # * 2;     --  X := X + X * 2; (it should be **2 to have sense)
  X#.Next;        --  X := X.Next;

http://www174.pair.com/yamir/programming/syntax.htm
Amir Yantimirov

Re: Ideas for Ada 200X

[Wesley Groleau]

> It would be the goofiest "+" operator around. If I write
> 
>     i := i + j + 1
> 
> what happens to j?

IFF we allow "+" to be a procedure as well as a function,
then, as a procedure, it can not return a result [1].
Therefore, neither "+" above could be the procedure.

However, if we allow "+" to be a procedure, and allow
it to be called with the syntax

    i + 1;

then we would have to decide whether to allow

    i + j + 1;

and if so, how to define its meaning.


[1] Remember, in Ada, (unlike C), you cannot change
     a function to a procedure by discarding its result.

Re: Ideas for Ada 200X "left hand side" repeater.

[Preben Randhol]

Chad R. Meiners wrote:
> So back to
> 
> [Pixel] Screen.Buffer(i) := Pixel + 1;
> 
> ? ;-)

No because it is not very readable I think.

-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Preben Randhol]

Amir Yantimirov wrote:
> 
>   X# + A;         --  X := X + A;
>   min ( X#, 0 );  --  X := min ( X, 0 );
>   X# + # * 2;     --  X := X + X * 2; (it should be **2 to have sense)
>   X#.Next;        --  X := X.Next;

OK, then I would vote a big fat NO to this as it is totally unreable and
is probably something you could find in Perl or sth similar :-)

-- 
�It's probably worth pointing out that  C's pointer arithmetic  is not
 only dangerous, and a significant source of errors, but it also makes
 programs run slower.�
               - James Kanze on comp.lang.ada,comp.lang.c++.moderated

Re: Ideas for Ada 200X

[Dmitry A. Kazakov]

Russ wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:<bcrpc1$mi00f$1@ID-77047.news.dfncis.de>...
>> That thing is called overloading. BTW, see my example below for a
>> procedure, which does *not* modify any of its arguments.
> 
> If i := i + 1 is equivalent to i + 1, then what does
> 
>     i = i + j + 1
> 
> mean?

It depends on the set of visible procedures and functions. However from the 
above it is absolutely unclear what you mean.

A. An expression: if i = i + j + 1 then ...

Then no procedure is even considered. A call to a procedure may appear in a 
call-statement only. (Sorry for a tautology (:-))

B. A statement, assuming that "=" should be ":=", plus a trailing semicolon:

i := i + j + 1;

Then everything left of ":=" is an expression, and see A.

C. If "=" is "=" and it is again a statement then things get more 
interesting:

i = i + j + 1;

The compiler should consider:

C.1  i = (i + j + 1);   -- "=" is a procedure 
C.2  (i = i) + (j + 1); -- 1st "+" is a procedure
C.3  (i = i + j) + 1;   -- 2nd "+" is a procedure

Because of operation priorities only C.1 is considered. So "=" is definitely 
a procedure, if exists, otherwise it is a compile error. Everything else 
are functions.

Technically it is no problem to parse that. Business as usuall for a 
compiler.

> Does j get incremented by 1? Either way, I'd say readability
> went out the window.

Well, overloading has problems with that. Yet, it is allowed in most of 
languages.

It is programmer's duty not to misuse overloading. Note that any additional 
operation reduces readability:

X := X + Y;
X +:= 1;

This could become a puzzle for a reader. Why author adds Y using a function 
but when he adds 1 he uses a procedure? Is there any semantic difference, 
or is it just a matter of taste? Could the code be improved when both were 
functions or procedures? May a change of implementation of "+" or "+:=" 
infuence the decision. Should we inspect the implementations? Should we 
revise all the code?

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

Re: Ideas for Ada 200X "left hand side" repeater.

[Dmitry A. Kazakov]

Chad R. Meiners wrote:

> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrnbf3anv.hi.randhol+abuse@kiuk0152.chembio.ntnu.no...
>> Wesley Groleau wrote:
>> >
>> > Hmmm.  It does make sense that way.  Perhaps the ambiguity
>> > is an argument against it.  :-)
>>
>> I would think so :-)
> 
> So back to
> 
> [Pixel] Screen.Buffer(i) := Pixel + 1;

Or stealing loop's naming syntax:

Pixel : Screen.Buffer(i) := Pixel + 1;

Better to leave [] for further operation set extensions (if any would 
happen).

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

Re: Ideas for Ada 200X

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 21 Jun 2003 07:35:39 -0500 (CDT)
NNTP-Posting-Host: !ca,D1k-VQZ1^99 (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbf5eau.hp.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Amir Yantimirov wrote:
> >
> >   X# + A;         --  X := X + A;
> >   min ( X#, 0 );  --  X := min ( X, 0 );
> >   X# + # * 2;     --  X := X + X * 2; (it should be **2 to have sense)
> >   X#.Next;        --  X := X.Next;
>
> OK, then I would vote a big fat NO to this as it is totally unreable and
> is probably something you could find in Perl or sth similar :-)

Second the motion.

Re: Ideas for Ada 200X

[John R. Strohm]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:v66cnYP9G6Q58G-jXTWJhQ@gbronline.com...
>
> > It would be the goofiest "+" operator around. If I write
> >
> >     i := i + j + 1
> >
> > what happens to j?
>
> IFF we allow "+" to be a procedure as well as a function,
> then, as a procedure, it can not return a result [1].
> Therefore, neither "+" above could be the procedure.
>
> However, if we allow "+" to be a procedure, and allow
> it to be called with the syntax
>
>     i + 1;
>
> then we would have to decide whether to allow
>
>     i + j + 1;
>
> and if so, how to define its meaning.

This would seem to be an OUTSTANDING argument AGAINST the whole idea.

> [1] Remember, in Ada, (unlike C), you cannot change
>      a function to a procedure by discarding its result.

Re: Ideas for Ada 200X

[Wesley Groleau]

John R. Strohm wrote:
>>However, if we allow "+" to be a procedure, and allow
>>it to be called with the syntax
>>
>>    i + 1;
>>
>>then we would have to decide whether to allow
>>
>>    i + j + 1;
>>
>>and if so, how to define its meaning.
> 
> This would seem to be an OUTSTANDING argument AGAINST the whole idea.

Well, I think I've said all along I'm opposed,
but _IF_ it seemed like the consensus was to
add the first construct into the language, I would
oppose the second.

Where do you draw the line?

Once you allow

    Call_something;
    Thing_To_Be_Incremented + Increment;
    Call_Something_Else;

Then it's harder to argue against allowing

    Target + Addend + Other_Addend;

Then when that gets in, why not

    A + B * C;

and on and on and on ....

Re: Ideas for Ada 200X

[AG]

"Alexander Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:e2e5731a.0306191037.3addbae5@posting.google.com...

> In addition to yesterday's "~name or ~~" proposal, here is yet another
one:
> use triplet (*) - asterisk inside round brackets. This compound symbol is
> quite different from others, and nicely associates with "focus".
>
>   X := (*) + A;
>
>   X := (*) + (*);

As written, I don't see how is it better
than just using X + A and X + X.
After all those forms actually *save*
keystrokes compared to the triplet
variants.

Seriously though, what's the (*) & X
semantics?  Is X allowed to be a function
returning some access value? If so, will
(*) require second call to the function
(with potentially different result) or not?

Re: Ideas for Ada 200X

[Lutz Donnerhacke]

* AG wrote:
> Seriously though, what's the (*) & X semantics?

The LHS 'X' is not evaluated twice to get the parameter a of the function "&".
For the parameter b of the same function "&", 'X' is evaluated a second time.

> Is X allowed to be a function returning some access value?

Yes.

> If so, will (*) require second call to the function (with potentially
> different result) or not?

(*) is required to NOT evaluate the LHS expression once more.
Furthermore this construct is required to evaluate the LHS expression before
any part of the RHS.

Re: Ideas for Ada 200X

[Bill Findlay]

On 24/6/03 11:11, in article slrnbfg8vd.nq.lutz@taranis.iks-jena.de, "Lutz
Donnerhacke" <lutz@iks-jena.de> wrote:

> * AG wrote:
>> Seriously though, what's the (*) & X semantics?
> 
> The LHS 'X' is not evaluated twice to get the parameter a of the function "&".
> For the parameter b of the same function "&", 'X' is evaluated a second time.
>> Is X allowed to be a function returning some access value?
> Yes.
>> If so, will (*) require second call to the function (with potentially
>> different result) or not?
> (*) is required to NOT evaluate the LHS expression once more.
> Furthermore this construct is required to evaluate the LHS expression before
> any part of the RHS.

I see the semantics of idem as being well described by the following (which
would need much refinement before being precise enough for inclusion in a
standard, of course):

Let:

   X  :=  f(idem);

be equivalent to declaring the procedure:

   procedure update_V_with_f (V : in out the_type_of_X) is
   begin
      V := f(V);
   end ;

in the environment of the assignment, and executing:

    update_V_with_f (X);

instead of the the assignment.

Naturally, update_V_with_f is intended to be an unspellable identifier so
that it cannot be called explicitly, etc, etc.

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

Re: Ideas for Ada 200X

[Alexander Kopilovitch]

Bill Findlay wrote:

>On 24/6/03 11:11, in article slrnbfg8vd.nq.lutz@taranis.iks-jena.de, "Lutz
>Donnerhacke" <lutz@iks-jena.de> wrote:
>
>> * AG wrote:
>>> Seriously though, what's the (*) & X semantics?
>> 
>> The LHS 'X' is not evaluated twice to get the parameter a of the function "&".
>> For the parameter b of the same function "&", 'X' is evaluated a second time.
>>> Is X allowed to be a function returning some access value?
>> Yes.
>>> If so, will (*) require second call to the function (with potentially
>>> different result) or not?
>> (*) is required to NOT evaluate the LHS expression once more.
>> Furthermore this construct is required to evaluate the LHS expression before
>> any part of the RHS.
>
>I see the semantics of idem as being well described by the following (which
>would need much refinement before being precise enough for inclusion in a
>standard, of course):
>
>Let:
>
>   X  :=  f(idem);
>
>be equivalent to declaring the procedure:
>
>   procedure update_V_with_f (V : in out the_type_of_X) is
>   begin
>      V := f(V);
>   end ;
>
>in the environment of the assignment, and executing:
>
>    update_V_with_f (X);
>
>instead of the the assignment.
>
>Naturally, update_V_with_f is intended to be an unspellable identifier so
>that it cannot be called explicitly, etc, etc.

Just one slight change in the denotation -- for convenience of common folk -:)
- use "expr" unstead of "f", that is:

Let:

   X  :=  expr(idem);  -- "expr" for an expression

be equivalent to declaring the procedure:

   procedure update_V_with_expr (V : in out the_type_of_X) is
   begin
      V := expr(V);
   end ;

in the environment of the assignment, and executing:

    update_V_with_expr (X);

instead of the assignment.

How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Jacob Sparre Andersen]

Marin David Condic wrote:

> Well, I won't say it *can't* work - just that it has been tried in a few 
> different ways and guess what? We don't have a Conventional Ada Library.
> 
> If the thing has zero interest from the vendors it will become Just 
> Another Ada Library like the half-dozen or so that are already out 
> there.

Yes, but...

 > A small teem of developers might be able to do a good job of
> building a library - even if they were volunteers - but it would need 
> some direction from those who have to adopt it as "The Right Thing". 
> Think "Requirements" - someone has to impose some.

If we can't get the compiler vendors (or ARA) to come up with some
requirements, wouldn't it be a viable alternative to get Ada Europe and
SIGAda to create a common working group for writing the requirements
(and specifications?) for a �Conventional Ada Library�?  Of course Ada
Europe and SIGAda do not have the same easy way to force a library on
the programmers as the compiler vendors, but I can't think of any better
solution right now.

> A group of enthusiasts sounds plausable, but I believe that unless it 
> has some cloak of "officialness" to it, some acceptance on the part of 
> the vendors and some sort of charter/requirements to work to, it will 
> either fall apart or produce Just Another Ada Library.

Ada Europe and SIGAda _do_ have a cloak of "officialness".  The question
is if it is sufficiently convincing.

Jacob
-- 
"This page inadvertently left blank."

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

My contention is that if a Conventional Ada Library is to succeed, you 
have to get at least *some* of the vendors to agree to distribute it 
with their product. Ada Europe and/or SIGAda might be perfectly good 
cloaks of officialness for helping to define what such a library is. I'd 
be 1000% behind such an effort. However, you've got to get at least a 
handful of the vendors involved - at least to the level where they agree 
to accept/distribute the resulting product. (Agree in principle. If the 
end product is trash, I wouldn't want to force that on them.)

My contention is that if a library just simply came along for the ride 
with any given Ada compiler and there was reasonable assurance that the 
library would remain "common" accross many implementations, it becomes a 
de facto standard and makes Ada a more attractive tool. If it is Just 
Another Ada Library sitting on a web page somewhere with no particular 
reaction to it from the vendors, it doesn't change the situation at all. 
We *already* have that and it is not really working well to make Ada a 
more attractive tool. (It isn't hurting - its just not making any sort 
of huge impact.) It needs the vendors on board or I'm convinced it won't 
work.

MDC


Jacob Sparre Andersen wrote:
> 
> 
> Ada Europe and SIGAda _do_ have a cloak of "officialness".  The question
> is if it is sufficiently convincing.
> 
> Jacob


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: How to get a �Conventional Ada Library� (Was: Ideas for Ada 200X)

[Martin Dowie]

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

"Jacob Sparre Andersen" <sparre@crs4.it> wrote in message
news:3F61BA28.3060507@crs4.it...
> If we can't get the compiler vendors (or ARA) to come up with some
> requirements, wouldn't it be a viable alternative to get Ada Europe and
> SIGAda to create a common working group for writing the requirements
> (and specifications?) for a �Conventional Ada Library�?  Of course Ada
> Europe and SIGAda do not have the same easy way to force a library on
> the programmers as the compiler vendors, but I can't think of any better
> solution right now.

There is such a WG:

http://www.acm.org/sigada/wg/apiwg/

(thanks to Dirk Craeynest for the link)

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Robert I. Eachus]

Jacob Sparre Andersen wrote:

>> Well, I won't say it *can't* work - just that it has been tried in a 
>> few different ways and guess what? We don't have a Conventional Ada 
>> Library.
>>
>> If the thing has zero interest from the vendors it will become Just 
>> Another Ada Library like the half-dozen or so that are already out there.

You are fighting the wrong battle here.  Back in 1984 there was a 
session at SIGAda to discuss CAIS a government developed APSE 
(development environment) for Ada.  We had a very lively discussion for 
about an hour, and I then decided to see if I could cut through the all 
the cross-currents and come up with a single position statement.

I started out by saying that I had spend three weeks studing the CAIS 
documentation, and I still wasn't sure I knew enough to use it as a 
development platform.  So I asked those people present who had use the 
CAIS prototype how much study by programmers was required to use it.  No 
answer.  Does anyone feel that a month per programmer is an 
overstatement.  This time I got a lot of heads shaking no.  Is there 
anyone here who has spent less time?  No answer.

Okay, I then asked people present who had developed fairly significant 
Ada projects that had been ported to a different environment, how long 
the ports had taken.  "About three weeks."  What if you had to do more 
ports?  "Much easier."  Now I asked the one group that had ported CAIS 
to a new environment how long that had taken.  "About three months."

That was basically the end of the meeting.  We wrote up a statement 
saying that the complexity of the CAIS environment was such that we 
didn't feel that using it for development would ever pay off.

Why bring this up?  I think this is currently where we are with Ada 
container libraries.  A SIMPLE Ada container library will get used.  But 
it is much easier for the developers to "improve" the libraries by 
adding new container types and modes than it is for the potential users 
to learn how to use the library.  I figure that about five to seven 
pages of technical documentation--including examples--is what Ada 
programmers are willing to spend on a container library before walking 
away and reinventing the wheel.  This doesn't say that the library can't 
have all those bells and whistles.  Just that the standard subset has 
got to be that easy to learn.

-- 
                                           Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Mário Amado Alves]

> . . . I figure that about five to seven 
> pages of technical documentation--including examples--is what Ada 
> programmers are willing to spend on a container library before walking 
> away and reinventing the wheel.  This doesn't say that the library can't 
> have all those bells and whistles.  Just that the standard subset has 
> got to be that easy to learn.

Additional ammunition for the 50 lines recommendation. Thanks.

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

I don't know what this group has produced or aims to produce, but my 
understanding of an "API" is not the same thing as that of a "Library". 
An API seems to me to be something along the lines of "If one day, Real 
Soon Now, you're going get motivated to build a package to do this job, 
its spec ought to look like this...." Whereas a library is more along 
the lines of "Here's the package to do this job..."

One is an interesting intellectual exercise that may or may not ever be 
realized and may or may not ever be considered "Part Of The Language". 
The other is a concrete reality I can use to get something done. I leave 
it as an exercise for the student to determine which is which. :-)

Remember that it is a key element of success for a library that the 
vendors be willing to agree that it should be part of their compiler 
distribution. Are the vendors on board with this WG and agreeing to 
implement whatever they come up with? (I'm not trying to be a wet 
blanket here - just realistic about what it takes to turn something like 
this into a success. At least some of the vendors got on board with ASIS 
& that seems to have a future of sorts. Albeit as a tool for a very 
limited set of developers. Are any vendors backing *any* SIGAda effort 
to define/produce a library?)

MDC



Martin Dowie wrote:
> 
> 
> There is such a WG:
> 
> http://www.acm.org/sigada/wg/apiwg/
> 
> (thanks to Dirk Craeynest for the link)
> 
> 


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

Just for the record, the quoted text was mine and not that of Jacob 
Sparre Andersen.

I don't understand what you mean about "Fighting the wrong battle." 
First, I wasn't saying that a library needs to be "Complex" in order to 
succeed. I said it needs acceptance by the vendors in order to succeed. 
There may be those who would care to dispute that point. I think its 
intuitively obvious to even the most casual observer. :-) One may argue 
about how to get there, but I think that is a necessary condition to 
success.

As for the CAIS - I remember discussions and papers about that but don't 
recall the specifics. I remember not understanding what it was trying to 
achieve or how it was supposed to work - that ought to be an indication 
it was doomed. ;-) If you can't understand what it is attempting to 
achieve and how it is going about getting there, its a warning flag.

As for a conventional Ada library getting too complex, let me start 
here: To the extent that containers are part of such a library, I'd 
support a plain-vanilla set of lists and maps with "Ease Of Use" as a 
primary goal. I'd also want to consider a second set of more elaborate 
and powerful containers with "Maximum Utility" as a goal - on which you 
go build whatever else you want to stick into the library. Make sure it 
is well documented.

Second, as for any concerns about "largeness" or "complexity" - lets do 
a counter-proof by existence: Java has a really large library. So does 
MSVC++. Programmers use those libraries *every*day* to build systems. If 
they count as "large" and "complex", then this must not be a handicap. 
If they are not "large" or "complex" then let's go off and build 
something similar to what they have and call that a Conventional Ada 
Library and we would similarly not be "large" and "complex".

One advantage to making sure we have a "Conventional" Ada library is 
that it makes it much easier for the academic types to write books about 
how to use it. I'd think it is really important to have good 
documentation with the library, but secondary books that discuss the 
"How Tos" of program development with the library would be just as 
important. I've got books on the "How Tos" of using MSVC++ and the MFC. 
I presume they exist for Java. Why not for Ada?

MDC



Robert I. Eachus wrote:
> Jacob Sparre Andersen wrote:
> 
>>> Well, I won't say it *can't* work - just that it has been tried in a 
>>> few different ways and guess what? We don't have a Conventional Ada 
>>> Library.
>>>
>>> If the thing has zero interest from the vendors it will become Just 
>>> Another Ada Library like the half-dozen or so that are already out 
>>> there.
>>
> 
> You are fighting the wrong battle here.  Back in 1984 there was a 
> session at SIGAda to discuss CAIS a government developed APSE 
> (development environment) for Ada.  We had a very lively discussion for 
> about an hour, and I then decided to see if I could cut through the all 
> the cross-currents and come up with a single position statement.
> 
> I started out by saying that I had spend three weeks studing the CAIS 
> documentation, and I still wasn't sure I knew enough to use it as a 
> development platform.  So I asked those people present who had use the 
> CAIS prototype how much study by programmers was required to use it.  No 
> answer.  Does anyone feel that a month per programmer is an 
> overstatement.  This time I got a lot of heads shaking no.  Is there 
> anyone here who has spent less time?  No answer.
> 
> Okay, I then asked people present who had developed fairly significant 
> Ada projects that had been ported to a different environment, how long 
> the ports had taken.  "About three weeks."  What if you had to do more 
> ports?  "Much easier."  Now I asked the one group that had ported CAIS 
> to a new environment how long that had taken.  "About three months."
> 
> That was basically the end of the meeting.  We wrote up a statement 
> saying that the complexity of the CAIS environment was such that we 
> didn't feel that using it for development would ever pay off.
> 
> Why bring this up?  I think this is currently where we are with Ada 
> container libraries.  A SIMPLE Ada container library will get used.  But 
> it is much easier for the developers to "improve" the libraries by 
> adding new container types and modes than it is for the potential users 
> to learn how to use the library.  I figure that about five to seven 
> pages of technical documentation--including examples--is what Ada 
> programmers are willing to spend on a container library before walking 
> away and reinventing the wheel.  This doesn't say that the library can't 
> have all those bells and whistles.  Just that the standard subset has 
> got to be that easy to learn.
> 


-- 
======================================================================
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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Robert I. Eachus]

Marin David Condic wrote:
> Just for the record, the quoted text was mine and not that of Jacob 
> Sparre Andersen.
> 
> I don't understand what you mean about "Fighting the wrong battle." 
> First, I wasn't saying that a library needs to be "Complex" in order to 
> succeed. I said it needs acceptance by the vendors in order to succeed. 
> There may be those who would care to dispute that point. I think its 
> intuitively obvious to even the most casual observer. :-) One may argue 
> about how to get there, but I think that is a necessary condition to 
> success.

I meant that ease of implementation for the compiler vendors is not that 
  important.  Ease of understanding and use of the library by Ada 
programmers is vital.

Even though I think this particular effort to come up with an interface 
is unlikely to succeed, at least it is tackling the right issue.  It 
would be nice to invent a simple interface and then provide an 
implementation.  But I think that we are now too close to decision time 
for another cut at library requirements to be finished in time to have 
any effect.  If anyone wants to look at existing Ada container 
libraries, and see if the interfaces can be simplified, that might be 
worthwhile.

--
                                        Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

O.K. I just didn't see anywhere in the thresd where it was being 
suggested that a library should be easy for the vendors to implement. 
I'd agree that this would be the wrong end to optimize - make it easy 
for the programmer to understand and use. I wouldn't even put 
"efficiency" high on the list. For most PC/Workstation apps, if some 
feature of the library were to be moderately inefficient, but it was 
easy to use and it got a job done, I don't think most developers would care.

Also, it seems possible that we are talking about two different 
"visions". Perhaps you are talking about specifically a container 
library to be included in the ARM in some form. I'd have a much more 
ambitious goal of producing a more general library (of which, containers 
might be a part) that provides a wide range of services beyond data 
storage and retrieval. In that ballpark, I don't really see each vendor 
coming up with a conforming implementation, but adopting a common 
"reference" version produced under some reasonable auspices wherein 
everyone has a voice in what the library sould look like. SIGAda could 
be a forum for that, but, as I've said before, the vendors have to be 
on-board to some extent or it would really flop.

MDC

Robert I. Eachus wrote:
> 
> 
> I meant that ease of implementation for the compiler vendors is not that 
>  important.  Ease of understanding and use of the library by Ada 
> programmers is vital.
> 

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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
...
> As for a conventional Ada library getting too complex, let me start 
> here: To the extent that containers are part of such a library, I'd 
> support a plain-vanilla set of lists and maps with "Ease Of Use" as a 
> primary goal. I'd also want to consider a second set of more elaborate 
> and powerful containers with "Maximum Utility" as a goal - on which you 
> go build whatever else you want to stick into the library. Make sure it 
> is well documented.

I would support this idea.

> Second, as for any concerns about "largeness" or "complexity" - lets do 
> a counter-proof by existence: Java has a really large library. So does 
> MSVC++. Programmers use those libraries *every*day* to build systems. If 
> they count as "large" and "complex", then this must not be a handicap. 
> If they are not "large" or "complex" then let's go off and build 
> something similar to what they have and call that a Conventional Ada 
> Library and we would similarly not be "large" and "complex".

I think this is an excellent point that you make here. How many
times have we heard that a such-n-such proposal/implementation is
too large or complex, and then stop there. Yet, as you point out,
others are already _using_ libraries far more (or equally) complex
in their day to day work. Simplicity is certainly a good goal, but
let's all realize that sometimes functionality dictates a more
complicated world.

Equally important is the fact that "they" are using something, and
often "we" are not. While the Booch Components often gets criticised
for their complexity (in instantiation mostly I think), they are a
very functional set of packages. They would be easier to use with
the appropriate level of documentation, which hasn't happened yet
(I had actually made it a goal to write such, but as you can see,
haven't come through on that yet). But the point here is that they
are fairly complete in functionality, but yet for one reason or
another, not fully accepted by the community (or maybe they have,
but the lurkers are not saying that ;-) ).

> MDC

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

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

Another important thing to notice is that when you are discussing a 
library, complexity doesn't insert itself into the language itself. The 
language can remain as simple and efficient and unencumbered as you 
like. The library may be complex, bloated, inefficient, etc. and if you 
don't like it, you don't use it.

Not that I'm arguing for complex, bloated and inefficient software. Just 
observing that one can back off from a lot of the requirements one might 
have for a language feature when discussing a library - or a particular 
library feature. These days, linkers ought to be smart enough to only 
bring in the stuff that is actually called, so any given feature might 
get pretty huge and bloated without impacting anyone who doesn't need it.

Libraries are a good thing and IMHO, the bigger the better. The more 
leverage I can get out of a library to build my end product, the less 
building I have to do, so I would put up with a lot of sub-optimal 
characteristics (such as possible complexity or inefficiency) in order 
to save me from having to do it myself.

MDC


Warren W. Gay VE3WWG wrote:
> 
> 
> I think this is an excellent point that you make here. How many
> times have we heard that a such-n-such proposal/implementation is
> too large or complex, and then stop there. Yet, as you point out,
> others are already _using_ libraries far more (or equally) complex
> in their day to day work. Simplicity is certainly a good goal, but
> let's all realize that sometimes functionality dictates a more
> complicated world.
> 
> Equally important is the fact that "they" are using something, and
> often "we" are not. While the Booch Components often gets criticised
> for their complexity (in instantiation mostly I think), they are a
> very functional set of packages. They would be easier to use with
> the appropriate level of documentation, which hasn't happened yet
> (I had actually made it a goal to write such, but as you can see,
> haven't come through on that yet). But the point here is that they
> are fairly complete in functionality, but yet for one reason or
> another, not fully accepted by the community (or maybe they have,
> but the lurkers are not saying that ;-) ).
> 
>> MDC
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
...
> Libraries are a good thing and IMHO, the bigger the better. The more 
> leverage I can get out of a library to build my end product, the less 
> building I have to do, so I would put up with a lot of sub-optimal 
> characteristics (such as possible complexity or inefficiency) in order 
> to save me from having to do it myself.
> 
> MDC

Which of course, brings us back to the issue of documentation ;-)

If it takes longer to figure out how to use even a simple, efficient
library due to lack of documentation, vs finding out quickly how to
use a more bloated and less efficient but well documented library,
then my bet is that (in the non-embedded case) the later will
usually be used.

What I have often observed in C code at least, is that a programmer
will re-invent the wheel when he is too lazy to lookup and re-use
something that exists. Certainly 2 barriers here include ignorance
and laziness, but the largest challenge is to make the
library elements "accessible", through online and/or hard copy
documentation.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

Yeah, but it shouldn't be all that hard to produce some reasonable level 
of documentation for a library. I agree that if Ada is going to get a 
library, it needs a document, but assuming there is sufficient 
motivation to create a library and sufficient backing to actually get it 
done and distributed with compilers, don't you think a document would be 
a pittance in additional extra effort? I'd insist on one if I were 
distributing it - and it isn't as if you'd need a hundred man-years to 
produce something either. You just need to insist that there be a 
document as one of the deliverables and that it meet some reasonable 
acceptance criteria.

Of course, making sure you get one presumes there is someone out there 
acting as a "customer" who has some leverage (such as a checkbook) to 
insist on things like documentation, coding standards, design strategy, 
etc. If you presume an all-volunteer effort, that gets really tough to 
enforce. You get whatever you get whenever they feel like giving it to 
you and its likely to look like a patchwork-quilt of different styles, 
strategies, levels of quality, etc.

MDC

Warren W. Gay VE3WWG wrote:
> 
> 
> Which of course, brings us back to the issue of documentation ;-)
> 
> If it takes longer to figure out how to use even a simple, efficient
> library due to lack of documentation, vs finding out quickly how to
> use a more bloated and less efficient but well documented library,
> then my bet is that (in the non-embedded case) the later will
> usually be used.
> 
> What I have often observed in C code at least, is that a programmer
> will re-invent the wheel when he is too lazy to lookup and re-use
> something that exists. Certainly 2 barriers here include ignorance
> and laziness, but the largest challenge is to make the
> library elements "accessible", through online and/or hard copy
> documentation.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Matthew Heaney]

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

> Marin David Condic wrote:
> ...
> > As for a conventional Ada library getting too complex, let me start
> > here: To the extent that containers are part of such a library, I'd
> > support a plain-vanilla set of lists and maps with "Ease Of Use" as
> > a primary goal. I'd also want to consider a second set of more
> > elaborate and powerful containers with "Maximum Utility" as a goal -
> > on which you go build whatever else you want to stick into the
> > library. Make sure it is well documented.
> 
> I would support this idea.

You might be interested in my container library proposal for Ada 0X.

<http://home.earthlink.net/~matthewjheaney/charles/ai302.txt>

My proposal is based on the STL.  The API I describe in the proposal is
close to the Charles library.

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

I'd be in favor of most any container library, so long as it becomes 
"The Standard" so we don't have a dozen different ones dangling out 
there and no consensus on what everyone should use. If the Keepers Of 
The Eternal Ada Flame want to get on board with Charles and declare that 
to be the answer, I can live with it.

Where I part ways is on the need to get this sort of thing into the Ada 
Standard. I think that makes it too rigid and hard to extend or improve. 
If we had a "Lower Tier Standard" that could easily be revised & 
extended - perhaps providing a reference implementation for the vendors 
to adopt - we'd be able to get new and interesting things into it 
without having to wait ten years and letting a dozen other languages out 
there beat us to the punch.

Ada should have had a "standard" container library back in Ada83. It 
could have, and should have had a whole "library concept" that included 
some big, general-use library right from the get-go. (C came with 
"standard" library packages, didn't it? Ada didn't even have a standard 
square-root subroutine! Whos silly-ass idea was that, anyway?) It should 
have beat C++ to the punch well before C++ got the STL. The problem here 
is that if we've got to wait for standard revisions we will be forever 
seeing capabilities added to other languages and going "Gee.... Maybe in 
*TEN*YEARS* I could have that too..." - In the mean time, what languages 
will people be selecting for their new products?

MDC



Matthew Heaney wrote:

> 
> 
> You might be interested in my container library proposal for Ada 0X.
> 
> <http://home.earthlink.net/~matthewjheaney/charles/ai302.txt>
> 
> My proposal is based on the STL.  The API I describe in the proposal is
> close to the Charles library.
> 
> 
> 
> 
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Robert I. Eachus]

Marin David Condic wrote:

> Ada should have had a "standard" container library back in Ada83. It 
> could have, and should have had a whole "library concept" that included 
> some big, general-use library right from the get-go. (C came with 
> "standard" library packages, didn't it? Ada didn't even have a standard 
> square-root subroutine! Whos silly-ass idea was that, anyway? 

Mine, along with a lot of other people.  The problem wasn't bad 
implementations of square root, it was truly horrible libraries of the 
other standard transendental functions.  The choice was to delay the 
standard until we knew what sort of a math library to put in, or 
standardize now (in 1982) and set up the NRG (back then the NumWG) to 
figure out what a good math library should look like, and standardize 
that separately.

That was done.  It took a lot longer than expected but ended up with a 
proposal, and a fast portable implementation of it, that had 
significantly better error limits for most of the functions than was 
known to be possible in 1982.  Most of those new better algorithms and 
limits were developed by the NumWG or NumWG members.  SC22 then set up 
the WG11 to do the same thing for all languages, and also incorporate 
some of the IEEE 754 work.  The result is the Language Independent 
Arithmetic standards.

Most Ada 83 compiler vendors followed the NumWG/NRG work, and provided a 
standard package that used the current state of the NumWG work.  But in 
early Ada days it was definitely a moving target.  I remember one 
meeting where several of the accuracy limits were reduced by a factor of 
eight.

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

O.K. Every other language I knew at the time had a square root routine 
somewhere in what it considered its "standard library" or intrinsic 
functions. Most of them had log and trig functions as well (I can't 
remember if Cobol did or not.) Along comes Ada83 and says "We're not 
going to specify a standard, portable set of calls to functions you get 
automagically in every other major language in use today..." How well 
was that received by the general programming public?

All it really needed was a standard package specification so that people 
weren't writing things dependent on different vendor's interpretations 
of what was the best name to call the package or its routines & 
parameters. Perhaps the libraries were terrible. But people were going 
to hook up to them and use them anyway - terrible or not. In fact, they 
did. There just weren't any two implementations that had the same 
package name and function names. Perhaps Ada was standing around saying 
"But because I can't *precisely* specify some behavior because of the 
crappy libraries out there, I'm not going to specify anything at all..." 
This was incredibly useless to the average developer. I'd have been real 
happy with a standard package spec, standard function names and standard 
parameter lists and a definition of "Implementation Defined - including 
monkeys flying out of your anus when you call these routines" At least 
the calls would have been source-code portable and it would have been up 
to me to figure out if a given implementations natural log function did 
me any good.

We see similar problems with the standard today - wherein because it is 
difficult to get something specified down to some precise, testable, 
verifiable behavior, we end up not doing anything at all - while other 
languages plough ahead and give the end-user important capabilities that 
may not be 100% perfect, but have the *infinitely* more important 
characteristic of "existence". That's why I think Ada needs some 
additional mechanism other than the ARM for specifying things that ought 
to be part of Ada. If back in 83 Ada had said "O.K., we can't specify a 
math library well enough today to make it part of the standard. But over 
here, on the side, we have the 'Conventional Ada Library' that is a 
reference implementation used by all vendors...." we could have had some 
sort of square root routine that was interface-compatible across all 
implementations. Eventually, the standard could have cought up - but in 
the mean time, the users would have had *something* that might have 
actually worked.

MDC



Robert I. Eachus wrote:
> 
> Mine, along with a lot of other people.  The problem wasn't bad 
> implementations of square root, it was truly horrible libraries of the 
> other standard transendental functions.  The choice was to delay the 
> standard until we knew what sort of a math library to put in, or 
> standardize now (in 1982) and set up the NRG (back then the NumWG) to 
> figure out what a good math library should look like, and standardize 
> that separately.
> 
> That was done.  It took a lot longer than expected but ended up with a 
> proposal, and a fast portable implementation of it, that had 
> significantly better error limits for most of the functions than was 
> known to be possible in 1982.  Most of those new better algorithms and 
> limits were developed by the NumWG or NumWG members.  SC22 then set up 
> the WG11 to do the same thing for all languages, and also incorporate 
> some of the IEEE 754 work.  The result is the Language Independent 
> Arithmetic standards.
> 
> Most Ada 83 compiler vendors followed the NumWG/NRG work, and provided a 
> standard package that used the current state of the NumWG work.  But in 
> early Ada days it was definitely a moving target.  I remember one 
> meeting where several of the accuracy limits were reduced by a factor of 
> eight.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Robert I. Eachus]

Marin David Condic wrote:

> All it really needed was a standard package specification so that people 
> weren't writing things dependent on different vendor's interpretations 
> of what was the best name to call the package or its routines & 
> parameters. Perhaps the libraries were terrible. But people were going 
> to hook up to them and use them anyway - terrible or not. In fact, they 
> did. There just weren't any two implementations that had the same 
> package name and function names. Perhaps Ada was standing around saying 
> "But because I can't *precisely* specify some behavior because of the 
> crappy libraries out there, I'm not going to specify anything at all..." 
> This was incredibly useless to the average developer. I'd have been real 
> happy with a standard package spec, standard function names and standard 
> parameter lists and a definition of "Implementation Defined - including 
> monkeys flying out of your anus when you call these routines" At least 
> the calls would have been source-code portable and it would have been up 
> to me to figure out if a given implementations natural log function did 
> me any good.

But the NumWG work did result in an ISO standard, well before Ada 95 
came along.  It probably would have been nice to have the ACVC require 
the vendors provide exactly that package but that didn't happen. 
However, the packages, including Complex and Simple packages were 
printed as an issue of Ada Letters, including all the specs, and a place 
to get a portable generic implementation.

As I said, it would have been nice if it had happened faster, but it 
didn't.  Those four packages were effectively folded into the numerics 
annex of Ada 95.  It would have been nice if the work had finished 
sooner.  But that was not the big issue.  The big issue, which Ada 95 
implements a nice compromise on, was whether Ada should specify the 
accuracy of floating-point arithmetic.  At the time Ada 83 was being 
finalized, the IEEE floating point specifications were still not ready. 
  And as a result there were machines where the floating-point hardware 
was very good, such as the VAX, and some where it was awful.  (The IBM 
360/370 family in particular.)

If we had tried to add the math libraries into the base standard in 
1981/82, the best that IBM hardware could have done was probably digits 
1 for single precision and digits 4 for double precision.  (Yes, the IBM 
floating point model, combined with the known algorithms for the 
trancendental functions, was that bad.  And there were C, Fortran, and 
BASIC implementations which did that badly, not on difficult operations 
like X**Y, but on sine and tangent.)  Do you think IBM would have gone 
along with that?  I don't, and I was there.

Also there was a desire to make it possible to compile an Ada program on 
a machine with 256k of main memory.  Back then that wasn't an L2 cache 
on your laptop computer.  There weren't any laptop computers, and many 
mainframes in use had 256k of memory or less.  (Most VAX 11/780s were 
shipped with 128k of memory, although customers usually upgraded that 
pretty quickly.  In fact EMC got its start selling memory upgrades for 
VAXes.)

-- 
                                            Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

O.K. I'll conceed that they eventually got it fixed. But my point was 
that a) it would have been easy to create a spec that at least provided 
a portable "standard" interface right from the get-go and b) that if 
there was a mechanism for extending the language - at least with respect 
to libraries - that didn't require updating the ISO standard, it would 
not be nearly so difficult or time-consuming to get these sort of 
corrections made.

I like having the standard and the ARM being as thorough as it is. I'd 
just like to see a mechanism for getting things like library components 
"standardized" across compilers without needing to go through all the 
rigamarole that has to happen in order to update the ARM. Had such a 
mechanism been in place, getting the numerics packages added at a 
post-Ada83 date would have been a piece of cake. It would also enable us 
to get extensions to the language capabilities done in some cycle time 
smaller than 10 years.

MDC


Robert I. Eachus wrote:
> 
> 
> But the NumWG work did result in an ISO standard, well before Ada 95 
> came along.  It probably would have been nice to have the ACVC require 
> the vendors provide exactly that package but that didn't happen. 
> However, the packages, including Complex and Simple packages were 
> printed as an issue of Ada Letters, including all the specs, and a place 
> to get a portable generic implementation.
> 
> As I said, it would have been nice if it had happened faster, but it 
> didn't.  Those four packages were effectively folded into the numerics 
> annex of Ada 95.  It would have been nice if the work had finished 
> sooner.  But that was not the big issue.  The big issue, which Ada 95 
> implements a nice compromise on, was whether Ada should specify the 
> accuracy of floating-point arithmetic.  At the time Ada 83 was being 
> finalized, the IEEE floating point specifications were still not ready. 
>  And as a result there were machines where the floating-point hardware 
> was very good, such as the VAX, and some where it was awful.  (The IBM 
> 360/370 family in particular.)
> 
> If we had tried to add the math libraries into the base standard in 
> 1981/82, the best that IBM hardware could have done was probably digits 
> 1 for single precision and digits 4 for double precision.  (Yes, the IBM 
> floating point model, combined with the known algorithms for the 
> trancendental functions, was that bad.  And there were C, Fortran, and 
> BASIC implementations which did that badly, not on difficult operations 
> like X**Y, but on sine and tangent.)  Do you think IBM would have gone 
> along with that?  I don't, and I was there.
> 
> Also there was a desire to make it possible to compile an Ada program on 
> a machine with 256k of main memory.  Back then that wasn't an L2 cache 
> on your laptop computer.  There weren't any laptop computers, and many 
> mainframes in use had 256k of memory or less.  (Most VAX 11/780s were 
> shipped with 128k of memory, although customers usually upgraded that 
> pretty quickly.  In fact EMC got its start selling memory upgrades for 
> VAXes.)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Robert I. Eachus]

Marin David Condic wrote:

> I like having the standard and the ARM being as thorough as it is. I'd 
> just like to see a mechanism for getting things like library components 
> "standardized" across compilers without needing to go through all the 
> rigamarole that has to happen in order to update the ARM. Had such a 
> mechanism been in place, getting the numerics packages added at a 
> post-Ada83 date would have been a piece of cake. It would also enable us 
> to get extensions to the language capabilities done in some cycle time 
> smaller than 10 years.

We (meaning the ARG and compiler vendors) have been getting better at 
that.  But even with unlimited money, standards move very slowly.

The other thing that you have to remember is that the programming 
culture around Ada had not developed when the original ANSI standard was 
produced.  I was surprised, and so were a lot of other people, at how 
the Ada culture developed in a way that was loathe to use almost 
anything that wasn't in the standard.

Even more surprising was the antipathy towards using representation 
attributes and other Chapter 13 features.  By the time the 9X effort was 
underway, no one was really surprised by the number of change requests 
that basically translated to, "We want to do unchecked conversions, but 
our coding standards don't allow us to use Unchecked_Conversion."

A sort of funny story about this happened when Dave Emery, Ben Brosgol 
and I published the ADAR components. I got a call from Rational.  My 
code wouldn't compile because it had an Unchecked_Conversion to an 
access type, and the Rational compiler didn't allow that.  I explained 
nicely that this particular use would be eliminated in Ada 9X by child 
packages, and I had done it to keep the visible package interface clean. 
  Then I told him how to modify the code to work in the Rational 
environment.

Afterwards, I asked why Rational thought it was so important to protect 
users from this particular use of Unchecked_Conversion.  He explained 
how Rational mananged storage and how it would be broken by converting 
an address to a pointer.*  I said, "But in this case I am using 
Unchecked_Conversion to convert to an object of a private type to 
itself!"  He looked at the code a bit more and said, "Maybe we should 
allow converting access types to access types..."

I don't know if Rational did modify their compiler.  But the point is 
that Rational, and their customers, thought that limiting the use of 
Unchecked_Conversion was a good thing.  Even in this case, where as I 
said, in Ada 95, one package would be a child of the other, so no 
conversion, checked or otherwise, would be required.

*Yes, they did garbage collection on the Rational hardware, but I don't 
think Rational does full garbage collection anymore.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic]

Robert I. Eachus wrote:
> 
> We (meaning the ARG and compiler vendors) have been getting better at 
> that.  But even with unlimited money, standards move very slowly.
> 

It isn't just money. Its that a standard that changes once a week isn't 
really much of a standard, is it? ;-)

But at the end of the day, if there were a library that existed as a 
"reference implementation" and it was maintained under the watchful eye 
of the ARG & Vendors and it was distributed along with most vendor's 
compilers, you'd have a mechanism for dealing with problems like lack of 
a "standard" square root routine as these things came up. I don't think 
anybody wants to see the syntax and semantics of the Ada language itself 
change on a quarterly basis, but a library could easily be released on a 
schedule like that and so long as it has some mantle of "officialness" 
and is distributed with most compilers, it becomes a mechanism for 
plugging up holes as they are found.

Its not that the job wouldn't still require some careful consideration 
regarding exactly what got into the library, what sort of specifications 
would be adopted and what the semantics should be for the 
implementations. You'd probably want the ARG/Vendors to come to some 
agreement about the intent of a given package and what its spec should 
look like. You'd also want them to do some "due diligence" to look over 
whatever has been produced to determine that it was of acceptable 
quality. Beyond that, you could probably leave lots of the details in 
the hands of whoever is actually doing the implementation. (That's 
typically how software gets built in "real world" projects anyway, 
right? And I think we're talking essentially about commissioning the 
development of a single body of software to be shared by all interested 
parties rather than the development of a "standard" that would be 
implemented by many interested parties.) So what I'm thinking about is a 
bit of a different situation than what the ARG and Vendors are typically 
doing with the standard. Rather than debating it endlessly and 
struggling to write formal, verifiable standards, they'd be in the 
business of outlining in broad-brush strokes what they thought they 
wanted for some specific subsystem and then reviewing the end-product to 
see if it met their intent sufficiently to warrant being released.

There are two catches here: One is agreement on the part of the ARG and 
Vendors that something like this should be done & accepted as part of 
"Ada" in some manner. (Its got to end up in most compiler distributions 
or its just another library dangling around on the Internet somewhere.) 
The other problem is to get people to develop the actual code once the 
Keepers Of The Eternal Flame have decided that a given thing is worth 
inclusion in the library. I think both these issues could be resolved. 
#1 is just the willingness of the ARG & Vendors to go down that path. 
(Yes, it would mean diverting some attention to it, so it isn't without 
cost. But if its worth having, its worth spending some $$$ to get it, 
right?) #2 is trickier, but we've seen in the past a variety of 
volunteer efforts in a number of settings that have attempted to do 
parts of this job. That means there are people out there willing to do 
the work, but they perhaps need some direction and incentivising in 
order to accomplish specific goals. I think it could be done with a 
little creativity. Get #1 resolved and somehow, some way, #2 can be 
brought about.


> The other thing that you have to remember is that the programming 
> culture around Ada had not developed when the original ANSI standard was 
> produced.  I was surprised, and so were a lot of other people, at how 
> the Ada culture developed in a way that was loathe to use almost 
> anything that wasn't in the standard.
> 

Sure. But this is not a goal in and of itself. Its more a symptom. (And 
it may be due to Ada over-selling the case for "portability". 
Realistically, most programs never port to a different compiler or 
platform.) I think most Ada users would be thinking along the lines of: 
"If its in the standard, then I know what it does and I can count on it 
being there. If its not in the standard, I may not be portable to a 
different implementation and I may not be able to find out what it does 
without difficulty." That doesn't automatically translate into a "Must 
Be In The Standard" requirement. If Ada had a library that was 
maintained as a reference implementation and distributed with most 
compilers, in some ways this would be even *more* "Standard" than 
something in the ARM. The ARM allows lots of wiggle room that can result 
in significant differences between implementations. If you had a 
reference implementation of a library, you'd have far less divergence in 
behavior between implementations because each vendor's realization of 
the library starts from a common code base. That, coupled with the fact 
that the end user is (presumably) getting source code for the library 
under some reasonably non-restrictive license and I think you'd see 
little difference in how the library would be treated compared to how 
the standard is treated.


> Even more surprising was the antipathy towards using representation 
> attributes and other Chapter 13 features.  By the time the 9X effort was 
> underway, no one was really surprised by the number of change requests 
> that basically translated to, "We want to do unchecked conversions, but 
> our coding standards don't allow us to use Unchecked_Conversion."
> 

I remember back in the olden-days of Ada83 how various lynch mobs formed 
up around some of the vendors, all of them carrying torches and 
pitchforks and chanting "Give Us Chapter 13 - Or Else!" :-) Chapter 13 
is absolutely essential for embedded system development and this was, of 
course, the original intended market for the language. Ada really 
succeeded in alienating that market who pretty much all went out and 
bought C compilers because they could at least get their job done and it 
didn't cost them their first born sons in order to get a working 
compiler. Having successfully driven away the original intended market, 
the ones that were left didn't care much about Chapter 13. But not to 
worry - Ada succeeded in finding enough other ways of alienating the 
remaining crowd that lack of Chapter 13 wasn't necessary to help it 
snatch defeat from the jaws of victory. And probably because Ada had 
concentrated on convincing its users on the virtues of portability and 
type safety, it actually might have created the climate of fear that 
lead to coding standards forbidding things in Chapter 13. Its a shame 
that the case got over-sold to the point where people wanted to chop out 
a critical part of the language rather than take a more practical view 
that aimed to use the features judiciously when and where it made sense.

The amazing thing is that Ada has had lots of die-hard fans who were 
convinced of the inherent goodness of the language. But despite that 
following, the language somehow managed to squander the capital by 
failing in its realization of the vision. Lots of things could be cited 
as missed opportunities. Initial poor quality of compilers, outrageously 
priced compilers, too ambitious a language for the hardware available at 
the time, too "big" a language for some of the smaller microprocessors 
it might have targeted, lack of cross-compilers for embedded hardware, 
etc. I'm sure we could go on but the real question ought to be "How do 
we take what we still have and parlay that into a substantially bigger 
market?"

I think the answer to that question is to focus in on Customer Needs. 
What is it that the average programmer in a given domain needs to get 
his job done? What are the important factors in satisfying that user? 
Rather than looking at this or that syntactic/semantic element of the 
language and asking if it can be enhanced or otherwise made "better", 
the focus should be on "If we do this thing to the language, how does 
that help the Ada user to get his job done faster, better, cheaper?" 
IMHO, most language changes might fall into the category of "This would 
be nice to have if you have unlimited resources to implement things, but 
I could find a reasonable way to program without it..." Whereas a 
library of useful tools that gave me lots of extra leverage because I 
won't be re-inventing the wheel would likely start making a much bigger 
impact on how useful the language would be for me.

The opportunity is there. We have yet to see if Ada can figure out how 
to exploit it.

> 
> I don't know if Rational did modify their compiler.  But the point is 
> that Rational, and their customers, thought that limiting the use of 
> Unchecked_Conversion was a good thing.  Even in this case, where as I 
> said, in Ada 95, one package would be a child of the other, so no 
> conversion, checked or otherwise, would be required.
> 
>

"Limiting the use..." probably is a good thing - but a limiting that 
should be done in the best engineering judgement of the end-user. I 
guess I sometimes resent a compiler trying to save me from myself when I 
am insisting "No, I *really* meant to do that and I *know* what the 
consequence is, so please get out of my way and stop trying to 'help' 
me!" Sometimes Ada gets too picky for the end-user's own good. But then 
again, I can't think of a language I've ever used that *didn't* get in 
my way sometimes, so maybe this is just normal. Still, for Ada's 
original intended audience, I think it was important not to take such an 
extreme approach to items like Unchecked_Conversion.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================