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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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.

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

[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

[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: 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

[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

[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

[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 ?

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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.