Manifesto against Vector

Manifesto against Vector

[Alexander E. Kopilovich]

As it follows from the Minutes of #22 ARG Meeting 
(http://www.ada.auth.org/ai-files/minutes/min-0403.html#AI302),
ARG chose the name Vector for Unbounded_Array container.
Here is a quotation from the minutes:

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

What should the names of the packages be?
  Pascal does not like Vector, because of confusion with AI-296
  type Vector. Tucker points out that both C++ and Java use
  Vector for this. Pascal would like Sequence. But both Vector
  and List are Sequences. Vector is chosen.

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

I think (and in fact I'm pretty sure) that this apparently tiny decision
will either produce very unpleasant results for the whole AI-302 Container
library (for example, by provoking competing mutations) or even negatively
(although perhaps not heavily) influence attitude to Ada in general.
(It is a well-known way to political defeat - trying to appease your opponents
at the "little" expense of your supporters).

The most essential argument against the name Vector for Unbounded_Array in
Ada is that true vectors in Ada usually should be represented by ordinary
arrays and not by any container from Container library (unlike C++ and Java,
where true vectors often enough should be represented using correspondily
named templates/classes/objects).

This is quite obvious that the most natural name for this container in Ada
is Unbounded_Array, because this name perfectly associates with both "array"
and Unbounded_String, for which it is natural generalization.

There is very little doubt that if there weren't C++ and Java with their
Vector then Unbounded_Array would emerge naturally and would be accepted
without much discussion.

So the problem seems to be a temptation to make a concession to C++ and Java
communities (as well as to their managers) in rather unfounded hope that this
can somehow decrease alienation.

As for the name Sequence (mentioned in the Minutes) - it might be acceptable,
but it seems it is better to use it for an interface name (that interface may
be useful for data structures more complex that Unbounded_Arrays or Lists).

Finally: why I'm sending this manifesto here, in comp.lang.ada newsgroup,
and not in Ada-Comment mailing list? Just because now I doubt that ARG is able
to focus on this matter. The ARG, at least active members of ARG, who attend
ARG meetings and take decisions, seems to be overloaded with many other, often
difficult and/or time-consuming problems, so they will not waste their time and
attention for this apparently little nuisance any more.





Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Manifesto against Vector

[Marius Amado Alves]

> As it follows from the Minutes of #22 ARG Meeting
> (http://www.ada.auth.org/ai-files/minutes/min-0403.html#AI302),
> ARG chose the name Vector for Unbounded_Array container.

I don't feel so *strong* about this as Kopilovich, but my feelings are in
the same direction.

Curiously enough, "Unbounded_Arrays for Unbounded Arrays" was the title of
my position paper in the kickoff workshop in Vienna, 2002, that ultimately
lead to Ada.Containers.

In the meanwhile "Vectors" stuck because of the Charles heritage, and also
because until recently there was a chance that the library would include
also fixed and bounded varieties, and somehow "vectors" didn't sound so bad
for that. But these varieties are definitely not there, so yes, ARG, please
change to "Unbounded_Arrays".

Re: Manifesto against Vector

[(see below)]

On 4/5/04 10:07 am, in article
mailman.64.1083661659.313.comp.lang.ada@ada-france.org, "Marius Amado Alves"
<amado.alves@netcabo.pt> wrote:

>> As it follows from the Minutes of #22 ARG Meeting
>> (http://www.ada.auth.org/ai-files/minutes/min-0403.html#AI302),
>> ARG chose the name Vector for Unbounded_Array container.
> 
...
> so yes, ARG, please  change to "Unbounded_Arrays".

I am with Alexander and Marius on this.
"Vector" is inaccurate and misleading for this use.
An Ada standard should not endorse sloppy terminology.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Manifesto against Vector

[Martin Dowie]

"(see below)" <byaldnif@blueyonder.co.uk> wrote in message
news:BCBD545F.86404%byaldnif@blueyonder.co.uk...
> On 4/5/04 10:07 am, in article
> mailman.64.1083661659.313.comp.lang.ada@ada-france.org, "Marius Amado
Alves"
> <amado.alves@netcabo.pt> wrote:
>
> >> As it follows from the Minutes of #22 ARG Meeting
> >> (http://www.ada.auth.org/ai-files/minutes/min-0403.html#AI302),
> >> ARG chose the name Vector for Unbounded_Array container.
> >
> ...
> > so yes, ARG, please  change to "Unbounded_Arrays".
>
> I am with Alexander and Marius on this.
> "Vector" is inaccurate and misleading for this use.
> An Ada standard should not endorse sloppy terminology.

1) "Vector" for better or worse, is now a widely accepted term for this type
of container;
2) comp.lang.ada submissions count for zilch and the ARG are just going to
ignore this thread; and
3) This has been debated ad nausium by the ARG (see
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00302.TXT?rev=1.13)

I'm afraid this one is a case of sucking it up and living with it - there
are _way_ more interesting things in the new language revision to get heat
up about.

My $0.02

-- Martin

Re: Manifesto against Vector

[chris]

Alexander E. Kopilovich wrote:
> 
> I think (and in fact I'm pretty sure) that this apparently tiny decision
> will either produce very unpleasant results for the whole AI-302 Container
> library (for example, by provoking competing mutations) or even negatively
> (although perhaps not heavily) influence attitude to Ada in general.
> (It is a well-known way to political defeat - trying to appease your opponents
> at the "little" expense of your supporters).

This is one reason why I'm perfectly happy to program in a community 
effort in OCaml, Erlang, Oz, C++, C, C# and Java (and maybe even 
Haskell) but not in an Ada effort now...


While not armageddon loop

New_Thread;

Put_Message ("We need +=, -=, cos it's more efficient.");
Put_Reply ("No, it's evil. c++ has it.  don't concede to c(++)");
Put_Reply ("Not necessarily. <good argument...>");

New_Thread;

Put_Message ("It's a vector");
Put_Reply ("No, it's an unbounded array.  Vectors are spawn of real 
world languages like c++");

New_Thread;

Put_Message ("We needed containers for Ada.  We chose the 'Charles 
proposal' as base since it's mature, as well as ideas from some other 
libraries");
Put_Reply ("Noooooooo!  Charles is the spawn of STL... i.e. C++!")

New_Thread;

Put_Message ("Ada is perfectly suited to real world applications as a 
language, but there are not a lot of libraries typical of desktop 
development for it.  That limits it's popularity");

Put_Reply ("Yes we want to make ada more popular, but for right now we 
can program jumbo jets!  That's good enough for me.");
Put_Reply ("I develop processor specific programs for webservers, that 
just need recompilation.  Just need to setup compilation environment, 
port libs x, y and z, compile and go!  Easy as Servlets.  Honest.");
Put_Reply ("Real world productivity is enhanced by the language.  Sure 
you need libraries, but the 2 fold increase in code productivity 
outweighs the 7 fold increase in development time caused by the lack of 
libraries!  Oh and 1 = 0 as shown here ...");
Put_Reply ("Let's Fork Thread");

Put_Message ("Ada is best language ever.  Why don't people use it more?");
Put_Reply ("Arianne 5");
Put_Reply ("- But Arianne 5 was the result of a management failure.");
Put_Reply ("-- Mud sticks.");
Put_Reply ("--- How can we wash it off?");
Put_Reply ("---- Wait until loop begins again");

Put_Reply ("Migration Costs");
...
Put_Reply ("----- How can we wash it off?");
Put_Reply ("------ Wait until loop begins again");

end loop;

New_Thread;

Put_Message ("The world is ending because it wasn't written in Ada!");
...
Put_Reply ("--- How can we wash it off?");
Put_Reply ("---- Wait until loop begins again");


Most niche language communities are similar, but the Ada one is not 
motivated or big enough in general to do anything without it falling 
apart without some serious dedication.  The other communities just get 
on with it, and go places!


> So the problem seems to be a temptation to make a concession to C++ and Java
> communities (as well as to their managers) in rather unfounded hope that this
> can somehow decrease alienation.

It is designed based on the STL, no?  In any event, this sounds like a 
load of hot air to me.  Why don't people stop focusing efforts on the 
littlest of the little details and deal with the real issues?  That's 
what the ARG are doing, and people like David Botton, Mr Heaney and 
others do.  The people who make the most noise, just make noise (the 
same noise at that) and put others off.

Re: Manifesto against Vector

[Jeffrey Carter]

While I agree that Vector is not the best name for this abstraction, I 
have expressed my opinion and the reasons behind it to the ARG during 
earlier discussions of AI-302-03, and the ARG chose Vector. The 
discussion is over. I can live with it.

-- 
Jeff Carter
"When danger reared its ugly head, he bravely
turned his tail and fled."
Monty Python and the Holy Grail
60

Re: Manifesto against Vector

[Marius Amado Alves]

[long rambling about how Adaists are, er... noisy]

Chris, you're mostly wrong. The serious discussions about advancing Ada are
100% free of antagonism towards C++. The arguments are always strictly
technical. Sure lessons learnt from all languages (including Ada 95) are
applied. But there's no fanatism involved. If it were we wouldn't have
Ada.Containers now, as it owes a lot to the STL of C++.

On the matter at hand, it's simply that we had postponed naming issues until
the design was done. Now it's done, and naming issues are not "noise"
anymore.

Re: Manifesto against Vector

[Marius Amado Alves]

> While I agree that Vector is not the best name for this abstraction, I
> have expressed my opinion and the reasons behind it to the ARG during
> earlier discussions of AI-302-03, and the ARG chose Vector. The
> discussion is over.

It's not over. It was tacitly postponed. I remember that discussion, and
I've just reviewed it. The main argument for "vectors" is that it is widely
used. Well, this argument is simply false. I my 20+ years of programming
languages "array" is clearly the term mostly used. "Vector" is just an
STLism and Java fad. There is additional experience exposed in the
discussion. Incidently, Kopolovich participated, and his arguments are
mostly right. As with all naming issues this one was tacitly postponed then
in favour of design issues. But now the design is done with, and it's time
to perfect naming. A similar thing happened with the indefinite elements
issue. It was once tacitly postponed, with the apparent tendency of *not* to
have them. But then when the more pressing issues cleared, the issue was
brought back, and the position inverted: we now have containers of
indefinite elements in the standard. Compared to this, changing "vectors" to
"arrays" will be a breeze. That said...

> I can live with it.

Me too.

Re: Manifesto against Vector

[Xenos]

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.68.1083695056.313.comp.lang.ada@ada-france.org...
> used. Well, this argument is simply false. I my 20+ years of programming
> languages "array" is clearly the term mostly used. "Vector" is just an
> STLism and Java fad. There is additional experience exposed in the
>

Oh is it?  You never heard of the language APL or did any DSP programming?
I also seem to recall that in discreet logic a 1d array is called a vector,
and a 2d array is called a matrix.

DrX

Re: Manifesto against Vector

[Marius Amado Alves]

> > used. Well, this argument is simply false. I my 20+ years of programming
> > languages "array" is clearly the term mostly used. "Vector" is just an
> > STLism and Java fad. There is additional experience exposed in the
> >
>
> Oh is it?  You never heard of the language APL or did any DSP programming?
> I also seem to recall that in discreet logic a 1d array is called a
vector,
> and a 2d array is called a matrix.

As I said, most of these items were discussed. In alternative 3.
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT?rev=1.5

Re: Manifesto against Vector

[Peter C. Chapin]

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in 
news:mailman.67.1083691152.313.comp.lang.ada@ada-france.org:

> Chris, you're mostly wrong. The serious discussions about advancing Ada are
> 100% free of antagonism towards C++. The arguments are always strictly
> technical. Sure lessons learnt from all languages (including Ada 95) are
> applied. But there's no fanatism involved. If it were we wouldn't have
> Ada.Containers now, as it owes a lot to the STL of C++.

As a C++ programmer in the process of learning Ada I appreciate the fact that 
Ada is in the process of adopting an STL-like container library. It will 
reduce my learning curve and that's a nice thing. Perhaps other C++ 
programmers will feel similarly. This is not to say that STL is the be-all 
and end-all of container libraries, of course. Also considering that Ada has 
real arrays, I can appreciate how the name Unbounded_Array makes sense.

Peter

Re: Manifesto against Vector

[Xenos]

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94DFA9B37ACCApchapinsovernet@207.106.92.237...
> "Marius Amado Alves" <amado.alves@netcabo.pt> wrote in
> news:mailman.67.1083691152.313.comp.lang.ada@ada-france.org:
>
> > Chris, you're mostly wrong. The serious discussions about advancing Ada
are
> > 100% free of antagonism towards C++. The arguments are always strictly
> > technical. Sure lessons learnt from all languages (including Ada 95) are
> > applied. But there's no fanatism involved. If it were we wouldn't have
> > Ada.Containers now, as it owes a lot to the STL of C++.
>
> As a C++ programmer in the process of learning Ada I appreciate the fact
that
> Ada is in the process of adopting an STL-like container library. It will
> reduce my learning curve and that's a nice thing. Perhaps other C++
> programmers will feel similarly. This is not to say that STL is the be-all
> and end-all of container libraries, of course. Also considering that Ada
has
> real arrays, I can appreciate how the name Unbounded_Array makes sense.
>
> Peter

As a programmer of both Ada and C++, I too am glad.  When I have to use Ada,
I sorely miss the STL.  Of course, when I have to use C++, I miss unique
(new) types derived from primative types...and ranges (oh how I miss
ranges!), oh and arrays as first-class types.

Re: Manifesto against Vector

[Russ]

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message news:<mailman.68.1083695056.313.comp.lang.ada@ada-france.org>...
> > While I agree that Vector is not the best name for this abstraction, I
> > have expressed my opinion and the reasons behind it to the ARG during
> > earlier discussions of AI-302-03, and the ARG chose Vector. The
> > discussion is over.
> 
> It's not over. It was tacitly postponed. I remember that discussion, and
> I've just reviewed it. The main argument for "vectors" is that it is widely
> used. Well, this argument is simply false. I my 20+ years of programming
> languages "array" is clearly the term mostly used. "Vector" is just an
> STLism and Java fad. There is additional experience exposed in the
> discussion. Incidently, Kopolovich participated, and his arguments are
> mostly right. As with all naming issues this one was tacitly postponed then
> in favour of design issues. But now the design is done with, and it's time
> to perfect naming. A similar thing happened with the indefinite elements
> issue. It was once tacitly postponed, with the apparent tendency of *not* to
> have them. But then when the more pressing issues cleared, the issue was
> brought back, and the position inverted: we now have containers of
> indefinite elements in the standard. Compared to this, changing "vectors" to
> "arrays" will be a breeze. That said...

Some of you may recall that I am an aerospace engineer rather than a
software engineer. My objection the the name "vector" is that it has a
specific meaning in science and engineering, and its not an unbounded
array. A vector is a physical quantity with an direction and a
magnitude. Force and velocity are vectors, for example.

In state estimation and control theory, a "state vector" is a list of
scalars and/or vectors that could include such things as position,
velocity, attitude, etc. It is manipulated according to the rules of
"Linear Algebra," an amazingly complex and useful branch of
mathematics that deals with vectors and matrices.

When I first heard about C++ STL "vectors," I was a bit puzzled as to
why they chose to override such a common and useful name. I agree with
the original poster that Ada should not repeat the mistake.

By the way, where do we stand on "with/use"? Ada needs it, and I hope
you guys aren't fumbling the ball on that!

Re: Manifesto against Vector

[tmoran]

> the name "vector" is that it has a specific meaning in science and
> engineering, and its not an unbounded array.
> ...
> When I first heard about C++ STL "vectors," I was a bit puzzled as to
> why they chose to override such a common and useful name. I agree with
> the original poster that Ada should not repeat the mistake.
   Perhaps though it's time to drop the assumption that programmers have
any background in science, engineering, or math.  If your background was
"'C for Dummies' is easy and pays better than waiting tables", then the
word "vector" has no implications but sounds tech-y and impressive. :(

Re: Manifesto against Vector

[Georg Bauhaus]

Xenos <dont.spam.me@spamhate.com> wrote:
: 
: "Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message
: news:mailman.68.1083695056.313.comp.lang.ada@ada-france.org...
:> used. Well, this argument is simply false. I my 20+ years of programming
:> languages "array" is clearly the term mostly used. "Vector" is just an
:> STLism and Java fad. There is additional experience exposed in the
:>
: 
: Oh is it?  You never heard of the language APL or did any DSP programming?

APL: A Programming Language, or Array Programming Language.
A vector in APL is a 1d array of fixed rank and shape.
Likewise a matrix is an array of rank 2.
If I'm not mistaken, arrays in APL cannot be lengthened
or shrunk, even by selective assignment, so the length of each
axis is fixed.  (If you want an array of different shape, you make
a new one from the old one.)

The "vectors" in question can have a changing number of components
along their only axis.



-- Georg

Re: Manifesto against Vector

[Kevin Hostelley]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message > > I am with Alexander and Marius on this.

> > "Vector" is inaccurate and misleading for this use.
> > An Ada standard should not endorse sloppy terminology.
> 
> 1) "Vector" for better or worse, is now a widely accepted term for this type
> of container;

IMO, the only time that a widely accepted (although inaccurate) term
should be used is if any other term you use would cause confusion.  I
don't think any programmer would have a problem understanding
"Unbounded_Array".


My $.02

Kevin Hostelley
khostelley@y 
            a
             h
              o
               o.com

Re: Manifesto against Vector

[Georg Bauhaus]

Kevin Hostelley <khostelley@yahoo.com> wrote:
 
: IMO, the only time that a widely accepted (although inaccurate) term
: should be used is if any other term you use would cause confusion.  I
: don't think any programmer would have a problem understanding
: "Unbounded_Array".
 
: My $.02

Another 2 cent: the `v' in vector is much closer in appearance to
the '<' and '>' found in cool languages. The 'U' in Unbounded_Array
looks similar to the boring '(' and ')' in Ada.  :->

-- Georg

Re: Manifesto against Vector

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0405042128.1a322885@posting.google.com...
> By the way, where do we stand on "with/use"? Ada needs it, and I hope
> you guys aren't fumbling the ball on that!

Russ,

As I pointed out to you when you first raise this:

Discussions on comp.lang.ada count for squat. If you have a proposal, go to
http://www.ada-auth.org/, read the procedure (e.g.
http://www.ada-auth.org/ai-files/minutes/ARGprc20.PDF - there are plain text
or Word versions available too) and submit an AI

I can tell you now that I would bet a months salary (before tax!) that it
would be rejected but you're free to try.

If you do submit a proposal, get your tin hat on and be prepared to bat your
corner - the ARG don't take prisoners! And that's not because they're
zealots or anything, they just _know_ the language and the _rationale_
behind the language better than 99.9999999999999999% of anyone else.

Cheers

-- Martin

Re: Manifesto against Vector

[Marius Amado Alves]

On Wednesday 05 May 2004 06:28, Russ wrote:
[more evidence in favour of "unbounded arrays"]

I think it's time someone posts a terse request for the name change to the 
ARG. In sum, "vectors" has problems, "unbounded arrays" does not, and 
"unbounded arrays" is indeed the established Ada terminology.

> ... By the way, where do we stand on "with/use"? Ada needs it...

Not badly enough, I'm afraid. This is a change where clearly the cons beat the 
pros. The cons include just too many things to check and reword.

Re: Manifesto against Vector

[Robert I. Eachus]

Jeffrey Carter wrote:

> While I agree that Vector is not the best name for this abstraction, I 
> have expressed my opinion and the reasons behind it to the ARG during 
> earlier discussions of AI-302-03, and the ARG chose Vector. The 
> discussion is over. I can live with it.

Technically, it is not over.  I think that this particular issue is a 
pimple on the rear of fly, but it is a good example of the differences 
in the roles of WG9 and the ARG.

The ARG is a sub-group of WG9 tasked with finding solutions to language 
issues that arise.  When the ARG has a solution that seems to deal with 
all the technical aspects of an issue, it is forwarded to WG9.  In the 
case of the Ada0Y extensions, the approved changes will be submitted in 
a group to SC22, and then to ISO/IEC JTC1 for approval.

Non-technical language issues are normally dealt with at the WG9 level. 
  It is fairly common for the ARG to come up with a good technical 
solution, and for WG9 to refer it back to the ARG to find a different 
solution.

In this case, I personally don't think that this is a big enough issue 
to merit that kind of attention.  But I don't dictate to WG9 
delegations.  Note that WG9 delegations represent ISO member countries. 
  So, for example, a name that was a swear word in, say, Polish would be 
the sort of issue WG9 would address, not the ARG.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: Manifesto against Vector

[Russ]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<c7b8oa$o6v$1@titan.btinternet.com>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0405042128.1a322885@posting.google.com...
> > By the way, where do we stand on "with/use"? Ada needs it, and I hope
> > you guys aren't fumbling the ball on that!
> 
> Russ,
> 
> As I pointed out to you when you first raise this:
> 
> Discussions on comp.lang.ada count for squat. If you have a proposal, go to
> http://www.ada-auth.org/, read the procedure (e.g.
> http://www.ada-auth.org/ai-files/minutes/ARGprc20.PDF - there are plain text
> or Word versions available too) and submit an AI

Thanks for the information.

> I can tell you now that I would bet a months salary (before tax!) that it
> would be rejected but you're free to try.

Just as I feared. They *are* fumbling the ball.

> If you do submit a proposal, get your tin hat on and be prepared to bat your
> corner - the ARG don't take prisoners! And that's not because they're
> zealots or anything, they just _know_ the language and the _rationale_
> behind the language better than 99.9999999999999999% of anyone else.

That may be so, but this particular issue is simple enough even for an
ameteur like me. I know that

with/use Ada.Integer_Text_IO;

is cleaner and simpler than

with Ada.Integer_Text_IO; use Ada.Inteqer_Text_IO

And I also that it is a trivial matter to parse the former to produce
the latter. I could do it myself in a few minutes. Nor does it break
compatibility with legacy code in any way. I see absolutely no
reasonable objection to "with/use" (but I have a funny feeling that I
may soon be bombarded with a lot of unreasonable objections).

By the way, the following is for those of you who prefer to read
everything twice:

That may be so, but this particular issue is simple enough even for an
ameteur like me. I know that

with/use Ada.Integer_Text_IO;

is cleaner and simpler than

with Ada.Integer_Text_IO; use Ada.Inteqer_Text_IO

And I also that it is a trivial matter to parse the former to produce
the latter. I could do it myself in a few minutes. Nor does it break
compatibility with legacy code in any way. I see absolutely no
reasonable objection to "with/use" (but I have a funny feeling that I
may soon be bombarded with a lot of unreasonable objections).

Get the message? Or should I repeat it again?

Re: Manifesto against Vector

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0405051942.59af7456@posting.google.com...
> > I can tell you now that I would bet a months salary (before tax!) that
it
> > would be rejected but you're free to try.
>
> Just as I feared. They *are* fumbling the ball.

No - there are just many more pressing things to add to/fix in the language.

Go have a look at the list of AI and the minutes from the ARG meetings -
there is a _lot_ to get through.

None of the ARG are going to write this AI for you - if you want to suggest
it, please do. But don't start accusing the ARG of "fumbling" anything just
because they don't think that *your* pet hobby-horse should make it into the
next revision.

Sumbit an AI - prove me wrong! :-)

p.s. I'm not opposed to what you suggest but I (personally) just don't get
very excited by the idea. Now "interfaces" on the other hand!..

Re: Manifesto against Vector

[Jean-Pierre Rosen]

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


"Russ" <18k11tm001@sneakemail.com> a �crit dans le message de
[...]
> That may be so, but this particular issue is simple enough even for an
> ameteur like me. I know that
>
> with/use Ada.Integer_Text_IO;
>
> is cleaner and simpler than
>
> with Ada.Integer_Text_IO; use Ada.Inteqer_Text_IO
>
> And I also that it is a trivial matter to parse the former to produce
> the latter. I could do it myself in a few minutes. Nor does it break
> compatibility with legacy code in any way. I see absolutely no
> reasonable objection to "with/use" (but I have a funny feeling that I
> may soon be bombarded with a lot of unreasonable objections).
>
Since you asked for it... (but I'll try to have reasonable objections).
Note that I am known for being strongly *in favor* of the use clause.

I would strongly oppose this proposal for a very simple reason: it defeats the main goal of having separated with from use.
With is a library level clause; it tells: "this unit, somewhere needs that unit".
Use opens the visibility: it tells: "here is the scope where I actually use the unit". A use clause should always be for the
innermost context where the unit is actually used.

Therefore, you should *never* have a use clause as a context clause. If I need to have something visible everywhere in a unit, I use
the same style as when the visibility is more restricted, i.e. I don't write:

with Foo; use Foo;
procedure P is
...
end P;

but rather:

with Foo;
procedure P is
   use Foo;
   ...
end P.

Allowing with/use would simply encourage a style that should be discouraged altogether. QED.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Manifesto against Vector

[Dmitry A. Kazakov]

On Thu, 6 May 2004 09:03:54 +0200, "Jean-Pierre Rosen"
<rosen@adalog.fr> wrote:

>Since you asked for it... (but I'll try to have reasonable objections).
>Note that I am known for being strongly *in favor* of the use clause.
>
>I would strongly oppose this proposal for a very simple reason: it defeats the main goal of having separated with from use.
>With is a library level clause; it tells: "this unit, somewhere needs that unit".

Why that should be told? I'd say that "with" is superfluous.

>Use opens the visibility: it tells: "here is the scope where I actually use the unit". A use clause should always be for the
>innermost context where the unit is actually used.

Maybe, but it should be placed at the beginning of the context. So it
is just one line difference. Not a big issue, IMO.

>Therefore, you should *never* have a use clause as a context clause. If I need to have something visible everywhere in a unit, I use
>the same style as when the visibility is more restricted, i.e. I don't write:
>
>with Foo; use Foo;
>procedure P is
>...
>end P;
>
>but rather:
>
>with Foo;
>procedure P is
>   use Foo;
>   ...
>end P.

This might work with bodies, but it does not with specifications. What
would you do with:

with Foo;
procedure P (<something here needs visibility of Foo>);

>Allowing with/use would simply encourage a style that should be discouraged altogether. QED.

Oh, Use is Use, and With is With, and never the twain shall meet, ...
(:-))

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

Re: Manifesto against Vector

[Vinzent 'Gadget' Hoefler]

Dmitry A. Kazakov wrote:

>On Thu, 6 May 2004 09:03:54 +0200, "Jean-Pierre Rosen"
><rosen@adalog.fr> wrote:
>
>>Since you asked for it... (but I'll try to have reasonable objections).
>>Note that I am known for being strongly *in favor* of the use clause.
>>
>>I would strongly oppose this proposal for a very simple reason: it
>>defeats the main goal of having separated with from use.
>>With is a library level clause; it tells: "this unit, somewhere needs
>>that unit".
>
>Why that should be told? I'd say that "with" is superfluous.

No! If at all then it is "use" which is superfluous. ;-)

>Maybe, but it should be placed at the beginning of the context. So it
>is just one line difference. Not a big issue, IMO.

It is more than a single line. Consider this:

|with Interfaces;
 ^^^^
|
|package body Timer is
|
[...]
|   function Hi_Byte (Value : in Interfaces.Unsigned_16)
|     return Interfaces.Unsigned_8 is
|      use type Interfaces.Unsigned_16;
       ^^^
|   begin
|      return Interfaces.Unsigned_8 (
|          Interfaces.Shift_Right (Value, 8) and 16#FF#);
|   end Hi_Byte;

>This might work with bodies, but it does not with specifications.

Well, most of it does.

The only part where I used "use" yet was in the private part of a
package spec, and this was just because I am lazy and wanted to have
"System.Storage_Elements.To_Address" visible there as the simpler
"To_Address". I could have used "renames" instead, I guess.

>with Foo;
>procedure P (<something here needs visibility of Foo>);

Simple: Use the full name there. If it's too long for you, I'd say
rename it.

>>Allowing with/use would simply encourage a style that should be
>>discouraged altogether. QED.
>
>Oh, Use is Use, and With is With, and never the twain shall meet, ...
>(:-))

It's much more simple: Never use "use". :)


Vinzent.

Re: Manifesto against Vector

[Dmitry A. Kazakov]

On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler
<nntp-2004-05@t-domaingrabbing.de> wrote:

>Dmitry A. Kazakov wrote:
>
>>On Thu, 6 May 2004 09:03:54 +0200, "Jean-Pierre Rosen"
>><rosen@adalog.fr> wrote:
>>
>>>Since you asked for it... (but I'll try to have reasonable objections).
>>>Note that I am known for being strongly *in favor* of the use clause.
>>>
>>>I would strongly oppose this proposal for a very simple reason: it
>>>defeats the main goal of having separated with from use.
>>>With is a library level clause; it tells: "this unit, somewhere needs
>>>that unit".
>>
>>Why that should be told? I'd say that "with" is superfluous.
>
>No! If at all then it is "use" which is superfluous. ;-)

How so? "Use" has some semantical sense. It changes visibility. You
might claim that this is not necessary, but that would be another
story. On the contrary "with" has no other sense than being just a
hint to the compiler/linker. It could well be just a pragma, like the
elaboration control ones.

>>Maybe, but it should be placed at the beginning of the context. So it
>>is just one line difference. Not a big issue, IMO.
>
>It is more than a single line. Consider this:
>
>|with Interfaces;
> ^^^^
>|
>|package body Timer is
>|
>[...]
>|   function Hi_Byte (Value : in Interfaces.Unsigned_16)
>|     return Interfaces.Unsigned_8 is
>|      use type Interfaces.Unsigned_16;
>       ^^^
>|   begin
>|      return Interfaces.Unsigned_8 (
>|          Interfaces.Shift_Right (Value, 8) and 16#FF#);
>|   end Hi_Byte;

We have no "with type" clause, so this example is incorrect.

>>with Foo;
>>procedure P (<something here needs visibility of Foo>);
>
>Simple: Use the full name there. If it's too long for you, I'd say
>rename it.

It cannot be. P is a unit! (:-))

Then semantics of renaming is inconsitent with one of "use", or better
to say, simply inconsistent. This is the source of numerous problems:

with Ada.IO_Exceptions;
package A is
   End_Error : exception renames Ada.IO_Exceptions.End_Error;
   X_Error : exception;
end A;
--------
with A;
package B renames A;
--------
with A; use A;
with B; use B;
with Ada.IO_Exceptions; use Ada.IO_Exceptions;
procedure C is
begin
   ...
exception
   when X_Error =>
      -- This is OK, multiple views of same thing
      ...
   when End_Error =>
      -- This is illegal, viewing two different views of one thing!
      ...
end C;

>>>Allowing with/use would simply encourage a style that should be
>>>discouraged altogether. QED.
>>
>>Oh, Use is Use, and With is With, and never the twain shall meet, ...
>>(:-))
>
>It's much more simple: Never use "use". :)

Once I will become a rich man, I will buy a LCD with horizontal
resolution of 10240 pixels, install small fonts, get spectacles ...
(:-))

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

Re: Manifesto against Vector

[Vinzent 'Gadget' Hoefler]

Dmitry A. Kazakov wrote:

>On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler
><nntp-2004-05@t-domaingrabbing.de> wrote:
>
>>Dmitry A. Kazakov wrote:
>>
>>>Why that should be told? I'd say that "with" is superfluous.
>>
>>No! If at all then it is "use" which is superfluous. ;-)
>
>How so? "Use" has some semantical sense. It changes visibility. You
>might claim that this is not necessary, but that would be another
>story. On the contrary "with" has no other sense than being just a
>hint to the compiler/linker.

And a idea to me which packages another one is using. This is
especially useful with some of the more "evil" parts of Ada like
Unchecked_Conversion. :)

>It could well be just a pragma, like the
>elaboration control ones.

Yes. Or like the C pragmas that tells the Preprocessor which files it
should include to get all the prototype-declarations. Well, sometimes
it even works without these, yes. Do you really *want* it to work in a
similar way? I don't.

(BTW, for that discussion it might be funny to note that these days
even more and more of the C++-folks consider "using some_namespace;"
to be evil. And now we want to encourage to do exactly the opposite of
that in Ada?)

>>>Maybe, but it should be placed at the beginning of the context. So it
>>>is just one line difference. Not a big issue, IMO.
>>
>>It is more than a single line. Consider this:
>>
>>|with Interfaces;
>> ^^^^
>>|
>>|package body Timer is
>>|
>>[...]
>>|   function Hi_Byte (Value : in Interfaces.Unsigned_16)
>>|     return Interfaces.Unsigned_8 is
>>|      use type Interfaces.Unsigned_16;
>>       ^^^
>>|   begin
>>|      return Interfaces.Unsigned_8 (
>>|          Interfaces.Shift_Right (Value, 8) and 16#FF#);
>>|   end Hi_Byte;
>
>We have no "with type" clause, so this example is incorrect.

Well, then read "use Interfaces;" instead and imagine all the packages
prefixes would go away then.

For me it is still the same principle: Make something as local as you
can. No matter if it is a variable, a procedure, ... or a namespace.

>>>with Foo;
>>>procedure P (<something here needs visibility of Foo>);
>>
>>Simple: Use the full name there. If it's too long for you, I'd say
>>rename it.
>
>It cannot be. P is a unit! (:-))

Hmm, what the heck? I was under the impression that

|subtype Sys_Addr is System.Address;
|
|procedure (foo : Sys_Addr)

would work.

>Then semantics of renaming is inconsitent with one of "use", or better
>to say, simply inconsistent. This is the source of numerous problems:
>
>with Ada.IO_Exceptions;
>package A is
>   End_Error : exception renames Ada.IO_Exceptions.End_Error;
>   X_Error : exception;
>end A;
>--------
>with A;
>package B renames A;
>--------
>with A; use A;
>with B; use B;
>with Ada.IO_Exceptions; use Ada.IO_Exceptions;
>procedure C is
>begin
>   ...
>exception
>   when X_Error =>
>      -- This is OK, multiple views of same thing
>      ...
>   when End_Error =>
>      -- This is illegal, viewing two different views of one thing!
>      ...
>end C;

See. That's a perfect example for a "use"-Problem, which I simply want
to avoid (and which I want to do consistently):

|c.adb:12:09: "End_Error" is not visible
|c.adb:12:09: multiple use clauses cause hiding
                       ^^^^^^^^^^^
|c.adb:12:09: hidden declaration at a.ads:3
|c.adb:12:09: hidden declaration at a-ioexce.ads:26
|gnatmake: "c.adb" compilation error

when you specify:

|   when A.End_Error =>

instead it surprisingly works. And if you always do that, there is
even no inconsistency that you sometimes use the short name and
sometimes the fully specified name "randomly" all over a package, just
depending on which packages you've just had to use and where the
compiler complained about not wanting to know what to do.

I don't know what this has to do with renaming. If you'd declare
End_Error separately in the packages you would run into the same
problem, so in fact it is a "use" problem.

Well, you might argue, just because you renamed it and thus in fact is
exactly the same, the compiler could figure this out by itself. But if
it would really do that, it then would be me to call this behaviour
inconsistent.

>>It's much more simple: Never use "use". :)
>
>Once I will become a rich man, I will buy a LCD with horizontal
>resolution of 10240 pixels, install small fonts, get spectacles ...
>(:-))

Considering I don't use "use" globally[0] and even restrict myself to
72 columns, I don't really understand that part of the problem. :)


Vinzent.

[0] And even locally I use "use" in relatively seldom circumstances,
the above "use type" is just because I consider the line
  | return Interfaces.Unsigned_8 (
  |   Interfaces."and" (Interfaces.Shift_Right (Value, 8), 16#FF#));
a little bit to much overkill even for my attitude to not using "use"
as much as I can't. Especially because this whole messy line just
compiles to a single "shrw $8, %ax". :)

Re: Manifesto against Vector

[Wes Groleau]

Russ wrote:
> Just as I feared. They *are* fumbling the ball.

No, they are a Superbowl team in a close game refusing to
pick up a basketball that they noticed on the sidelines.

> And I also that it is a trivial matter to parse the former to produce
> the latter. I could do it myself in a few minutes. Nor does it break

One of the benchwarmers could take care of the basketball
in a few seconds IF he cared.  So why should one of the players
on the field run over and do it?

Most of us can do a one-liner perl command to do the above
or put it in a Makefile or build script in a few seconds.
So why should the ARG study to make sure something _you_
might not have thought of _could_ break existing code, modify
the Reference Manual, and make all the compiler vendors change
compiler code?

But of course, that is an "unreasonable objection" to your
earth-shakingly important change.  Or is your change just
an excuse that some addict to another language uses for
not using Ada?

-- 
Wes Groleau

He that is good for making excuses, is seldom good for anything else.
                                     -- Benjamin Franklin

Re: Manifesto against Vector

[Wes Groleau]

Vinzent 'Gadget' Hoefler wrote:
> |c.adb:12:09: "End_Error" is not visible
> |c.adb:12:09: multiple use clauses cause hiding

Which is less likely to happen if the various use clauses
have their scope restricted to the minimum instead of
all three covering the entire compilation unit.
(Not arguing with Vincent, supporting him)

-- 
Wes Groleau
Heroes, Heritage, and History
http://freepages.genealogy.rootsweb.com/~wgroleau/

Re: Manifesto against Vector

[Georg Bauhaus]

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

: On the contrary "with" has no other sense than being just a
: hint to the compiler/linker.

It is also a hint to me, the reader! And if there is redundancy
in explicitness, this does help analysing, understanding, and
debugging programs, doesn't it? In particular if the program text
is not correct.


-- Georg

Re: Manifesto against Vector

[Jean-Pierre Rosen]

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


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> a �crit dans le message de news:na0k90h8oii6063v7n6u5mmib5v20b2emh@4ax.com...

> Why that should be told? I'd say that "with" is superfluous.
Oh no! It's one of the nicest features of Ada. The dependance graph of the program is hard-coded, you always know which module needs
which module.

> This might work with bodies, but it does not with specifications. What
> would you do with:
>
> with Foo;
> procedure P (<something here needs visibility of Foo>);
This case is extremely rare in practice. Stand-alone procedures are almost always main programs (and hence have no parameters).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Manifesto against Vector

[Jeffrey Carter]

Jean-Pierre Rosen wrote:
> Oh no! It's one of the nicest features of Ada. The dependance graph
> of the program is hard-coded, you always know which module needs 
> which module.

Unfortunately, this is not always true. With tagged types and 
dispatching, it is possible for a module to call an operation in another 
module that is not "with"ed by the first module.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Manifesto against Vector

[Matthew Heaney]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> As it follows from the Minutes of #22 ARG Meeting 
> (http://www.ada-auth.org/ai-files/minutes/min-0403.html#AI302),
> ARG chose the name Vector for Unbounded_Array container.

I have just uploaded the latest version of the definite-element vector.

ai302-containers-vectors.ad[sb]

<http://charles.tigris.org/source/browse/charles/src/ai302/?sortby=date#dirlist>

<http://charles.tigris.org/>

See the src/ai302/examples/shapes subdirectory for an example of how the
vector is used.

The latest version of the API is here:

<http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT?rev=1.5>

If you notice any inconsistencies between the vector source and the
vector description in the API, please let me know.

I'll have the indefinite-element vector done this weekend.

-Matt

Re: Manifesto against Vector

[Simon Wright]

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

> This might work with bodies, but it does not with
> specifications. What would you do with:
> 
> with Foo;
> procedure P (<something here needs visibility of Foo>);

My view is that declarations should always contain the fully-qualified
type if it comes from a package that you had to with, even if you've
used the package; in other words, don't 'use' until the end of a
declarative region. Saves a vast amount of grief finding where things
come (I know that GNAT will often retain enough context after a failed
compilation for browsing to work, but it's just so much easier for the
writer to tell the reader where stuff is supposed to come from!)

Exceptions:
   Ada.Text_IO
   Packages in a hierarchy

-- 
Simon Wright                               100% Ada, no bugs.

Re: Manifesto against Vector

[Russ]

Wes Groleau <groleau+news@freeshell.org> wrote in message news:<zbydnU1bwNTh1gfdRVn-hA@gbronline.com>...
> Russ wrote:
> > Just as I feared. They *are* fumbling the ball.
> 
> > And I also that it is a trivial matter to parse the former to produce
> > the latter. I could do it myself in a few minutes. Nor does it break
> 
> Most of us can do a one-liner perl command to do the above
> or put it in a Makefile or build script in a few seconds.

Bingo! But why should every programmer who values clean code have to
write a "one-liner perl command" when someone can do it once an for
all for everyone?

> So why should the ARG study to make sure something _you_
> might not have thought of _could_ break existing code, modify
> the Reference Manual, and make all the compiler vendors change
> compiler code?

I'd like to know how "with/use" could *possibly* break existing code.

And you're worried about modifying the Reference Manual? For Pete's
sake, I'll write the two sentences it will take. Here you go:

The new keyword "with/use", when it appears in a context section, is a
convenient shorthand for combining "with" and "use" without repeating
the library unit name. For example,

with/use Ada.Text_IO, Ada.Integer_Text_IO;

is equivalent to

with Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO,
Ada.Integer_Text_IO;

except that it is shorter, cleaner, less error prone, and easier to
read.

[end of addition to RM]

There. It's done.

> But of course, that is an "unreasonable objection" to your
> earth-shakingly important change.  Or is your change just
> an excuse that some addict to another language uses for
> not using Ada?

First of all, I never said anything about "earth-shaking". That's your
strawman characterization. I would call "with/use" significant,
however. A significant cleanup of the crap that litters the start of
so many Ada source files.

I'll tell you the impression I get when I read about your concern for
the precious time of the Ada designers. I get the impression you
consider their bandwidth to be miniscule. If so, Ada is in trouble.
They're too busy remodeling the house to have time to dump the trash?
I have some advice: they had better find time to dump the trash before
they try to sell the house.

You are right about one thing: your objection is unreasonable -- at
least it makes no sense to me.

Re: Manifesto against Vector

[Martin Krischik]

Jean-Pierre Rosen wrote:

> 
> "Russ" <18k11tm001@sneakemail.com> a ï¿œcrit dans le message de
> [...]
>> That may be so, but this particular issue is simple enough even for an
>> ameteur like me. I know that
>>
>> with/use Ada.Integer_Text_IO;
>>
>> is cleaner and simpler than
>>
>> with Ada.Integer_Text_IO; use Ada.Inteqer_Text_IO
>>
>> And I also that it is a trivial matter to parse the former to produce
>> the latter. I could do it myself in a few minutes. Nor does it break
>> compatibility with legacy code in any way. I see absolutely no
>> reasonable objection to "with/use" (but I have a funny feeling that I
>> may soon be bombarded with a lot of unreasonable objections).

> Therefore, you should *never* have a use clause as a context clause. If I
> need to have something visible everywhere in a unit, I use the same style
> as when the visibility is more restricted, i.e. I don't write:
> 
> with Foo; use Foo;
> procedure P is
> ...
> end P;
> 
> but rather:
> 
> with Foo;
> procedure P is
>    use Foo;
>    ...
> end P.

And he is not the only one. I doing it just same way.
 
> Allowing with/use would simply encourage a style that should be
> discouraged altogether. QED.

Right.

With Regards

Martin

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

Re: Manifesto against Vector

[Martin Krischik]

Dmitry wrote:

> This might work with bodies, but it does not with specifications. What
> would you do with:
> 
> with Foo;
> procedure P (<something here needs visibility of Foo>);

You can always use "Foo.<something>". Remember: specifications need to
double for documentation. Any user who whiches do use procedure P need to
know from which unit <something> comes from as well.

I, for example I use "use" in specifications not before "private". 

>>Allowing with/use would simply encourage a style that should be
>>discouraged altogether. QED.
 
> Oh, Use is Use, and With is With, and never the twain shall meet, ...
> (:-))

More importantly use "use" sparsly.

With Regards

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

Re: Manifesto against Vector

[Jean-Pierre Rosen]

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


"Jeffrey Carter" <spam@spam.com> a �crit dans le message de news:DXAmc.10133$Hs1.326@newsread2.news.pas.earthlink.net...
> Jean-Pierre Rosen wrote:
> > Oh no! It's one of the nicest features of Ada. The dependance graph
> > of the program is hard-coded, you always know which module needs
> > which module.
>
> Unfortunately, this is not always true. With tagged types and
> dispatching, it is possible for a module to call an operation in another
> module that is not "with"ed by the first module.
>
True if you are thinking in terms of call-graph.

But you don't depend logically on something that you don't with. With tagged types, you are really calling an implementation (in
another package) of something that you depend on - which is defined in a package that you have withed.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Manifesto against Vector

[Martin Krischik]

Dmitry A. Kazakov wrote:

 
> Once I will become a rich man, I will buy a LCD with horizontal
> resolution of 10240 pixels, install small fonts, get spectacles ...
> (:-))

package T_IO renames Ada.Text_IO;

works fine for with with a 1600x1200 pixel, 106 dpi Display and 10px Font.

As a mathematician you can, of corse, argue on the theoretical advantages
much better then I. However I am on the other side an engineer and
therefore more interested in the practical value of things.

With Regards

Martin

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

Re: Manifesto against Vector

[Dmitry A. Kazakov]

On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
<nntp-2004-05@t-domaingrabbing.de> wrote:

>Dmitry A. Kazakov wrote:
>
>>On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler
>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>
>>>Dmitry A. Kazakov wrote:
>>>
>>>>Why that should be told? I'd say that "with" is superfluous.
>>>
>>>No! If at all then it is "use" which is superfluous. ;-)
>>
>>How so? "Use" has some semantical sense. It changes visibility. You
>>might claim that this is not necessary, but that would be another
>>story. On the contrary "with" has no other sense than being just a
>>hint to the compiler/linker.
>
>And a idea to me which packages another one is using.

Either you agree on that IDE could tell you that better, or I would
claim that all packages with-ed implicitly should be made explicit!
(:-))

>This is
>especially useful with some of the more "evil" parts of Ada like
>Unchecked_Conversion. :)

Then it it should be "without"!

BTW Ada will now have a notion of profile (like Ravenscar). It would
be nice to have an ability to define a profile, a contract of using
some definite subset of Ada. Like one without instantiations of
Unchecked_Conversion.

>>It could well be just a pragma, like the
>>elaboration control ones.
>
>Yes. Or like the C pragmas that tells the Preprocessor which files it
>should include to get all the prototype-declarations. Well, sometimes
>it even works without these, yes. Do you really *want* it to work in a
>similar way? I don't.

ARM does not specify how unit library works. So even if you write
"with X", it does not warranty that X will be with-ed, especially when
it is not in the library. (:-)) You have to set up the project, use -I
key in gnatmake etc. The point is, if this work has to be done in one
place, why should it be repeated in the source again?

>(BTW, for that discussion it might be funny to note that these days
>even more and more of the C++-folks consider "using some_namespace;"
>to be evil. And now we want to encourage to do exactly the opposite of
>that in Ada?)

Because Ada was designed with "use" in mind! The difference is that
Ada allows view management. To drop this idea, essential for building
and maintaining large layered system, just because of a moss-grown
language where types and subroutines are global, that would be at
least unwise.

>For me it is still the same principle: Make something as local as you
>can. No matter if it is a variable, a procedure, ... or a namespace.

I didn't object this principle.

>>Then semantics of renaming is inconsitent with one of "use", or better
>>to say, simply inconsistent. This is the source of numerous problems:
>>
>>with Ada.IO_Exceptions;
>>package A is
>>   End_Error : exception renames Ada.IO_Exceptions.End_Error;
>>   X_Error : exception;
>>end A;
>>--------
>>with A;
>>package B renames A;
>>--------
>>with A; use A;
>>with B; use B;
>>with Ada.IO_Exceptions; use Ada.IO_Exceptions;
>>procedure C is
>>begin
>>   ...
>>exception
>>   when X_Error =>
>>      -- This is OK, multiple views of same thing
>>      ...
>>   when End_Error =>
>>      -- This is illegal, viewing two different views of one thing!
>>      ...
>>end C;
>
>See. That's a perfect example for a "use"-Problem, which I simply want
>to avoid (and which I want to do consistently):

No, "use" is consistent. When you use something twice, that does not
create additional views. What is inconsistent, is that renaming of an
exception creates a view colliding with a view of the renamed thing.

[...]

>I don't know what this has to do with renaming. If you'd declare
>End_Error separately in the packages you would run into the same
>problem, so in fact it is a "use" problem.

>Well, you might argue, just because you renamed it and thus in fact is
>exactly the same,

Yes I do.

>the compiler could figure this out by itself. But if
>it would really do that, it then would be me to call this behaviour
>inconsistent.

Don't you agree that there is a difference between views and viewed
things? How could names indicating the same thing conflict? What is
overloaded here to cause the conflict? What is the sense of the
conflict? Something unresolved, ambiguous, what? 

>>>It's much more simple: Never use "use". :)
>>
>>Once I will become a rich man, I will buy a LCD with horizontal
>>resolution of 10240 pixels, install small fonts, get spectacles ...
>>(:-))
>
>Considering I don't use "use" globally[0] and even restrict myself to
>72 columns, I don't really understand that part of the problem. :)

There is no problem. Just if you were consistently against any view
management, then you should have gone further:

"Never use child packages, they are globally using their parents!"

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

Re: Manifesto against Vector

[Dmitry A. Kazakov]

On Thu, 6 May 2004 14:48:43 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>: On the contrary "with" has no other sense than being just a
>: hint to the compiler/linker.
>
>It is also a hint to me, the reader!

I answered that.

>And if there is redundancy
>in explicitness, this does help analysing, understanding, and
>debugging programs, doesn't it?

Not at all. In most cases it is just an importunate noise.

>In particular if the program text
>is not correct.

How could that help, keeping in mind, that use-haters are pushing for
using full names everywhere?

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

Re: Manifesto against Vector

[Vinzent 'Gadget' Hoefler]

Dmitry A. Kazakov wrote:

>On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
><nntp-2004-05@t-domaingrabbing.de> wrote:
>
>>Dmitry A. Kazakov wrote:
>>
>>>On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler
>>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>>
>>>>Dmitry A. Kazakov wrote:
>>>>
>>>>>Why that should be told? I'd say that "with" is superfluous.
>>>>
>>>>No! If at all then it is "use" which is superfluous. ;-)
>>>
>>>How so? "Use" has some semantical sense. It changes visibility. You
>>>might claim that this is not necessary, but that would be another
>>>story. On the contrary "with" has no other sense than being just a
>>>hint to the compiler/linker.
>>
>>And a idea to me which packages another one is using.
>
>Either you agree on that IDE could tell you that better, or I would
>claim that all packages with-ed implicitly should be made explicit!
>(:-))

Well, call me old school or so, but most of the times the only IDE I
use is just a simple text editor.

And sometimes I am just using the ssh-connection to a simple
text-based terminal to change some lines of code. No place for a big
IDE keeping track of everything here.

>>This is
>>especially useful with some of the more "evil" parts of Ada like
>>Unchecked_Conversion. :)
>
>Then it it should be "without"!

Hmm.

You mean instead of:

|with Elan520.Basic_Types;
|with Elan520.CPU_Registers;
|with Elan520.MMCR;
|with Elan520.Programmable_Address_Region;
|with Elan520.Registers;
|with Elan520.SDRAM_Controller_Registers;
|
|package body Elan520 is [...]

I should simply write:

|without Ada.*;
|without System.*;
|without Unchecked_*;

? ;-)

>BTW Ada will now have a notion of profile (like Ravenscar). It would
>be nice to have an ability to define a profile, a contract of using
>some definite subset of Ada. Like one without instantiations of
>Unchecked_Conversion.

You've never read Annex H.4?

|pragma Restrictions (No_Unchecked_Conversion);

Well, it's not exactly a profile, but seeing how many of these you
could combine just to define this or that specific profile...

Just assuming that each argument to pragma Restriction could have two
options only, you could form up to 65536 different profiles alone from
those 16 restrictions defined there.

>ARM does not specify how unit library works. So even if you write
>"with X", it does not warranty that X will be with-ed, especially when
>it is not in the library. (:-))

Well, if it doesn't, it won't compile in the end.

>You have to set up the project, use -I
>key in gnatmake etc. The point is, if this work has to be done in one
>place, why should it be repeated in the source again?

Because I want to fucking *know* about it.

>>(BTW, for that discussion it might be funny to note that these days
>>even more and more of the C++-folks consider "using some_namespace;"
>>to be evil. And now we want to encourage to do exactly the opposite of
>>that in Ada?)
>
>Because Ada was designed with "use" in mind!

Hmm. What's wrong with that? ;)

>The difference is that
>Ada allows view management. To drop this idea, essential for building
>and maintaining large layered system, just because of a moss-grown
>language where types and subroutines are global, that would be at
>least unwise.

Yes, but this is exactly what "use" without "with" would be then (well
well, not quite). But all the "use"s could then be scattered all over
the source file and no human would know about what really *is* used
without reading the whole source file.

>>For me it is still the same principle: Make something as local as you
>>can. No matter if it is a variable, a procedure, ... or a namespace.
>
>I didn't object this principle.

Well, the "with use Something;" (or whatever someone might like to see
instead) which was proposed would violate this principle. :)

It would throw me back to the old days of good ol' Turbo-Pascal where
each "uses" of a unit put the whole thing into view.

>>>Then semantics of renaming is inconsitent with one of "use", or better
>>>to say, simply inconsistent. This is the source of numerous problems:
>>>
[...]
>>>   when X_Error =>
>>>      -- This is OK, multiple views of same thing
>>>      ...
>>>   when End_Error =>
>>>      -- This is illegal, viewing two different views of one thing!
>>>      ...
>>>end C;
>>
>>See. That's a perfect example for a "use"-Problem, which I simply want
>>to avoid (and which I want to do consistently):
>
>No, "use" is consistent.

Yes. I didn't say otherwise. I just mentioned that it can cause
problems as you illustrated here.

>When you use something twice, that does not
>create additional views.

Well, right. If you do it inside the same namespace.

>What is inconsistent, is that renaming of an
>exception creates a view colliding with a view of the renamed thing.

No, not exactly, we're talking about different packages here. What
you've created here was:

|A.End_Error;
|B.End_Error;

and (not exactly created)

|Ada.Exceptions.End_Error;

Yes, because of the renaming in this example those are all the same
thing.

_But_: the compiler does not want to know about the implementation.
So, because nobody can hinder me to change the definition in A and/or
B later, it won't know [and even if it does, it does not *want* to ;)]
that all these names all denote the same entity. So when you said just
"End_Error", the compiler could not know which one to choose, of
course. Really, it does not matter that all these names in fact just
accidently denote the same entity, they are not bound to do this each
time.

Remember that Ada is about software engineering and this includes
being able to compile something even without having the actual
implementation of some other packages as long as the interface is
known.

Consider when you just change the definitions in packages A and B you
will have the same problem of having three entities with the same
short name and then the compiler *really* can't know which one you
meant.
So now suppose in the former case the compiler would compile package C
(like you want it to) and now your junior co-programmer decides to
change A.End_Error and declares it as its own exception, not a
renaming because the first attempt was just a quick prototype to get
the rest of the project to compile. Now your package C would just
suddenly *not* compile, although nothing really changed considerably,
the interface of the other packages remain the same (after all,
A.End_Error is still an exception) and package C wasn't even changed a
single bit. That would cause horrible confusion.

So the current behaviour is indeed very consistent.

>>I don't know what this has to do with renaming. If you'd declare
>>End_Error separately in the packages you would run into the same
>>problem, so in fact it is a "use" problem.
>
>>Well, you might argue, just because you renamed it and thus in fact is
>>exactly the same,
>
>Yes I do.

As I am trying to argue above, this behaviour is absolutely correct.

>>the compiler could figure this out by itself. But if
>>it would really do that, it then would be me to call this behaviour
>>inconsistent.
>
>Don't you agree that there is a difference between views and viewed
>things?

Well, sort of. Yes.

>How could names indicating the same thing conflict?

Because they are not in the same view.

Just because someone writes "Foo : constant Some_Type;" and another
"Bar : constant Some_Type;" and in the private part they *are* the
same that doesn't mean, you will *not* sooner or later run into
problems when you just randomly interchange them in your code.

>What is
>overloaded here to cause the conflict?

Common sense?

Who tells you that A.End_Error and B.End_Error have to remain the same
in all eternity, just because they were at the very moment you used
them?

>What is the sense of the
>conflict? Something unresolved, ambiguous, what?

The possibility that a simple change would break the project that
compiled perfectly.

>There is no problem. Just if you were consistently against any view
>management,

Oh, view management is ok.

>then you should have gone further:
>"Never use child packages, they are globally using their parents!"

Yes, they do. Of course they do: Logically such a package hierarchy is
just a big single package. The fact that you *do* break it into more
small packages and thus be able to control the views into it in some
finer granularity doesn't break anything here.

A subroutine inside a soubroutine can see its "parent", too. I don't
see any problem involved here.


Vinzent.

-- 
To err is human, to forgive beyond the scope of the operating system.

Re: Manifesto against Vector

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>And if there is redundancy
:>in explicitness, this does help analysing, understanding, and
:>debugging programs, doesn't it?
: 
: Not at all. In most cases it is just an importunate noise.
: 
:>In particular if the program text
:>is not correct.
: 
: How could that help, keeping in mind, that use-haters are pushing for
: using full names everywhere?

Does the 3k lines body of package X depend on Foo.Bar, or
is there an occurence of the string Foo.Bar somewhere in the
body of package X?

If this argument were taken to Eiffel, would you want the compiler
to figure out what the inheritance relations for the class
in question is, by having it analyse the class and its closure?
That is instead of specifying what the inheritance hierarchy 
(and thus package dependeces) is?


-- Georg

Re: Manifesto against Vector

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Thu, 6 May 2004 09:03:54 +0200, "Jean-Pierre Rosen"
> <rosen@adalog.fr> wrote:
>>Since you asked for it... (but I'll try to have reasonable objections).
>>Note that I am known for being strongly *in favor* of the use clause.
>>
>>I would strongly oppose this proposal for a very simple reason: it defeats the main goal of having separated with from use.
>>With is a library level clause; it tells: "this unit, somewhere needs that unit".
> 
> Why that should be told? I'd say that "with" is superfluous.

Not really, for two reasons:

1. Readability
2. The use of USE is not manditory (and arguably should
    be used with care)

Since WITH can only be used at the start of the source
code, it becomes a very big plus in _readability_. With a quick
inspection of a spec/body, you can be certain of the references
(or not) to other units.

USE on the other hand, may appear in numerous other places, or
not at all. For example, I may WITH Ada.Text_IO, and never USE
it. I may just code Ada.Text_IO.Put_Line etc.

While one might be tempted to suggest that WITH references may be
deduced from USE clauses, this is not always true. This is
because USE clauses may not be used at all.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Manifesto against Vector

[Jeffrey Carter]

Jean-Pierre Rosen wrote:
> 
> But you don't depend logically on something that you don't with. With
> tagged types, you are really calling an implementation (in another
> package) of something that you depend on - which is defined in a
> package that you have withed.

To my way of thinking, you depend on any types you may have objects of 
and anything you may invoke. A derived type is not the same type as its 
parent, nor are its operations the same as its parent's operations. 
Since type extension is a form of type derivation, I apply the same 
rules to type extension that I did to type derivation in Ada 83: the 
parent must be either a predefined type, or a type declared in the same 
declarative region as the child. Anything else quickly becomes unreadable.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Manifesto against Vector

[Simon Wright]

Jeffrey Carter <spam@spam.com> writes:

> To my way of thinking, you depend on any types you may have objects
> of and anything you may invoke. A derived type is not the same type
> as its parent, nor are its operations the same as its parent's
> operations. Since type extension is a form of type derivation, I
> apply the same rules to type extension that I did to type derivation
> in Ada 83: the parent must be either a predefined type, or a type
> declared in the same declarative region as the child. Anything else
> quickly becomes unreadable.

A(n abstract) parent, and its operations, define a contract that
extensions must obey. I guess it's like recursion, at some point you
just have to take things on trust.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Manifesto against Vector

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> :>And if there is redundancy
> :>in explicitness, this does help analysing, understanding, and
> :>debugging programs, doesn't it?
> : 
> : Not at all. In most cases it is just an importunate noise.
> : 
> :>In particular if the program text
> :>is not correct.
> : 
> : How could that help, keeping in mind, that use-haters are pushing for
> : using full names everywhere?
> 
> Does the 3k lines body of package X depend on Foo.Bar, or
> is there an occurence of the string Foo.Bar somewhere in the
> body of package X?
> 
> If this argument were taken to Eiffel, would you want the compiler
> to figure out what the inheritance relations for the class
> in question is, by having it analyse the class and its closure?

You must be talking about Prolog. (:-))

> That is instead of specifying what the inheritance hierarchy
> (and thus package dependeces) is?

This comparison is interesting, but I think it is not exact. We should
distinguish type/package relations from ad hoc dependencies. Non trivial
inheritance and child packages are design decisions. These are taken early,
have a great influence and thus deserve manifesting. An ad hoc use of types
(creating simple subtypes) and packages (with/use-ing) is much more
occasional and fluid. Note that we have it for types too. Constrained
subtypes have a lightweight syntax. Constant/in/out/in-out/access subtypes
are completely ad hoc, they are anonymous and matched by-structure (i.e.
through analyze, exactly as you said). With by-reference vs. by-value
subtypes Ada goes even further and requires no explicit declaration at all.

So in my view, Ada made a great step forward by introducing inherent package
relations in the form of child packages. It could do that even better by
allowing multiple parents (a counterpart of so hated multiple inheritance).
Doing so there is no more reason to keep "with" at least when there is an
explicit "use".

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

Re: Manifesto against Vector

[Dmitry A. Kazakov]

Vinzent 'Gadget' Hoefler wrote:

> Dmitry A. Kazakov wrote:
> 
>>On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>
>>>Dmitry A. Kazakov wrote:
>>>
>>>>On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler
>>>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>>>
>>>>>Dmitry A. Kazakov wrote:
>>>>>
>>>>>>Why that should be told? I'd say that "with" is superfluous.
>>>>>
>>>>>No! If at all then it is "use" which is superfluous. ;-)
>>>>
>>>>How so? "Use" has some semantical sense. It changes visibility. You
>>>>might claim that this is not necessary, but that would be another
>>>>story. On the contrary "with" has no other sense than being just a
>>>>hint to the compiler/linker.
>>>
>>>And a idea to me which packages another one is using.
>>
>>Either you agree on that IDE could tell you that better, or I would
>>claim that all packages with-ed implicitly should be made explicit!
>>(:-))
> 
> Well, call me old school or so, but most of the times the only IDE I
> use is just a simple text editor.

So, here you are. You have to mention *all* used packages, or?

> And sometimes I am just using the ssh-connection to a simple
> text-based terminal to change some lines of code. No place for a big
> IDE keeping track of everything here.

I hope that it is not Ada's design goal to support programming over modem
connections? Anyway, if you want to use "slow-connection/typewriter-use"
argument, then note that it works against both "with" and full names.

>>>This is
>>>especially useful with some of the more "evil" parts of Ada like
>>>Unchecked_Conversion. :)
>>
>>Then it it should be "without"!
> 
> Hmm.
> 
> You mean instead of:
> 
> |with Elan520.Basic_Types;
> |with Elan520.CPU_Registers;
> |with Elan520.MMCR;
> |with Elan520.Programmable_Address_Region;
> |with Elan520.Registers;
> |with Elan520.SDRAM_Controller_Registers;
> |
> |package body Elan520 is [...]
> 
> I should simply write:
> 
> |without Ada.*;
> |without System.*;
> |without Unchecked_*;

No. "without" would be a contract not to use something. At least it would
have some sense. "with" is just a comment. So far nobody brought any other
argument in its favor.

> Just assuming that each argument to pragma Restriction could have two
> options only, you could form up to 65536 different profiles alone from
> those 16 restrictions defined there.

Is it an argument against profiles and restrictions? (:-)) Honestly, I would
agree, they erode the language. But it is an inevitable evil.

>>ARM does not specify how unit library works. So even if you write
>>"with X", it does not warranty that X will be with-ed, especially when
>>it is not in the library. (:-))
> 
> Well, if it doesn't, it won't compile in the end.

So where is any difference between:

with Ada.Text_IO;
-- with Ada.Text_IO?

>>You have to set up the project, use -I
>>key in gnatmake etc. The point is, if this work has to be done in one
>>place, why should it be repeated in the source again?
> 
> Because I want to fucking *know* about it.

Put a comment to remember. For example: 

A.B.C.D.E := 2;
  -- We need A
  -- We need A.B too
  -- Not to forget: A.B.C
  -- And A.B.C.D, of course

>>>(BTW, for that discussion it might be funny to note that these days
>>>even more and more of the C++-folks consider "using some_namespace;"
>>>to be evil. And now we want to encourage to do exactly the opposite of
>>>that in Ada?)
>>
>>Because Ada was designed with "use" in mind!
> 
> Hmm. What's wrong with that? ;)

I have asked first! (:-))

>>The difference is that
>>Ada allows view management. To drop this idea, essential for building
>>and maintaining large layered system, just because of a moss-grown
>>language where types and subroutines are global, that would be at
>>least unwise.
> 
> Yes, but this is exactly what "use" without "with" would be then (well
> well, not quite). But all the "use"s could then be scattered all over
> the source file

Sorry, but you support this principle, i.e. "move "use" as far down as you
can". You can replace it with another - "start with "use"". Even if you
want both, fine, Ada supports this too, multiple "uses" of the package are
OK!

> and no human would know about what really *is* used
> without reading the whole source file.

Why a human should know? The point is that "use" helps a reader to
understand the program. If it does not, do not use it. If it does, then its
mission is over, there is nothing to "know" here. As simple as that.

>>>For me it is still the same principle: Make something as local as you
>>>can. No matter if it is a variable, a procedure, ... or a namespace.
>>
>>I didn't object this principle.
> 
> Well, the "with use Something;" (or whatever someone might like to see
> instead) which was proposed would violate this principle. :)

Only if it is "with use". I talked about "use" implying with. That would be
compatible with any principle, even with one requiring avoiding "use"!
(:-))

>>>>Then semantics of renaming is inconsitent with one of "use", or better
>>>>to say, simply inconsistent. This is the source of numerous problems:
>>>>
> [...]
>>>>   when X_Error =>
>>>>      -- This is OK, multiple views of same thing
>>>>      ...
>>>>   when End_Error =>
>>>>      -- This is illegal, viewing two different views of one thing!
>>>>      ...
>>>>end C;
>>>
>>>See. That's a perfect example for a "use"-Problem, which I simply want
>>>to avoid (and which I want to do consistently):
>>
>>No, "use" is consistent.
> 
> Yes. I didn't say otherwise. I just mentioned that it can cause
> problems as you illustrated here.

The problems are caused solely by renaming.

>>What is inconsistent, is that renaming of an
>>exception creates a view colliding with a view of the renamed thing.
> 
> No, not exactly, we're talking about different packages here.

It is no matter. [BTW, renaming A to B does not create any new package. If
renaming would be consistently inconsistent (:-)), it would clash in
"use"-ing both A and B!]

> What
> you've created here was:
> 
> |A.End_Error;
> |B.End_Error;
> 
> and (not exactly created)
> 
> |Ada.Exceptions.End_Error;
> 
> Yes, because of the renaming in this example those are all the same
> thing.
> 
> _But_: the compiler does not want to know about the implementation.
> So, because nobody can hinder me to change the definition in A and/or
> B later, it won't know [and even if it does, it does not *want* to ;)]
> that all these names all denote the same entity. So when you said just
> "End_Error", the compiler could not know which one to choose, of
> course. Really, it does not matter that all these names in fact just
> accidently denote the same entity, they are not bound to do this each
> time.

Wrong. The example was *not* a case of implementation through renaming. In
which case you were right. For example:

-- This is not Ada!
package A is
   End_Error : exception is private; -- Will be defined later
private
   End_Error : exception renames Ada.IO_Exceptions.End_Error;

> Remember that Ada is about software engineering and this includes
> being able to compile something even without having the actual
> implementation of some other packages as long as the interface is
> known.

This has nothing to do with renaming [*].

>>>the compiler could figure this out by itself. But if
>>>it would really do that, it then would be me to call this behaviour
>>>inconsistent.
>>
>>Don't you agree that there is a difference between views and viewed
>>things?
> 
> Well, sort of. Yes.

Then re-read your arguments, and choose something! (:-))

>>How could names indicating the same thing conflict?
> 
> Because they are not in the same view.
> 
> Just because someone writes "Foo : constant Some_Type;" and another
> "Bar : constant Some_Type;" and in the private part they *are* the
> same that doesn't mean, you will *not* sooner or later run into
> problems when you just randomly interchange them in your code.

There is absolutely no problem with that, if you mean Foo privately renaming
Bar. In public view there are two *different* Some_Type, because you have
an implementation through renaming. On the contrary in private view there
should be only one object!

>>What is overloaded here to cause the conflict?
> 
> Common sense?
> 
> Who tells you that A.End_Error and B.End_Error have to remain the same
> in all eternity,

They were declared as such. This is the contract, because it happened in the
public part.

> just because they were at the very moment you used
> them?

See above. If the program designer had an intention to keep them separate
he/she should have chosen other design.

>>What is the sense of the
>>conflict? Something unresolved, ambiguous, what?
> 
> The possibility that a simple change would break the project that
> compiled perfectly.

The project will cease to compile. This is what we have *NOW*. And, well,
hire better programmers! (:-))

>>then you should have gone further:
>>"Never use child packages, they are globally using their parents!"
> 
> Yes, they do. Of course they do: Logically such a package hierarchy is
> just a big single package. The fact that you *do* break it into more
> small packages and thus be able to control the views into it in some
> finer granularity doesn't break anything here.
> 
> A subroutine inside a soubroutine can see its "parent", too. I don't
> see any problem involved here.

Child packages are just a form of "with/use".

---
*) Except view changing renamings, which alas are also inconsistent in Ada.

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

Re: Manifesto against Vector

[Matthew Heaney]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

I have just uploaded the 2004/04/29 API release of the
indefinite-element vector.

ai302-containers-indefinite_vectors.ad[sb]

There were also a few changes to the definite-element vector, too.


-Matt


> "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:
> 
> > As it follows from the Minutes of #22 ARG Meeting 
> > (http://www.ada-auth.org/ai-files/minutes/min-0403.html#AI302),
> > ARG chose the name Vector for Unbounded_Array container.
> 
> I have just uploaded the latest version of the definite-element vector.
> 
> ai302-containers-vectors.ad[sb]
> 
> <http://charles.tigris.org/source/browse/charles/src/ai302/?sortby=date#dirlist>
> 
> The latest version of the API is here:
> 
> <http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT?rev=1.5>

Re: Manifesto against Vector

[Martin Krischik]

Alexander E. Kopilovich wrote:

> This is quite obvious that the most natural name for this container in Ada
> is Unbounded_Array, because this name perfectly associates with both
> "array" and Unbounded_String, for which it is natural generalization.

But perhaps Unbounded_Array might be used for something far more Ada like:

package Unbounded_String
is new
   Unbounded_Array (
      Element_Type => Character,
      Index_Type => Natural,
      Base_Array => String);    

package Unbounded_Wide_String
is new
   Unbounded_Array (
      Element_Type => Wide_Character,
      Index_Type => Natural,
      Base_Array => Wide_String);    

Personally I wonder why they have not done that for Ada95 allready. And if
Unicode_Character aka Wide_Wide_Character is implemented an generic
implementation of Unbounded_String becomes even more usefull.

With Regards

Martin

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

Re: Manifesto against Vector

[Jean-Pierre Rosen]

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


"Jeffrey Carter" <spam@spam.com> a �crit dans le message de news:8sQmc.11414$V97.6807@newsread1.news.pas.earthlink.net...
> Jean-Pierre Rosen wrote:
> >
> > But you don't depend logically on something that you don't with. With
> > tagged types, you are really calling an implementation (in another
> > package) of something that you depend on - which is defined in a
> > package that you have withed.
>
> To my way of thinking, you depend on any types you may have objects of
> and anything you may invoke. A derived type is not the same type as its
> parent, nor are its operations the same as its parent's operations.
> Since type extension is a form of type derivation, I apply the same
> rules to type extension that I did to type derivation in Ada 83: the
> parent must be either a predefined type, or a type declared in the same
> declarative region as the child. Anything else quickly becomes unreadable.
>
But tagged types (OOP actually) is just about that: being able to add types later, without requiring recompiling existing modules
that use the class. I understand that you may not like that; in this case, just don't use tagged types. It was a very deliberate
decision to prevent tagged types from invading the whole language, precisely for this reason: they have no effect on people who
don't use them.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Manifesto against Vector

[Vinzent 'Gadget' Hoefler]

Dmitry A. Kazakov wrote:

>Vinzent 'Gadget' Hoefler wrote:
>
>> Dmitry A. Kazakov wrote:
>> 
>>>On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
>>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>>
>> Well, call me old school or so, but most of the times the only IDE I
>> use is just a simple text editor.
>
>So, here you are. You have to mention *all* used packages, or?

All directly used ones, yes. And I *want* to mention them. :)

>> And sometimes I am just using the ssh-connection to a simple
>> text-based terminal to change some lines of code. No place for a big
>> IDE keeping track of everything here.
>
>I hope that it is not Ada's design goal to support programming over modem
>connections? Anyway, if you want to use "slow-connection/typewriter-use"
>argument, then note that it works against both "with" and full names.

It doesn't have to do anything with "slow" (I still can't type that
fast to outperform even a really slow 56K-connection, can you?). It's
just the case that I don't have the cool IDE running there that tells
me everything about my project like "this type's from here, that from
there, etc. pp.".

>No. "without" would be a contract not to use something. At least it would
>have some sense. "with" is just a comment.

No it's not just a comment. Yes, it is sort of redundancy. But
repeating all the function declaration is, too. And nobody seems to
complain about that.

>So far nobody brought any other
>argument in its favor.

It tells me, what I am using, it tells the compiler what I am going to
intend to use. If there is a discrepancy in that I am trying to use
something which I didn't say so before, the damn stupid compiler will
complain. That's a *good* thing.

>> Just assuming that each argument to pragma Restriction could have two
>> options only, you could form up to 65536 different profiles alone from
>> those 16 restrictions defined there.
>
>Is it an argument against profiles and restrictions? (:-))

No. It's just an argument against declaring a profile for each
possible case someone weird could think of. ;)

You wanted something that could forbid you to use Unchecked_Conversion
in a project, here you have it. It's the sort of "without" you've
asked for before.

>>>ARM does not specify how unit library works. So even if you write
>>>"with X", it does not warranty that X will be with-ed, especially when
>>>it is not in the library. (:-))
>> 
>> Well, if it doesn't, it won't compile in the end.
>
>So where is any difference between:
>
>with Ada.Text_IO;
>-- with Ada.Text_IO?

That the compiler can tell me that it agrees with me here.

>>>You have to set up the project, use -I
>>>key in gnatmake etc. The point is, if this work has to be done in one
>>>place, why should it be repeated in the source again?
>> 
>> Because I want to fucking *know* about it.
>
>Put a comment to remember.

NO! I want to be sure and the compiler is a good tool to give me
confidence about it. I am the one who is making mistakes, so I don't
rely on anything I've written. Especially if nobody counterchecks if
this is eventually a case where I was actually right.

>>>The difference is that
>>>Ada allows view management. To drop this idea, essential for building
>>>and maintaining large layered system, just because of a moss-grown
>>>language where types and subroutines are global, that would be at
>>>least unwise.
>> 
>> Yes, but this is exactly what "use" without "with" would be then (well
>> well, not quite). But all the "use"s could then be scattered all over
>> the source file
>
>Sorry, but you support this principle, i.e. "move "use" as far down as you
>can".

Yes. But before I do that I "with" everything I "use" at the first
lines of the source. So I *know* if some module is fiddling around
with the programmable address region registers for instance.

>> and no human would know about what really *is* used
>> without reading the whole source file.
>
>Why a human should know?

Because the people who must write and later understand the source code
*are* humans, not machines or some nifty IDE.

>Only if it is "with use". I talked about "use" implying with.

That's even worse. Now the only way to find out if the source is
actually messing around with some of the nastier parts of the hardware
is - to read each whole sourcefile.

>>>>>Then semantics of renaming is inconsitent with one of "use", or better
>>>>>to say, simply inconsistent. This is the source of numerous problems:
>>>>>
>> [...]
>>>>>   when X_Error =>
>>>>>      -- This is OK, multiple views of same thing
>>>>>      ...
>>>>>   when End_Error =>
>>>>>      -- This is illegal, viewing two different views of one thing!
>>>>>      ...
>>>>>end C;
>>>>
>>>>See. That's a perfect example for a "use"-Problem, which I simply want
>>>>to avoid (and which I want to do consistently):
>>>
>>>No, "use" is consistent.
>> 
>> Yes. I didn't say otherwise. I just mentioned that it can cause
>> problems as you illustrated here.
>
>The problems are caused solely by renaming.

The problem is because you have the same name in two packages which
the compiler is bound *not* to resolve autoamtically in any way.

>>>What is inconsistent, is that renaming of an
>>>exception creates a view colliding with a view of the renamed thing.
>> 
>> No, not exactly, we're talking about different packages here.
>
>It is no matter. [BTW, renaming A to B does not create any new package. If
>renaming would be consistently inconsistent (:-)), it would clash in
>"use"-ing both A and B!]

No. It doesn't even clash if you use "Ada.Text_IO" twice. So why
should it here?

>> What
>> you've created here was:
>> 
>> |A.End_Error;
>> |B.End_Error;
>> 
>> and (not exactly created)
>> 
>> |Ada.Exceptions.End_Error;
>> 
>> Yes, because of the renaming in this example those are all the same
>> thing.
>> 
>> _But_: the compiler does not want to know about the implementation.
>> So, because nobody can hinder me to change the definition in A and/or
>> B later, it won't know [and even if it does, it does not *want* to ;)]
>> that all these names all denote the same entity. So when you said just
>> "End_Error", the compiler could not know which one to choose, of
>> course. Really, it does not matter that all these names in fact just
>> accidently denote the same entity, they are not bound to do this each
>> time.
>
>Wrong. The example was *not* a case of implementation through renaming.

The compiler sees a package. It sees a name for one or more entities
there and their corresponding type. That's it. It doesn't care about
any implementation at this stage. This gets resolved later. (At least
that's what I'd say.)

>> Remember that Ada is about software engineering and this includes
>> being able to compile something even without having the actual
>> implementation of some other packages as long as the interface is
>> known.
>
>This has nothing to do with renaming [*].

I tried to explain it. Of course my view could be totally wrong, I am
trying to be an Ada practitioner, not a language-lawyer. And in my own
personal view this all makes almost perfect sense.

>>>How could names indicating the same thing conflict?
>> 
>> Because they are not in the same view.
>> 
>> Just because someone writes "Foo : constant Some_Type;" and another
>> "Bar : constant Some_Type;" and in the private part they *are* the
>> same that doesn't mean, you will *not* sooner or later run into
>> problems when you just randomly interchange them in your code.
>
>There is absolutely no problem with that, if you mean Foo privately renaming
>Bar. In public view there are two *different* Some_Type, because you have
>an implementation through renaming. On the contrary in private view there
>should be only one object!

So what's the difference here? Why shouldn't the compiler know about
the more private parts (in fact, at some stage it needs to know at
least to preserve enough storage space for the type) here?

>>>What is overloaded here to cause the conflict?
>> 
>> Common sense?
>> 
>> Who tells you that A.End_Error and B.End_Error have to remain the same
>> in all eternity,
>
>They were declared as such. This is the contract, because it happened in the
>public part.

And where in the contract does A know about that it will be renamed by
B?

>> just because they were at the very moment you used
>> them?
>
>See above. If the program designer had an intention to keep them separate
>he/she should have chosen other design.

Quick prototyping? Just filling out some blanks so that it *will*
compile some of the more important rest?

>>>What is the sense of the
>>>conflict? Something unresolved, ambiguous, what?
>> 
>> The possibility that a simple change would break the project that
>> compiled perfectly.
>
>The project will cease to compile. This is what we have *NOW*.

No, not if you don't use "use". So we're back at the evil that causes
the problem.

>>>then you should have gone further:
>>>"Never use child packages, they are globally using their parents!"
>> 
>> Yes, they do. Of course they do: Logically such a package hierarchy is
>> just a big single package. The fact that you *do* break it into more
>> small packages and thus be able to control the views into it in some
>> finer granularity doesn't break anything here.
>> 
>> A subroutine inside a soubroutine can see its "parent", too. I don't
>> see any problem involved here.
>
>Child packages are just a form of "with/use".

That's your personal viewpoint. For me its a big package that allows
different "peek" views into it, depending on what is really needed. Of
course this personal view is totally wrong, too, because the whole
purpose of child packages were to be able to extend some package
without even touching the existing one. :)


Vinzent.

-- 
Wenn alle Stricke reissen, kann man sich immer noch erschiessen.

Re: Manifesto against Vector

[Martin Dowie]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0405062115.2685ca1b@posting.google.com>...
> And you're worried about modifying the Reference Manual? For Pete's
> sake, I'll write the two sentences it will take. Here you go:
> 
> The new keyword "with/use", when it appears in a context section, is a
> convenient shorthand for combining "with" and "use" without repeating
> the library unit name. For example,
> 
> with/use Ada.Text_IO, Ada.Integer_Text_IO;
> 
> is equivalent to
> 
> with Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO,
> Ada.Integer_Text_IO;
> 
> except that it is shorter, cleaner, less error prone, and easier to
> read.
> 
> [end of addition to RM]

So go and propose this via an AI! The ARG aren't going to do this as
_none_ of the compiler vendor's customers are asking for it.

I assume you are not a current customer... if you are then go and
hassle your vendor!!!!

Cheers

-- Martin

Re: Manifesto against Vector

[Dmitry A. Kazakov]

On Mon, 10 May 2004 10:26:38 +0200, Vinzent 'Gadget' Hoefler
<nntp-2004-05@t-domaingrabbing.de> wrote:

>Dmitry A. Kazakov wrote:
>
>>Vinzent 'Gadget' Hoefler wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>> 
>>>>On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
>>>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>>>
>>> Well, call me old school or so, but most of the times the only IDE I
>>> use is just a simple text editor.
>>
>>So, here you are. You have to mention *all* used packages, or?
>
>All directly used ones, yes. And I *want* to mention them. :)

Ah, and you surely would define "directly used" as ones mentioned in
"with". Looks much like a vicious circle! (:-))

>>No. "without" would be a contract not to use something. At least it would
>>have some sense. "with" is just a comment.
>
>No it's not just a comment. Yes, it is sort of redundancy. But
>repeating all the function declaration is, too.

It is necessary because their names can be overloaded. Package names
are also repeated in their bodies. No problem with that.

>And nobody seems to complain about that.

There are warts to complain about:

1. The parameter defaults should not be repeated in the
implementation. C++ does it right.

2. There should be a way to make the defaults private. Presently one
should expose them in the public part.

>>So far nobody brought any other
>>argument in its favor.
>
>It tells me, what I am using,

It does not:

1. See above. An incomplete truth is a lie.

2. It tells that to early, defeating the principle: "declare something
as late as you can".

3. What you are using is already said either in a fully qualified name
or in "use".

>it tells the compiler what I am going to
>intend to use. If there is a discrepancy in that I am trying to use
>something which I didn't say so before, the damn stupid compiler will
>complain. That's a *good* thing.

It will complain anyway. And note that it is quite often non-trivial,
especially for a beginner, to design a correct "with" when generics
are in play. That's a *bad* thing.

>>> Just assuming that each argument to pragma Restriction could have two
>>> options only, you could form up to 65536 different profiles alone from
>>> those 16 restrictions defined there.
>>
>>Is it an argument against profiles and restrictions? (:-))
>
>No. It's just an argument against declaring a profile for each
>possible case someone weird could think of. ;)

True. I am feel myself a bit uncomfortable with the idea of profiles.
But it seems that there is no better way. Though, don't you see that
the set of "with" clauses is a kind of profile? Then ...

>You wanted something that could forbid you to use Unchecked_Conversion
>in a project, here you have it. It's the sort of "without" you've
>asked for before.

I didn't ask for it. It was just an example.

>>>>ARM does not specify how unit library works. So even if you write
>>>>"with X", it does not warranty that X will be with-ed, especially when
>>>>it is not in the library. (:-))
>>> 
>>> Well, if it doesn't, it won't compile in the end.
>>
>>So where is any difference between:
>>
>>with Ada.Text_IO;
>>-- with Ada.Text_IO?
>
>That the compiler can tell me that it agrees with me here.

Agree on what? Again, if you bring this argument, then it should be
"without". An unused "with" clause is not an error.

>>>>You have to set up the project, use -I
>>>>key in gnatmake etc. The point is, if this work has to be done in one
>>>>place, why should it be repeated in the source again?
>>> 
>>> Because I want to fucking *know* about it.
>>
>>Put a comment to remember.
>
>NO! I want to be sure and the compiler is a good tool to give me
>confidence about it. I am the one who is making mistakes, so I don't
>rely on anything I've written. Especially if nobody counterchecks if
>this is eventually a case where I was actually right.

Fortunately the compiler *always* checks all names.

>>>>The difference is that
>>>>Ada allows view management. To drop this idea, essential for building
>>>>and maintaining large layered system, just because of a moss-grown
>>>>language where types and subroutines are global, that would be at
>>>>least unwise.
>>> 
>>> Yes, but this is exactly what "use" without "with" would be then (well
>>> well, not quite). But all the "use"s could then be scattered all over
>>> the source file
>>
>>Sorry, but you support this principle, i.e. "move "use" as far down as you
>>can".
>
>Yes. But before I do that I "with" everything I "use" at the first
>lines of the source. So I *know* if some module is fiddling around
>with the programmable address region registers for instance.

This clearly violates the principle. BTW it would also require that no
"with" be allowed in the bodies.

You should first decide whether "with X" is *always* a contract and
never an implementation detail. Once you agree that it might be the
later, then you should also agree that it would be better to deduce
it, when possible.

My position is that in many cases "with" constitutes no contract. If
it yet appears to do, then probably the package should be made a
child.

>>Only if it is "with use". I talked about "use" implying with.
>
>That's even worse. Now the only way to find out if the source is
>actually messing around with some of the nastier parts of the hardware
>is - to read each whole sourcefile.

I do not understand this. The package name is specified in "use".

>>>>>>Then semantics of renaming is inconsitent with one of "use", or better
>>>>>>to say, simply inconsistent. This is the source of numerous problems:
>>>>>>
>>> [...]
>>>>>>   when X_Error =>
>>>>>>      -- This is OK, multiple views of same thing
>>>>>>      ...
>>>>>>   when End_Error =>
>>>>>>      -- This is illegal, viewing two different views of one thing!
>>>>>>      ...
>>>>>>end C;
>>>>>
>>>>>See. That's a perfect example for a "use"-Problem, which I simply want
>>>>>to avoid (and which I want to do consistently):
>>>>
>>>>No, "use" is consistent.
>>> 
>>> Yes. I didn't say otherwise. I just mentioned that it can cause
>>> problems as you illustrated here.
>>
>>The problems are caused solely by renaming.
>
>The problem is because you have the same name in two packages which
>the compiler is bound *not* to resolve autoamtically in any way.

Names are always resolved.

>>>>What is inconsistent, is that renaming of an
>>>>exception creates a view colliding with a view of the renamed thing.
>>> 
>>> No, not exactly, we're talking about different packages here.
>>
>>It is no matter. [BTW, renaming A to B does not create any new package. If
>>renaming would be consistently inconsistent (:-)), it would clash in
>>"use"-ing both A and B!]
>
>No. It doesn't even clash if you use "Ada.Text_IO" twice. So why
>should it here?

According to your [wrong] theory it should, because once I have
renamed A to B, I have different names A.* and B.* which should
collide.

>>> What
>>> you've created here was:
>>> 
>>> |A.End_Error;
>>> |B.End_Error;
>>> 
>>> and (not exactly created)
>>> 
>>> |Ada.Exceptions.End_Error;
>>> 
>>> Yes, because of the renaming in this example those are all the same
>>> thing.
>>> 
>>> _But_: the compiler does not want to know about the implementation.
>>> So, because nobody can hinder me to change the definition in A and/or
>>> B later, it won't know [and even if it does, it does not *want* to ;)]
>>> that all these names all denote the same entity. So when you said just
>>> "End_Error", the compiler could not know which one to choose, of
>>> course. Really, it does not matter that all these names in fact just
>>> accidently denote the same entity, they are not bound to do this each
>>> time.
>>
>>Wrong. The example was *not* a case of implementation through renaming.
>
>The compiler sees a package. It sees a name for one or more entities
>there and their corresponding type. That's it. It doesn't care about
>any implementation at this stage. This gets resolved later. (At least
>that's what I'd say.)

Wrong. Observe that the following is illegal in Ada:

with Ada.IO_Exceptions;
procedure Test is
   End_Error : exception renames Ada.IO_Exceptions.End_Error;
begin
   null;
exception
   when End_Error => null;
   when Ada.IO_Exceptions.End_Error => null;
end Test;

End_Error and Ada.IO_Exceptions.End_Error is the same thing. And the
compiler perfectly *knows* that. Your theory that renaming is an
implementation is wrong.

>>>>How could names indicating the same thing conflict?
>>> 
>>> Because they are not in the same view.
>>> 
>>> Just because someone writes "Foo : constant Some_Type;" and another
>>> "Bar : constant Some_Type;" and in the private part they *are* the
>>> same that doesn't mean, you will *not* sooner or later run into
>>> problems when you just randomly interchange them in your code.
>>
>>There is absolutely no problem with that, if you mean Foo privately renaming
>>Bar. In public view there are two *different* Some_Type, because you have
>>an implementation through renaming. On the contrary in private view there
>>should be only one object!
>
>So what's the difference here? Why shouldn't the compiler know about
>the more private parts (in fact, at some stage it needs to know at
>least to preserve enough storage space for the type) here?

The difference is that the public part is a contract to fulfil. If it
states that Foo is not Bar, then they should appear as such. The
implementation (private part) may privately change this, if necessary,
but that may have no influence on the contract.

>>>>What is overloaded here to cause the conflict?
>>> 
>>> Common sense?
>>> 
>>> Who tells you that A.End_Error and B.End_Error have to remain the same
>>> in all eternity,
>>
>>They were declared as such. This is the contract, because it happened in the
>>public part.
>
>And where in the contract does A know about that it will be renamed by
>B?

Does that matter?

>>> just because they were at the very moment you used
>>> them?
>>
>>See above. If the program designer had an intention to keep them separate
>>he/she should have chosen other design.
>
>Quick prototyping? Just filling out some blanks so that it *will*
>compile some of the more important rest?

To do that one needs no renaming. One should just declare End_Error as
an independent exception.

>>>>What is the sense of the
>>>>conflict? Something unresolved, ambiguous, what?
>>> 
>>> The possibility that a simple change would break the project that
>>> compiled perfectly.
>>
>>The project will cease to compile. This is what we have *NOW*.
>
>No, not if you don't use "use". So we're back at the evil that causes
>the problem.

See my example. It will never compile, because either with or without
"use" A.End_Error is Ada.IO_Exceptions.End_Error.

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

Re: Manifesto against Vector

[Jeffrey Carter]

Jean-Pierre Rosen wrote:

> But tagged types (OOP actually) is just about that: being able to add
>  types later, without requiring recompiling existing modules that use
>  the class.

OOP (which is unrelated to OOD) is really about increasing ease of
writing at the expense of ease of reading; that's why it's embraced by 
the same coders who prefer C to Ada. Software engineers emphasize ease 
of reading over ease of writing and prefer Ada to C, and don't mind 
having to recompile to achieve that. I agree with some guy named Rosen 
who had an /Ada Letters/ article about what orientation Ada's objects 
should take, and concluded that composition was more readable than 
inheritance. (See also Carter, J. R., "OOP vs. Readability," /Ada 
Letters/, 1997 Mar/Apr.)

-- 
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83

Re: Manifesto against Vector

[Jeffrey Carter]

Martin Krischik wrote:

> Alexander E. Kopilovich wrote:
> 
>>This is quite obvious that the most natural name for this container in Ada
>>is Unbounded_Array, because this name perfectly associates with both
>>"array" and Unbounded_String, for which it is natural generalization.
> 
> But perhaps Unbounded_Array might be used for something far more Ada like:
> 
> package Unbounded_String
> is new
>    Unbounded_Array (
>       Element_Type => Character,
>       Index_Type => Natural,
>       Base_Array => String);    

Right. Unbounded_String is a special case of an unbounded array; in 
hindsight, it would have been much better for Ada 95 to have had an 
unbounded array package and to have defined Unbounded_String in terms of 
it. That didn't happen, though, so there's no point in worrying about it.

What Unbounded_String does give us is guidance and reasons about how to 
design and name an unbound array abstraction and its operations. Since 
Unbounded_String is a special case of an unbounded array, for 
consistency an unbounded array package added now should have similar 
operations to Unbounded_Strings, with the same name when possible, and 
be named something like Unbounded_Array. Calling it Vector, having a 
bunch of operations that aren't in Unbounded_String, and different names 
for the operations that exist in both is a good way to create confusion.

However, the design, including the operations and names, of Vector is 
essentially fixed now (see the previous post by Eachus; I suspect it's 
more authoritative than the post by Heaney claiming otherwise). There's 
no longer any point to this discussion; let's direct our energies to 
something where we can make a difference.

-- 
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83

Re: Manifesto against Vector

[Matthew Heaney]

Jeffrey Carter <spam@spam.com> writes:

> What Unbounded_String does give us is guidance and reasons about how
> to design and name an unbound array abstraction and its
> operations. Since Unbounded_String is a special case of an unbounded
> array, for consistency an unbounded array package added now should
> have similar operations to Unbounded_Strings, with the same name when
> possible, and be named something like Unbounded_Array. Calling it
> Vector, having a bunch of operations that aren't in Unbounded_String,
> and different names for the operations that exist in both is a good
> way to create confusion.

Indeed, it's a good thing the vector isn't named "Unbounded_Array",
since it's not an unbounded array.  (The vector uses an unbounded array
as a model, in order to describe the semantics of the abstraction, but
of course that doesn't mean the vector is an unbounded array.  In fact,
at least two compiler vendors will not be using an unbounded array as
the representation of their vector implementation.)

Re: Manifesto against Vector

[Martin Krischik]

Jeffrey Carter wrote:

> Martin Krischik wrote:
> 
>> Alexander E. Kopilovich wrote:
>> 
>>>This is quite obvious that the most natural name for this container in
>>>Ada is Unbounded_Array, because this name perfectly associates with both
>>>"array" and Unbounded_String, for which it is natural generalization.
>> 
>> But perhaps Unbounded_Array might be used for something far more Ada
>> like:
>> 
>> package Unbounded_String
>> is new
>>    Unbounded_Array (
>>       Element_Type => Character,
>>       Index_Type => Natural,
>>       Base_Array => String);
> 
> Right. Unbounded_String is a special case of an unbounded array; in
> hindsight, it would have been much better for Ada 95 to have had an
> unbounded array package and to have defined Unbounded_String in terms of
> it. That didn't happen, though, so there's no point in worrying about it.

But there is still Unicode_Character aka Wide_Wide_Character. They will need
Unbounded, Bounded, Fixed etc. packages as well. 

So perhaps one should rethink the String Library.

With Regards

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

Re: Manifesto against Vector

[Jean-Pierre Rosen]

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


"Jeffrey Carter" <spam@spam.com> a �crit dans le message de news:yWOnc.14671$V97.11541@newsread1.news.pas.earthlink.net...
> OOP (which is unrelated to OOD) is really about increasing ease of
> writing at the expense of ease of reading; that's why it's embraced by
> the same coders who prefer C to Ada. Software engineers emphasize ease
> of reading over ease of writing and prefer Ada to C, and don't mind
> having to recompile to achieve that. I agree with some guy named Rosen
> who had an /Ada Letters/ article about what orientation Ada's objects
> should take, and concluded that composition was more readable than
> inheritance. (See also Carter, J. R., "OOP vs. Readability," /Ada
> Letters/, 1997 Mar/Apr.)

Well, I agree with that guy :-). If you remember one of my previous posts, I said "if you don't want tagged types, don't use them".
I am furiously fighting against the "inheritance everywhere" disease. However, the opposite of "inheritance everywhere" is not
"inheritance nowhere". There are cases where inheritance can be useful; I would not describe it as favouring ease of writing over
ease of reading, but rather as favouring flexibility over security. There are some applications where flexibility is a prime
concern.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Manifesto against Vector

[Alexander E. Kopilovich]

Matthew Heaney wrote:

> it's a good thing the vector isn't named "Unbounded_Array",
> since it's not an unbounded array.  (The vector uses an unbounded array
> as a model, in order to describe the semantics of the abstraction, but
> of course that doesn't mean the vector is an unbounded array.

Apparently the name "Unbounded_Array" implies for you a particular method of
implementation; probably you think that the "Array" part of this name hints
on that the whole container occupies contiguous chunk of memory (or, perhaps,
several chunks, with many elements of the array in each). But this is just
your personal association, and I don't think that this association is too
widespread.

Anyway, the method of implementation of this container doesn't matter much
for a user, because if it did matter then the standard container probably
should not be used at all - according to general presumption for intended use
of the whole Container Library.

>  In fact,
> at least two compiler vendors will not be using an unbounded array as
> the representation of their vector implementation.)

There aren't too many options for those compiler vendors - I guess that they
will use unbounded array of accesses to the objects in container. In Delphi's
VCL the container implemented in this way is called List - and there were no
complaints among Delphi programmers regarding this name. By the way, the name
Flexible_Array (inspired by Algol-68) would be totally neutral regarding an 
implementation.

The essence of the problem at which I pointed, is not that the particular
name (Unbounded_Array) was not chosen, but in that the chosen name (Vector)
has another predefined meaning in several application domains (which are
among few Ada-friendly ones), And that this name will be in the standard.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Manifesto against Vector

[Marius Amado Alves]

> > it's a good thing the vector isn't named "Unbounded_Array",
> > since it's not an unbounded array.  (The vector uses an unbounded array
> > as a model, in order to describe the semantics of the abstraction, but
> > of course that doesn't mean the vector is an unbounded array.) (Heaney)
>
> Apparently the name "Unbounded_Array" implies for you a particular method
of
> implementation; probably you think that the "Array" part of this name
hints
> on that the whole container occupies contiguous chunk of memory (or,
perhaps,
> several chunks, with many elements of the array in each). But this is just
> your personal association, and I don't think that this association is too
> widespread. (Kopilovich)

FWIW, my perception coincides with Kopilovich's. Hence the title of my ASCL
Workshop paper, "Unbounded_Arrays for Unbounded Arrays" (remember, Matt?)

Re: Manifesto against Vector

[Pascal Obry]

Matthew,

A side question about AI302, I sent a message to issues@charles.tigris.org
but got no response. Is that list really active ? If not were should question
about current implementation be posted ?

Thanks,
Pascal.

-- 

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

Re: Manifesto against Vector

[Matthew Heaney]

Pascal Obry <pascal@obry.org> writes:

> A side question about AI302, I sent a message to
> issues@charles.tigris.org but got no response. Is that list really
> active ? If not were should question about current implementation be
> posted ?

I haven't tried using those lists yet.  As the list owner, I assumed I'd
get something, but maybe I need to subscribe explicitly?

I agree that that's a good list to use, so let me see what's up.  In the
meantime, send me your question directly, and I'll get back to you.

-Matt

Re: Manifesto against Vector

[Matthew Heaney]

Pascal Obry <pascal@obry.org> writes:

> A side question about AI302, I sent a message to
> issues@charles.tigris.org but got no response. Is that list really
> active ? If not were should question about current implementation be
> posted ?


I just replied to you on the mailing list.  

I thought that as project owner, I would be automatically subscribed,
but apparently that's not the case, and so I just subscribed myself to
all the lists for the charles project.

-Matt

Re: Manifesto against Vector

[Randy Brukardt]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0405062115.2685ca1b@posting.google.com...
...
> > So why should the ARG study to make sure something _you_
> > might not have thought of _could_ break existing code, modify
> > the Reference Manual, and make all the compiler vendors change
> > compiler code?
>
> I'd like to know how "with/use" could *possibly* break existing code.
>
> And you're worried about modifying the Reference Manual? For Pete's
> sake, I'll write the two sentences it will take. Here you go:
>
> The new keyword "with/use", when it appears in a context section, is a
> convenient shorthand for combining "with" and "use" without repeating
> the library unit name. For example,
>
> with/use Ada.Text_IO, Ada.Integer_Text_IO;
>
> is equivalent to
>
> with Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO,
> Ada.Integer_Text_IO;
>
> except that it is shorter, cleaner, less error prone, and easier to
> read.

No good. Too much useless verbiage, and it depends on an equivalence.
Equivalences almost never work; we avoid them if at all possible. (The ARG
spends a lot of time fixing problems caused by equivalences that aren't -
for instance, truncating Stream_IO files).

In any case, we discussed something like 4 problems with this proposal in
the past. None of them are insurmountable, but they simply aren't worth the
effort (which is substantial). And since the the Ada 2005 effort is
substantially voluteer, the effort does matter.

In any case, no syntax tweaks are going to have the slightest impact on
Ada's use/popularity. If people can adjust to gibberish syntax like Lisp and
C++, they certainly can handle a few quirks in Ada. Bigger issues will make
the difference, and few, if any of them have anything to do with the
language standard.

                          Randy.

Re: Manifesto against Vector

[Randy Brukardt]

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:af783afe.0405100355.71238d6a@posting.google.com...
> 18k11tm001@sneakemail.com (Russ) wrote in message
news:<bebbba07.0405062115.2685ca1b@posting.google.com>...
> > And you're worried about modifying the Reference Manual? For Pete's
> > sake, I'll write the two sentences it will take. Here you go:
> >
> > The new keyword "with/use", when it appears in a context section, is a
> > convenient shorthand for combining "with" and "use" without repeating
> > the library unit name. For example,
> >
> > with/use Ada.Text_IO, Ada.Integer_Text_IO;
> >
> > is equivalent to
> >
> > with Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO,
> > Ada.Integer_Text_IO;
> >
> > except that it is shorter, cleaner, less error prone, and easier to
> > read.
> >
> > [end of addition to RM]
>
> So go and propose this via an AI! The ARG aren't going to do this as
> _none_ of the compiler vendor's customers are asking for it.
>
> I assume you are not a current customer... if you are then go and
> hassle your vendor!!!!

It was. And it was given the consideration that it deserved. Note that the
ARG does not discuss every proposal that it is sent, or it would be
overwhelmed.

                Randy.

Re: Manifesto against Vector

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:mrem90lkgi1om9aip1d4dcqti538v9sbr8@4ax.com...
> >: On the contrary "with" has no other sense than being just a
> >: hint to the compiler/linker.

It's much more than a "hint". It also controls which entities *can be*
visible in a particular unit. Otherwise, it would be necessary for a
compiler to load the universe into its symboltable -- and then it would be
impossible to determine if any program is legal or not. (Because you could
make almost any program legal by just saying that the universe includes more
stuff).

So the main function of "with" is to limit the universe of symbols that can
be referenced in a program. Besides implementation issues (what to load into
the symboltable for a particular compile), this also has an impact on
legality.

                        Randy.

Re: Manifesto against Vector

[Russ]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<9cadnQ6PhYWg4z_dRVn-sA@megapath.net>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0405062115.2685ca1b@posting.google.com...
> ...
> > > So why should the ARG study to make sure something _you_
> > > might not have thought of _could_ break existing code, modify
> > > the Reference Manual, and make all the compiler vendors change
> > > compiler code?
> >
> > I'd like to know how "with/use" could *possibly* break existing code.
> >
> > And you're worried about modifying the Reference Manual? For Pete's
> > sake, I'll write the two sentences it will take. Here you go:
> >
> > The new keyword "with/use", when it appears in a context section, is a
> > convenient shorthand for combining "with" and "use" without repeating
> > the library unit name. For example,
> >
> > with/use Ada.Text_IO, Ada.Integer_Text_IO;
> >
> > is equivalent to
> >
> > with Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO,
> > Ada.Integer_Text_IO;
> >
> > except that it is shorter, cleaner, less error prone, and easier to
> > read.
> 
> No good. Too much useless verbiage, and it depends on an equivalence.
> Equivalences almost never work; we avoid them if at all possible. (The ARG
> spends a lot of time fixing problems caused by equivalences that aren't -
> for instance, truncating Stream_IO files).

Too much "useless verbiage"? Where? Are you replying to *my* post, or
did you get mixed up with some other post? I am totally baffled by
your reply. My simple proposal *eliminates* "useless verbiage". Oh,
and it eliminates "useless verbiage" too. Did I mention it eliminates
"useless verbiage"?

But I am getting the impression that you Ada guys *like* useless
verbiage, which is why I am providing some for you here. Yes, it's as
useless as repeating library unit names twice. By the way, if twice is
better than once, why not three times? This is not an Ada issue; it is
a simple matter of common sense.

> In any case, we discussed something like 4 problems with this proposal in
> the past. None of them are insurmountable, but they simply aren't worth the
> effort (which is substantial). And since the the Ada 2005 effort is
> substantially voluteer, the effort does matter.

I'd like to know what the 4 problems are, but I'll save you the time
and just ask for one non-trivial problem with having "with/use x;"
mean "with x; use x;" It's trivial text substitution and nothing else.

> In any case, no syntax tweaks are going to have the slightest impact on
> Ada's use/popularity. If people can adjust to gibberish syntax like Lisp and
> C++, they certainly can handle a few quirks in Ada. Bigger issues will make
> the difference, and few, if any of them have anything to do with the
> language standard.

What I am suggesting is a trivial freebie that can only help. It's
like the difference between a long and short URL for a website. No,
having a short URL is not the most important factor in the popularity
of a website, but you better believe it is a factor. Convenience is
always important, and people who deny that are rarely successful
selling anything. Why? Because they don't give a darn about their
customer.

Re: Manifesto against Vector

[Randy Brukardt]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0405122123.23661b16@posting.google.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<9cadnQ6PhYWg4z_dRVn-sA@megapath.net>...
...
> > > except that it is shorter, cleaner, less error prone, and easier to
> > > read.
> >
> > No good. Too much useless verbiage, and it depends on an equivalence.
> > Equivalences almost never work; we avoid them if at all possible. (The
ARG
> > spends a lot of time fixing problems caused by equivalences that
aren't -
> > for instance, truncating Stream_IO files).
>
> Too much "useless verbiage"? Where? Are you replying to *my* post, or
> did you get mixed up with some other post? I am totally baffled by
> your reply. My simple proposal *eliminates* "useless verbiage". Oh,
> and it eliminates "useless verbiage" too. Did I mention it eliminates
> "useless verbiage"?

The wording has too much useless verbiage. The part I left above (in
particular) does not belong in RM wording - the RM is not trying to sell
anyone on the benefits of a feature. (The AI needs to do that, but not the
wording.)

...
> > In any case, we discussed something like 4 problems with this proposal
in
> > the past. None of them are insurmountable, but they simply aren't worth
the
> > effort (which is substantial). And since the the Ada 2005 effort is
> > substantially voluteer, the effort does matter.
>
> I'd like to know what the 4 problems are, but I'll save you the time
> and just ask for one non-trivial problem with having "with/use x;"
> mean "with x; use x;" It's trivial text substitution and nothing else.

Yes, you do seem to have trouble remembering previous discussions. I suggest
you go back and read them. One example is that "with A.B" means "with A;
with A.B" while "use A.B" means just that; so a "simple text substitution"
is inconsistent and likely to be confusing.

> > In any case, no syntax tweaks are going to have the slightest impact on
> > Ada's use/popularity. If people can adjust to gibberish syntax like Lisp
and
> > C++, they certainly can handle a few quirks in Ada. Bigger issues will
make
> > the difference, and few, if any of them have anything to do with the
> > language standard.
>
> What I am suggesting is a trivial freebie that can only help.

This is a trivial freebie that encourages horrible Ada style. That's why
some of us (like me) would oppose it even if it *was* free, which it is not.

> It's like the difference between a long and short URL for a website. No,
> having a short URL is not the most important factor in the popularity
> of a website, but you better believe it is a factor. Convenience is
> always important, and people who deny that are rarely successful
> selling anything. Why? Because they don't give a darn about their
> customer.

Ada has never been about *convenience*. It is about readability, and it
about correct programs. "Use" clauses in general are a hindrance to both of
those goals (although they can help readability in limited circumstances).
Because they bring in *everything* from a package, it is really only safe to
use them on the smallest or most common things -- or to limit their
effectiveness to a small area (which of course is certainly not going to be
in a context clause).

Tools (such as IDEs) provide whatever convenience features are needed.
(That's true in C++ and Java as well). If Ada has a problem, it's not enough
good tools. Wasting time messing with the syntax is not going to help that.

In any case, I've spend far more time on this topic already than it ever has
desired. I'm not going to spend any more -- nice talking to you again.

                  Randy.


                       Randy.

Re: Manifesto against Vector

[Robert I. Eachus]

Randy Brukardt wrote:

> In any case, I've spend far more time on this topic already than it ever has
> desired. I'm not going to spend any more -- nice talking to you again.

I've been staying out of the with/use discussion Part II, because it is 
a waste of time and electrons.  But I'll make one last try to convince 
Russ.  There are issues that Russ is either not willing to understand, 
or does not consider important.  The ARG has considered ALL the 
technical and software engineering issues and concluded that this is a 
bad idea.

If you, Russ, were willing to do the work (on all issues) and have the 
time and necessary mindset to be an ARG member, go for it.  But on this, 
as on any issue, you will have only one vote and the power of persuasion.

But another ARG rule is not to reopen old issues without new evidence. 
(Almost always something overlooked that makes the agreed solution 
wrong. Not just less popular.)  Without that the ARG would spend all its 
time rehashing old issues and never get anything done.

Or you could apply for membership on the US TAG to WG9 (or the 
equivalent group for whatever country you are a citizen of).  WG9 
reviews ARG approved issues and can send the ARG back to the drawing 
board if WG9 doesn't like the proposed solution.  (And sometimes WG9 
gets told, "Tough, we can't find a better solution." ;-) But again, you 
would have one vote among many, and I think at the WG9 level this 
proposal has even less of a chance of passing.

So drop it.  And notice that any ARG member has plenty of pet hobby 
horses he is willing to ride on the slightest excuse.  But in the ARG, 
if you can't put that aside, accept the results of the vote, and 
consider the next AI, you don't belong there.

Oh, and don't bother to respond to this post.  In fact, I almost set 
followups to /dev/null or alt.flame, but I consider that anti-social.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney

Re: Manifesto against Vector

[Russ]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<nZ6dnaivKYOgkT7dRVn-uw@megapath.net>...
> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0405122123.23661b16@posting.google.com...
> > "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:<9cadnQ6PhYWg4z_dRVn-sA@megapath.net>...
> ...
> > > > except that it is shorter, cleaner, less error prone, and easier to
> > > > read.

> The wording has too much useless verbiage. The part I left above (in
> particular) does not belong in RM wording - the RM is not trying to sell
> anyone on the benefits of a feature. (The AI needs to do that, but not the
> wording.)

OK, then put it in the AI instead. It's one line!

> ...
> > > In any case, we discussed something like 4 problems with this proposal
>  in
> > > the past. None of them are insurmountable, but they simply aren't worth
>  the
> > > effort (which is substantial). And since the the Ada 2005 effort is
> > > substantially voluteer, the effort does matter.
> >
> > I'd like to know what the 4 problems are, but I'll save you the time
> > and just ask for one non-trivial problem with having "with/use x;"
> > mean "with x; use x;" It's trivial text substitution and nothing else.
> 
> Yes, you do seem to have trouble remembering previous discussions. I suggest
> you go back and read them. One example is that "with A.B" means "with A;
> with A.B" while "use A.B" means just that; so a "simple text substitution"
> is inconsistent and likely to be confusing.

You still don't seem to get it. It's nothing more than trivial text
substitution. All the stuff about the exact meaning of "with" and
"use" is completely irrelevant here. You'd still be able to use "with"
and "use" exactly as you do now. The only difference would be the
following:

IF (IF, IF, IF, IF) you want to use "with" and "use" on the EXACT SAME
EXPRESSION, you would be able to do it with "with/use" and avoid
repeating the expression. That's it. Nothing more, nothing less. In
the Ada source files I have seen, such repeats are very common.

Now, you apparently believe that "use" is overused. So be it. You
don't have to use "use", nor would you ever be forced to use
"with/use". Personally, I consider it ridiculous to use fully
qualified library calls for basic I/O and math functions, for example.
At the same time, I don't want to clutter my code by naming packages
twice at the top of the file.

> > > In any case, no syntax tweaks are going to have the slightest impact on
> > > Ada's use/popularity. If people can adjust to gibberish syntax like Lisp
>  and
> > > C++, they certainly can handle a few quirks in Ada. Bigger issues will
>  make
> > > the difference, and few, if any of them have anything to do with the
> > > language standard.
> >
> > What I am suggesting is a trivial freebie that can only help.
> 
> This is a trivial freebie that encourages horrible Ada style. That's why
> some of us (like me) would oppose it even if it *was* free, which it is not.
> 
> > It's like the difference between a long and short URL for a website. No,
> > having a short URL is not the most important factor in the popularity
> > of a website, but you better believe it is a factor. Convenience is
> > always important, and people who deny that are rarely successful
> > selling anything. Why? Because they don't give a darn about their
> > customer.
> 
> Ada has never been about *convenience*. It is about readability, and it
> about correct programs. "Use" clauses in general are a hindrance to both of
> those goals (although they can help readability in limited circumstances).
> Because they bring in *everything* from a package, it is really only safe to
> use them on the smallest or most common things -- or to limit their
> effectiveness to a small area (which of course is certainly not going to be
> in a context clause).

Here we go again. I am perfectly willing to stipulate that "use" is
overused, but I also think that there is a perfectly good use for it
in context sections for basic I/O, math, and other standard libraries.
That's why the language allows it, I suppose. But I still fail to see
how readability is improved by forcing the reader to read the same
thing twice and verify that it is indeed the same thing. But I still
fail to see how readability is improved by forcing the reader to read
the same thing twice and verify that it is indeed the same thing. I
guess I'll just never get that one.

> Tools (such as IDEs) provide whatever convenience features are needed.
> (That's true in C++ and Java as well). If Ada has a problem, it's not enough
> good tools. Wasting time messing with the syntax is not going to help that.
> 
> In any case, I've spend far more time on this topic already than it ever has
> desired. I'm not going to spend any more -- nice talking to you again.

I'm sorry you find me so annoying. I'm really not trying to be so. I'm
just trying to make a simple point.