Re: Anybody in US using ADA ? One silly idea..

Re: Anybody in US using ADA ? One silly idea..

[Grein, Christoph]

> > Not at all, your amplification brings the point out more fully; but it
> > should be said that:
> >
> > >             SUBTYPE S IS INTEGER RANGE READ .. READ;
> >
> > is formally undefined, as the language does not specify the order in which
> > the lower and upper bounds of the range are evaluated.
> >
> Which is easily solved by saying:
>      Lower : constant Integer := Read;
>      Upper : constant Integer := Read;
>      subtype S is Integer range Lower..Upper;
> 
> (Fortunately, declarations *are* elaborated in order :-)

which, by RM 3.3.1(7), is the same as

       Lower, Upper: constant Integer := Read;

Re: Anybody in US using ADA ? One silly idea..

[Stephen Leake]

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

> > Which is easily solved by saying:
> >      Lower : constant Integer := Read;
> >      Upper : constant Integer := Read;
> >      subtype S is Integer range Lower..Upper;
> > 
> > (Fortunately, declarations *are* elaborated in order :-)
> 
> which, by RM 3.3.1(7), is the same as
> 
>        Lower, Upper: constant Integer := Read;

Which is an excellent example of why declaring multiple initialized
variables in one statement is a horrible thing to do. I'd have to
check the manual to see if Read is called once or twice for this;
please never do it!

-- 
-- Stephe

Re: Anybody in US using ADA ? One silly idea..

[Victor Porton]

In article <uiswpvzrh.fsf@nasa.gov>,
	Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
> "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
> 
>> > Which is easily solved by saying:
>> >      Lower : constant Integer := Read;
>> >      Upper : constant Integer := Read;
>> >      subtype S is Integer range Lower..Upper;
>> > 
>> > (Fortunately, declarations *are* elaborated in order :-)
>> 
>> which, by RM 3.3.1(7), is the same as
>> 
>>        Lower, Upper: constant Integer := Read;
> 
> Which is an excellent example of why declaring multiple initialized
> variables in one statement is a horrible thing to do. I'd have to
> check the manual to see if Read is called once or twice for this;
> please never do it!

So compilers need to give warnings if calling a not pure
function in a "multiple-initializer".

If we would be able to turn time back, we would to make this
an error in Ada Standard.

Oh, maybe make this an error in Ada0X despite of backward
incompatibility, as almost all these cases seem to be
erroneous or at least poorly coded (e.g. forgotten
pragma Pure).

Re: Anybody in US using ADA ? One silly idea..

[Grein, Christoph]

> "Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
> news:mailman.10.1044267682.3911.comp.lang.ada@ada.eu.org...
> > > > Do you know, an integer is definitely a real number.
> > >
> > > You sure? How about a simple theorem that any two distinct
> > > real numbers have another real number between them? Either
> > > this theorem doesn't hold (and the whole math goes out
> > > the window) or the integers are most definitely not reals.
> > >
> > > Which will it be?
> >
> > Where is there the contradiction? Integers can be embedded in reals as a
> subset.
> 
> Operations available for the type and how they behave.
> The theorem above was an example. Let's see:
> 
> F(X, Y) = A
> 
> such that for any given, finite X and Y where X < Y it
> produces A that satisfies the requirement that X < A < Y
> 
> Trivial to do for real numbers. Impossible for integers.
> Which means that, at least in this respect, integers are
> not a subset of reals. To be more precise, you could


I'm out of words with this statement...

Why on earth do you think that each and every trait of a superset is going to 
hold in subsets? That's a very peculiar definiton of "subset", to say at least.




> argue that they are a subset or real *values* but that's
> not the same thing.
> 
> You could also define an operation F that takes two
> integers and returns a generic real but that would also
> mean that integers do not posess a property critical
> to the definition of the real numbers.

Re: Anybody in US using ADA ? One silly idea..

[AG]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
news:mailman.14.1044350541.3911.comp.lang.ada@ada.eu.org...

> I'm out of words with this statement...
>
> Why on earth do you think that each and every trait of a superset is going
to
> hold in subsets?

LSP? Wasn't it what started this thread (or sub-sub
thereof)? Mind you, I'm actually arguing against it if
you haven't noticed.

> That's a very peculiar definiton of "subset", to say at least.

See below. It seems we are talking two different definitions
of [sub]sets: You seem to imply that only *values* count
in defining subsets. My point is that *operations* on them
are just as if not more important.

>
> > argue that they are a subset or real *values* but that's
> > not the same thing.
> >
> > You could also define an operation F that takes two
> > integers and returns a generic real but that would also
> > mean that integers do not posess a property critical
> > to the definition of the real numbers.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 4 Feb 2003 22:50:01 -0800, "AG" <ang@xtra.co.nz> wrote:

>"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
>news:mailman.14.1044350541.3911.comp.lang.ada@ada.eu.org...
>
>> That's a very peculiar definiton of "subset", to say at least.
>
>See below. It seems we are talking two different definitions
>of [sub]sets: You seem to imply that only *values* count
>in defining subsets. My point is that *operations* on them
>are just as if not more important.

Yes, but for LSP-subtypes, not for subsets. Subset is a well-defined
term and there is no need to overload it.

Only if we will consider types as sets of values + closure of all
operations on them, then, probably this construct for an LSP-subtype
would be a subset of one of its base type.

Anyway, an absolute LSP is absolutely useless. (:-))

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

Re: Anybody in US using ADA ? One silly idea..

[Grein, Christoph]

> > Do you know, an integer is definitely a real number.
> 
> You sure? How about a simple theorem that any two distinct
> real numbers have another real number between them? Either
> this theorem doesn't hold (and the whole math goes out
> the window) or the integers are most definitely not reals.
> 
> Which will it be?

Where is there the contradiction? Integers can be embedded in reals as a subset.

Re: Anybody in US using ADA ? One silly idea..

[AG]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
news:mailman.10.1044267682.3911.comp.lang.ada@ada.eu.org...
> > > Do you know, an integer is definitely a real number.
> >
> > You sure? How about a simple theorem that any two distinct
> > real numbers have another real number between them? Either
> > this theorem doesn't hold (and the whole math goes out
> > the window) or the integers are most definitely not reals.
> >
> > Which will it be?
>
> Where is there the contradiction? Integers can be embedded in reals as a
subset.

Operations available for the type and how they behave.
The theorem above was an example. Let's see:

F(X, Y) = A

such that for any given, finite X and Y where X < Y it
produces A that satisfies the requirement that X < A < Y

Trivial to do for real numbers. Impossible for integers.
Which means that, at least in this respect, integers are
not a subset of reals. To be more precise, you could
argue that they are a subset or real *values* but that's
not the same thing.

You could also define an operation F that takes two
integers and returns a generic real but that would also
mean that integers do not posess a property critical
to the definition of the real numbers.

Re: Anybody in US using ADA ? One silly idea..

[Chad R. Meiners]

"AG" <ang@xtra.co.nz> wrote in message
news:W1L%9.68847$F63.1401723@news.xtra.co.nz...
>
> "Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
> news:mailman.10.1044267682.3911.comp.lang.ada@ada.eu.org...
> > > > Do you know, an integer is definitely a real number.
> > >
> > > You sure? How about a simple theorem that any two distinct
> > > real numbers have another real number between them? Either
> > > this theorem doesn't hold (and the whole math goes out
> > > the window) or the integers are most definitely not reals.
> > >
> > > Which will it be?
> >
> > Where is there the contradiction? Integers can be embedded in reals as a
> subset.
>
> Operations available for the type and how they behave.
> The theorem above was an example. Let's see:
>
> F(X, Y) = A
>
> such that for any given, finite X and Y where X < Y it
> produces A that satisfies the requirement that X < A < Y
>
> Trivial to do for real numbers. Impossible for integers.
> Which means that, at least in this respect, integers are
> not a subset of reals. To be more precise, you could
> argue that they are a subset or real *values* but that's
> not the same thing.
>
> You could also define an operation F that takes two
> integers and returns a generic real but that would also
> mean that integers do not posess a property critical
> to the definition of the real numbers.
>

Of course integers are a proper subset of reals.  You cannot simply invent a
new definition for subset ;)  You are letting language confuse the issue.
To reformulate your statements above

Does there exist a function F(X,Y) with the signature F:R x R -> R such that
for all X and Y there exists an A such that
X < A < Y?

Yes.

and for the integers

Does there exist a function F(X,Y) with the signature F:Z x Z -> Z such that
for all X and Y there exists an A such that
X < A < Y?

No.

but let's get tricky here and ask a similar question about integer numbers

Does there exist a function F(X,Y) with the signature F:Z x Z -> R such that
for all X and Y there exists an A such that
X < A < Y?

Yes.  But wait those numbers are integers how dare there exist a number
in-between them that belongs to the reals! ;)

A number by itself has very few properties.  Sets on the other hand have
most of the properties you care about ;)
Subsets do not necessarily have the same properties as their supersets.

-CRM

Re: Anybody in US using ADA ? One silly idea..

[Grein, Christoph]

> "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
> 
> > > Which is easily solved by saying:
> > >      Lower : constant Integer := Read;
> > >      Upper : constant Integer := Read;
> > >      subtype S is Integer range Lower..Upper;
> > > 
> > > (Fortunately, declarations *are* elaborated in order :-)
> > 
> > which, by RM 3.3.1(7), is the same as
> > 
> >        Lower, Upper: constant Integer := Read;
> 
> Which is an excellent example of why declaring multiple initialized
> variables in one statement is a horrible thing to do. I'd have to
> check the manual to see if Read is called once or twice for this;
> please never do it!

You have a point in posing that plea. But what would you do in this case:

       Limits: constant array (1..1000) of Integer := (others => Read);

Do you also think Read is just called once?

And in the above, if you want Read to be called exactly once, you'd have to 
write

   Lower: constant Integer := Read;
   Upper: constant Integer := Lower;

Re: Anybody in US using ADA ? One silly idea..

[Alexandre E. Kopilovitch]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
>In a language controversy on comp.arch a few weeks ago, some of us came to
>the conclusion that a lot of the irrational antipathy to Ada was based on
>unregenerate machismo. Real Programmers О©╫ don't want to hear about "software
>safety" (obviously a namby-pamby concern) and they certainly don't want
>their code criticized by Ada (a mere slip of girl).
>
>I suggested that we Ada proponents should talk instead about "aggressive bug
>destruction" and that the 0Y committee should look at changing the name to
>something that exudes testosterone. My first idea was "Rocky", but "Brutus"
>attracted more support.

Well, if the gender matters here then...


    THE FEMALE OF THE SPECIES

       (R. Kipling, 1911)


When the Hymalayan peasant meets the he-bear in his pride,
He shouts to scare the monster, who will often turn aside.
But the she-bear thus accosted rends the peasant tooth and nail,
For the female of the species is more deadly that the male.


When Nag the basking cobra hears the careless foot of man,
He will sometimes wriggle sideways and avoid it if he can.
But his mate makes no such motion where she camps beside her trail,
For the female of the species is more deadly that the male.


When the early Jesuit fathers preached the Hurons and Choctaws,
They prayed to be delivered from the vengeance of the squaws.
'Twas the women, not the warriors, turned those stark enthusiasts pale,
For the female of the species is more deadly that the male.


Man's timid heart is bursting with the things he must not say,
For the Woman that God gave him isn't his to give away;
But the hunter meets with husband, each confirms the other's tale--
For the female of the species is more deadly that the male.


Man, a bear in most relations--worm and savage otherwise,--
Man propounds negotiations, Man accepts the compromise.
Very rarely will he squarely push his logic of a fact
To its ultimate conclusion in unmitigated act.


Fear, or foolishness, impels him, ere he lay the wicked low,
To concede some form of trial even to his fiercest foe.
Mirth obscene diverts his anger--Doubt and Pity oft perplex
Him in dealing with an issue--to the scandal of The Sex!


But the Woman that God gives him, every fibre of her frame
Proves her launched for sole issue, armed and engined for the same;
And to serve that single issue, lest the generations fail,
The female of the species must be deadlier that the male.


She who faces Death by torture for each life beneath her breast
May not deal in doubt or pity--must not swerve for fact or jest.
These be purely male diversions--not in these her honour dweils,
She the Other Law we live by, is that Law and nothing else.


She can bring no more to living than the powers that make her great
As the Mother of the Infant and the Mistress of the Mate.
And whe Babe and Man are lacking and she strides unclaimed to claim
Her right as femme (and baron), and equipment is the same.


She is wedded to convictions--in default of grosser ties;
Her contentions are her children, Heaven help him who denies!--
He will meet no snave discussion, but the instant, white-hot, wild,
Wakened female of the species warring as for spouse and child.


Unprovoked and awful charges--even so the she-bear fights,
Speech that drips, corrodes, and poisons--even so the cobra bites,
Scientific vivisection of one nerve till it is raw
And the victim writhes in anguish--like the Jesuit with the squaw!


So it comes that Man, the coward, when he gathers to confer
With his fellow-braves in council, dare not leave a place for her
Where, at war with Life and Conscience, he uplifts his erring hands
To some God of Abstract Justice--which no woman understands.


And Man knows it! Knows moreover, that the Woman that God gave him
Must command but may not govern--shall enthral but not enslave him.
And ~She~ knows, because She warns him, and Her instincts never fail
That the Female of Her Species is more deadly that the Male.

Anybody in US using ADA ?

[Mr Bill]

It seems to have fallen out of favor with everybody I know.

Thanks,
Bill

Re: Anybody in US using ADA ?

[John R. Strohm]

I *THINK* that Lockheed-Martin Fort Worth is using Ada for F-22 and F-16.
You might try looking at their web sight (http://www.lmco.com) and seeing
what they are looking to hire.  (Most of their effort appears to be trawling
for resumes for  Joint Strike Fighter, which is in C++.

"Mr Bill" <nospam@nospam.com> wrote in message
news:VtlQ9.42144$%3.10762066@twister.neo.rr.com...
> It seems to have fallen out of favor with everybody I know.
>
> Thanks,
> Bill
>
>

Re: Anybody in US using ADA ?

[Marin David Condic]

I believe Pratt & Whitney is still using Ada for engine controls. At least
some of them. As one who is working on the engines for the JSF, I can tell
you that those controls are still in Ada - for the time being. (Don't know
what will happen when they go into full scale development.)

Its a shame to see that many in the DoD arena are abandoning Ada because
"Everybody else is using C++". In this area, Ada does not tend to suffer so
much from lack of large libraries or other development enhancers since
hardware is often custom built and/or software development is not the long
pole in the tent. Here Ada's faster development time and reduced defect
characteristics can truly stand out. I'm afraid I don't know how to overcome
the "follow the crowd" mentality here. Ada has the technical edge and so
long as compilers/tools are available for the target (at a reasonable cost)
there isn't a whole lot of business/financial edge to something else (in
many cases at least). None of that tends to persuade the programmers or
their managers that they shouldn't try to be like everyone else. The only
real hope is for Ada to find its way into a significant commercial niche so
that there is a large body of "everyone else" out there to be followed.

Its hard to blame the programmers or the managers. Programmers want to have
skills that can get them a job somewhere else if Congress pulls the plug on
what they're doing - or simply want to use what they are familiar with
already. Managers don't want to be perceived as taking unnecessary risks
and - as the saying used to be - "Nobody ever got fired for picking IBM".
Similarly, management won't be fired for using tools that are "industry
standard". Nobody is going to change that position unless Ada is adopted for
some reasonably wide sector of the software market.

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

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

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

John R. Strohm <strohm@airmail.net> wrote in message
news:C900921B7A3FDDD4.5FD752FF5D42F9AF.349D2214D482463F@lp.airnews.net...
> I *THINK* that Lockheed-Martin Fort Worth is using Ada for F-22 and F-16.
> You might try looking at their web sight (http://www.lmco.com) and seeing
> what they are looking to hire.  (Most of their effort appears to be
trawling
> for resumes for  Joint Strike Fighter, which is in C++.
>

Re: Anybody in US using ADA ? One silly idea..

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> I believe Pratt & Whitney is still using Ada for engine controls. At least
> some of them. As one who is working on the engines for the JSF, I can tell
> you that those controls are still in Ada - for the time being. (Don't know
> what will happen when they go into full scale development.)
> 
> Its a shame to see that many in the DoD arena are abandoning Ada because
> "Everybody else is using C++". In this area, Ada does not tend to suffer so
> much from lack of large libraries or other development enhancers since
> hardware is often custom built and/or software development is not the long
> pole in the tent. Here Ada's faster development time and reduced defect
> characteristics can truly stand out. I'm afraid I don't know how to overcome
> the "follow the crowd" mentality here. ...

Maybe what needs to be done is to form a brand new committee, to design
a spashy new language that basically implements the same features, with
similar syntax (but not too obviously). Then give it a splashy new name
after a popular young female (no programmer experience required), and
call it something like "Shania". Make sure it gets included in .Net, and
have the Universities preach about it and.. world domination!

;-)

Just a thought.

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

Re: Anybody in US using ADA ? One silly idea..

[Vinzent Hoefler]

Warren W. Gay VE3WWG wrote:

> Maybe what needs to be done is to form a brand new committee, to
> design a spashy new language that basically implements the same
> features, with similar syntax (but not too obviously). Then give it a
> splashy new name after a popular young female (no programmer
> experience required), and call it something like "Shania".

new language Shania renames Ada;

But, WTF is Shania?

> Make sure
> it gets included in .Net, and have the Universities preach about it
> and.. world domination!

We already got A#. :-)


Vinzent.

Re: Anybody in US using ADA ? One silly idea..

[Warren W. Gay VE3WWG]

Vinzent Hoefler wrote:
> Warren W. Gay VE3WWG wrote:
>>Maybe what needs to be done is to form a brand new committee, to
>>design a spashy new language that basically implements the same
>>features, with similar syntax (but not too obviously). Then give it a
>>splashy new name after a popular young female (no programmer
>>experience required), and call it something like "Shania".
> 
> new language Shania renames Ada;
> 
> But, WTF is Shania?

No real reason, other than her naval seems to
still persist in my memory cells ;-)

Warren.

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

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 2/1/03 17:57, in article 3E147D79.2070703@cogeco.ca, "Warren W. Gay
VE3WWG" <ve3wwg@cogeco.ca> wrote:
> 
> Maybe what needs to be done is to form a brand new committee, to design
> a spashy new language that basically implements the same features, with
> similar syntax (but not too obviously). Then give it a splashy new name
> after a popular young female (no programmer experience required), and
> call it something like "Shania".

In a language controversy on comp.arch a few weeks ago, some of us came to
the conclusion that a lot of the irrational antipathy to Ada was based on
unregenerate machismo. Real Programmers � don't want to hear about "software
safety" (obviously a namby-pamby concern) and they certainly don't want
their code criticized by Ada (a mere slip of girl).

I suggested that we Ada proponents should talk instead about "aggressive bug
destruction" and that the 0Y committee should look at changing the name to
something that exudes testosterone. My first idea was "Rocky", but "Brutus"
attracted more support.

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

Re: Anybody in US using ADA ? One silly idea..

[Marin David Condic]

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

Machismo may be interesting, but nobody is going to be fooled by empty,
shallow, marketing for very long. Eventually, they open the box up and see
the same old Ada and word gets out. I don't think Ada is *bad* - but it sure
has a problem selling itself with "reliability", etc. That's why I've become
convinced that a new emphasis and new tools might do a better job of getting
Ada accepted. I'd be happy to be proven wrong - that all we really had to do
was change the name and use some more cosmetics - but I don't think that's
the case.

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

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

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

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message
news:BA3A535D.177F%yaldnifw@blueyonder.co.uk...
>
> In a language controversy on comp.arch a few weeks ago, some of us came to
> the conclusion that a lot of the irrational antipathy to Ada was based on
> unregenerate machismo. Real Programmers � don't want to hear about
"software
> safety" (obviously a namby-pamby concern) and they certainly don't want
> their code criticized by Ada (a mere slip of girl).
>
> I suggested that we Ada proponents should talk instead about "aggressive
bug
> destruction" and that the 0Y committee should look at changing the name to
> something that exudes testosterone. My first idea was "Rocky", but
"Brutus"
> attracted more support.
>
> --
> Bill-Findlay chez blue-yonder.co.uk ("-" => "")
>
>

Re: Anybody in US using ADA ? One silly idea..

[sk]

mcondic.auntie.spam@acm.org

 > Machismo may be interesting, but nobody is going to be fooled by
 > empty, shallow, marketing for very long. Eventually, they open the
 > box up and see...

How has MS and windows survivied then ? :-)


-- 
--
-- Merge vertically for real address
--
------------------------------------
-- s n p @ t . o
--  k i e k c c m
------------------------------------

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 3/1/03 02:56, in article av2u64$qj$1@slb5.atl.mindspring.net, "Marin
David Condic" <mcondic.auntie.spam@acm.org> wrote:

> Machismo may be interesting, but nobody is going to be fooled by empty,
> shallow, marketing for very long.

It was a joke, Marin.

> Eventually, they open the box up and see the same old Ada and word gets out.

"Same old Ada"? For all practical purposes Ada 95 is the same age as Java.

"Word gets out"? What word is that? Are you saying that there are serious
unacknowledged technical defects in Ada 95?

Opposition to Ada in comp.arch fell into three categories, which I parody
(grotesquely unfairly, I admit 8-) as follows:
(1) "We don't care about software quality. We make money selling ****
written in C, and that's fine with us."
(2) "We do care about software quality. We write our software in C (or
other, even less safe, languages) and ensure its quality by being faultless
programmers and superior human beings. Ada is for talentless losers."
(3) "Ada is too low-level. Our favourite language is Functional-Telepathy/1,
which generates an optimal program for you while you are still thinking
about the specification. It should be implemented real soon now."

Depressingly, type (1) critics were in a majority. When shown evidence (the
Rational data) that Ada could help them to make even more money, the
response was "I don't believe it"; taken even to the point of suggesting
that Rational had fabricated their figures. In other words: "I've no
evidence of my own, so I'll find reasons to ignore yours".

The intensity of denial was astonishing.

Type (2) and type (3) critics tended to post from academic domains (no
surprise 8-), although academia did not have a monopoly on false pride.

It's interesting that essentially no-one objected to Ada on the grounds of
technical or pragmatic issues such as are are openly discussed here.

> I don't think Ada is *bad* -

That's damming with faint praise. I think Ada 95 is very, very good indeed.

> but it sure has a problem selling itself with "reliability", etc.
> That's why I've become
> convinced that a new emphasis and new tools might do a better job of getting
> Ada accepted. I'd be happy to be proven wrong - that all we really had to do
> was change the name and use some more cosmetics - but I don't think that's
> the case.

Why do you care whether anyone adopts Ada, if "reliability, etc" is not the
primary concern? I look at this the other way round. I want the general
level of software quality to rise, and I believe that better understanding
and wider adoption of Ada would promote this objective. I'm more than happy
to make common cause with anyone, such as yourself, who has ideas about how
to make that happen. But I do not think that it is Ada that is the barrier;
and I do think that the barrier is fairly impenetrable. 8-(
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

RE: Anybody in US using ADA ? One silly idea..

[Robert C. Leif]

I have just spent a total of 12 of hours trying to open a file with Windows
XP Professional. This file was created under Windows 98 and still opens
under 98. The customers would flock to something that worked! 
In case this bug happens to anyone else, shorten the file names under an old
version of Windows. Evidently XP has a constraint that does not exist in the
older versions. Although XP has not crashed itself, many applications still
crash including Windows Explorer. Rebooting once a day is a reasonable means
of eliminating pointer garbage. Ada needs commercial products. 
Bob Leif

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]
On Behalf Of Bill Findlay
Sent: Thursday, January 02, 2003 8:43 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..

On 3/1/03 02:56, in article av2u64$qj$1@slb5.atl.mindspring.net, "Marin
David Condic" <mcondic.auntie.spam@acm.org> wrote:

> Machismo may be interesting, but nobody is going to be fooled by empty,
> shallow, marketing for very long.

It was a joke, Marin.

> Eventually, they open the box up and see the same old Ada and word gets
out.

"Same old Ada"? For all practical purposes Ada 95 is the same age as Java.

"Word gets out"? What word is that? Are you saying that there are serious
unacknowledged technical defects in Ada 95?

Opposition to Ada in comp.arch fell into three categories, which I parody
(grotesquely unfairly, I admit 8-) as follows:
(1) "We don't care about software quality. We make money selling ****
written in C, and that's fine with us."
(2) "We do care about software quality. We write our software in C (or
other, even less safe, languages) and ensure its quality by being faultless
programmers and superior human beings. Ada is for talentless losers."
(3) "Ada is too low-level. Our favourite language is Functional-Telepathy/1,
which generates an optimal program for you while you are still thinking
about the specification. It should be implemented real soon now."

Depressingly, type (1) critics were in a majority. When shown evidence (the
Rational data) that Ada could help them to make even more money, the
response was "I don't believe it"; taken even to the point of suggesting
that Rational had fabricated their figures. In other words: "I've no
evidence of my own, so I'll find reasons to ignore yours".

The intensity of denial was astonishing.

Type (2) and type (3) critics tended to post from academic domains (no
surprise 8-), although academia did not have a monopoly on false pride.

It's interesting that essentially no-one objected to Ada on the grounds of
technical or pragmatic issues such as are are openly discussed here.

> I don't think Ada is *bad* -

That's damming with faint praise. I think Ada 95 is very, very good indeed.

> but it sure has a problem selling itself with "reliability", etc.
> That's why I've become
> convinced that a new emphasis and new tools might do a better job of
getting
> Ada accepted. I'd be happy to be proven wrong - that all we really had to
do
> was change the name and use some more cosmetics - but I don't think that's
> the case.

Why do you care whether anyone adopts Ada, if "reliability, etc" is not the
primary concern? I look at this the other way round. I want the general
level of software quality to rise, and I believe that better understanding
and wider adoption of Ada would promote this objective. I'm more than happy
to make common cause with anyone, such as yourself, who has ideas about how
to make that happen. But I do not think that it is Ada that is the barrier;
and I do think that the barrier is fairly impenetrable. 8-(
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1041573722.6746.comp.lang.ada@ada.eu.org>...
> I have just spent a total of 12 of hours trying to open a file with 
> Windows
> XP Professional. This file was created under Windows 98 and still opens
> under 98. The customers would flock to something that worked! 
> In case this bug happens to anyone else, shorten the file names under an 
> old
> version of Windows. Evidently XP has a constraint that does not exist in 
> the
> older versions. Although XP has not crashed itself, many applications 
> still
> crash including Windows Explorer. Rebooting once a day is a reasonable 
> means
> of eliminating pointer garbage. Ada needs commercial products. 

Given that few if any current Ada implementations provide garbage
collection,
the programmers would still have to manage memory via
new/unchecked_deallocation
And the same programmers who leak memory or create dangling pointers
with new/delete/malloc/free would do the same thing with
new/unchecked_deallocation.

Re: Anybody in US using ADA ? One silly idea..

[tmoran]

> And the same programmers who leak memory or create dangling pointers
> with new/delete/malloc/free would do the same thing with
> new/unchecked_deallocation.
  "If there's a 'with Ada.Unchecked_Deallocation' on the body, there
ought to be a 'with Ada.Finalization' on the spec."

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

tmoran@acm.org wrote in message news:<VaGS9.672077$NH2.47101@sccrnsc01>...
> > And the same programmers who leak memory or create dangling pointers
> > with new/delete/malloc/free would do the same thing with
> > new/unchecked_deallocation.
>   "If there's a 'with Ada.Unchecked_Deallocation' on the body, there
> ought to be a 'with Ada.Finalization' on the spec."

Right.  There ought to be.  The same programmers who leak memory
with new/delete/malloc/free are the same programmers who wouldn't
use Ada.Finalization.

Re: Anybody in US using ADA ? One silly idea..

[Marin David Condic]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message
news:BA3AC562.17A7%yaldnifw@blueyonder.co.uk...
>
> It was a joke, Marin.
>
Ahhh, but a "joke" that's been seriously suggested here before. :-)


> > Eventually, they open the box up and see the same old Ada and word gets
out.
>
> "Same old Ada"? For all practical purposes Ada 95 is the same age as Java.
>
By which I meant that simply changing the terminology to be more "Macho"
and/or just tinkering with the syntax a little to make it look different
isn't going to fool anyone into thinking its something "new".


> "Word gets out"? What word is that? Are you saying that there are serious
> unacknowledged technical defects in Ada 95?
>
Nope. See above.

> Opposition to Ada in comp.arch fell into three categories, which I parody
> (grotesquely unfairly, I admit 8-) as follows:
> (1) "We don't care about software quality. We make money selling ****
> written in C, and that's fine with us."
> (2) "We do care about software quality. We write our software in C (or
> other, even less safe, languages) and ensure its quality by being
faultless
> programmers and superior human beings. Ada is for talentless losers."
> (3) "Ada is too low-level. Our favourite language is
Functional-Telepathy/1,
> which generates an optimal program for you while you are still thinking
> about the specification. It should be implemented real soon now."
>
> Depressingly, type (1) critics were in a majority. When shown evidence
(the
> Rational data) that Ada could help them to make even more money, the
> response was "I don't believe it"; taken even to the point of suggesting
> that Rational had fabricated their figures. In other words: "I've no
> evidence of my own, so I'll find reasons to ignore yours".
>
> The intensity of denial was astonishing.
>
I understand and sympathize. The problem is that those are your potential
customers for Ada and if you don't find a way to persuade them with
*something* then you'd might as well just give up. I've had my own data
showing how Ada can make more money and the problem is that this sort of
data just doesn't seem to help people get interested in it. Mostly because
it is "Life Cycle" money and most business efforts are driven by "Time To
Market" money. They don't care if it costs more in the long run because if
it doesn't get there first, it won't earn anything anyway, so better to
spend more "in the long run" if whatever you do gets a product out the door
quicker.

So if we could find a way to show some segment of this market that Ada
brought them some truckload of leverage that got them to market twice as
fast, don't you think they'd perk up and be interested? I did a stint in the
Cable TV Set Top Box world and if Ada had been there with a whole package of
stuff that got the box delivered faster - and with fewer defects - it might
have been given a serious shot. (And found a nice "emerging technology" to
tie itself to.) There ought to be some segment of the developer world that
Ada can address more effectively by listening to its concerns and providing
it with leverage.


> Type (2) and type (3) critics tended to post from academic domains (no
> surprise 8-), although academia did not have a monopoly on false pride.
>
> It's interesting that essentially no-one objected to Ada on the grounds of
> technical or pragmatic issues such as are are openly discussed here.
>
So if you want to sell to them, using technical arguments of superiority or
pragmatic arguments of life cycle costs aren't going to work. (That
shouldn't be news. Ada's been making that case for 20 years now and
customers are ignoring it by the millions.) That means we ought to find out
what the customer *would* buy and find a way to get that into Ada if it
doesn't already exist.


> > I don't think Ada is *bad* -
>
> That's damming with faint praise. I think Ada 95 is very, very good
indeed.
>
Maybe. I've been an Ada advocate for a very long time, so I think I'm on
record as saying nice things about it. My intent was to indicate that I
didn't see some fundamental flaws in the language itself that were causing
it to fail to be adopted. Syntactic or semantic changes are probably not
necessary on any large scale - more an emphasis on what else Ada provides
besides its syntax & semantics.


>
> Why do you care whether anyone adopts Ada, if "reliability, etc" is not
the
> primary concern? I look at this the other way round. I want the general
> level of software quality to rise, and I believe that better understanding
> and wider adoption of Ada would promote this objective. I'm more than
happy
> to make common cause with anyone, such as yourself, who has ideas about
how
> to make that happen. But I do not think that it is Ada that is the
barrier;
> and I do think that the barrier is fairly impenetrable. 8-(
> --
O.K. I hope I can make myself crystal clear on this one: I am NOT opposed to
reliability nor do I think it is irrelevant or should be taken out of the
language or anything of that sort. What I'm saying is that Ada has been
harping on "Reliability" for TWENTY YEARS and people are staying away from
it in droves. Twenty more years of harping on reliability is not likely to
change that. Hence, let's keep reliability in our back pocket to pull out
when it makes sense to talk about it, but in the mean time, lets find
something more appealing to put in front of the potential users that they
might actually care about. Find out what some commercial developers in some
sector might want in a programming language and fill that need. When they
get reliability as a byproduct, then you can pull the "See??? I Told You
So!!!" out of your back pocket and we can all brag about that.

As someone who likes and uses Ada, I'd like to see the language grow and
prosper. I think the best way to do that is to get Ada focused on providing
something that some large segment of the developer population just can't
resist using. If we give thought to that, maybe we can come up with the
right changes and the right focus.

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

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

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

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 3/1/03 13:16, in article av42f6$d5i$1@slb6.atl.mindspring.net, "Marin
David Condic" <mcondic.auntie.spam@acm.org> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message
> news:BA3AC562.17A7%yaldnifw@blueyonder.co.uk...
>> 
>> It was a joke, Marin.
>> 
> Ahhh, but a "joke" that's been seriously suggested here before. :-)

!!!!
 
>> "Same old Ada"? For all practical purposes Ada 95 is the same age as Java.
> By which I meant that simply changing the terminology to be more "Macho"
> and/or just tinkering with the syntax a little to make it look different
> isn't going to fool anyone into thinking its something "new".

I agree, of course.

[...]
>> (1) "We don't care about software quality ..."
>> (2) "We do care about software quality. ... Ada is for talentless losers."
>> (3) "Ada is too low-level. ..."
>> 
>> Depressingly, type (1) critics were in a majority.
[...]
>> 
> I understand and sympathize. The problem is that those are your potential
> customers for Ada and if you don't find a way to persuade them with
> *something* then you'd might as well just give up. I've had my own data
> showing how Ada can make more money and the problem is that this sort of
> data just doesn't seem to help people get interested in it. Mostly because
> it is "Life Cycle" money and most business efforts are driven by "Time To
> Market" money. They don't care if it costs more in the long run because if
> it doesn't get there first, it won't earn anything anyway, so better to
> spend more "in the long run" if whatever you do gets a product out the door
> quicker.

That pretty much sums up what type (1) critics said.
Despite my making fun of them, I do think they have the makings of a point.
But don�t you think that (other things being equal - and that is what you
are emphasizing) Ada *would* get them to market sooner?

I was even more depressed that type (2) critics, who did care about quality,
had the perception that Ada was a crutch for the talentless.
This is so contrary to my own perception that I find it bewildering.

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

Re: Anybody in US using ADA ? One silly idea..

[Marin David Condic]

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

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message
news:BA3B86D9.17DB%yaldnifw@blueyonder.co.uk...
>
> That pretty much sums up what type (1) critics said.
> Despite my making fun of them, I do think they have the makings of a
point.
> But don�t you think that (other things being equal - and that is what you
> are emphasizing) Ada *would* get them to market sooner?
>
Well if they are saying exactly what I'm saying, then they're right. :-)
They may be saying something else - or you're hearing something else, if you
find disagreements here. Your problem is the "Other things being equal"
part. They never are. Contemplating a project you want to take to market,
you look at what is available to you and quite often with C or C++, you've
got an OS, GUI, Database, etc. that are all written in C and can be
interfaced/embedded/whatever rather readily as long as you use C/C++ to do
the job. Sure you'll spend twice as long debugging the unholy mess, but
you'll have something to show the customer *much* sooner than the guys who
are working in Ada and spending the first 6 months developing the bindings,
libraries, utilities, etc., they'll need to just get to where you are at
when you open up the box and install the compiler. Sure your product will be
a piece of crap - but it will be the only thing available to the customer,
so he'll buy it and use it anyway and you'll have money in your pocket and a
customer locked in to your product just about the time the Ada guys are
going "Hey, we've got the bindings and libraries and tools now. Let's get
started building the app."

I don't think most companies build crap software because they *want* to.
They do it because they're using tools/methods that result in crap, but crap
that gets there quickly. Bringing them something that let them build
solid-gold apps just as quickly might persuade them to switch.




> I was even more depressed that type (2) critics, who did care about
quality,
> had the perception that Ada was a crutch for the talentless.
> This is so contrary to my own perception that I find it bewildering.
>
I've always been disappointed by the "Any *competent* programmer..."
argument, but not at all surprised. Back in the days of Shakespear there was
the "Any *competent* carpenter can do his job with an axe and doesn't need
that crutch you call a 'saw'..." Eventually, the crutch can win out because
it is providing leverage to the developer, so I don't get discouraged. Its
just that Ada's particular 'crutch' is not being perceived as a big enough
deal to warrant switching to Ada. So maybe Ada just needs to come up with a
bigger, better crutch?

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

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

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

Re: Anybody in US using ADA ? One silly idea..

[faust]

 Bill Findlay <yaldnifw@blueyonder.co.uk> ,  emitted these fragments:

>I was even more depressed that type (2) critics, who did care about quality,
>had the perception that Ada was a crutch for the talentless.
>This is so contrary to my own perception that I find it bewildering.

A talented analyst/programmer with Fujitsu once told me that Ada is
"COBOL for the clueless".

This was after I told him about the nifty default parameters that
functions could be given.


-- 
natsu-gusa ya     / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones          / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dennis Lee Bieber wrote:
>         What would you expect ACT folks to say if you were trying to sell them 
> on the benefits of COBOL? <G>

That you are preaching to the choir?
Robert Dewar is one of the creators of Realia COBOL.
That compiler was written in itself.

Re: Anybody in US using ADA ? One silly idea..

[tmoran]

>something that some large segment of the developer population just can't
>resist using.
  Is there an Ada compiler targetted to the chips used by cell phones?
PDAs?  Consumer robots (beyond the Ada-subset => C for Lego)?
Small, cheap, embedded gadgets in general?  If so, are there bindings?

Re: Anybody in US using ADA ? One silly idea..

[Martin Dowie]

<tmoran@acm.org> wrote in message news:m4mR9.615001$QZ.89410@sccrnsc02...
> >something that some large segment of the developer population just can't
> >resist using.
>   Is there an Ada compiler targetted to the chips used by cell phones?
> PDAs?  Consumer robots (beyond the Ada-subset => C for Lego)?
> Small, cheap, embedded gadgets in general?  If so, are there bindings?

The Symbian OS can use gcc, so GNAT shouldn't be outrageously difficult to
port to that.

Re: Anybody in US using ADA ? One silly idea..

[faust]

 "Martin Dowie" <martin.dowie@no.spam.btopenworld.com> ,  emitted
these fragments:

>>   Is there an Ada compiler targetted to the chips used by cell phones?
>> PDAs?  Consumer robots (beyond the Ada-subset => C for Lego)?
>> Small, cheap, embedded gadgets in general?  If so, are there bindings?
>
>The Symbian OS can use gcc, so GNAT shouldn't be outrageously difficult to
>port to that.

ie: There is f*ing vapourware.

-- 
natsu-gusa ya     / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones          / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

RE: Anybody in US using ADA ? One silly idea..

[Robert C. Leif]

If the target is based on Windows CE or Windows embedded.NET, then A# should
work for all of the processors supported by these operating systems. Since
ECMA is a legitimate standards organization, multiple chip vendors should be
considering developing code generators specific for the ECMA intermediate
language. If they are smart, they will hardwire the ECMA intermediate
language in a manner similar to the J code processors.
Bob Leif

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]
On Behalf Of tmoran@acm.org
Sent: Friday, January 03, 2003 12:08 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..

>something that some large segment of the developer population just can't
>resist using.
  Is there an Ada compiler targetted to the chips used by cell phones?
PDAs?  Consumer robots (beyond the Ada-subset => C for Lego)?
Small, cheap, embedded gadgets in general?  If so, are there bindings?

Re: Anybody in US using ADA ? One silly idea..

[Steve]

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:mailman.1041664082.19130.comp.lang.ada@ada.eu.org...
[snip]
  Is there an Ada compiler targetted to the chips used by cell phones?
PDAs?  Consumer robots (beyond the Ada-subset => C for Lego)?
Small, cheap, embedded gadgets in general?  If so, are there bindings?

Funny you should ask.
I just purchased a Handspring Visor Platinum (PDA) to replace my Day Timer.
While I'm not planning on writing programs, I was curious as to what's
available for development.

It turns out the Visor uses a Motorola MC68VZ328 processor, one of the
variants of the 68K.  You can download a version of gcc that includes what
is needed to program the visor, but the version referenced by handsprings
site uses a version of GCC prior to 3.0 so Ada is not included in the kit.

It may very well be possible to build a new version of GCC targeting PalmOS
(m68k-palmos-gcc).  I am not aware of any run-time library support, but it
looks like building GNAT to target PalmOS may not be that difficult.

Since I'm not that interested in programming PDAs I don't plan on pursuing
it, but some ambitious soul might.  I would be very suprised if ACT turned
down a request from a paying customer.

Steve
(The Duck)

RE: Anybody in US using ADA ? One silly idea..

[Robert C. Leif]

I did not write that statement. I did state that the work-around was to use
the ECMA intermediate language. This is how Java and before that UCSD Pascal
facilitated hosting.
Bob Leif

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]
On Behalf Of Steve
Sent: Saturday, January 04, 2003 9:50 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:mailman.1041664082.19130.comp.lang.ada@ada.eu.org...
[snip]
  Is there an Ada compiler targetted to the chips used by cell phones?
PDAs?  Consumer robots (beyond the Ada-subset => C for Lego)?
Small, cheap, embedded gadgets in general?  If so, are there bindings?

Funny you should ask.
I just purchased a Handspring Visor Platinum (PDA) to replace my Day Timer.
While I'm not planning on writing programs, I was curious as to what's
available for development.

It turns out the Visor uses a Motorola MC68VZ328 processor, one of the
variants of the 68K.  You can download a version of gcc that includes what
is needed to program the visor, but the version referenced by handsprings
site uses a version of GCC prior to 3.0 so Ada is not included in the kit.

It may very well be possible to build a new version of GCC targeting PalmOS
(m68k-palmos-gcc).  I am not aware of any run-time library support, but it
looks like building GNAT to target PalmOS may not be that difficult.

Since I'm not that interested in programming PDAs I don't plan on pursuing
it, but some ambitious soul might.  I would be very suprised if ACT turned
down a request from a paying customer.

Steve
(The Duck)

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Marin David Condic wrote:

> O.K. I hope I can make myself crystal clear on this one: I am NOT opposed to
> reliability nor do I think it is irrelevant or should be taken out of the
> language or anything of that sort.

Programmers, most of them I know, don't care a whit about reliability.  They
care about convenience.    Remember when we would teach Ada 83 and
we had to show the students how to instantiate a generic package so they
could do simple I/O?   Remember how difficult it was, with Ada 83
to do  simple file management?    Remember how frustrating it was to
format an MS-DOS screen using standard Ada?    Remember how the
students reacted when exposed to the visibility rules?

Most of those new Ada programmers just wanted to write simple programs
to get started.  Many wanted to use Ada on their home machines to do
little projects for fun.   I recall the Meridian compiler had a DOS package
that was pretty good, but still fell short of what we needed.  For example,
with the overpriced Alsys compiler, one could access any part of memory
because the type Address allowed it.   With the Meridian compiler the
type Address was a type signed integer so one could not directly address
the display address values in the upper 360KB of DOS space.   Sounds
silly.  Maybe, but it prevented one of my customers from doing the kind
of high-peformance graphics they could do with Alsys.

We have the defined the language for technical people and made it almost
inaccessible to those who simply want to do the kind of programming they
usually do with Fortran.   We have some libraries, finally, for doing GUI
programming, but too late to inspire the ordinary programmer to take a
second look.   My students are at different levels of capability.  Some love
to program with John English's JEWL package since it so easy to do so
many interesting Windows programs.  Others love CLAW.   At least one
pair of students did a great M.S. thesis using GtkAda.

One of the saddest things was the abandonment of the Java Byte Code
initiative from GNAT.   Yes, I realize there was insufficient commercial
demand.  However, I had generated a lot of interest in it at NPS until it
turned out that the existing version was not up-to-date with the current
JVM capabilities.  My colleagues, at first enthusiastic, quickly lost
interest.  In the parlance of the "romance novel" this is known as
"seduced and abandoned."

Ada is, in my view, the best choice of programming languages for a wide
range of applications, wider than reliabiility-oriented applications, and
wider than most other languages.   I was just reading my new copy of
the Consolidated Ada Language Reference Manual at 2:00 AM this
morning and found myself entertained by the improvement in language,
explanation, and clarification.    We need more literature explaining,
in depth and with examples,  how certain things work.   For example,
someone could do a good tutorial on the mathematical capabilities
of the language using some examples from the Numerical Recipes
Series.     I tried to create a little booklet with my Ada Distilled to
make the language more accessible.   The responses I get from readers
of Ada Distilled has been encouraging and I continue to update and
expand it based on that feedback.

We need more libraries similar to those created by Jerry Van Djik,
such as his NT_Console package.   In fact, that package needs a
little enhancement, but is pretty good as it is.

I have mentioned before, and re-emphasize again, those of us who want
to promote Ada can do nothing better than create commercial applications
using it.  There is not end to the ideas for new applications and no end
to what can be sold in the marketplace.   Where are the games programmed
in Ada and sold in shrink-wrap?   Where are the database applications
created in Ada and marketed to the business community?    Where is the
spreadsheet program written in Ada that makes Excel look like yesterday's
stale bread?

The best way to sell Ada is to use it for building applications that people
use on their computers.   CLAW is a great starting place for creating
such applications for Windows.    GtkAda is a great starting place to
create the sorely needed applications for Linux, a platform where users
are desperate for new applications.

The path to commercial success for Ada is to use it for successful commercial
products.   Harness your own creativity to Ada.    Build products.   Don't
tout them as Ada products but as products that solve a problem.   Only after
your product is wildly successful do you need to reveal that you used Ada.

It is nearly impossible to convince a large corporation to change course in
its choice of programming languages once the bureaucracy has made its
decision.   Such decisions are rarely made on technical grounds.  They
are usually made by people who have little knowledge of software and
less knowledge of programming languages.   They make incredibly
stupid decisions, most often choosing something as disastrous as
C++.   I often suggest to my students that, if C++ is the best we can
do in programming languages, this industry is in trouble for a long
time to come.

Ruby is achieving success because developers are choosing it.   Python
is successful for the same reason.   Eiffel, which should be more
successful, is not as widely received, in part, I suspect because it
is viewed as an expensive commercial alternative.  Ada is now
available in free, downloadble versions similar to Ruby, Smalltalk,
Scheme, and Python.    That is a good start, but not quite enough.

Go and make your fortune with a product created in Ada and you can
walk away from that dour, windowless cubicle in which you have been
imprisoned by some huge defense contractor.  You can build as good or
better products using what we now have available in the Ada language
and its available libraries.

Programmers of the world, choose Ada.  You have nothing to lose but your chains.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[faust]

 Richard Riehle <richard@adaworks.com> ,  emitted these fragments:

> Harness your own creativity to Ada.     ...
.....
>Programmers of the world, choose Ada.  You have nothing to lose but your chains.

Or the productive years of your life.
Do you really want to end up like the OS/2 advocates, forever whining
on about how the bad bureaucrats wont let them use their technically
superior solution ?

-- 
natsu-gusa ya     / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones          / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BA3A535D.177F%yaldnifw@blueyonder.co.uk>...
> On 2/1/03 17:57, in article 3E147D79.2070703@cogeco.ca, "Warren W. Gay
> VE3WWG" <ve3wwg@cogeco.ca> wrote:
> > 
> > Maybe what needs to be done is to form a brand new committee, to design
> > a spashy new language that basically implements the same features, with
> > similar syntax (but not too obviously). Then give it a splashy new name
> > after a popular young female (no programmer experience required), and
> > call it something like "Shania".
> 
> In a language controversy on comp.arch a few weeks ago, some of us came to
> the conclusion that a lot of the irrational antipathy to Ada was based on
> unregenerate machismo. 

Not all the antipathy to Ada is irrational.  Most of it comes
from sad experience.  Mine was trying to use Ada-83 to write Unix 
applications with a Motif UI.  Regardless of any superiority in
reliability, the scarcity of libraries and trained
programmers makes Ada too expensive for most commercial software
projects.

Re: Anybody in US using ADA ? One silly idea..

[John R. Strohm]

"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0301030124.237c7a7e@posting.google.com...
> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message
news:<BA3A535D.177F%yaldnifw@blueyonder.co.uk>...
> > On 2/1/03 17:57, in article 3E147D79.2070703@cogeco.ca, "Warren W. Gay
> > VE3WWG" <ve3wwg@cogeco.ca> wrote:
> > >
> > > Maybe what needs to be done is to form a brand new committee, to
design
> > > a spashy new language that basically implements the same features,
with
> > > similar syntax (but not too obviously). Then give it a splashy new
name
> > > after a popular young female (no programmer experience required), and
> > > call it something like "Shania".
> >
> > In a language controversy on comp.arch a few weeks ago, some of us came
to
> > the conclusion that a lot of the irrational antipathy to Ada was based
on
> > unregenerate machismo.
>
> Not all the antipathy to Ada is irrational.  Most of it comes
> from sad experience.  Mine was trying to use Ada-83 to write Unix
> applications with a Motif UI.  Regardless of any superiority in
> reliability, the scarcity of libraries and trained
> programmers makes Ada too expensive for most commercial software
> projects.

In the very early 1980s, General Dynamics / Fort Worth Division started the
F-16C/D program.  This was a MAJOR upgrade of the airplane, involving, among
other things, all new computers and all new software.

Ada wasn't there yet, so they chose JOVIAL J73.

At that time, there existed precisely one J73 compiler, and it didn't target
EITHER of the processors they were designing into the airplane (Zilog Z8002
and MIL-STD-1750A).  They wound up having to let compiler development
contracts to two (small) companies to develop toolsets.

At that time, trained J73 programmers just plain didn't exist.  GD/FW had to
train every single programmer they hired for that project.

Every time I hear someone grumbling about the scarcity of trained Ada
programmers, I think about F-16C/D and JOVIAL, and I wonder how GD/FW ever
managed to get that airplane off the ground, if training is so hard.

I'm not even going to mention HAL/S, the Space Shuttle language, which to my
(unclassified) knowledge was not used for anything else on the planet.
Where does NASA (and the SEI Level 5 contractor) get trained HAL/S
programmers?

Re: Anybody in US using ADA ? One silly idea..

[Marin David Condic]

Problem: Those were big companies and the projects were very long lived
where software development was not going to be the cost or schedule driver.
How many commercial products are in that position? Your average
garage-startup company is never going to be able to let out contracts to get
a compiler retargeted and your average small business is never going to be
able to wait until the retargeted compiler is ready to use before they can
start development.

Ada shot itself in the foot early on because it was A) Too expensive, B)
Didn't work well and C) Wasn't available for the platforms people were
developing on. It pretty much cured those problems by now - but too late to
avoid all the damage and missed opportunities. Now it faces new problems and
it has to address those if it hopes to avoid the same missed opportunities.

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

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

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

John R. Strohm <strohm@airmail.net> wrote in message
news:80F453381B124BF8.ACEC58777658C8DC.89DCAA63449DBB7B@lp.airnews.net...
>
> In the very early 1980s, General Dynamics / Fort Worth Division started
the
> F-16C/D program.  This was a MAJOR upgrade of the airplane, involving,
among
> other things, all new computers and all new software.
>
> Ada wasn't there yet, so they chose JOVIAL J73.
>
> At that time, there existed precisely one J73 compiler, and it didn't
target
> EITHER of the processors they were designing into the airplane (Zilog
Z8002
> and MIL-STD-1750A).  They wound up having to let compiler development
> contracts to two (small) companies to develop toolsets.
>
> At that time, trained J73 programmers just plain didn't exist.  GD/FW had
to
> train every single programmer they hired for that project.
>
> Every time I hear someone grumbling about the scarcity of trained Ada
> programmers, I think about F-16C/D and JOVIAL, and I wonder how GD/FW ever
> managed to get that airplane off the ground, if training is so hard.
>
> I'm not even going to mention HAL/S, the Space Shuttle language, which to
my
> (unclassified) knowledge was not used for anything else on the planet.
> Where does NASA (and the SEI Level 5 contractor) get trained HAL/S
> programmers?
>
>
>

Re: Anybody in US using ADA ? One silly idea..

[John R. Strohm]

I don't know whether I can use this as a counterexample or not.  My
recollection is that Silicon Graphics was using Ada internally VERY early in
their life, and they were keeping this VERY quiet because it was helping
them, a lot, and they didn't really want anyone else to know.

Rational used Ada internally, and it helped them a lot.  They published
their numbers, but the reaction at GD/FW was that it just wasn't possible to
get those kinds of numbers.

McDonnell-Douglas had been using assembly language on F-15.  For the
IFFC/Firefly demonstration, they jumped into Ada with both feet,
enthusiastically, and reported very good numbers, for a digital flight
control application.  (IFFC/Firefly was Integrated Flight and Fire Controls:
the idea was to let the firecontrol computers cue the flight control system
directly, to let the airplane help the pilot point the airplane and the
weapons at the target.  The demo pilot reportedly said, very
enthusiastically, "I don't know if I fired the gun or the airplane did, but
WE GOT HIM!")

I do know that Silicon Graphics was unique among workstation manufacturers
for having a solid Ada toolset long before anyone else did.

Software development very much WAS the schedule driver on F-16C/D.  First
flight was a year late because the software came in a year behind schedule.
You better believe that caused some ruffled feathers.  (I was told by an
old-timer there that it had something to do with a senior manager
arbitrarily carving a year out of the development schedule estimates...)

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:av42sd$jje$1@slb6.atl.mindspring.net...
> Problem: Those were big companies and the projects were very long lived
> where software development was not going to be the cost or schedule
driver.
> How many commercial products are in that position? Your average
> garage-startup company is never going to be able to let out contracts to
get
> a compiler retargeted and your average small business is never going to be
> able to wait until the retargeted compiler is ready to use before they can
> start development.
>
> Ada shot itself in the foot early on because it was A) Too expensive, B)
> Didn't work well and C) Wasn't available for the platforms people were
> developing on. It pretty much cured those problems by now - but too late
to
> avoid all the damage and missed opportunities. Now it faces new problems
and
> it has to address those if it hopes to avoid the same missed
opportunities.
>
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>     "I'd trade it all for just a little more"
>         --  Charles Montgomery Burns, [4F10]
> ======================================================================
>
> John R. Strohm <strohm@airmail.net> wrote in message
> news:80F453381B124BF8.ACEC58777658C8DC.89DCAA63449DBB7B@lp.airnews.net...
> >
> > In the very early 1980s, General Dynamics / Fort Worth Division started
> the
> > F-16C/D program.  This was a MAJOR upgrade of the airplane, involving,
> among
> > other things, all new computers and all new software.
> >
> > Ada wasn't there yet, so they chose JOVIAL J73.
> >
> > At that time, there existed precisely one J73 compiler, and it didn't
> target
> > EITHER of the processors they were designing into the airplane (Zilog
> Z8002
> > and MIL-STD-1750A).  They wound up having to let compiler development
> > contracts to two (small) companies to develop toolsets.
> >
> > At that time, trained J73 programmers just plain didn't exist.  GD/FW
had
> to
> > train every single programmer they hired for that project.
> >
> > Every time I hear someone grumbling about the scarcity of trained Ada
> > programmers, I think about F-16C/D and JOVIAL, and I wonder how GD/FW
ever
> > managed to get that airplane off the ground, if training is so hard.
> >
> > I'm not even going to mention HAL/S, the Space Shuttle language, which
to
> my
> > (unclassified) knowledge was not used for anything else on the planet.
> > Where does NASA (and the SEI Level 5 contractor) get trained HAL/S
> > programmers?
> >
> >
> >
>
>

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<694A0F8ED8C6BEE3.22D30132AB9CC656.F5BBD1A702580BDE@lp.airnews.net>...
> I don't know whether I can use this as a counterexample or not.  My
> recollection is that Silicon Graphics was using Ada internally VERY early in
> their life, and they were keeping this VERY quiet because it was helping
> them, a lot, and they didn't really want anyone else to know.

I'm skeptical that Ada was ever very widely used at SGI.
 
> Rational used Ada internally, and it helped them a lot.  They published
> their numbers, but the reaction at GD/FW was that it just wasn't possible to
> get those kinds of numbers.

At the time, Rational had an Ada compiler to sell, and not much else,
so their numbers are suspect.

> McDonnell-Douglas had been using assembly language on F-15.  For the
> IFFC/Firefly demonstration, they jumped into Ada with both feet,
> enthusiastically, and reported very good numbers, for a digital flight
> control application.  

I would certainly expect programming in Ada to be much more productive
than programming in assembly language!

Re: Anybody in US using ADA ? One silly idea..

[John R. Strohm]

"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0301040105.7d1a7ad6@posting.google.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
news:<694A0F8ED8C6BEE3.22D30132AB9CC656.F5BBD1A702580BDE@lp.airnews.net>...
> > I don't know whether I can use this as a counterexample or not.  My
> > recollection is that Silicon Graphics was using Ada internally VERY
early in
> > their life, and they were keeping this VERY quiet because it was helping
> > them, a lot, and they didn't really want anyone else to know.
>
> I'm skeptical that Ada was ever very widely used at SGI.

I don't have any data one way or the other to prove it.  I observe that SGI
had a complete Ada toolset for their machines long before any of the other
Unix workstation companies did.

> > Rational used Ada internally, and it helped them a lot.  They published
> > their numbers, but the reaction at GD/FW was that it just wasn't
possible to
> > get those kinds of numbers.
>
> At the time, Rational had an Ada compiler to sell, and not much else,
> so their numbers are suspect.

A few reports trickled out that other people using the R1000 were getting
similar numbers.

Also, it is very easy to reality-check the Rational numbers, to a rough
order of magnitude: Take the number of SLOC in the product, which they
reported, divide by the number of years the company had been in existence,
and you get SLOC/year.  From there, it is utterly trivial to divide by trial
values of SLOC/man/year to estimate the number of programmers involved, and
then compare them to the company headcount and money burn rate.

The short answer is that Rational's numbers stand up under reality checking.

> > McDonnell-Douglas had been using assembly language on F-15.  For the
> > IFFC/Firefly demonstration, they jumped into Ada with both feet,
> > enthusiastically, and reported very good numbers, for a digital flight
> > control application.
>
> I would certainly expect programming in Ada to be much more productive
> than programming in assembly language!

Their numbers were good even for high-order language development.

There is this, also.  At the time, the conventional wisdom was that Ada
would not EVER be suitable for "real" embedded work.  Using it for digital
flight controls *and* firecontrol, and doing a successful demonstration (gun
shootdown of a QF-102 drone from a 90 degree aspect: something that is
essentially impossible for a human pilot on his own), *AND* getting good
productivity numbers to boot, was a very solid counter to that belief.

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<80F453381B124BF8.ACEC58777658C8DC.89DCAA63449DBB7B@lp.airnews.net>...
> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0301030124.237c7a7e@posting.google.com...
> > Not all the antipathy to Ada is irrational.  Most of it comes
> > from sad experience.  Mine was trying to use Ada-83 to write Unix
> > applications with a Motif UI.  Regardless of any superiority in
> > reliability, the scarcity of libraries and trained
> > programmers makes Ada too expensive for most commercial software
> > projects.
> 
> In the very early 1980s, General Dynamics / Fort Worth Division started the
> F-16C/D program.  This was a MAJOR upgrade of the airplane, involving, among
> other things, all new computers and all new software.
> 
> Ada wasn't there yet, so they chose JOVIAL J73.
> 
> At that time, there existed precisely one J73 compiler, and it didn't target
> EITHER of the processors they were designing into the airplane (Zilog Z8002
> and MIL-STD-1750A).  They wound up having to let compiler development
> contracts to two (small) companies to develop toolsets.
> 
> At that time, trained J73 programmers just plain didn't exist.  GD/FW had to
> train every single programmer they hired for that project.
> 
> Every time I hear someone grumbling about the scarcity of trained Ada
> programmers, I think about F-16C/D and JOVIAL, and I wonder how GD/FW ever
> managed to get that airplane off the ground, if training is so hard.
> 
> I'm not even going to mention HAL/S, the Space Shuttle language, which to my
> (unclassified) knowledge was not used for anything else on the planet.
> Where does NASA (and the SEI Level 5 contractor) get trained HAL/S
> programmers?

I said "commercial software projects" -- i.e. projects undertaken in the
hope of making a profit, that have to be compatible with a large base
of existing software and systems, and that have to be delivered within
a few months of initiation.  In other words, about 99% of the software
work in the world.  Ada is a poor fit for these projects, and is therefore
unpopular.

The projects you mentioned are taxpayer-supported with software budgets 
in the billions and initial delivery some years after project start.  
NASA spends about $500 for every line of shuttle code changed.  
With that kind of budget and timeline training costs can be absorbed.
Most projects can't afford it.

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

kcline17@hotmail.com (Kevin Cline) wrote in message news:<ba162549.0301030124.237c7a7e@posting.google.com>...
> Not all the antipathy to Ada is irrational.  Most of it comes
> from sad experience.  Mine was trying to use Ada-83 to write Unix 
> applications with a Motif UI.  Regardless of any superiority in
> reliability, the scarcity of libraries and trained
> programmers makes Ada too expensive for most commercial software
> projects.


Odd. That's one of the few domains where Ada (even 83) is almost
ideal. I've done just that myself, and you can actually do Motif UI's
in Ada way quicker than you can in C (counting debugging), even if you
have *no* bindings to start with. UIL can do all the GUI work, and the
Ada "glue" code only needs a few UIL, Motif, and X routines bound (3
to load and paste the UI, plus one for any widget class you interact
with, if I remember correctly). The profusion of UIL GUI builders out
there pretty handily negates Ada's usual disadvantages with library
support.

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0301031434.51a0c880@posting.google.com>...
> kcline17@hotmail.com (Kevin Cline) wrote in message news:<ba162549.0301030124.237c7a7e@posting.google.com>...
> > Not all the antipathy to Ada is irrational.  Most of it comes
> > from sad experience.  Mine was trying to use Ada-83 to write Unix 
> > applications with a Motif UI.  Regardless of any superiority in
> > reliability, the scarcity of libraries and trained
> > programmers makes Ada too expensive for most commercial software
> > projects.
> 
> 
> Odd. That's one of the few domains where Ada (even 83) is almost
> ideal. 

With no access to subprogram types, attaching Ada-83 subprograms to
widget callbacks was a real puzzle for me.  At the time I was doing
the
work (1988) I had two buggy compilers, Verdix for Solaris and TeleSoft
for Silicon Graphics.  Both were expensive, validated, and neither was
anywhere
near the quality of the free GNU C compiler.  Within a week of
starting
to program in Ada I found legal code that one or the other compiler
rejected.  

With no compiler supporting both the target architectures, I was left
to
deal with different pragmas for calling C functions, 
different bindings to POSIX, different bindings to X windows,
and no bindings to Xt or Motif.  Neither had a useful mapping of
Ada tasks to POSIX threads, but instead simulated multitasking within
a single kernel thread.  This was useless for all practical purposes.

We were fortunate enough to have the TeleSoft GUI builder, which in
an indirect way allowed us to connect Ada subprograms to widget
callbacks.

After many years of C programming, it was nice to work in a language
where I was fairly sure that any code that compiled would probably
work.  But most
of the problems with C were solved by the introduction of C++.

After a while I was comfortable with Ada.  But the insular
viewpoint of the original Ada community meant that Ada just
wasn't helpful for the programs I needed to write.

Today, the features that Ada provides have little value
compared with the features that C++ provides and Ada lacks:
the STL, automatic template function instantiation, smooth
integration of user-defined and primitive datatypes, and
bindings to every API in existence.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Kevin Cline wrote:

> Today, the features that Ada provides have little value
> compared with the features that C++ provides and Ada lacks:
> the STL, automatic template function instantiation,

Generics in any form is an illness of programming languages.

> smooth integration of user-defined and primitive datatypes,

Why do you think C++ is better in that respect? C++ OO model is badly flawed 
as compared with Ada's one. In any case both Ada and C++ have primitive 
types separated from user-defined types by a fire wall. The difference is 
that Ada's design potentially allows to mend this, while in C++ it is 
beyond repair.

> and bindings to every API in existence.

That's not language fault. This can be addressed to any language except C. 
Even C++ suffers from that: you might need 'extern "C" {}' to call most of 
API functions. You are unable to pass a class as a parameter etc.

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

Re: Anybody in US using ADA ? One silly idea..

[Robert A Duff]

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

> Generics in any form is an illness of programming languages.

Why?

- Bob

Re: Anybody in US using ADA ? One silly idea..

[Hillel Y. Sims]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:av6hla$cggao$1@ID-77047.news.dfncis.de...
> Kevin Cline wrote:
>
> > Today, the features that Ada provides have little value
> > compared with the features that C++ provides and Ada lacks:
> > the STL, automatic template function instantiation,
>
> Generics in any form is an illness of programming languages.

As someone who uses C++ template functionality extensively, I find that a
very odd statement and completely inconsistent with my own experience. Can
you provide some rationale?

thanks,
hys

--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hillel Y. Sims wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:av6hla$cggao$1@ID-77047.news.dfncis.de...
>> Kevin Cline wrote:
>>
>> > Today, the features that Ada provides have little value
>> > compared with the features that C++ provides and Ada lacks:
>> > the STL, automatic template function instantiation,
>>
>> Generics in any form is an illness of programming languages.
> 
> As someone who uses C++ template functionality extensively, I find that a
> very odd statement and completely inconsistent with my own experience. Can
> you provide some rationale?

In short generics is a meta language and no more than dressed macros used to 
patch the source code. More elaborated:

1. Generics are static. You cannot have an object or dynamic-link library of 
generics.

1.a. This kills code reuse at run-time.

1.b. You cannot have a true polymorphism with generics. [A fake, "static" 
polymorphism was invented to hide the truth.]

1.c. You have geometric code size explosion if you consequently use 
generics.

2. You have no ADT with generics. All generic types are hard-wired. In C++ 
you have only one generic type: "class". In Ada there are few: "private", 
"range <>" etc. This is Stone Age. Theoretically one could leverage 
generics to full ADT, but what for? It is much better to have a better ADT 
in the core language and abadon generics.

3. Generics are inconsistent with type relationships. When you instantiate 
something, this something is absolutely unrelated to everything else. A 
generic container instantiated with a subtype will never become a subtype 
of same container instantiated with the base type.

4. Generics are inconsistent with DbC. In C++ you just instantiate and pray. 
In Ada it is better, but still you have reemergence of predefined 
operations and other contract violations. The reason is clear, while the 
core language operates with types and their relations, generics are sort 
of: let's substitute one string for another and see if the result go 
through the compiler. I think it was Kernigan and Ritchie who said that 
preprocessor does not know C. Substitute generics for preprocessor and 
language X for C.

5. Generics are unstructured and too powerful. They are comparable with 
gotos. Gotos arbitrarely change control flow. Generics arbitrarely produce 
new language objects. You can have a generic type, subroutine, package, 
everything. The consequences of an instantiation is almost impossible to 
predict. As with gotos, you should admit, that a program with generics is 
very difficult to understand and maintain. [For C++ replace difficult to 
impossible, because of automated instantiation]

6. Generics completely fall out of the language, because in fact they form a 
meta-langauge. A generic object does not exist for the core language. What 
could be done with a generic object? The answer is: nothing. One cannot 
pass a generic function as a parameter to a normal function. Even a generic 
parameter cannot be generic (:-)), only instances [= objects of the core 
language] are allowed. So even as a meta-language, generics represent an 
inconsistent one.

------------------------
A little of bad philosophy as a conclusion. (:-)) If we consider the 
evolution of programming languages, we could note maybe unconscious, but 
constant and very successfull attempts to solve the problem of 
parametrization in a more civilized way than just by brute force of 
preprocessing = generics.

A subroutine is parametrized by the values of the arguments [FORTRAN]

A subroutine is a value which can be a parameter [?]

A type is parametrized by the values of the discriminants [Ada 83]

A type set (=class-wide type) is parametrized by a type (=type tag) [OOPL 
with dispatching]

In the end of this process we will need generics as much as we need gotos 
now.

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

Re: Anybody in US using ADA ? One silly idea..

[James S. Rogers]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:av9egl$dd34q$2@ID-77047.news.dfncis.de...
>
> 1. Generics are static. You cannot have an object or dynamic-link library
of
> generics.
>
> 1.a. This kills code reuse at run-time.
>
> 1.b. You cannot have a true polymorphism with generics. [A fake, "static"
> polymorphism was invented to hide the truth.]
>
> 1.c. You have geometric code size explosion if you consequently use
> generics.
>
> 2. You have no ADT with generics. All generic types are hard-wired. In C++
> you have only one generic type: "class". In Ada there are few: "private",
> "range <>" etc. This is Stone Age. Theoretically one could leverage
> generics to full ADT, but what for? It is much better to have a better ADT
> in the core language and abadon generics.
>
> 3. Generics are inconsistent with type relationships. When you instantiate
> something, this something is absolutely unrelated to everything else. A
> generic container instantiated with a subtype will never become a subtype
> of same container instantiated with the base type.
>
> 4. Generics are inconsistent with DbC. In C++ you just instantiate and
pray.
> In Ada it is better, but still you have reemergence of predefined
> operations and other contract violations. The reason is clear, while the
> core language operates with types and their relations, generics are sort
> of: let's substitute one string for another and see if the result go
> through the compiler. I think it was Kernigan and Ritchie who said that
> preprocessor does not know C. Substitute generics for preprocessor and
> language X for C.
>
> 5. Generics are unstructured and too powerful. They are comparable with
> gotos. Gotos arbitrarely change control flow. Generics arbitrarely produce
> new language objects. You can have a generic type, subroutine, package,
> everything. The consequences of an instantiation is almost impossible to
> predict. As with gotos, you should admit, that a program with generics is
> very difficult to understand and maintain. [For C++ replace difficult to
> impossible, because of automated instantiation]
>
> 6. Generics completely fall out of the language, because in fact they form
a
> meta-langauge. A generic object does not exist for the core language. What
> could be done with a generic object? The answer is: nothing. One cannot
> pass a generic function as a parameter to a normal function. Even a
generic
> parameter cannot be generic (:-)), only instances [= objects of the core
> language] are allowed. So even as a meta-language, generics represent an
> inconsistent one.
>

Are you also against the use of abstract tagged types?

Jim Rogers

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

James S. Rogers wrote:

> Are you also against the use of abstract tagged types?

By no means. It would mean that I am against generic programming. I am 
against overusing generics in generic programming.

In my view tagged types are a real alternative to generics. We have T'Class 
which denotes a set of types as "digits <>" or "private" does. But they 
need a long way to evolve before they will supersede generics in things 
like STL.

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

Re: Anybody in US using ADA ? One silly idea..

[Hillel Y. Sims]

I can't really speak much for experience with generics in Ada, but since
your original point was "Generics in any form is an illness of programming
languages", let me try to address a few of your general issues w/r/t C++
templates at least..

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:av9egl$dd34q$2@ID-77047.news.dfncis.de...
> In short generics is a meta language and no more than dressed macros used
to
> patch the source code.

They are much more than dressed macros; there is also a great deal of
semantic context which is totally unavailable with macros.

>More elaborated:
>
> 1. Generics are static. You cannot have an object or dynamic-link library
of
> generics.

I have written and maintain a number of (large) dynamic-link libraries of
instantiations of C++ templates.

>
> 1.a. This kills code reuse at run-time.

This is therefore not necessarily true, based on the above.

>
> 1.b. You cannot have a true polymorphism with generics. [A fake, "static"
> polymorphism was invented to hide the truth.]

Depends on your definition of 'polymorphism'. I have done some interesting
things with compile-time polymorphism (inheriting a class from a template
base class of the derived type). Anyhow, I see compile-time static and
run-time dynamic polymorphism as complementary techniques which can provide
a greater amount of flexibility in combination than either alone.

>
> 1.c. You have geometric code size explosion if you consequently use
> generics.

I guess this depends on the instantiation model and a lot of other
variables. It is not inherently true with C++ templates.

>
> 4. Generics are inconsistent with DbC. In C++ you just instantiate and
pray.
> In Ada it is better, but still you have reemergence of predefined
> operations and other contract violations. The reason is clear, while the
> core language operates with types and their relations, generics are sort
> of: let's substitute one string for another and see if the result go
> through the compiler. I think it was Kernigan and Ritchie who said that
> preprocessor does not know C. Substitute generics for preprocessor and
> language X for C.

Sorry, I don't really follow this point at all.

>
> 5. Generics are unstructured and too powerful. They are comparable with
> gotos. Gotos arbitrarely change control flow. Generics arbitrarely produce
> new language objects. You can have a generic type, subroutine, package,
> everything. The consequences of an instantiation is almost impossible to
> predict. As with gotos, you should admit, that a program with generics is
> very difficult to understand and maintain. [For C++ replace difficult to
> impossible, because of automated instantiation]

Again, I can't really speak of Ada generics, but I maintain several sizeable
C++ libraries which make extensive use of templates. The amount of
functionality provided is far greater with much fewer lines of code than the
equivalent non-templated version would be. This complexity issue simply does
not seem to be inherent in the manner in which you imply, at least with C++
templates.

> 6. Generics completely fall out of the language, because in fact they form
a
> meta-langauge. A generic object does not exist for the core language. What
> could be done with a generic object? The answer is: nothing. One cannot
> pass a generic function as a parameter to a normal function. Even a
generic
> parameter cannot be generic (:-)), only instances [= objects of the core
> language] are allowed. So even as a meta-language, generics represent an
> inconsistent one.
>

The biggest research/growth area in C++ these days seems to be templates and
meta-programming. It is true there are some inconsistencies in the
meta-language, but they don't prevent a lot of interesting programming from
being done. If you have never seen the Boost Meta-Programming Library
(http://www.boost.org/libs/mpl/doc/), you might want to check it out
briefly; it demonstrates that quite a great deal can be done at compile-time
with uninstantiated generic meta-objects.

Anyhow, I will acknowledge that there are issues which need to be
addressed/understood for successful use of generics/templates, and some of
your points may be more oriented toward Ada than any other language, but I
remain fully unconvinced that true generics (not glorified macros) are
inherently a bad idea in any particular programming language.

hys

--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hillel Y. Sims wrote:

> I can't really speak much for experience with generics in Ada, but since
> your original point was "Generics in any form is an illness of programming
> languages", let me try to address a few of your general issues w/r/t C++
> templates at least..
> 
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:av9egl$dd34q$2@ID-77047.news.dfncis.de...
>> In short generics is a meta language and no more than dressed macros used
> to
>> patch the source code.
> 
> They are much more than dressed macros; there is also a great deal of
> semantic context which is totally unavailable with macros.
> 
>>More elaborated:
>>
>> 1. Generics are static. You cannot have an object or dynamic-link library
> of
>> generics.
> 
> I have written and maintain a number of (large) dynamic-link libraries of
> instantiations of C++ templates.

Note that "instantiations of" is not what follows "of". A library of 
instantiations is not a library of templates.

>> 1.a. This kills code reuse at run-time.
> 
> This is therefore not necessarily true, based on the above.

No, you cannot reuse code across instantiations. Each of them is a macro 
expansion which has a separate body. Theoretically one could share generic 
bodies [at least in Ada it is sometimes possible], but practically it is 
not the case.

>> 1.b. You cannot have a true polymorphism with generics. [A fake, "static"
>> polymorphism was invented to hide the truth.]
> 
> Depends on your definition of 'polymorphism'. I have done some interesting
> things with compile-time polymorphism (inheriting a class from a template
> base class of the derived type). Anyhow, I see compile-time static and
> run-time dynamic polymorphism as complementary techniques which can
> provide a greater amount of flexibility in combination than either alone.

The time of binding (dispatch in a polymorphic call) is an *implementation* 
detail. If the type information is known at compile-time, then, at least in 
Ada, dispatch happens at compile time.

>> 1.c. You have geometric code size explosion if you consequently use
>> generics.
> 
> I guess this depends on the instantiation model and a lot of other
> variables. It is not inherently true with C++ templates.

If you bind at compile time then this is just a consequence.

>> 4. Generics are inconsistent with DbC. In C++ you just instantiate and
> pray.
>> In Ada it is better, but still you have reemergence of predefined
>> operations and other contract violations. The reason is clear, while the
>> core language operates with types and their relations, generics are sort
>> of: let's substitute one string for another and see if the result go
>> through the compiler. I think it was Kernigan and Ritchie who said that
>> preprocessor does not know C. Substitute generics for preprocessor and
>> language X for C.
> 
> Sorry, I don't really follow this point at all.

template <class X> class Y
{
public :
   X max (X A, X B) { if (A > B) return A; else return B; }
};

What ensures that X has ">"? There is no word about a contract, because 
"class X" means anything. In FORTRAN-IV you also can pass an INTEGER*4 
instead of REAL*4. I remember some people claiming that this is a very 
useful feature.

>> 5. Generics are unstructured and too powerful. They are comparable with
>> gotos. Gotos arbitrarely change control flow. Generics arbitrarely
>> produce new language objects. You can have a generic type, subroutine,
>> package, everything. The consequences of an instantiation is almost
>> impossible to predict. As with gotos, you should admit, that a program
>> with generics is very difficult to understand and maintain. [For C++
>> replace difficult to impossible, because of automated instantiation]
> 
> Again, I can't really speak of Ada generics, but I maintain several
> sizeable C++ libraries which make extensive use of templates. The amount
> of functionality provided is far greater with much fewer lines of code
> than the equivalent non-templated version would be. This complexity issue
> simply does not seem to be inherent in the manner in which you imply, at
> least with C++ templates.

Code density and simplicity of language constructs do not imply 
maintainability. What could be simplier than "JMP $1034"?

>> 6. Generics completely fall out of the language, because in fact they
>> form
> a
>> meta-langauge. A generic object does not exist for the core language.
>> What could be done with a generic object? The answer is: nothing. One
>> cannot pass a generic function as a parameter to a normal function. Even
>> a
> generic
>> parameter cannot be generic (:-)), only instances [= objects of the core
>> language] are allowed. So even as a meta-language, generics represent an
>> inconsistent one.
> 
> The biggest research/growth area in C++ these days seems to be templates
> and meta-programming. It is true there are some inconsistencies in the
> meta-language, but they don't prevent a lot of interesting programming
> from being done. If you have never seen the Boost Meta-Programming Library
> (http://www.boost.org/libs/mpl/doc/), you might want to check it out
> briefly; it demonstrates that quite a great deal can be done at
> compile-time with uninstantiated generic meta-objects.
>
> Anyhow, I will acknowledge that there are issues which need to be
> addressed/understood for successful use of generics/templates, and some of
> your points may be more oriented toward Ada than any other language, but I
> remain fully unconvinced that true generics (not glorified macros) are
> inherently a bad idea in any particular programming language.

A need in a meta language indicates that the core language is incomplete. 
Then the question is only whether this incompleteness is inherent or not. 
As long as the former is not proved I will claim that we do not need a meta 
language.

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

Re: Anybody in US using ADA ? One silly idea..

[Randy Brukardt]

Dmitry A. Kazakov wrote in message ...
>>> 1.a. This kills code reuse at run-time.
>>
>> This is therefore not necessarily true, based on the above.
>
>No, you cannot reuse code across instantiations. Each of them is a
macro
>expansion which has a separate body. Theoretically one could share
generic
>bodies [at least in Ada it is sometimes possible], but practically it
is
>not the case.

Bull.

You just need to use a different compiler. Ada /= GNAT!

Janus/Ada 95 shares all generic bodies. That's probably too aggressive,
but it's too expensive to change.

Dan Eilers will tell you that their compiler (ICC) shares generic bodies
(I believe unless pragma Inline is used on the generic).

Many Ada 83 compilers shared generic bodies, include DEC and Rational.
It's harder in Ada 95, but if there was any significant demand,
compilers would have it.

                       Randy Brukardt.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 6 Jan 2003 13:07:44 -0600, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>Dmitry A. Kazakov wrote in message ...
>>>> 1.a. This kills code reuse at run-time.
>>>
>>> This is therefore not necessarily true, based on the above.
>>
>>No, you cannot reuse code across instantiations. Each of them is a
>macro
>>expansion which has a separate body. Theoretically one could share
>generic
>>bodies [at least in Ada it is sometimes possible], but practically it
>is
>>not the case.
>
>Bull.
>
>You just need to use a different compiler. Ada /= GNAT!

GNAT becomes sort of MS VC++ for Ada. (:-))

>Janus/Ada 95 shares all generic bodies. That's probably too aggressive,
>but it's too expensive to change.
>
>Dan Eilers will tell you that their compiler (ICC) shares generic bodies
>(I believe unless pragma Inline is used on the generic).
>
>Many Ada 83 compilers shared generic bodies, include DEC and Rational.
>It's harder in Ada 95, but if there was any significant demand,
>compilers would have it.

Yes, I know.

Shared bodies are working against the C++'s myth about unbeatable
efficience of templates. Then if we can share bodies, then why do we
need to instantiate something at compile-time? Should we drop this
limitation completely, then instead of a "generic type", we would have
our well-known friend discriminated type. My point is that we could
get rid of generics in most cases and Ada is much more fit for that
than C++.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Shared bodies are working against the C++'s myth about unbeatable
> efficience of templates.

Do you have any evidence that this is a myth, rather than a fact?

That is, in the C++ model of generics, the compiler has all the type
information available at the point where it is compiling the code,
so it's hard to see how any other model can be *more* efficient. So
the best you can hope for is to be as efficient. I think of the
canonical case as being std::sort, which can inline comparison between
objects, so sorting an array of integers involves just doing an inline
machine integer compare.

Not only that, but the C++ model allows for specialization, so that the
body of code in question does not all have to come from the same block of
generic code - there can be completely different bodies for different
types. This makes generic sharing even less likely there.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Shared bodies are working against the C++'s myth about unbeatable
>> efficience of templates.
> 
> Do you have any evidence that this is a myth, rather than a fact?

No study I know of. However, it is easy to imagine a case when a non-inlined 
subroutine could be more efficient [in terms of speed] than an inlined one. 
I do not care about the realism of the following example, but let we have a 
sort of applet which runs some simple algorithm for many different types. 
Each time you load it, only one branch for one selected type is executed. 
If the algorithm is an inlined instance, the time for loading, 
initialization of the paged memory, symbol relocation etc, could be longer 
than the time of all dereferences and dispatch.

> That is, in the C++ model of generics, the compiler has all the type
> information available at the point where it is compiling the code,
> so it's hard to see how any other model can be *more* efficient. So
> the best you can hope for is to be as efficient.

Yes. Only "hope" is IMO a wrong word. I think it is indeed possible to make 
tagged types as efficient as fully inlined macro expansions, provided that 
the corresonding class-wide routines are also inlined.

> I think of the
> canonical case as being std::sort, which can inline comparison between
> objects, so sorting an array of integers involves just doing an inline
> machine integer compare.

> Not only that, but the C++ model allows for specialization, so that the
> body of code in question does not all have to come from the same block of
> generic code - there can be completely different bodies for different
> types. This makes generic sharing even less likely there.

My point was:

- either we implement generics as macro expansions and then have 
disadvantages XYZ;

- or we share bodies, loosing some power of generics, so that a question 
arise, why generics and not tagged types?

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

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

There is at least one way that inlining of code
or not sharing bodies can decrease efficiency:

If we are alternating calls between two sections
of identical machine code, we could be doing
unnecessary paging.

Which is sort of what you said, but I thought
I'd emphasize it a little.

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<avhak5$fbnqe$1@ID-77047.news.dfncis.de>...
> Hyman Rosen wrote:
> No study I know of. However, it is easy to imagine a case when a non-inlined 
> subroutine could be more efficient [in terms of speed] than an inlined one. 
> I do not care about the realism of the following example, but let we have a 
> sort of applet which runs some simple algorithm for many different types. 
> Each time you load it, only one branch for one selected type is executed. 
> If the algorithm is an inlined instance, the time for loading, 
> initialization of the paged memory, symbol relocation etc, could be longer 
> than the time of all dereferences and dispatch.

Actually, an effect I would be even more worried about is the effect
on CPU instruction caches. A non-inlined program is going to be
smaller than an inlined program, perhaps significantly smaller if a
lot of inlining is performed. If that causes an instruction cache miss
where there would not have been one, you could find your 8 CPU-cyle
"optimization" (less if you have a good Branch Prediction Unit, like
most modern 32-bit processors do) actually *costing* you hundreds of
CPU-cycles every time its executed.



> 
> > That is, in the C++ model of generics, the compiler has all the type
> > information available at the point where it is compiling the code,
> > so it's hard to see how any other model can be *more* efficient. So
> > the best you can hope for is to be as efficient.
> 
> Yes. Only "hope" is IMO a wrong word. I think it is indeed possible to make 
> tagged types as efficient as fully inlined macro expansions, provided that 
> the corresonding class-wide routines are also inlined.
> 
> > I think of the
> > canonical case as being std::sort, which can inline comparison between
> > objects, so sorting an array of integers involves just doing an inline
> > machine integer compare.
>  
> > Not only that, but the C++ model allows for specialization, so that the
> > body of code in question does not all have to come from the same block of
> > generic code - there can be completely different bodies for different
> > types. This makes generic sharing even less likely there.
> 
> My point was:
> 
> - either we implement generics as macro expansions and then have 
> disadvantages XYZ;
> 
> - or we share bodies, loosing some power of generics, so that a question 
> arise, why generics and not tagged types?

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Yes. Only "hope" is IMO a wrong word. I think it is indeed possible to make 
> tagged types as efficient as fully inlined macro expansions, provided that 
> the corresonding class-wide routines are also inlined.

I think that without generics, even using a clever compiler which does
the equivalent of generic expansion when routines are called with
known types, there's still lots of opportunity to lose type information.
For example, lack of generics means that your container classes will
not know what they're holding, and you're going to run into Java-like
issues there.

Frankly, I just don't see the point. What is it about a table of
pointers to functions that's so almighty appealing that everything
needs to be expressed in terms of it?

RE: Anybody in US using ADA ? One silly idea..

[Robert C. Leif]

I disagree! A very simple construct is a generic set of types and objects
that are also part of a private tagged record. This structure can be
extended and manipulated. For instance, when dealing with hardware, Intel
input-output registers and memory locations can be 8, 16, and 32 bits. A
generic is a simple way to model this. In fact if it were possible, I would
greatly prefer generic constructs to pointers. I must note that generics can
be instantiated at run-time and, I believe, still be located on the heap. No
need for garbage collection. Oberon.NET, which is very new, has generics.
Bob Leif

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]
On Behalf Of Dmitry A. Kazakov
Sent: Sunday, January 05, 2003 6:13 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..

Hillel Y. Sims wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:av6hla$cggao$1@ID-77047.news.dfncis.de...
>> Kevin Cline wrote:
>>
>> > Today, the features that Ada provides have little value
>> > compared with the features that C++ provides and Ada lacks:
>> > the STL, automatic template function instantiation,
>>
>> Generics in any form is an illness of programming languages.
> 
> As someone who uses C++ template functionality extensively, I find that a
> very odd statement and completely inconsistent with my own experience. Can
> you provide some rationale?

In short generics is a meta language and no more than dressed macros used to

patch the source code. More elaborated:

1. Generics are static. You cannot have an object or dynamic-link library of

generics.

1.a. This kills code reuse at run-time.

1.b. You cannot have a true polymorphism with generics. [A fake, "static" 
polymorphism was invented to hide the truth.]

1.c. You have geometric code size explosion if you consequently use 
generics.

2. You have no ADT with generics. All generic types are hard-wired. In C++ 
you have only one generic type: "class". In Ada there are few: "private", 
"range <>" etc. This is Stone Age. Theoretically one could leverage 
generics to full ADT, but what for? It is much better to have a better ADT 
in the core language and abadon generics.

3. Generics are inconsistent with type relationships. When you instantiate 
something, this something is absolutely unrelated to everything else. A 
generic container instantiated with a subtype will never become a subtype 
of same container instantiated with the base type.

4. Generics are inconsistent with DbC. In C++ you just instantiate and pray.

In Ada it is better, but still you have reemergence of predefined 
operations and other contract violations. The reason is clear, while the 
core language operates with types and their relations, generics are sort 
of: let's substitute one string for another and see if the result go 
through the compiler. I think it was Kernigan and Ritchie who said that 
preprocessor does not know C. Substitute generics for preprocessor and 
language X for C.

5. Generics are unstructured and too powerful. They are comparable with 
gotos. Gotos arbitrarely change control flow. Generics arbitrarely produce 
new language objects. You can have a generic type, subroutine, package, 
everything. The consequences of an instantiation is almost impossible to 
predict. As with gotos, you should admit, that a program with generics is 
very difficult to understand and maintain. [For C++ replace difficult to 
impossible, because of automated instantiation]

6. Generics completely fall out of the language, because in fact they form a

meta-langauge. A generic object does not exist for the core language. What 
could be done with a generic object? The answer is: nothing. One cannot 
pass a generic function as a parameter to a normal function. Even a generic 
parameter cannot be generic (:-)), only instances [= objects of the core 
language] are allowed. So even as a meta-language, generics represent an 
inconsistent one.

------------------------
A little of bad philosophy as a conclusion. (:-)) If we consider the 
evolution of programming languages, we could note maybe unconscious, but 
constant and very successfull attempts to solve the problem of 
parametrization in a more civilized way than just by brute force of 
preprocessing = generics.

A subroutine is parametrized by the values of the arguments [FORTRAN]

A subroutine is a value which can be a parameter [?]

A type is parametrized by the values of the discriminants [Ada 83]

A type set (=class-wide type) is parametrized by a type (=type tag) [OOPL 
with dispatching]

In the end of this process we will need generics as much as we need gotos 
now.

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

RE: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Robert C. Leif wrote:

> I disagree! A very simple construct is a generic set of types and objects
> that are also part of a private tagged record. This structure can be
> extended and manipulated.

Why to put something into anything else? Why not to have the tagged record 
doing everything what you want from the start?

> For instance, when dealing with hardware, Intel
> input-output registers and memory locations can be 8, 16, and 32 bits. A
> generic is a simple way to model this.

An abstract integer type with three non-abstract descendants is even more 
simple model. My point is that almost everything you do with generics could 
be done with ADT.

> In fact if it were possible, I
> would greatly prefer generic constructs to pointers. I must note that
> generics can be instantiated at run-time and, I believe, still be located
> on the heap. No need for garbage collection. Oberon.NET, which is very
> new, has generics. Bob Leif

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

Re: Anybody in US using ADA ? One silly idea..

[Pascal Obry]

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

> An abstract integer type with three non-abstract descendants is even more 
> simple model. My point is that almost everything you do with generics could 
> be done with ADT.

I'm not sure what you have in mind, but ADT and generics are orthogonal
notion. In fact a lot of generic components are designed as ADT. The fact 
that 'A' stand for abstract has nothing to do the "abstract" Ada keywords or
OO feature.

Pascal.

-- 

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

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On 06 Jan 2003 20:13:16 +0100, Pascal Obry <p.obry@wanadoo.fr> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> An abstract integer type with three non-abstract descendants is even more 
>> simple model. My point is that almost everything you do with generics could 
>> be done with ADT.
>
>I'm not sure what you have in mind, but ADT and generics are orthogonal
>notion. In fact a lot of generic components are designed as ADT. The fact 
>that 'A' stand for abstract has nothing to do the "abstract" Ada keywords or
>OO feature.

I called it abstract in Ada sense, i.e. a type having no instances.
Abstract integer type is thing with integer arithmetic operations
defined on it. Whether it is a 64-bit machine integer or an array of
characters is no matter.

As for orthogonality, surely, generics are orthogonal [to everything].

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Why to put something into anything else? Why not to have the tagged record 
> doing everything what you want from the start?

I'm not sure what specific case we're talking about here,
but in general, one uses generics (or templates) when
complete type information is available at compile time,
and tagged types when type information is available only
at run time.

Under typical compiler implementations, very large gains in
efficiency become possible using generics, mainly because of
inlining opportunities.

You may not like this, but the Ada designers clearly saw generics
as a benefit, and the C++ metaprogramming developers have sealed
its fate - generics are here to stay, and will probably become
more enhanced.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 06 Jan 2003 22:00:22 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Why to put something into anything else? Why not to have the tagged record 
>> doing everything what you want from the start?
>
>I'm not sure what specific case we're talking about here,
>but in general, one uses generics (or templates) when
>complete type information is available at compile time,
>and tagged types when type information is available only
>at run time.

That's silly. Tagged types are good in static case. One may wish
generics only if they offers something what tagged types cannot.

>Under typical compiler implementations, very large gains in
>efficiency become possible using generics, mainly because of
>inlining opportunities.

This is also possible with tagged types. You are free to make
operations inline. The compiler may remove the type tag if it is
statically known. Under these conditions a static dispatch would cost
nothing.

>You may not like this, but the Ada designers clearly saw generics
>as a benefit,

In 80s there were no alternative to generics.

>and the C++ metaprogramming developers have sealed
>its fate - generics are here to stay, and will probably become
>more enhanced.

I have no doubts about it. But the fate of C++ was decided much more
earlier, when {} were chosen to indicate a block of statements. You
know after that, everything else is just a consequence! (:-))

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> This is also possible with tagged types. You are free to make
> operations inline. The compiler may remove the type tag if it is
> statically known. Under these conditions a static dispatch would cost
> nothing.

The point here is using your newly created types with libraries of
existing code which are to operate on those types. If those libraries
are generic, then it may be possible to get significant inlining
benefits. If those libraries operate on tagged types, then it won't
matter that *you* know the static type in your code, because the
library won't. It's the difference, in C++ terms, between qsort and
std::sort. The former takes a pointer to function which it must call
for each comparison, while the latter can inline the comparison.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> This is also possible with tagged types. You are free to make
>> operations inline. The compiler may remove the type tag if it is
>> statically known. Under these conditions a static dispatch would cost
>> nothing.
> 
> The point here is using your newly created types with libraries of
> existing code which are to operate on those types. If those libraries
> are generic, then it may be possible to get significant inlining
> benefits. If those libraries operate on tagged types, then it won't
> matter that *you* know the static type in your code, because the
> library won't. It's the difference, in C++ terms, between qsort and
> std::sort. The former takes a pointer to function which it must call
> for each comparison, while the latter can inline the comparison.

But this is not generics vs. tagged, it is inlined vs. not. It is clear that 
an inlined subroutine cannot be put into a library. The difference is only 
that tagged types leave me a choice, while generics don't.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But this is not generics vs. tagged, it is inlined vs. not. It is clear that 
> an inlined subroutine cannot be put into a library. The difference is only 
> that tagged types leave me a choice, while generics don't.

The inlining in question here is bits of your new object's code
getting inlined into the library code, rather than the usual
direction of inlining library code into your code. While you
are not wrong in the abstract, the facts of implementations are
that libraries which receive tagged types on which to operate
are shipped as compiled binaries, and the opportunities to
inline are simply not there.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> But this is not generics vs. tagged, it is inlined vs. not. It is clear
>> that an inlined subroutine cannot be put into a library. The difference
>> is only that tagged types leave me a choice, while generics don't.
> 
> The inlining in question here is bits of your new object's code
> getting inlined into the library code, rather than the usual
> direction of inlining library code into your code. While you
> are not wrong in the abstract, the facts of implementations are
> that libraries which receive tagged types on which to operate
> are shipped as compiled binaries, and the opportunities to
> inline are simply not there.

I agree. As I said, it is a long way to go to get rid of generics.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> I agree. As I said, it is a long way to go to get rid of generics.

And as I said, I have no idea why you would want to.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> I agree. As I said, it is a long way to go to get rid of generics.
> 
> And as I said, I have no idea why you would want to.

I think I explained why. But to avoid that discussion again, just take the 
unit solution for C++ you mentioned and try to implement a calculator for 
dimensioned values using it.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> I think I explained why. But to avoid that discussion again, just take the 
> unit solution for C++ you mentioned and try to implement a calculator for 
> dimensioned values using it.

No, I don't want to do that. If I did want to do that,
my solution would be inappropriate, but so what? Part
of designing a program is deciding what is fixed at
compile-time and what is decided at run-time. Ada has
ranged types where the ranges are fixed at compile-time,
and records whose field names are fixed at compile-time,
and procedures whose parameters are fixed at compile-time.
Similarly, it has generics whose parameters are fixed at
compile-time. When I know what I need at compile-time,
why should I be required to funnel it through a mechanism
which is designed for run-time variation?

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 15/1/03 17:23, in article 1042651417.215661@master.nyc.kbcfp.com, "Hyman
Rosen" <hyrosen@mail.com> wrote:

> Dmitry A. Kazakov wrote:
>> I think I explained why. But to avoid that discussion again, just take the
>> unit solution for C++ you mentioned and try to implement a calculator for
>> dimensioned values using it.
> 
> No, I don't want to do that. If I did want to do that,
> my solution would be inappropriate, but so what? Part
> of designing a program is deciding what is fixed at
> compile-time and what is decided at run-time. Ada has
> ranged types where the ranges are fixed at compile-time [...]

I've noticed you say something like this before, Hyman, and I wonder if I'm
mistaking your meaning. Ada ranged types are NOT fixed at compile-time, they
may be fully dynamic.

E.g. You can say:

    procedure try is

        function read return integer is
            n : integer;
        begin
            get(n);
            return n;
        end read;
        
        SUBTYPE S IS INTEGER RANGE READ .. READ;

    begin
        put_line(integer'image(s'first) & " .. " & integer'image(s'last));
    end try;

$ ./try
123
456
 123 ..  456


(although you probably shouldn't)
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Bill Findlay wrote:
> I've noticed you say something like this before, Hyman, and I wonder if I'm
> mistaking your meaning. Ada ranged types are NOT fixed at compile-time, they
> may be fully dynamic.

Oh, that's interesting, I didn't know that.
Can I then have arrays whose index type is
this dynamic subtype? Can I have records
which have such arrays as components?

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 15/1/03 19:02, in article 1042657338.377677@master.nyc.kbcfp.com, "Hyman
Rosen" <hyrosen@mail.com> wrote:

> Bill Findlay wrote:
>> I've noticed you say something like this before, Hyman, and I wonder if I'm
>> mistaking your meaning. Ada ranged types are NOT fixed at compile-time, they
>> may be fully dynamic.
> 
> Oh, that's interesting, I didn't know that.
> Can I then have arrays whose index type is
> this dynamic subtype? Can I have records
> which have such arrays as components?
> 

Yes!
In the record case, an array field bound can even be the value of another
(discriminant) field of the same record.
8-)

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

Re: Anybody in US using ADA ? One silly idea..

[chris.danx]

Bill Findlay wrote:
> On 15/1/03 19:02, in article 1042657338.377677@master.nyc.kbcfp.com, "Hyman
> Rosen" <hyrosen@mail.com> wrote:

>>Oh, that's interesting, I didn't know that.
>>Can I then have arrays whose index type is
>>this dynamic subtype? Can I have records
>>which have such arrays as components?

> Yes!
> In the record case, an array field bound can even be the value of another
> (discriminant) field of the same record.
> 8-)

Pardon my stupidity but how do you do this?  If this is what it sounds 
like, it might be an ideal solution to a problem I've encountered.



-- 
for personal replies change spamoff to chris

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 15/1/03 22:51, in article
AAlV9.4495$K63.158061@newsfep1-gui.server.ntli.net, "chris.danx"
<spamoff.danx@ntlworld.com> wrote:

> Bill Findlay wrote:
>> On 15/1/03 19:02, in article 1042657338.377677@master.nyc.kbcfp.com, "Hyman
>> Rosen" <hyrosen@mail.com> wrote:
> 
>>> Oh, that's interesting, I didn't know that.
>>> Can I then have arrays whose index type is
>>> this dynamic subtype? Can I have records
>>> which have such arrays as components?
> 
>> Yes!
>> In the record case, an array field bound can even be the value of another
>> (discriminant) field of the same record.
>> 8-)
> 
> Pardon my stupidity but how do you do this?  If this is what it sounds
> like, it might be an ideal solution to a problem I've encountered.

I refer my learned friend to Cohen,
"Ada as a second language", pp 379 et.seq.

Here is the gist of the first example. (N.B. Untested code!):

   type Int_Array_Type is array(Positive range <>) of Integer;
...
   type Int_Stack_Type (Max : Positive) is
      record
         Top  : Natural := 0;
         Data : Int_Array_Type (1..Max);
         -- N.B. Only "Max" is allowed, even "Max+1" is illegal here
      end record;
...
   N : Positive := Read; -- N.B. N's value is read in
...
   subtype Stack_Of_Ints is Int_Stack_Type (N*(N+1)/2);
...
   Illegal_Stack : Int_Stack_Type;  -- ILLEGAL, Max has no value
   Legal_Stack_1 : Int_Stack_Type (N*(N+1)/2);
   Legal_Stack_2 : Stack_Of_Ints;

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

Re: Anybody in US using ADA ? One silly idea..

[chris.danx]

Bill Findlay wrote:

> 
> I refer my learned friend to Cohen,
> "Ada as a second language", pp 379 et.seq.

It's in the bible?  Worse still, the minute I saw your code I realised I 
already knew how to do it and had used it before in places.  I've been 
away from Ada too long, it's all evaporating! :(


Chris
-- 
for personal replies change spamoff to chris

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 15/1/03 23:57, in article
QymV9.4805$K63.171246@newsfep1-gui.server.ntli.net, "chris.danx"
<spamoff.danx@ntlworld.com> wrote:

> Bill Findlay wrote:
> 
>> 
>> I refer my learned friend to Cohen,
>> "Ada as a second language", pp 379 et.seq.
> 
> It's in the bible?  Worse still, the minute I saw your code I realised I
> already knew how to do it and had used it before in places.  I've been
> away from Ada too long, it's all evaporating! :(

It's the curly-bracket languages you've had foisted on you in CS3!
They rot the brain!
8-)

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

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Bill Findlay wrote:

> It's the curly-bracket languages you've had foisted on you in CS3!
> They rot the brain!

Well, I've mentioned this before as a cautionary issue, but reports are
coming in of an impending world-wide shortage of curly braces.  Soon,
languages that depend on curly braces will run out of this essential
resource, and other languages will have to fill in the gap.  :-)

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Richard Riehle wrote:
> Well, I've mentioned this before as a cautionary issue, but reports are
> coming in of an impending world-wide shortage of curly braces.  Soon,
> languages that depend on curly braces will run out of this essential
> resource, and other languages will have to fill in the gap.  :-)

Ada had better watch out as well. Due to the popularity of
template metaprogramming in C++, angle brackets will soon
be in short supply, and Ada programmers will no longer be
able to use "is <>" :-)

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Hyman Rosen wrote:

> Richard Riehle wrote:
> > Well, I've mentioned this before as a cautionary issue, but reports are
> > coming in of an impending world-wide shortage of curly braces.  Soon,
> > languages that depend on curly braces will run out of this essential
> > resource, and other languages will have to fill in the gap.  :-)
>
> Ada had better watch out as well. Due to the popularity of
> template metaprogramming in C++, angle brackets will soon
> be in short supply, and Ada programmers will no longer be
> able to use "is <>" :-)

Time for us all to rehabilitate our Smalltalk skills.  :-)

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1042737099.670536@master.nyc.kbcfp.com...
> Richard Riehle wrote:
> > Well, I've mentioned this before as a cautionary issue, but reports are
> > coming in of an impending world-wide shortage of curly braces.  Soon,
> > languages that depend on curly braces will run out of this essential
> > resource, and other languages will have to fill in the gap.  :-)
>
> Ada had better watch out as well. Due to the popularity of
> template metaprogramming in C++, angle brackets will soon
> be in short supply, and Ada programmers will no longer be
> able to use "is <>" :-)

Didn't Lisp suffer from a parentheses shortage? I always thought that one
could write Lisp faster with one additional input device: left parenthese
and right parenthese foot pedals.

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

> Didn't Lisp suffer from a parentheses shortage? I always thought that one
> could write Lisp faster with one additional input device: left parenthese
> and right parenthese foot pedals.

Ooh, Repetitive Stress Injuries in the calf muscles!

Re: Anybody in US using ADA ? One silly idea..

[Anders Wirzenius]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message news:iPCV9.2441$c6.2445@bos-service2.ext.raytheon.com...
> 
> > Didn't Lisp suffer from a parentheses shortage? I always thought that one
> > could write Lisp faster with one additional input device: left parenthese
> > and right parenthese foot pedals.
> 
> Ooh, Repetitive Stress Injuries in the calf muscles!
> 

A pianist background and especially organist background could be an advantage.

Anders

Re: Anybody in US using ADA ? One silly idea..

[Warren W. Gay VE3WWG]

Dennis Lee Bieber wrote:
> Wes Groleau fed this fish to the penguins on Thursday 16 January 2003 
> 10:26 am:
> 
>>>Didn't Lisp suffer from a parentheses shortage? I always thought that
>>>one could write Lisp faster with one additional input device: left
>>>parenthese and right parenthese foot pedals.
>>
>>Ooh, Repetitive Stress Injuries in the calf muscles!
> 
>         Now there is an idea -- I never use the M$ "windows" keys; maybe they 
> can be rebound for such punctuation.

Hook up a 2nd serial mouse, but put it on the floor
as your "foot pedal" ;-)

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

Re: Anybody in US using ADA ? One silly idea..

[Warren W. Gay VE3WWG]

Frank J. Lhota wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1042737099.670536@master.nyc.kbcfp.com...
> 
>>Richard Riehle wrote:
>>
>>>Well, I've mentioned this before as a cautionary issue, but reports are
>>>coming in of an impending world-wide shortage of curly braces.  Soon,
>>>languages that depend on curly braces will run out of this essential
>>>resource, and other languages will have to fill in the gap.  :-)
>>
>>Ada had better watch out as well. Due to the popularity of
>>template metaprogramming in C++, angle brackets will soon
>>be in short supply, and Ada programmers will no longer be
>>able to use "is <>" :-)
> 
> Didn't Lisp suffer from a parentheses shortage? I always thought that one
> could write Lisp faster with one additional input device: left parenthese
> and right parenthese foot pedals.

I like the "foot pedals" idea, LOL.

It should also be pointed out that C did not want to use
'(' and ')' more than necessary, since they like short
function and variable names, and abbreviated operators etc.

Therefore subscripting is done with '[' and ']' rather
than parenthesis, because it does not require a shift key.

But the curlies are easily had since it only requires
a shift key added to the fingers already poised
for action on the square bracket keys that they
already use for subscripting ;-)

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

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Bill Findlay wrote:

> I've noticed you say something like this before, Hyman, and I wonder if I'm
> mistaking your meaning. Ada ranged types are NOT fixed at compile-time, they
> may be fully dynamic.

Bill, Great example.  I have modified it slightly to emphasize the point.  Hope
you don't mind.  Here is the altered version.

-- modified from example submitted to cla by Bill Findlay
with Ada.Integer_Text_IO;
with Ada.Text_IO;
use  Ada;
procedure try is

    function read return integer is
        n : integer;
    begin
       Integer_Text_IO.get(n);
       return n;
     end read;

begin -- Try
    loop
         Dynamic_Array:
         declare
              SUBTYPE S IS INTEGER RANGE READ .. READ;
             A : array(S) of Integer := (others => 0);
          begin -- Dynamic_Array
             exit when S'Last = S'First;
             for I in A'Range
             loop
               Integer_Text_IO.Get(A(I));
             end loop;
            Text_IO.put_line(integer'image(s'first)
                        & " .. " & integer'image(s'last));
         end Dynamic_Array;
    end loop;
end try;

Re: Anybody in US using ADA ? One silly idea..

[chris.danx]

Richard Riehle wrote:

> -- modified from example submitted to cla by Bill Findlay
> with Ada.Integer_Text_IO;
> with Ada.Text_IO;
> use  Ada;
> procedure try is
> 
>     function read return integer is
>         n : integer;
>     begin
>        Integer_Text_IO.get(n);
>        return n;
>      end read;
> 
> begin -- Try
>     loop
>          Dynamic_Array:
>          declare
>               SUBTYPE S IS INTEGER RANGE READ .. READ;
>              A : array(S) of Integer := (others => 0);
>           begin -- Dynamic_Array
>              exit when S'Last = S'First;
>              for I in A'Range
>              loop
>                Integer_Text_IO.Get(A(I));
>              end loop;
>             Text_IO.put_line(integer'image(s'first)
>                         & " .. " & integer'image(s'last));
>          end Dynamic_Array;
>     end loop;
> end try;


Hey, that's nifty!  Never knew you could do stuff like that.


Chris
-- 
for personal replies change spamoff to chris

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 16/1/03 00:16, in article
AQmV9.4910$K63.170955@newsfep1-gui.server.ntli.net, "chris.danx"
<spamoff.danx@ntlworld.com> wrote:

> Richard Riehle wrote:
> 
...
>>          declare
>>               SUBTYPE S IS INTEGER RANGE READ .. READ;
>>              A : array(S) of Integer := (others => 0);
>>           begin -- Dynamic_Array
...
>>              for I in A'Range
>>              loop
>>                Integer_Text_IO.Get(A(I));
>>              end loop;
...
> 
> Hey, that's nifty!  Never knew you could do stuff like that.

(Not referring specifically to Chris.)

Many who learned to program in 1970s languages and their satanic progeny
(we all know what languages I mean)
find it hard to credit the full dynamic power of Ada. 8-)

Those who cut their teeth on Algols 60..68 have it easier in that respect.

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

Re: Anybody in US using ADA ? One silly idea..

[Jeffrey Carter]

chris.danx wrote:

[example of dynamic subtype and array type deleted]

> Hey, that's nifty!  Never knew you could do stuff like that.

Having become accustomed to the excellent expressive power of Ada, I 
find other languages cramped, uncomfortable, and difficult to use.

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

"chris.danx" wrote:

An appreciation.  Unfortunately, even though this will work,
I have an problem with my algorithm, as pointed out by several
people.  In my haste to illustrate the dynamic array, I created
a sloppy algorithm.   Try a better approach to getting out of
the loop.

Richard

> Richard Riehle wrote:
>
> > -- modified from example submitted to cla by Bill Findlay
> > with Ada.Integer_Text_IO;
> > with Ada.Text_IO;
> > use  Ada;
> > procedure try is
> >
> >     function read return integer is
> >         n : integer;
> >     begin
> >        Integer_Text_IO.get(n);
> >        return n;
> >      end read;
> >
> > begin -- Try
> >     loop
> >          Dynamic_Array:
> >          declare
> >               SUBTYPE S IS INTEGER RANGE READ .. READ;
> >              A : array(S) of Integer := (others => 0);
> >           begin -- Dynamic_Array
> >              exit when S'Last = S'First;
> >              for I in A'Range
> >              loop
> >                Integer_Text_IO.Get(A(I));
> >              end loop;
> >             Text_IO.put_line(integer'image(s'first)
> >                         & " .. " & integer'image(s'last));
> >          end Dynamic_Array;
> >     end loop;
> > end try;
>
> Hey, that's nifty!  Never knew you could do stuff like that.
>
> Chris
> --
> for personal replies change spamoff to chris

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 16/1/03 00:19, in article 3E25FA9A.2549C263@adaworks.com, "Richard
Riehle" <richard@adaworks.com> wrote:

> Bill Findlay wrote:
> 
>> I've noticed you say something like this before, Hyman, and I wonder if I'm
>> mistaking your meaning. Ada ranged types are NOT fixed at compile-time, they
>> may be fully dynamic.
> 
> Bill, Great example.  I have modified it slightly to emphasize the point.
> Hope  you don't mind.  Here is the altered version.

Not at all, your amplification brings the point out more fully; but it
should be said that:

>             SUBTYPE S IS INTEGER RANGE READ .. READ;

is formally undefined, as the language does not specify the order in which
the lower and upper bounds of the range are evaluated.

(So don't try this at home, folks!)

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

Re: Anybody in US using ADA ? One silly idea..

[Jean-Pierre Rosen]

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


"Bill Findlay" <yaldnifw@blueyonder.co.uk> a �crit dans le message de news: BA4BAC1F.1C55%yaldnifw@blueyonder.co.uk...
> Not at all, your amplification brings the point out more fully; but it
> should be said that:
>
> >             SUBTYPE S IS INTEGER RANGE READ .. READ;
>
> is formally undefined, as the language does not specify the order in which
> the lower and upper bounds of the range are evaluated.
>
Which is easily solved by saying:
     Lower : constant Integer := Read;
     Upper : constant Integer := Read;
     subtype S is Integer range Lower..Upper;

(Fortunately, declarations *are* elaborated in order :-)

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

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> I think I explained why. But to avoid that discussion again, just take
>> the unit solution for C++ you mentioned and try to implement a calculator
>> for dimensioned values using it.
> 
> No, I don't want to do that. If I did want to do that,
> my solution would be inappropriate, but so what?

It is not a universal solution. That's the point. A floating-point type is 
one for real logarithmic values. Are you sure that dimensioned values have 
no universal solution at all?

> Part
> of designing a program is deciding what is fixed at
> compile-time and what is decided at run-time.

Yes, but sometimes it is the language that forces you to decide. The 
question is again, is that a cruelty of the Universe or just an arbitrary 
defect of a particular language.

> Ada has ranged types where the ranges are fixed at compile-time,

They are not, up to some limit. But the problem is whether the language 
gives you an opportunity to define new numeric types without the 
restrictions you do not need and close enough to the theoretical 
performance limit for the remaining restrictions. Ada almost can this. 
[Almost, because one cannot make a private type "numeric" for the 
compiler.]

> and records whose field names are fixed at compile-time,
> and procedures whose parameters are fixed at compile-time.

It is not very useful, I mean untyped containers if you point at that. What 
can you do with the elements of an "unknown" type? Only put them into 
another container. Ada is not Lisp.

> Similarly, it has generics whose parameters are fixed at
> compile-time. When I know what I need at compile-time,
> why should I be required to funnel it through a mechanism
> which is designed for run-time variation?

No, this is wrong. This mechanism and generics are both designed *just* for 
variation. The nature of generics excludes run-time variation. This is a 
restriction. If you are trying to defend this restriction, then well, I 
admit that there are useful restrictions, but I see no advantages in this 
case. It is same as to claim that:

generic
   Size : Natural;
package ... is
   type My_String is record
      Text : String (1..Size);
   end record;

is better than

   type My_String (Size : Natural) is record
      Text : String (1..Size);
   end record;

Dispatching, discriminants, array bounds have no such restiriction. Moreover 
subtyping/subclassing enrich the structure of types, while generics just 
ignore types and relations between them. What's the use of a variation over 
a type set if you are unable to specify an element of the set?

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> This mechanism and generics are both designed *just* for variation.

The dispatching mechanism is designed for runtime variation.
The generic mechanism is designed for compile-time variation.
Just because you can occasionally track types well enough
through dispatching code so that dispatches can be replaced
with explicit calls doesn't change that.

> I see no advantages in this case.

The advantage is that more efficient (smaller/faster) code
can be generated from generics, if not in theory then certainly
in practice. Programming languages are not just abstract
constructs, they are means for generating sequences of native
machine code to perform some task.

> It is same as to claim that (generic)
 > is better than (discriminated type)

Yes, and that's a valid claim. Given a fixed size, it's likely
that better code can be generated than when the size must be
passed around as a variable.

 > What's the use of a variation over a type set if you are unable
 > to specify an element of the set?

The use is to specify an operation on elements of the set a
single time, and yet have that operation work for many elements.

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Hyman Rosen wrote:

> The advantage is that more efficient (smaller/faster) code
> can be generated from generics, if not in theory then certainly
> in practice. Programming languages are not just abstract
> constructs, they are means for generating sequences of native
> machine code to perform some task.

Bill Findlay posted some code earlier, that I revised slightly
to make a point in this conversation.   Here is another example
using generics.

with Ada.Text_IO;
with Ada.Integer_Text_IO;
with System;
use  Ada;
procedure Conditional_Instantiation is
  X : Character := ' ';
  type Large_Number is range System.Min_Int..System.Max_Int;
  Bound : Large_Number := Large_Number'Last;
begin
  loop
    Text_IO.Put("Enter a Character: ");
    Text_IO.Get(X);
    Text_IO.New_Line;
    if X in 'A'..'Z' or X in 'a'..'z' then
       Text_IO.Put("Enter a number: ");
       Integer_Text_IO.Get(Integer(Bound));
       declare
          type Number is new Large_Number range 1..Bound;
          package IIO is new Text_IO.Integer_IO(Num => Number);
       begin
          Text_IO.Put("Upper Bound - 1 = ");
          IIO.Put(Number'Last - 1);
          Text_IO.New_Line;
       end;
    else
       exit;
    end if;
  end loop;
end Conditional_Instantiation;

Note that the result of the IIO.Put statement will reflect the
value of one less than whatever has been selected for the
value of Bound in the type declaration.   This will only
work on derived types and subtypes, but that is good
enough for most kind of applications.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Richard Riehle wrote:
> Bill Findlay posted some code earlier, that I revised slightly
> to make a point in this conversation.   Here is another example
> using generics.

Yep. I already knew that the Ada generic model is different from
the C++ one. Thanks for another example illustrating why this must
be so. C++ types don't carry around little runtime bits to augment
their static information, so a C++ template instantiation is much
more of a "macro expansion" than is an Ada generic instantiation.

I can also see why Dmitry Kazakov is dubious of the benefits of
generics over dispatching, since Ada generics already seem to need
to access runtime type information. It's quite different in C++.

Very interesting. As another thread is saying, comparing different
programming languages is a good thing. You have to be pretty expert
in a language to see how apparent low-level design details spread
throughout and affect seemingly unrelated areas.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> This mechanism and generics are both designed *just* for variation.
> 
> The dispatching mechanism is designed for runtime variation.
> The generic mechanism is designed for compile-time variation.
> Just because you can occasionally track types well enough
> through dispatching code so that dispatches can be replaced
> with explicit calls doesn't change that.

Not occasionaly, but when they are statically known. There is absolutely no 
difference with generics, which also "occasionally" work in this case.

>> I see no advantages in this case.
> 
> The advantage is that more efficient (smaller/faster) code
> can be generated from generics, if not in theory then certainly
> in practice. Programming languages are not just abstract
> constructs, they are means for generating sequences of native
> machine code to perform some task.

I never argued this point, which actually sounds: we use them because there 
is nothing better. But this does not exclude that there could be something 
better than generics.

>> It is same as to claim that (generic)
>  > is better than (discriminated type)
> 
> Yes, and that's a valid claim. Given a fixed size, it's likely
> that better code can be generated than when the size must be
> passed around as a variable.

Seems that you are summoning the ghost of Pascal-strings. (:-)) Leave them 
resting in peace, they are useless!

>  > What's the use of a variation over a type set if you are unable
>  > to specify an element of the set?
> 
> The use is to specify an operation on elements of the set a
> single time, and yet have that operation work for many elements.

But because you cannot specify the set, you are very limited in which 
operation you can define. For instance, you cannot have an iterator of the 
set, you cannot have subsets, pointers, containers and many other things 
which make ADT so useful. This is the price of text substitution.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Not occasionaly, but when they are statically known.
 > There is absolutely no difference with generics,
 > which also "occasionally" work in this case.

There is certainly a difference. With generics, the type
propogates through the code and can't be lost.
With dispatching, the compiler has to be able to deduce
that class wide objects and pointers are actually of a
specific type. That may not always be possible, especially
where containers are concerned.

> we use them because there is nothing better.

Well, in my opinion, they *are* better, but I guess
that's just a matter of taste.

> Seems that you are summoning the ghost of Pascal-strings. (:-))
 > Leave them resting in peace, they are useless!

They have their place. And in Pascal, there were no generics,
so you would have to rewrite your code for each different size.
Gnereics do that for you, and sometimes that may be exactly what
you want.

> But because you cannot specify the set, you are very limited in which 
> operation you can define. For instance, you cannot have an iterator of the 
> set, you cannot have subsets, pointers, containers and many other things 
> which make ADT so useful. This is the price of text substitution.

No, that is the price of using Ada generics. In C++, because of
specialization, you can have all of those things. Specialization
means that you can have entirely different code for a generic
instantiation based on the parameters; in Ada you cannot do this.
Andrei Alexandrescu's _Modern C++ Design_ is the best exposition
of these kind of techniques. The attitude in this kind of
programming is that using a specifc type instead of a generic
parameter is a lot like using a magic number in the code.

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Hyman Rosen wrote:

> No, that is the price of using Ada generics. In C++, because of
> specialization, you can have all of those things. Specialization
> means that you can have entirely different code for a generic
> instantiation based on the parameters; in Ada you cannot do this.
> Andrei Alexandrescu's _Modern C++ Design_ is the best exposition
> of these kind of techniques. The attitude in this kind of
> programming is that using a specifc type instead of a generic
> parameter is a lot like using a magic number in the code.

I have read Alexandrescu's discussion of this interesting feature
of C++.   His is probably the first good book on C++ design
I have seen.   It almost makes the language look reasonable. :-)

Note the smiley, Hyman.

Here is a generic in Ada, which while not identical to the C++ model,
does permit combining specialization with genericity and which has
turned out to be quite useful for certain kinds of problems.  When combined
with some of the other examples Mr. Findlay and I have posted, it
becomes a powerful tool for designing complex solutions.

================================================

generic
  type Item is abstract tagged private;
package Generic_Abstract_Type is

  type Starting_Type is abstract new Item with private;
  -- override inherited methods from Item

  procedure Make (The_Item : Starting_Type);
  -- extend with additional methods
  -- including, optionally, abstract methods

private

  type Starting_Type is abstract new Item with null record;

end Generic_Abstract_Type;

==============================================

The generic formal parameter could also have been something such
as,

         generic
             type Item is abstract new T with private;
             type Reference is access all Item'Class;
         package Generic_T_Derivation is ... end Generic_T_Derivation;

Many more variations are possible.   We can combine specialization
with genericity.  In this example, we also include a generic formal access
type so we can do indirect access operations at the classwide level.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Richard Riehle wrote:
> Here is a generic in Ada, which while not identical to the C++ model,
> does permit combining specialization with genericity and which has
> turned out to be quite useful for certain kinds of problems.

This looks like something we would write in C++ like this:

template <class Item>
struct Starting_Type : public Item
{
	void Make();
};

I agree - there are plenty or circumstances where this is useful
and powerful.

C++ template specialization is different though; it doesn't
(necessarily) involve tagged types at all. Here's a simple
example:

// General case
template<int N>
struct Factorial { enum { Value = N * Factorial<N - 1>::Value } };

// Specialization for 0
template<>
struct Factorial<0> { enum { Value = 1 } };

// Use it, as a compile-time constant expression
int array[Factorial<5>::Value];

When you ask for Factorial<0>, the compiler uses the special case
you provided, otherwise it uses the general case. Notice that the
bodies of the specialization is completely different from the one
in the general case. (They both define a Value enumerator, but in
general, they could have been completely unrelated.)

The same thing works for type parameters:

// General case
template <typename T>
struct RemovePointers { typedef T type; };

// Specialize for pointers
template <typename T>
struct RemovePointers <T *> { typedef RemovePointers<T>::type type; };

RemovePointers<double *****>::type its_a_double = 17.29;

When you ask for RemovePointers<SomeType>, the compiler matches
SomeType against the specializatons. If it finds that one of them
is a better match than the generic type (using rules defined by
the language), it uses that one.

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Hyman Rosen wrote:

> C++ template specialization is different though; it doesn't
> (necessarily) involve tagged types at all. Here's a simple
> example:
>
> // General case
> template<int N>
> struct Factorial { enum { Value = N * Factorial<N - 1>::Value } };
>
> // Specialization for 0
> template<>
> struct Factorial<0> { enum { Value = 1 } };
>
> // Use it, as a compile-time constant expression
> int array[Factorial<5>::Value];
>
> When you ask for Factorial<0>, the compiler uses the special case
> you provided, otherwise it uses the general case.

This looks a lot like a form of overloading.   Combine this with
generic subprograms, or generic child library units, and we have
a pretty close match in capability.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Richard Riehle wrote:
> This looks a lot like a form of overloading.

But with compile-time evaluation. I don't believe Ada has anything like it.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Not occasionaly, but when they are statically known.
>  > There is absolutely no difference with generics,
>  > which also "occasionally" work in this case.
> 
> There is certainly a difference. With generics, the type
> propogates through the code and can't be lost.
> With dispatching, the compiler has to be able to deduce
> that class wide objects and pointers are actually of a
> specific type. That may not always be possible, especially
> where containers are concerned.

If not possible, then it is not a case where generics may be applied. My 
point is, anywhere generics work, the specific type can be tacked down.

>> we use them because there is nothing better.
> 
> Well, in my opinion, they *are* better, but I guess
> that's just a matter of taste.

If they are better, then there should be a rationale for that. So far, there 
are only two arguments:

1. Efficiency [which is arguable and very often not an issue in a large 
system]

2. They can something, that other gears cannot [what if they could?]

Compare this with gotos. They are extremely efficient and they do can [make 
a maintenance nightmare out of any program]

>> Seems that you are summoning the ghost of Pascal-strings. (:-))
>  > Leave them resting in peace, they are useless!
> 
> They have their place. And in Pascal, there were no generics,
> so you would have to rewrite your code for each different size.
> Gnereics do that for you, and sometimes that may be exactly what
> you want.
> 
>> But because you cannot specify the set, you are very limited in which
>> operation you can define. For instance, you cannot have an iterator of
>> the set, you cannot have subsets, pointers, containers and many other
>> things which make ADT so useful. This is the price of text substitution.
> 
> No, that is the price of using Ada generics. In C++, because of
> specialization, you can have all of those things. Specialization
> means that you can have entirely different code for a generic
> instantiation based on the parameters; in Ada you cannot do this.

This changes nothing:

template <class X> class Y ...;

how a specialization could help to create a container for Y. Note missing <> 
after Y. There is simply no such thing as Y. There is only a bunch of 
instances of Y, which are absolutely *unrelated*!

> Andrei Alexandrescu's _Modern C++ Design_ is the best exposition
> of these kind of techniques. The attitude in this kind of
> programming is that using a specifc type instead of a generic
> parameter is a lot like using a magic number in the code.

This statement will retain its meaning if you replace "generic parameter" 
with "class-wide". However, maybe not "modern", but rather *careful* design 
requires a precise consideration when a class-wide/generic and when a 
specific type is appropriate.

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

Re: Anybody in US using ADA ? One silly idea..

[Hillel Y. Sims]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:b0bhef$ni0jk$1@ID-77047.news.dfncis.de...
> If they are better, then there should be a rationale for that. So far,
there
> are only two arguments:
>
> 1. Efficiency [which is arguable and very often not an issue in a large
> system]
>

Are you serious? Just a small example of potential efficiency, C++ templated
std::sort() function is proven to be non-trivially faster than the
mostly-equivalent C-based non-templated std::qsort() function which uses
untyped void* parameters. On my system (HP Alphas running OpenVMS),
templated std::sort() is more than 60% faster than std::qsort() for arrays
of 500,000 integers or floats. Recent profiling of our system (financial
data integration/analysis) indicated some sorting routines (really old
fortran-based code) as potential relevant targets for efficiency
improvement. I imagine similar kinds of efficiency improvement are possible
in Ada using generics vs. untyped code?

> 2. They can something, that other gears cannot [what if they could?]

Has anyone suggested anything better yet?

>
> Compare this with gotos. They are extremely efficient and they do can
[make
> a maintenance nightmare out of any program]

How do you compare gotos to generics? Generics do not destroy structured
code. I just don't understand the analogy.

>
> This changes nothing:
>
> template <class X> class Y ...;
>
> how a specialization could help to create a container for Y. Note missing
<>
> after Y. There is simply no such thing as Y. There is only a bunch of
> instances of Y, which are absolutely *unrelated*!

It can actually help. For example, in the case of the standard C++ container
class std::vector<T> -- there can be a specialization defined (I forget if
it is mandated by the Standard, but it is possible anyhow) for all
std::vector<T*> such that they are inherited from std::vector<void*> with
just the necessary casts thrown in by the compiler (inline). This can
eliminate a large amount of unnecessary code bloat for all instantiations of
vectors of pointer types.

hys

--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

"Hillel Y. Sims" <usenet@phatbasset.com> wrote in message news:<_VkW9.266404$FT6.43771824@news4.srv.hcvlny.cv.net>...
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:b0bhef$ni0jk$1@ID-77047.news.dfncis.de...
> > If they are better, then there should be a rationale for that. So far,
>  there
> > are only two arguments:
> >
> > 1. Efficiency [which is arguable and very often not an issue in a large
> > system]
> >
> 
> Are you serious? Just a small example of potential efficiency, C++ templated
> std::sort() function is proven to be non-trivially faster than the
> mostly-equivalent C-based non-templated std::qsort() function which uses
> untyped void* parameters. On my system (HP Alphas running OpenVMS),
> templated std::sort() is more than 60% faster than std::qsort() for arrays
> of 500,000 integers or floats. Recent profiling of our system (financial
> data integration/analysis) indicated some sorting routines (really old
> fortran-based code) as potential relevant targets for efficiency
> improvement. I imagine similar kinds of efficiency improvement are possible
> in Ada using generics vs. untyped code?
> 
> > 2. They can something, that other gears cannot [what if they could?]
> 
> Has anyone suggested anything better yet?
> 
> >
> > Compare this with gotos. They are extremely efficient and they do can
>  [make
> > a maintenance nightmare out of any program]
> 
> How do you compare gotos to generics? Generics do not destroy structured
> code. I just don't understand the analogy.
> 
> >
> > This changes nothing:
> >
> > template <class X> class Y ...;
> >
> > how a specialization could help to create a container for Y. Note missing
>  <>
> > after Y. There is simply no such thing as Y. There is only a bunch of
> > instances of Y, which are absolutely *unrelated*!
> 
> It can actually help. For example, in the case of the standard C++ container
> class std::vector<T> -- there can be a specialization defined (I forget if
> it is mandated by the Standard, but it is possible anyhow) for all
> std::vector<T*> such that they are inherited from std::vector<void*> with
> just the necessary casts thrown in by the compiler (inline). This can
> eliminate a large amount of unnecessary code bloat for all instantiations of
> vectors of pointer types.

It's not mandated by the standard and it's generally not done.
There's not much point since most of the standard container
member functions are rather short, and are almost always compiled inline.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hillel Y. Sims wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:b0bhef$ni0jk$1@ID-77047.news.dfncis.de...
>> If they are better, then there should be a rationale for that. So far,
> there
>> are only two arguments:
>>
>> 1. Efficiency [which is arguable and very often not an issue in a large
>> system]
> 
> Are you serious? Just a small example of potential efficiency, C++
> templated std::sort() function is proven to be non-trivially faster than
> the mostly-equivalent C-based non-templated std::qsort() function which
> uses untyped void* parameters. On my system (HP Alphas running OpenVMS),
> templated std::sort() is more than 60% faster than std::qsort() for arrays
> of 500,000 integers or floats. Recent profiling of our system (financial
> data integration/analysis) indicated some sorting routines (really old
> fortran-based code) as potential relevant targets for efficiency
> improvement. I imagine similar kinds of efficiency improvement are
> possible in Ada using generics vs. untyped code?

This is a wrong comparison. A correct one would be an instance of a generic 
subroutine vs. an inlined subroutine and, note, when the type is statically 
known.

>> 2. They can something, that other gears cannot [what if they could?]
> 
> Has anyone suggested anything better yet?

Yes.

type X is array (Integer range <>) of Y; is definitely better than a generic 
version with the array size as the parameter.

type X (Param : Y) is ...; is also almost always better than generics.

>> Compare this with gotos. They are extremely efficient and they do can
> [make
>> a maintenance nightmare out of any program]
> 
> How do you compare gotos to generics? Generics do not destroy structured
> code. I just don't understand the analogy.

They are as chaotic as gotos. They destroy the type structure of the program 
as gotos do the control flow. Hyman Rosen gave us a brilliant example of 
generic code for handling dimensioned values. But get a programmer from 
street and ask him why and how it works. Programming should be as simple as 
tooth powder. (:-))

>> This changes nothing:
>>
>> template <class X> class Y ...;
>>
>> how a specialization could help to create a container for Y. Note missing
> <>
>> after Y. There is simply no such thing as Y. There is only a bunch of
>> instances of Y, which are absolutely *unrelated*!
> 
> It can actually help. For example, in the case of the standard C++
> container class std::vector<T> -- there can be a specialization defined (I
> forget if it is mandated by the Standard, but it is possible anyhow) for
> all std::vector<T*> such that they are inherited from std::vector<void*>
> with just the necessary casts thrown in by the compiler (inline). This can
> eliminate a large amount of unnecessary code bloat for all instantiations
> of vectors of pointer types.

With pointer types we do not need generics at all, because all pointers are 
of some predictable size. Then it is not the actual problem. The problem is 
that std::vector is not a type, so even std::vector* cannot exist.

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

Re: Anybody in US using ADA ? One silly idea..

[Hillel Y. Sims]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:b0e5vu$ognn6$1@ID-77047.news.dfncis.de...
> Hillel Y. Sims wrote:
>
[templated C++ sort() is faster than qsort()]
>
> This is a wrong comparison. A correct one would be an instance of a
generic
> subroutine vs. an inlined subroutine and, note, when the type is
statically
> known.

sort<int>() vs. sort_ints()? In that case the performance should really be
exactly the same (since as you say, it really *is* to a large extent just a
bunch of text substitution :-). The benefit is that you don't need to
rewrite or copy/paste the code over and over for each unique type, the
compiler does it automatically (while maintaining full type safety, unlike
dumb macros) -- and better yet, when you fix a bug in the generic version,
it is immediately fixed for all instantiations automatically (vs.
sort_ints(), sort_floats(), sort_strings(), sort_xyz())

> > How do you compare gotos to generics? Generics do not destroy structured
> > code. I just don't understand the analogy.
>
> They are as chaotic as gotos. They destroy the type structure of the
program
> as gotos do the control flow. Hyman Rosen gave us a brilliant example of
> generic code for handling dimensioned values. But get a programmer from
> street and ask him why and how it works. Programming should be as simple
as
> tooth powder. (:-))

No argument that some crazy stuff can be done that is really difficult to
interpret by humans. I'm not sure you've really made the case "generics
considered harmful" though yet..

> > It can actually help. For example, in the case of the standard C++
> > container class std::vector<T> -- there can be a specialization defined
(I
> > forget if it is mandated by the Standard, but it is possible anyhow) for
> > all std::vector<T*> such that they are inherited from std::vector<void*>
> > with just the necessary casts thrown in by the compiler (inline). This
can
> > eliminate a large amount of unnecessary code bloat for all
instantiations
> > of vectors of pointer types.
>
> With pointer types we do not need generics at all, because all pointers
are
> of some predictable size.

However, full type safety is maintained without requiring programmers to
manually do (error-prone) casting.

>Then it is not the actual problem. The problem is
> that std::vector is not a type, so even std::vector* cannot exist.
>

Sure it can:

template <typename T>
void f(std::vector<T>* pVec)
{
   pVec->clear();
   //etc...
}

:-)

hys
--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 21 Jan 2003 02:10:37 GMT, "Hillel Y. Sims"
<usenet@phatbasset.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:b0e5vu$ognn6$1@ID-77047.news.dfncis.de...
>> Hillel Y. Sims wrote:
>>
>[templated C++ sort() is faster than qsort()]
>>
>> This is a wrong comparison. A correct one would be an instance of a
>generic
>> subroutine vs. an inlined subroutine and, note, when the type is
>statically
>> known.
>
>sort<int>() vs. sort_ints()? In that case the performance should really be
>exactly the same (since as you say, it really *is* to a large extent just a
>bunch of text substitution :-). The benefit is that you don't need to
>rewrite or copy/paste the code over and over for each unique type, the
>compiler does it automatically (while maintaining full type safety, unlike
>dumb macros) -- and better yet, when you fix a bug in the generic version,
>it is immediately fixed for all instantiations automatically (vs.
>sort_ints(), sort_floats(), sort_strings(), sort_xyz())

This is an advantage of generics over blind preprocessing. The problem
is whether same can be achieved without both.

Consider class-wide sort written for all arrays derived from some
abstract array of comparable elements. If that sort is inlined, then
then compiler theoretically would have all necessary information to
make code as efficient as generic sort could. Presently it is
impossible in both Ada and C++.

>> > How do you compare gotos to generics? Generics do not destroy structured
>> > code. I just don't understand the analogy.
>>
>> They are as chaotic as gotos. They destroy the type structure of the
>program
>> as gotos do the control flow. Hyman Rosen gave us a brilliant example of
>> generic code for handling dimensioned values. But get a programmer from
>> street and ask him why and how it works. Programming should be as simple
>as
>> tooth powder. (:-))
>
>No argument that some crazy stuff can be done that is really difficult to
>interpret by humans. I'm not sure you've really made the case "generics
>considered harmful" though yet..
>
>> > It can actually help. For example, in the case of the standard C++
>> > container class std::vector<T> -- there can be a specialization defined
>(I
>> > forget if it is mandated by the Standard, but it is possible anyhow) for
>> > all std::vector<T*> such that they are inherited from std::vector<void*>
>> > with just the necessary casts thrown in by the compiler (inline). This
>can
>> > eliminate a large amount of unnecessary code bloat for all
>instantiations
>> > of vectors of pointer types.
>>
>> With pointer types we do not need generics at all, because all pointers
>are
>> of some predictable size.
>
>However, full type safety is maintained without requiring programmers to
>manually do (error-prone) casting.
>
>>Then it is not the actual problem. The problem is
>> that std::vector is not a type, so even std::vector* cannot exist.
>
>Sure it can:
>
>template <typename T>
>void f(std::vector<T>* pVec)
>{
>   pVec->clear();
>   //etc...
>}

This gives nothing because you just moved T from one place to another.
It just highlights the problem. Once you made something generic, then
everything using that becomes generic as well. That's alone is bad.
Buf for inherently non-static things (like class-wide pointers in my
example) it is catastrophic, because there cannot be solution for
them.

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

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<ga3q2vkds5akg0iaommdaniqp3ubo293pl@4ax.com>...
> On Tue, 21 Jan 2003 02:10:37 GMT, "Hillel Y. Sims"
> <usenet@phatbasset.com> wrote:
> 
> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> >news:b0e5vu$ognn6$1@ID-77047.news.dfncis.de...
> >> Hillel Y. Sims wrote:
> >>
>  [templated C++ sort() is faster than qsort()]
> >>
> >> This is a wrong comparison. A correct one would be an instance of a
>  generic
> >> subroutine vs. an inlined subroutine and, note, when the type is
>  statically
> >> known.
> >
> >sort<int>() vs. sort_ints()? In that case the performance should really be
> >exactly the same (since as you say, it really *is* to a large extent just a
> >bunch of text substitution :-). The benefit is that you don't need to
> >rewrite or copy/paste the code over and over for each unique type, the
> >compiler does it automatically (while maintaining full type safety, unlike
> >dumb macros) -- and better yet, when you fix a bug in the generic version,
> >it is immediately fixed for all instantiations automatically (vs.
> >sort_ints(), sort_floats(), sort_strings(), sort_xyz())
> 
> This is an advantage of generics over blind preprocessing. The problem
> is whether same can be achieved without both.
> 
> Consider class-wide sort written for all arrays derived from some
> abstract array of comparable elements. If that sort is inlined, then
> then compiler theoretically would have all necessary information to
> make code as efficient as generic sort could. Presently it is
> impossible in both Ada and C++.

But then to be sortable the element type would have be derived from
some "Comparable" base type.  And to be stored in a hash table,
they would have to be derived from a "Hashable" base type.  And to be
used with some generic mathematical algorithm they would have to
be derived from an "Arithmetic" base type...

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On 21 Jan 2003 10:55:36 -0800, kcline17@hotmail.com (Kevin Cline)
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<ga3q2vkds5akg0iaommdaniqp3ubo293pl@4ax.com>...
>> On Tue, 21 Jan 2003 02:10:37 GMT, "Hillel Y. Sims"
>> <usenet@phatbasset.com> wrote:
>> 
>> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> >news:b0e5vu$ognn6$1@ID-77047.news.dfncis.de...
>> >> Hillel Y. Sims wrote:
>> >>
>>  [templated C++ sort() is faster than qsort()]
>> >>
>> >> This is a wrong comparison. A correct one would be an instance of a
>>  generic
>> >> subroutine vs. an inlined subroutine and, note, when the type is
>>  statically
>> >> known.
>> >
>> >sort<int>() vs. sort_ints()? In that case the performance should really be
>> >exactly the same (since as you say, it really *is* to a large extent just a
>> >bunch of text substitution :-). The benefit is that you don't need to
>> >rewrite or copy/paste the code over and over for each unique type, the
>> >compiler does it automatically (while maintaining full type safety, unlike
>> >dumb macros) -- and better yet, when you fix a bug in the generic version,
>> >it is immediately fixed for all instantiations automatically (vs.
>> >sort_ints(), sort_floats(), sort_strings(), sort_xyz())
>> 
>> This is an advantage of generics over blind preprocessing. The problem
>> is whether same can be achieved without both.
>> 
>> Consider class-wide sort written for all arrays derived from some
>> abstract array of comparable elements. If that sort is inlined, then
>> then compiler theoretically would have all necessary information to
>> make code as efficient as generic sort could. Presently it is
>> impossible in both Ada and C++.
>
>But then to be sortable the element type would have be derived from
>some "Comparable" base type.  And to be stored in a hash table,
>they would have to be derived from a "Hashable" base type.  And to be
>used with some generic mathematical algorithm they would have to
>be derived from an "Arithmetic" base type...

Yes of course. Derived here means only "implements interface of". It
is also an advantage over generics, because with templates you never
know if the actual type is "Hashable", until you instantiate all
functions using all methods of "Hashable". And even so, nobody can say
whether these methods really comprise a "Hashable" type or they just 
have similar names and the profiles appropriate to go through the
compiler.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> with templates you never know if the actual type is "Hashable",
 > until you instantiate all functions using all methods of "Hashable".

You also don't *care* if the actual type supports all methods of
"Hashable" if you don't use them!

> And even so, nobody can say whether these methods really comprise
 > a "Hashable" type or they just have similar names and the profiles
 > appropriate to go through the compiler.

Nobody can say whether something that inherits from "Hashable" has
implemented the methods correctly. For example, I could have a type
that I think will never actually go into a hashtable but must be
"Hashable" for some reason, so I implement its hashing method to
just return zero. Then someone decides to put it into a table after
all...

By the way, you might find the following link interetsing.
<http://spirit.sourceforge.net/index.php?doc=docs/v1_5/introduction.html>
It's a recursive descent parsing system designed using C++ template
metaprogramming. There are a few places where the code uses inheritance
and virtual dispatch, but only to get around C++'s limitations in naming
a type based on an expression. The author complains about how virtual
methods get in the way of efficient code. The problem is that we want to
abe able to say 'declare variable = expression' and have the type of the
variable be the type of the expression. Because C++ instantiates generics
automatically, and as you saw in the Unit code I posted, can synthesize
return types, it's difficult to examine an expression and write out its
type, even though the compiler has no trouble doing so. To work around
this, you can create a placeholder type which can hold any kind of
expression of interest, but then this forces you into dispatch mode
instead of generic mode. It's especially annoying because all the
facilities are already present in the language - if you declare
template <typename T> void func(const T &) { }, and call func(expression),
the compiler deduces the expression type, and it's available inside func.
But there's no way to get it out, that is, to use the same type deduction
to declare a variable of the appropriate type, outside of the function.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> with templates you never know if the actual type is "Hashable",
>  > until you instantiate all functions using all methods of "Hashable".
> 
> You also don't *care* if the actual type supports all methods of
> "Hashable" if you don't use them!

What of I don't care now, might become a nightmare for somebody other 5 
years later. What is [arguable] good for C++ is inacceptable for Ada.

But the point is: you cannot rely on specifications in case of templates. 
There are no specifications [of the type set] at all. To verify the code 
using templates, you have to look into the bodies of the template 
functions.

>> And even so, nobody can say whether these methods really comprise
>  > a "Hashable" type or they just have similar names and the profiles
>  > appropriate to go through the compiler.
> 
> Nobody can say whether something that inherits from "Hashable" has
> implemented the methods correctly. For example, I could have a type
> that I think will never actually go into a hashtable but must be
> "Hashable" for some reason, so I implement its hashing method to
> just return zero. Then someone decides to put it into a table after
> all...

This is an intentionally made semantic fault, sabotage if you want. (:-))

If you do not plan to put a type into a hash table, why should it be 
"Hashable"? That is the crucial point. If someone, later decides that your 
type has to be "Hashable" it will be his responsibility to do so. My idea 
(rather a dream (:-)), is that he will be able to create a "bridge" type, 
which will be a subtype of "Hashable" and a supertype of your type. Doing 
so, he will be obliged to override the abstract hashing method of 
"Hashable".

> By the way, you might find the following link interetsing.
> <http://spirit.sourceforge.net/index.php?doc=docs/v1_5/introduction.html>
> It's a recursive descent parsing system designed using C++ template
> metaprogramming. There are a few places where the code uses inheritance
> and virtual dispatch, but only to get around C++'s limitations in naming
> a type based on an expression. The author complains about how virtual
> methods get in the way of efficient code. The problem is that we want to
> abe able to say 'declare variable = expression' and have the type of the
> variable be the type of the expression. Because C++ instantiates generics
> automatically, and as you saw in the Unit code I posted, can synthesize
> return types, it's difficult to examine an expression and write out its
> type, even though the compiler has no trouble doing so. To work around
> this, you can create a placeholder type which can hold any kind of
> expression of interest, but then this forces you into dispatch mode
> instead of generic mode. It's especially annoying because all the
> facilities are already present in the language - if you declare
> template <typename T> void func(const T &) { }, and call func(expression),
> the compiler deduces the expression type, and it's available inside func.
> But there's no way to get it out, that is, to use the same type deduction
> to declare a variable of the appropriate type, outside of the function.

Thank you for the interesting reference.

BTW another almost-have-it in C++. Let, we want subtypes having alternative 
representations, like in case Ellipse<-Cricle. C++ almost has it:

class Ellipse
{
public :
   double X;
   double Y;

   Ellipse (double X, double Y) : X (X), Y (Y) {}
};

class Circle // Not derived from Ellipse to get rid of X and Y
{
public :
   double Radius;

   Circle (double Radius)         : Radius (Radius) {}
   Circle (const Circle& Object)  : Radius (Object.Radius) {}
   Circle (const Ellipse& Object) : Radius (Object.X)
   {
      if (Radius != Object.Y) throw NotACircle;
   }
   operator Ellipse () const
   {
      return Ellipse (Radius, Radius);
   }
};

Unfortunately in most cases Circle will never be converted to Ellipse and 
back, even though the compiler has everything for that.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> To verify the code using templates, you have to look into the
 > bodies of the template functions.

You just have to read the documentation, just like any other
function with preconditions.

> If you do not plan to put a type into a hash table, why should it be 
> "Hashable"?

Because in the absence of multiple inheritance, there is a tendency
to "pile on" stuff that might be useful, because it's hard to add later?

> Unfortunately in most cases Circle will never be converted to Ellipse and 
> back, even though the compiler has everything for that.

Why? It looks like you wrote the code correctly to do just that.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Sun, 26 Jan 2003 06:32:35 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> To verify the code using templates, you have to look into the
> > bodies of the template functions.
>
>You just have to read the documentation, just like any other
>function with preconditions.

If nothing other helps, please, read the documentation! (:-))

Precondition is a part of the specification, not body. Let you change
the body in a way that it will use an operation with was not used
before. Then one should revise all the code that uses this body. With
proper DbC you should check only the contracts and most of these
checks does the compiler.

In other words, "Hashable" has to be a type property, while with
generics it is rather a property of the given compilation.

>> If you do not plan to put a type into a hash table, why should it be 
>> "Hashable"?
>
>Because in the absence of multiple inheritance, there is a tendency
>to "pile on" stuff that might be useful, because it's hard to add later?

Yes and that is absolutely wrong. Thick base classes is an evil caused
by absense of MI, lack of supertyping and overuse of representation
inheritable.

>> Unfortunately in most cases Circle will never be converted to Ellipse and 
>> back, even though the compiler has everything for that.
>
>Why? It looks like you wrote the code correctly to do just that.

If I define a method or a free a procedure on Ellipse:

void Foo (Ellipse& A);

then the compiler will not substitute a Circle for Ellipse. Because it
has first to convert Circle to Ellipse, then apply the procedure and
then to convert the result back. It is similar to what Ada does with
by-value parameters or when an in out parameter is explicitly
converted like in:

Get_Real (Float (Some_Integer));

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> If I define a method or a free a procedure on Ellipse:
> void Foo (Ellipse& A);
> then the compiler will not substitute a Circle for Ellipse.

Oh, You want to do *that* :-) It's an odd sort of thing to
want to do, but if you did, you wouldn't do it with copy-in/
copy-out, at least in C++. If I had to, I would do it like this,
in typical OO fashion:

struct EllipseInterface
{
     virtual void set(double x, double y) = 0;
     virtual void get(double &x, double &y) const = 0;
};

class Ellipse : public EllipseInterface
{
     double X, Y;
public:
     Ellipse(double x, double y) : X(x), Y(y) { }
     void set(double x, double y) { X = x; Y = y; }
     void get(double &x, double &y) const { x = X; y = Y; }
};

class Circle : public EllipseInterface
{
     double R;
public:
     struct NotCircle { };
     Circle(double r) : R(r) { }
     void set(double x, double y) { R = x == y ? x : throw NotCircle(); }
     void get(double &x, double &y) const { x = R; y = R; }
};

void Foo (EllipseInterface &A);

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 27 Jan 2003 10:08:17 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> If I define a method or a free a procedure on Ellipse:
>> void Foo (Ellipse& A);
>> then the compiler will not substitute a Circle for Ellipse.
>
>Oh, You want to do *that* :-)

Surely, isn't Circle an Ellipse? (:-))

> It's an odd sort of thing to
>want to do, but if you did, you wouldn't do it with copy-in/
>copy-out, at least in C++. If I had to, I would do it like this,
>in typical OO fashion:
>
>struct EllipseInterface
>{
>     virtual void set(double x, double y) = 0;
>     virtual void get(double &x, double &y) const = 0;
>};
>
>class Ellipse : public EllipseInterface
>{
>     double X, Y;
>public:
>     Ellipse(double x, double y) : X(x), Y(y) { }
>     void set(double x, double y) { X = x; Y = y; }
>     void get(double &x, double &y) const { x = X; y = Y; }
>};
>
>class Circle : public EllipseInterface
>{
>     double R;
>public:
>     struct NotCircle { };
>     Circle(double r) : R(r) { }
>     void set(double x, double y) { R = x == y ? x : throw NotCircle(); }
>     void get(double &x, double &y) const { x = R; y = R; }
>};
>
>void Foo (EllipseInterface &A);

But that's another thing. Here, Circle cannot use (inherit) the
methods of Ellipse. It inherits only the abstract methods of
EliipseInterface and thus, have to implement all of them for scratch.
This kills the whole idea of inheritance for code reuse.

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

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<3afc3v4uur2kvd53v4ul18b5npjfm188o3@4ax.com>...

> But that's another thing. Here, Circle cannot use (inherit) the
> methods of Ellipse. It inherits only the abstract methods of
> EliipseInterface and thus, have to implement all of them for scratch.
> This kills the whole idea of inheritance for code reuse.

I thought that idea was dead many years ago, when it was discovered
that failure to separate interface and implementation leads to a mess.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On 28 Jan 2003 07:48:37 -0800, kcline17@hotmail.com (Kevin Cline)
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<3afc3v4uur2kvd53v4ul18b5npjfm188o3@4ax.com>...
>
>> But that's another thing. Here, Circle cannot use (inherit) the
>> methods of Ellipse. It inherits only the abstract methods of
>> EliipseInterface and thus, have to implement all of them for scratch.
>> This kills the whole idea of inheritance for code reuse.
>
>I thought that idea was dead many years ago, when it was discovered
>that failure to separate interface and implementation leads to a mess.

Why do you think that making related types [Ellipse and Circle]
siblings (i.e. in fact unrelated) should provide the separation?

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Why do you think that making related types [Ellipse and Circle]
> siblings (i.e. in fact unrelated) should provide the separation?

Why do you think that the program objects Ellipse and Circle are
related (as opposed to the mathematical objects, that is)? After
all, mathematical objects are immutable. You have a circle with
a given radius, or an ellipse with given axes. They don't come
with knobs.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 28 Jan 2003 12:14:43 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Why do you think that making related types [Ellipse and Circle]
>> siblings (i.e. in fact unrelated) should provide the separation?
>
>Why do you think that the program objects Ellipse and Circle are
>related (as opposed to the mathematical objects, that is)?

Because program objects are used to model the mathematical ones. The
mathematical fact that circle is an ellipse makes possible
substitutability (limited of course) of the corresponding model
objects in programming language, which in turn is the basis of code
reuse.

>After all, mathematical objects are immutable.

So what? All values are immutable as well. If you think that
immutability implies absolute substitutability, then you are wrong. It
is a common delusion.

>You have a circle with
>a given radius, or an ellipse with given axes. They don't come
>with knobs.

If you do not like Circle and Ellipse, take int and float in C++.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But that's another thing. Here, Circle cannot use (inherit) the
> methods of Ellipse. It inherits only the abstract methods of
> EliipseInterface and thus, have to implement all of them for scratch.
> This kills the whole idea of inheritance for code reuse.

It's just the way I wrote it here, because I figured Circle
didn't need to store two doubles, just one. It could have
inherited directly from Ellipse if I'd wanted it that way:

class Circle : public Ellipse
{
public:
     struct NotCircle() { }
     Circle(double r) : Ellipse(r, r) { }
     void set(double x, double y) {
         if (x != y) throw NotCircle();
         Ellipse::set(x, y);
     }
};

Someone can sabotage this version though, by taking a
Circle and calling its Ellipse::set method directly.
In my other version, that couldn't happen.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 28 Jan 2003 12:11:50 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> But that's another thing. Here, Circle cannot use (inherit) the
>> methods of Ellipse. It inherits only the abstract methods of
>> EliipseInterface and thus, have to implement all of them for scratch.
>> This kills the whole idea of inheritance for code reuse.
>
>It's just the way I wrote it here, because I figured Circle
>didn't need to store two doubles, just one. It could have
>inherited directly from Ellipse if I'd wanted it that way:

That's the whole point. We want to inherit from Ellipse (non-abstract)
some of its methods, but we do not want to inherit the representation
(two doubles). Of course, if you change the representation, you lose
view conversions and thus an ability to pass Circle by-reference where
an Ellipse is required. You have to pass it by-copy instead. C++
cannot this, it lacks in out parameters, but Ada well can.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> That's the whole point. We want to inherit from Ellipse (non-abstract)
> some of its methods, but we do not want to inherit the representation
> (two doubles).

I don't understand what you are trying to accomplish.
If you want to inherit method implementation, how can
this not be tied to object representation?

Re: Anybody in US using ADA ? One silly idea..

[Mark Biggar]

Hyman Rosen wrote:
> Dmitry A. Kazakov wrote:
> 
>> That's the whole point. We want to inherit from Ellipse (non-abstract)
>> some of its methods, but we do not want to inherit the representation
>> (two doubles).
> 
> 
> I don't understand what you are trying to accomplish.
> If you want to inherit method implementation, how can
> this not be tied to object representation?
> 

What is going on here is the fundamential paradox of OO systems.
It often happens that the direction of substutibility inheritence and
implementation inheritence are opposite to each other.  For example,
you would normally like class Integer to be a subclass of class Float
because you want to be able to use an Integer anywhere you can use
a Float.  But, given methods in class Float like Get_Exponent you
want to implement class Float using Class Integer.  Oops, you can't
do both.

In general there are four ways two classes can be related to each
other in an OO system.

I.  class A isa class B
	you can use a A anywhere you can use an B

In Ada terms this is "type A is new B ..."

II. class A is implemented as class B
	each instance of class A is implemeted under the covers as
	an instance of class B, but you have provided a completely
	different interface.  E.G., class Stack is implemented using
	class Array, but you access it via push and pop instead of
	indexing.

	type A is private;
     private
	type A is new B ...;

III. class A contains class B.  Class A has a visible member
	of type class B plus some other stuff.

	type A is record B_mem: B; ... end record;

1V.  class A is not related ot class B at all.  included of
	completeness.

Unfortunately I and II can be in conflict like Integer and Float above
and you end up wiht an unresolvable circular dependency and so
must give up one or the other.

-- 
Mark Biggar
mark.a.biggar@attbi.com

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Mark Biggar wrote:
> What is going on here is the fundamential paradox of OO systems.

The OO lesson notwithstanding, I still don't see how
anyone thinks they can inherit method implementations
while not inheriting data representations. Aren't the
methods inextricably tied to the data they manipulate?

And this whole "isa" business is just a matter of what
methods the classes implement. A Circle "isa" Ellipse
as long as the interface doesn't include changing the
axes. I think the main problem is that people are
thinking instead of programming. What is going on here
is the fundamental mistake of OO systems, which is
imagining that these things that you are writing in
order to get a computer program to produce a useful
result have all the properties of the things whose
names they bear, rather than the tiny subset which is
implemented.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Wed, 29 Jan 2003 17:54:02 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Mark Biggar wrote:
>> What is going on here is the fundamential paradox of OO systems.
>
>The OO lesson notwithstanding, I still don't see how
>anyone thinks they can inherit method implementations
>while not inheriting data representations. Aren't the
>methods inextricably tied to the data they manipulate?

Yes. But if you inherit a method it does not necessarily mean that
this is the *same* method.

Even in case of "class Circle : public Ellipse", when you call
Ellipse::Foo on a Circle, the compiler will *add* some code to convert
view. This means, that even if not overridden Circle::Foo is not
Ellipse::Foo. Now, consider that this additional code not just shifts
a reference, but creates a new object (Ellipse). In this case the
representation of Circle can be any.

>And this whole "isa" business is just a matter of what
>methods the classes implement. A Circle "isa" Ellipse
>as long as the interface doesn't include changing the
>axes.

Circle is substitutable in all in-methods of Ellipse. But does it mean
that we should not use out-methods? Consider:

subtype Non_Negative is Float range 0.0..Float'Last;

Would you reimplement "-" for Non_Negative just because Non_Negative
is not "isa" Float? [the result of "-" is an out-parameter] Surely
not, you would just catch Constraint_Error as necessary.

>I think the main problem is that people are
>thinking instead of programming.

(:-)) IMO the main problem that people are programming without
thinking!

>What is going on here
>is the fundamental mistake of OO systems, which is
>imagining that these things that you are writing in
>order to get a computer program to produce a useful
>result have all the properties of the things whose
>names they bear, rather than the tiny subset which is
>implemented.

Absolutely. LSP cannot be enforced in all contexts.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Now, consider that this additional code not just shifts
> a reference, but creates a new object (Ellipse).

I suppose a language could define this copy-in/copy-out
stuff with conversions. I don't know how useful it would
be, but I guess I could be convinced with a compelling
example. I would point out that this is completely
orthogonal to OO. That is, the only relationship that
needs to exist between the two types is for them to be
interconvertible. That you want this implies that you
are a secret C++ programmer :-)

> subtype Non_Negative is Float range 0.0..Float'Last;
> 
> Would you reimplement "-" for Non_Negative just because Non_Negative
> is not "isa" Float?

I'm a little puzzled. I would try to arrange for "-" NN -> NN
to be undefined, and for "-" NN -> Float to have its obvious
meaning. I don't know what Ada allows in this case, but that's
what I want.

> Surely not, you would just catch Constraint_Error as necessary.

Surely not, why would I want exceptions raised at run-time for
errors that should be prevented at compile-time?

> Absolutely. LSP cannot be enforced in all contexts.

I don't think you grasped my meaning. I mean that LSP should be
decided based on the implemented properties of the programmed
objects, not on the abstract or real-world objects that they
(partially) model. You can group your properties into subsets,
which become interfaces, and then code which operates on these
objects can choose to receive the smallest set of interfaces
that it needs. I think this is why the C++ template model is so
appealing. C++ template functions *automatically* require only
the properties they actually use, so you don't need to do an
a priori factorization of properties into subsets. I know you
object to the fact that the set of used properties is specified
only implicitly, and is therefore subject to accidental change,
but the positive side is there as well.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Thu, 30 Jan 2003 09:59:42 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Now, consider that this additional code not just shifts
>> a reference, but creates a new object (Ellipse).
>
>I suppose a language could define this copy-in/copy-out
>stuff with conversions. I don't know how useful it would
>be, but I guess I could be convinced with a compelling
>example.

Consider Unbounded_String, Bounded_String, String. Why one cannot be a
subtype of another? In my view it is very reasonable, because all of
them are in fact just different representation of the same concept of
"array of characters". And a representation has to be no issue.

>I would point out that this is completely
>orthogonal to OO.

No, it is an extension of OO and ADT. It is a simple consequence of
the principle that interface and implementation have to be separated. 

>That is, the only relationship that
>needs to exist between the two types is for them to be
>interconvertible.

This what you require by saying:

class Circle : public Ellipse.

namely that Circle is convertible to Ellipse and back. The conversions
might be empty, but it is more general approach to think that they are
always present.

>That you want this implies that you
>are a secret C++ programmer :-)

C++ defines some conversion of this type, but it does not allow me to
define my own type relations. The former is bad because, I do not want
these conversions. The latter is just OO.

>> subtype Non_Negative is Float range 0.0..Float'Last;
>> 
>> Would you reimplement "-" for Non_Negative just because Non_Negative
>> is not "isa" Float?
>
>I'm a little puzzled. I would try to arrange for "-" NN -> NN
>to be undefined, and for "-" NN -> Float to have its obvious
>meaning. I don't know what Ada allows in this case, but that's
>what I want.

Well, but "-" has covariant result, so either you immediately violate
LSP with the consequence that NN will be unusable, or like Ada does,
define "-": NN x NN -> NN in a most reasonable way.

>> Surely not, you would just catch Constraint_Error as necessary.
>
>Surely not, why would I want exceptions raised at run-time for
>errors that should be prevented at compile-time?

Because, you cannot detect all substitutability violations at
compile-time. You might well define "-" contravariant, but this
medicine is even worse than the illnes.

>> Absolutely. LSP cannot be enforced in all contexts.
>
>I don't think you grasped my meaning. I mean that LSP should be
>decided based on the implemented properties of the programmed
>objects, not on the abstract or real-world objects that they
>(partially) model. You can group your properties into subsets,
>which become interfaces, and then code which operates on these
>objects can choose to receive the smallest set of interfaces
>that it needs. I think this is why the C++ template model is so
>appealing. C++ template functions *automatically* require only
>the properties they actually use, so you don't need to do an
>a priori factorization of properties into subsets. I know you
>object to the fact that the set of used properties is specified
>only implicitly, and is therefore subject to accidental change,
>but the positive side is there as well.

This could be an option if the software were never modified. In the
real world you would like to have as much compile-time checks as
possible, even for errors which will never occur in the given version
of the program. You never know in which direction the code will
evolve. And there is no better mechanism for compile-time checks than
the type system.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Consider Unbounded_String, Bounded_String, String. Why one cannot be a
> subtype of another? In my view it is very reasonable, because all of
> them are in fact just different representation of the same concept of
> "array of characters". And a representation has to be no issue.

You see, that's exactly what I'm talking about. You get lost
because you're thinking about "concepts" instead of the nuts
and bolts of the string types themselves. Ada is not an OO
language in its entirety, and some of those strings are just
arrays, so you're not going to get subtyping in the way you
want. If there are operations common to all types, you should
be able to capture that in generics.

> No, it is an extension of OO and ADT. It is a simple consequence of
> the principle that interface and implementation have to be separated. 

I don't see that at all. You want language support for the
notion that if an object of type A can be converted to an
object of type B, and vice versa, than a function which
operates on one should automatically operate on the other
using convert-in/convert-out. I do not see at all what this
has to do with any of OO, ADT, or separation.

> This what you require by saying:
> class Circle : public Ellipse.
> namely that Circle is convertible to Ellipse and back.

No one else thinks that this is what A : B means, though.
You would be better off if you stopped trying to overload
everyone's understanding of inheritance with a new concept
that no one associates with that.

> C++ does not allow me to define my own type relations.

Well, not for convert-in/convert-out, but plenty else.
To do what you want, you can do

struct A
{
     struct BehaveLikeB : B
     {
         A &object;
         BehaveLikeB(A &o) : object(o) { }
         // Implement B methods, affecting A object
     };
     BehaveLikeB likeB;
     A() : likeB(*this) { }
     B &asB() { return likeB; }
};

void foo(B &);
A anA;
foo(anA.asB());

> define "-": NN x NN -> NN in a most reasonable way.

Oh, sorry about that. For some reason my brain was saying
unary minus, not subtraction. Yes, for subtraction throwing
a constraint error is the way to go.

> This could be an option if the software were never modified. In the
> real world you would like to have as much compile-time checks as
> possible, even for errors which will never occur in the given version
> of the program. You never know in which direction the code will
> evolve. And there is no better mechanism for compile-time checks than
> the type system.

But the template system gives you complete type safety,
and compile-time checks! If you modify the code to use
an unavailable operation, the compiler will tell you.
All your method does is add an additional set of things
that the types must be able to do even though the code
doesn't need those operations. It is no more future-
proof than the template version, because you do not know
for sure that you will never need to add methods to the
interface.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Thu, 30 Jan 2003 12:58:27 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Consider Unbounded_String, Bounded_String, String. Why one cannot be a
>> subtype of another? In my view it is very reasonable, because all of
>> them are in fact just different representation of the same concept of
>> "array of characters". And a representation has to be no issue.
>
>You see, that's exactly what I'm talking about. You get lost
>because you're thinking about "concepts" instead of the nuts
>and bolts of the string types themselves. Ada is not an OO
>language in its entirety, and some of those strings are just
>arrays, so you're not going to get subtyping in the way you
>want.

I never said that Ada can this.

>If there are operations common to all types, you should
>be able to capture that in generics.

Of course no. Generics are unable to make String a subtype of
Unbounded_String.

>> No, it is an extension of OO and ADT. It is a simple consequence of
>> the principle that interface and implementation have to be separated. 
>
>I don't see that at all. You want language support for the
>notion that if an object of type A can be converted to an
>object of type B, and vice versa,

Any OO language does this.

> than a function which
>operates on one should automatically operate on the other

Only if it is inherited.

>using convert-in/convert-out.

Ada does this.

>I do not see at all what this
>has to do with any of OO, ADT, or separation.

The point was that subtyping relation and substitutablity have nothing
to do with the representation of the objects. As expected, if you
separate interface and implementation.

>> This what you require by saying:
>> class Circle : public Ellipse.
>> namely that Circle is convertible to Ellipse and back.
>
>No one else thinks that this is what A : B means, though.
>You would be better off if you stopped trying to overload
>everyone's understanding of inheritance with a new concept
>that no one associates with that.

Where you see a new concept? Circle and Ellise are two different
types. So if you want make an Ellipse out of a Circle you must convert
it. In Ada such conversions are called view-conversions.

>> define "-": NN x NN -> NN in a most reasonable way.
>
>Oh, sorry about that. For some reason my brain was saying
>unary minus, not subtraction. Yes, for subtraction throwing
>a constraint error is the way to go.

Now tell me why for SetAxis : Circle x R x R -> Circle it is not
reasonable to throw an exception? Do not you see that NN vs. Float is
same as Circle vs. Ellipse? In both cases you produce a new [sub]type
by constraining the base type. This says nothing about the
representation of both.

>> This could be an option if the software were never modified. In the
>> real world you would like to have as much compile-time checks as
>> possible, even for errors which will never occur in the given version
>> of the program. You never know in which direction the code will
>> evolve. And there is no better mechanism for compile-time checks than
>> the type system.
>
>But the template system gives you complete type safety,
>and compile-time checks! If you modify the code to use
>an unavailable operation, the compiler will tell you.
>All your method does is add an additional set of things
>that the types must be able to do even though the code
>doesn't need those operations. It is no more future-
>proof than the template version, because you do not know
>for sure that you will never need to add methods to the
>interface.

Sort of:

template <double X> double sine () { return X; }
//
// Works pretty well, as long X is close to zero
//

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Of course no. Generics are unable to make String a subtype of
> Unbounded_String.

Ada generics, which labor under the restriction of needing to
specify things about the types on which they operate, not C++
templates, which work as long as used operations are supported.

> Any OO language does this.

Ada does not, C++ does not, I don't know for sure but I think
Eiffel does not. Smalltalk, maybe?

> Only if it is inherited.

Why? Since you're converting, what possible relevance is there
to requiring that the operation be present in both types?

> Ada does this.

Really? It does convert-in/convert-out of different types?
I've never seen that before. Can you show me sample code?

> Where you see a new concept? Circle and Ellise are two different
> types. So if you want make an Ellipse out of a Circle you must convert
> it. In Ada such conversions are called view-conversions.

As I said, no one else sees it this way. The normal OO view of
things is that if type B inherits from type A, then an object
of type B is also of type A. No conversion is required - the
object is already all of its base types.

> Now tell me why for SetAxis : Circle x R x R -> Circle it is not
> reasonable to throw an exception? Do not you see that NN vs. Float
> is same as Circle vs. Ellipse?

It is reasonable to do so if you must have your Circle put into
places that expect modifiable Ellipses. But I believe the general
feeling is that having subtypes which restrict the legality of
parent operations in this way is not good design. I suppose
Eiffel fans will disagree with this, since they seem to love the
idiom of inheriting operations but only allowing the new subtype
as an argument. Shudder. Java uses this style as well, with all
sorts of operations in subtypes throwing not-implemeneted exceptions.

> Sort of:
> template <double X> double sine () { return X; }
> // Works pretty well, as long X is close to zero

Actually, C++ template parameters can't be doubles, but why is
this any worse, or different, than

#include <iostream>
#include <cmath>

struct SineInterface
{ virtual double operator()(double) const = 0; };
struct SmallSine : SineInterface
{ double operator()(double x) const { return x; } };
struct RealSine : SineInterface
{ double operator()(double x) const { return std::sin(x); } };

void UsesSine(const SineInterface &si1, const SineInterface &si2)
{
     for (double x = 0; x < 1e-5; x += 1e-7)
         std::cout << x << ' ' << si1(x) << ' ' << si2(x) << '\n';
}

int main()
{
     UsesSine(SmallSine(), RealSine());
}

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Fri, 31 Jan 2003 10:02:15 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Of course no. Generics are unable to make String a subtype of
>> Unbounded_String.
>
>Ada generics, which labor under the restriction of needing to
>specify things about the types on which they operate, not C++
>templates, which work as long as used operations are supported.

I do not see how this would make one substitutable for another.

>> Any OO language does this.
>
>Ada does not, C++ does not, I don't know for sure but I think
>Eiffel does not. Smalltalk, maybe?

Thunk code.

>> Only if it is inherited.
>
>Why? Since you're converting, what possible relevance is there
>to requiring that the operation be present in both types?

I do not want flawed implicit type conversions. I want sub- and
supertyping. If an implementation of sub-/supertyping is based on some
conversions, I do not care.

>> Ada does this.
>
>Really? It does convert-in/convert-out of different types?
>I've never seen that before. Can you show me sample code?

procedure Query (X : in out Float);
  -- The initial value is used as a default
...
   I : Integer := 10;
begin
   Query (Float (I));

>> Where you see a new concept? Circle and Ellise are two different
>> types. So if you want make an Ellipse out of a Circle you must convert
>> it. In Ada such conversions are called view-conversions.
>
>As I said, no one else sees it this way. The normal OO view of
>things is that if type B inherits from type A, then an object
>of type B is also of type A.

A given object may have only one type.

>No conversion is required - the
>object is already all of its base types.

Sure? Try this:

class A { public : int A_Field; };
class B { public : int B_Field; };
class C : public A, public B (};

A X;
C Y;

memcpy (&X, &Y, sizeof (Y));

If C is A why memcpy does not work?

>> Now tell me why for SetAxis : Circle x R x R -> Circle it is not
>> reasonable to throw an exception? Do not you see that NN vs. Float
>> is same as Circle vs. Ellipse?
>
>It is reasonable to do so if you must have your Circle put into
>places that expect modifiable Ellipses. But I believe the general
>feeling is that having subtypes which restrict the legality of
>parent operations in this way is not good design.

I do not belive you, because the whole science is built using the
principle of specialization by constraining. You could send a proposal
to ARG to remove things like:

subtype Positive is Integer range 0..Integer'Last;

from Ada, but I do not think it will gain much support. (:-))

>I suppose
>Eiffel fans will disagree with this, since they seem to love the
>idiom of inheriting operations but only allowing the new subtype
>as an argument. Shudder. Java uses this style as well, with all
>sorts of operations in subtypes throwing not-implemeneted exceptions.

Unfortunately there is no way out. An ability to constrain has its
price.

>> Sort of:
>> template <double X> double sine () { return X; }
>> // Works pretty well, as long X is close to zero
>
>Actually, C++ template parameters can't be doubles, but why is
>this any worse, or different, than
>
>#include <iostream>
>#include <cmath>
>
>struct SineInterface
>{ virtual double operator()(double) const = 0; };
>struct SmallSine : SineInterface
>{ double operator()(double x) const { return x; } };
>struct RealSine : SineInterface
>{ double operator()(double x) const { return std::sin(x); } };
>
>void UsesSine(const SineInterface &si1, const SineInterface &si2)
>{
>     for (double x = 0; x < 1e-5; x += 1e-7)
>         std::cout << x << ' ' << si1(x) << ' ' << si2(x) << '\n';
>}
>
>int main()
>{
>     UsesSine(SmallSine(), RealSine());
>}

It is not better. My point was: we should check as much as possible at
compile-time. Your point was: we should check only things actually
used in the given program, as templates do. I gave you an example why
it is a bad idea. You responded with another example. So the point
stands.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> I do not see how this would make one substitutable for another.

This makes it possible to write code that works seamlessly with
the different kinds of string, as long as the operations used
are common to all of them. In C++ you just write your generic
method, and the compiler instantiates it for the types you
supply, without you having to tell it anything.

> Thunk code.

Huh? What does this mean? That thunk code needs to be generated
to do what you want? I know that. But things don't work this
way in Ada, C++, or Java, at least as far as I know about Ada.

> I do not want flawed implicit type conversions. I want sub- and
> supertyping. If an implementation of sub-/supertyping is based
 > on some conversions, I do not care.

But as I keep repeating, your concept of sub/supertyping is at odds
with the general understanding of this. When you describe what you
want, it looks like two-way type conversion is the only thing that
is necessaery, so it is natural to ask why inheritance should be
involved in this at all.

> procedure Query (X : in out Float);
>   -- The initial value is used as a default
> ...
>    I : Integer := 10;
> begin
>    Query (Float (I));

Cool. More stuff I didn't know about Ada. But to quote from the Ada RM,
     "If the target type is tagged, then an assignment to the view
      assigns to the corresponding part of the object denoted by
      the operand;"
so as I've been saying, Ada follows the conventional view that an
object is its base type(s), without any conversions needed. The
view conversion for a tagged type just winds up pointing at the
appropriate subobject.

Hmm. the same section continues
     "otherwise, an assignment to the view assigns to the object,
      after converting the assigned value to the subtype of the
      object (which might raise Constraint_Error);"

Ada experts - does this mean that each time the Query routine
above assigns a value to X it has to know that X is really a
view conversion of I, and check for error? Or can it just do
the check once at copy-out time? The former would seem to add
draconian complexity to subroutines.

> A given object may have only one type.

Says who?

> If C is A why memcpy does not work?

Because memcpy yields undefined behavior when copying
C++ objects around. On the other hand, X = Y will work
perfectly fine.

> subtype Positive is Integer range 0..Integer'Last;

You know, I used to think that C++ could benefit from having
Ada-like subranges. Thanks for opening my eyes :-)

> It is not better. My point was: we should check as much as possible at
> compile-time. Your point was: we should check only things actually
> used in the given program, as templates do. I gave you an example why
> it is a bad idea. You responded with another example. So the point
> stands.

I think I failed to understand your example, then.
You say that we should check as much as possible at
compile-time, but what does that mean? Perhaps I
should require that my types all be able to dance a
soft-shoe number, in case I have to give a demo of
my code to executives? You claim that there is benefit
in requiring that types support unused operations. I
don't see what that benefit is, or where you cut off
the infinite list of possible operations that a type
could conceivably support.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Fri, 31 Jan 2003 12:11:03 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> I do not see how this would make one substitutable for another.
>
>This makes it possible to write code that works seamlessly with
>the different kinds of string, as long as the operations used
>are common to all of them. In C++ you just write your generic
>method, and the compiler instantiates it for the types you
>supply, without you having to tell it anything.

In this case the types a siblings, not subtypes.

BTW generics give us an example of substituatability independent on
the type representation. Consider a generic function:

generic
   type X is private;
procedure Foo (Arg : X);

Here, any "private" is substitutable for Arg. I can be Integer, Float,
almost everything.

>> Thunk code.
>
>Huh? What does this mean? That thunk code needs to be generated
>to do what you want?

To make view conversion when an inherited method is called.

> I know that. But things don't work this
>way in Ada, C++, or Java, at least as far as I know about Ada.
>
>> I do not want flawed implicit type conversions. I want sub- and
>> supertyping. If an implementation of sub-/supertyping is based
> > on some conversions, I do not care.
>
>But as I keep repeating, your concept of sub/supertyping is at odds
>with the general understanding of this. When you describe what you
>want, it looks like two-way type conversion is the only thing that
>is necessaery, so it is natural to ask why inheritance should be
>involved in this at all.

It is inheritance in my view. If there are two things present for a
method and a type:

1) substitutability (conversions is a way to provide it) 
2) automatic substitution [by the compiler]

then I say that the method is inherited by the type.

>> procedure Query (X : in out Float);
>>   -- The initial value is used as a default
>> ...
>>    I : Integer := 10;
>> begin
>>    Query (Float (I));
>
>Cool. More stuff I didn't know about Ada. But to quote from the Ada RM,
>     "If the target type is tagged, then an assignment to the view
>      assigns to the corresponding part of the object denoted by
>      the operand;"
>so as I've been saying, Ada follows the conventional view that an
>object is its base type(s), without any conversions needed. The
>view conversion for a tagged type just winds up pointing at the
>appropriate subobject.

"just winds up pointing" *is* a conversion. Imagine that other sorts
were allowed too!

>Hmm. the same section continues
>     "otherwise, an assignment to the view assigns to the object,
>      after converting the assigned value to the subtype of the
>      object (which might raise Constraint_Error);"
>
>Ada experts - does this mean that each time the Query routine
>above assigns a value to X it has to know that X is really a
>view conversion of I, and check for error? Or can it just do
>the check once at copy-out time? The former would seem to add
>draconian complexity to subroutines.

You can do conversions at a call point. That is the whole idea of
substitutability. The "inherited" method remains same. You just
compose it with apporipriate conversions to and back.

>> A given object may have only one type.
>
>Says who?

Me, is that matter? (:-))

There could be many type theories, but the simpliest one is to require
that there is only one type of a given value.

>> If C is A why memcpy does not work?
>
>Because memcpy yields undefined behavior when copying
>C++ objects around. On the other hand, X = Y will work
>perfectly fine.

Then you should explain what "is a" does mean. It is definitely not
mathematical =, as memcpy shows.

It is rather a sort of equivalence. Equivalence in OO is defined as
substitutability, which does not necessarily imply equality. So C is
not A, C is only substitutable for A, i.e. it is an equivalent to A.

>> subtype Positive is Integer range 0..Integer'Last;
>
>You know, I used to think that C++ could benefit from having
>Ada-like subranges. Thanks for opening my eyes :-)
>
>> It is not better. My point was: we should check as much as possible at
>> compile-time. Your point was: we should check only things actually
>> used in the given program, as templates do. I gave you an example why
>> it is a bad idea. You responded with another example. So the point
>> stands.
>
>I think I failed to understand your example, then.
>You say that we should check as much as possible at
>compile-time, but what does that mean? Perhaps I
>should require that my types all be able to dance a
>soft-shoe number, in case I have to give a demo of
>my code to executives? You claim that there is benefit
>in requiring that types support unused operations. I
>don't see what that benefit is, or where you cut off
>the infinite list of possible operations that a type
>could conceivably support.

If you define a type, say, "field". Then you should implement all
operations of the field. Otherwise, it is not a field, but a group or
something else. So the users of your type would have no delusions
about it. If it has interface of a group, why to present it as field?
It is just DbC. Ada gives an example of this approach: when you derive
from an abstract type, the derived non-abstract type has to implement
all abstract operations, no matter whether some of them will never be
used. Failure to do that is a *compile-time* error. Same thing with
C++ templates produces a "valid" program! (Ada generics are safer in
this respect)

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Then you should explain what "is a" does mean. It is definitely not
> mathematical =, as memcpy shows.

Memcpy is not a "mathematical =" but a procedure which copies
a bunch of bytes in memory. You won't like my explanation of
"is a" becuase it's purely practical - "B is a A" means that
a pointer or reference to A may hold a pointer or reference to
an object of type B (or a type which "is a B") and may call
methods of A using that pointer or reference.

> If you define a type, say, "field".

But we are not talking about defining a type, but about
defining a procedure. This procedure defines an interface
implicitly by virtue of the operations it uses. You then
claim that this implicit interface needs to be augmented
with operations that the procedure doesn't need, and then
that types upon which the procedure operates need to have
these useless operations, and that this somehow achieves
safety! I am just baffled.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 03 Feb 2003 08:26:33 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Then you should explain what "is a" does mean. It is definitely not
>> mathematical =, as memcpy shows.
>
>Memcpy is not a "mathematical =" but a procedure which copies
>a bunch of bytes in memory. You won't like my explanation of
>"is a" becuase it's purely practical - "B is a A" means that
>a pointer or reference to A may hold a pointer or reference to
>an object of type B (or a type which "is a B") and may call
>methods of A using that pointer or reference.

But this is an unsatisfactory definition. It involves pointers and
references, you have to define what they are. You have to admit that
your "is a" does not work if there are no pointers. Is an integer in a
register "is a" an integer in the memory, on a remote host? What does
it mean "may call". In FORTRAN-IV you may call a function passing
INTEGER*4 instead of REAL.*4!

It is much simplier just to say an instance of B is substitutable for
a parameter where A is required. With further clarification what
"substitutable" means.

>> If you define a type, say, "field".
>
>But we are not talking about defining a type, but about
>defining a procedure.

But each procedure is related to the type of its parameters. Then a
type is a set of values and operations on them. So to define a type is
to define these operations as well.

>This procedure defines an interface
>implicitly by virtue of the operations it uses.

This clearly violates DbC principle. The only contract of the
procedure is that it takes an object of some known type [+ possibly
pre- and postconditions]. The type of the object determines all
operations the procedure may use. If you restrict this set of
operation and want to expose this fact, then it is *another* type.

>You then
>claim that this implicit interface needs to be augmented
>with operations that the procedure doesn't need, and then
>that types upon which the procedure operates need to have
>these useless operations, and that this somehow achieves
>safety! I am just baffled.

They are not useless, they constitute the type. That's the point.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But this is an unsatisfactory definition.

It satisfies me, so it is not unsatisfactory for everyone.

> It involves pointers and references, you have to define what they are.

A (data) pointer is an object which holds the address of another object,
where "address" is an implementation-defined value which identifies one
particular object and no other. A reference is an alternate name for
an object. References and pointers are declared with a type which limits
the objects to which they may refer.

> You have to admit that your "is a" does not work if there are no pointers.

Fortunately, the programming language which I use has pointers.

> Is an integer in a register "is a" an integer in the memory, on a remote host?

I don't care, as C++ regards integers as primitive types.
I have no interest at all in philosophical "is a", only
in methods of programming.

> What does it mean "may call".

In C++, it means that the pointer may appear to the left of a '->'
and the reference to the left of a '.', with the right-hand side
looking like a call - that is, a method name defined in the class
which is the static type of the pointer or reference or one of its
base classes, followed by parenthesized arguments.

> In FORTRAN-IV you may call a function passing
> INTEGER*4 instead of REAL.*4!

How nice for FORTRAN-IV.

> It is much simplier just to say an instance of B is substitutable for
> a parameter where A is required. With further clarification what
> "substitutable" means.

If it was much simpler we wouldn't be having this little chat.

> But each procedure is related to the type of its parameters.

Not for generics.

> This clearly violates DbC principle.

If I attempt to instantiate a generic procedure with a type
which does not support the operations used, the code will
not even compile. How in the world can this be construed as
violating DbC?

> The only contract of the procedure is that it takes
 > an object of some known type

Who made you God of what a contract is? Why is a set of
required operations a worse contract than a type?

> If you restrict this set of operation and want to expose
 > this fact, then it is *another* type.

Correct. But it would be mind-numbingly tedious to have to
name these types, and modify all the used types to adopt
the new interface, and to make adapters for the fundamental
types, and fortunately C++ doesn't require it.
In Ada, because of lack of MI, it wouldn't work at all.

> They are not useless, they constitute the type. That's the point.

They are useless because the procedure doesn't need them.
Why must the procedure specify that its parameters are
required to have operations that won't be used? What is
to limit this infinite set of possible but unused operations?

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 03 Feb 2003 12:00:55 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> But this is an unsatisfactory definition.
>
>It satisfies me, so it is not unsatisfactory for everyone.

OK, I knew people who made global weather simulation assuming that the
planet Earth is flat. (:-))

>> It involves pointers and references, you have to define what they are.
>
>A (data) pointer is an object which holds the address of another object,
>where "address" is an implementation-defined value which identifies one
>particular object and no other. A reference is an alternate name for
>an object. References and pointers are declared with a type which limits
>the objects to which they may refer.

What is the type of a pointer/reference? You have just started and
already you have two sorts of citizens: objects that are pointers and
objects that are not.

How your definition would answer a very simple question whether a
pointer to A is a subtype of A? In Ada an access type of an array is
very much a subtype of the array, because it inherits the indexing
operation:

type A is array (Integer range <>) of Element_Type;
type A_Ptr is access A;

X : A_Ptr := ...;

X (3..6) -- This is legal in Ada.

What if some new language or even Ada, would push this idea further
and make all type operations transparent for pointers?

>> You have to admit that your "is a" does not work if there are no pointers.
>
>Fortunately, the programming language which I use has pointers.

Not every object can be accessed through a pointer. Your definition is
inconsistent with that. If I did not define an access type, then I
loose subtyping relation? If the object is a bit in a packed array,
then it is no more object?

>> Is an integer in a register "is a" an integer in the memory, on a remote host?
>
>I don't care, as C++ regards integers as primitive types.
>I have no interest at all in philosophical "is a", only
>in methods of programming.

Integer is a type. It is no matter whether it is primitive or not. To
be "practical", your theory should work for all types.

>> What does it mean "may call".
>
>In C++, it means that the pointer may appear to the left of a '->'
>and the reference to the left of a '.', with the right-hand side
>looking like a call - that is, a method name defined in the class
>which is the static type of the pointer or reference or one of its
>base classes, followed by parenthesized arguments.

X * Ptr = 0;

Ptr->Foo ();

Here we may call, hence that incredible thing, which a null-pointer
points to, is a subtype of X?

>> In FORTRAN-IV you may call a function passing
>> INTEGER*4 instead of REAL.*4!
>
>How nice for FORTRAN-IV.

But not for your theory. FORTRAN-IV does no type checks. So you may
call, but the result is nonsense. May call /= substitutable.

>> It is much simplier just to say an instance of B is substitutable for
>> a parameter where A is required. With further clarification what
>> "substitutable" means.
>
>If it was much simpler we wouldn't be having this little chat.
>
>> But each procedure is related to the type of its parameters.
>
>Not for generics.

Wrong. A generic procedure is polymorphic, so the type of its
parameter (if it is a formal generic type) is not a specific type, but
a type type. In C++ it is <class X> which denotes "set of any types
which would go through the compiler", in Ada there are "private", "mod
<>, "range <>" etc.

>> This clearly violates DbC principle.
>
>If I attempt to instantiate a generic procedure with a type
>which does not support the operations used, the code will
>not even compile. How in the world can this be construed as
>violating DbC?

I didn't say that. I said that the idea that a type could be defined
by a set of operations used in some [generic] body, is a bad one, and
then it contradics to DbC, separating interface and implementation and
number of other principles considered valuable for software
development.

>> The only contract of the procedure is that it takes
> > an object of some known type
>
>Who made you God of what a contract is? Why is a set of
>required operations a worse contract than a type?

It is not worse it is same. A set of required operations defines a
type. This type has to be *explicitly* specified. You propose to do
this *implicitly* by the fact of using some of the operations in some
bodies. It is no more a contract, if implementation details get
involved. It is not a contract because no specification even exists.
Moreover if you would still claim that this a contract, you would be
unable to verify this "contract", because to check whether an
operation is required is a halting problem. This is typical for C++,
to use very simple, "practical" [at first look] ideas, which lead to a
mess if you dig just a bit deeper.

>> If you restrict this set of operation and want to expose
> > this fact, then it is *another* type.
>
>Correct. But it would be mind-numbingly tedious to have to
>name these types, and modify all the used types to adopt
>the new interface, and to make adapters for the fundamental
>types, and fortunately C++ doesn't require it.

Huh, I remeber people claiming that it is tedious to declare an
object, because the compiler has a nice rule that everything that has
a name starting with I, J, K, L, M is an INTEGER.

>In Ada, because of lack of MI, it wouldn't work at all.

MI is nice to have, but it would not solve this. Operation disallowing
could. However in most cases, one need just a careful software design
instead of usual quick'n'dirty, which would be better to call "no more
quick, but still dirty".

>> They are not useless, they constitute the type. That's the point.
>
>They are useless because the procedure doesn't need them.
>Why must the procedure specify that its parameters are
>required to have operations that won't be used? What is
>to limit this infinite set of possible but unused operations?

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

Re: Anybody in US using ADA ? One silly idea..

[Colin Paul Gloster]

Dmitry A. Kazakov wrote:
"On Mon, 03 Feb 2003 12:00:55 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
[..]  
>In Ada, because of lack of MI, it wouldn't work at all.

MI is nice to have, but it would not solve this. Operation disallowing
could. However in most cases, one need just a careful software design
instead of usual quick'n'dirty, which would be better to call "no more
quick, but still dirty".

Or 'not quicker but dirtier'. (:

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> What is the type of a pointer/reference?

"Pointer to OtherType"/"Reference to OtherType"

> You have just started and already you have two sorts  of citizens:
 > objects that are pointers and objects that are not.

Yes, so? Obviously, as soon as you define any static type, you will
have objects which are of that type and objects which are not.

> How your definition would answer a very simple question whether a
> pointer to A is a subtype of A?

It will answer "no"? Pointers are never (OO) subtypes of anything.

> What if some new language or even Ada, would push this idea further
> and make all type operations transparent for pointers?

Then there would be an implicit dereference of the pointer before
the operation is applied. There is no reason to impute all of the
operations to the pointer itself.

> Not every object can be accessed through a pointer.

Correct for the usual definition of pointer on typical hardware.

> Your definition is inconsistent with that.

No.

> If I did not define an access type, then I lose subtyping relation?

Not exactly. If you are not using a pointer or reference to an object,
then you are simply using the object itself. Then you know its actual
most-derived type, and its full set of available operations. If you
invoke an operation of one of its base classes, then when the compiler
calls that method, it will pass in a pointer to the base subobject and
then you are back in pointer-land. In C++, you get your pointers for
free :-)

> If the object is a bit in a packed array, then it is no more object?

Correct. In fact, the C++ standard library specifies a specialization
for vector<bool> that works that way, giving sub-byte access. This is
universally considered to be a mistake. The reason to consider such
bits as second-class citizens is for simplicity of implementation. You
could force the definition of bit-level pointers, and classes that took
only four bits of space and so forth, but that doesn't map neatly onto
typical hardware, so the C and C++ approach is not to do that. If it
messes up someone's abstract ideas, too bad.

> Integer is a type. It is no matter whether it is primitive or not. To
> be "practical", your theory should work for all types.

I don't have a theory. If I write code that does operations on an
integer, the compiler generates assembly language that does the
work.

> X * Ptr = 0;
> Ptr->Foo ();

There are semantic restrictions on pointers that make the above illegal.
I can quote C++ standardese at you about when a pointer is derefernceable,
but I don't see what that has to do with anything.

> But not for your theory. FORTRAN-IV does no type checks. So you may
> call, but the result is nonsense. May call /= substitutable.

That's nice. Why am I supposed to care about FORTRAN? I don't have a
theory. I haven't defined substitutable.

> I didn't say that. I said that the idea that a type could be defined
> by a set of operations used in some [generic] body, is a bad one, and
> then it contradics to DbC, separating interface and implementation and
> number of other principles considered valuable for software
> development.

That's a matter of opinion. The clear utility of this approach in C++
is an argument against your claim. I don't use DbC, it's not clear to
me that meaningful contracts can be specified for complex tasks, and
I don't care at all about abstract theories of how to program. I think
that contracts have exactly the same problems as correctness proofs and
similar ideas, namely that the statement of what you want is exactly as
complex as the problem you're trying to solve, and therefore is exactly
as likely to be incorrect as the program itself.

> Huh, I remeber people claiming that it is tedious to declare an object

In C++ there would also be the additional complexity of defining how
a set of operations could be defined, because of all the overloading
and implicit conversion rules. A simple "a + b" can mean a large number
of different things depending oon the types involved. Whether that's
good or bad, it is nevertheless an additional obstacle which prevents
such "operation contracts" (C++ gurus call them "concept checks") from
being required.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 04 Feb 2003 10:56:30 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> What is the type of a pointer/reference?
>
>"Pointer to OtherType"/"Reference to OtherType"

Is pointer to other type a type? If yes, then your definition has to
define what does it mean to be a subtype of a pointer object. Which
would produce pointers to pointers. The next round will give us
pointers to pointers to pointers. Etc.

>> You have just started and already you have two sorts  of citizens:
> > objects that are pointers and objects that are not.
>
>Yes, so? Obviously, as soon as you define any static type, you will
>have objects which are of that type and objects which are not.

But staticness has no impact on my definition of subtyping. While
according to your definition, static objects cannot be subtypes,
because there cannot be pointers to most of them, especially to ones
eliminated by the compiler.

>> How your definition would answer a very simple question whether a
>> pointer to A is a subtype of A?
>
>It will answer "no"? Pointers are never (OO) subtypes of anything.

Really? In Ada:

type A is access all B;
subtype Sub_A is A;

Now you will say that this is not OO. (:-)) Fine, here is OO:

type A is access all B'Class;
type Sub_A is access all B;

>> What if some new language or even Ada, would push this idea further
>> and make all type operations transparent for pointers?
>
>Then there would be an implicit dereference of the pointer before
>the operation is applied. There is no reason to impute all of the
>operations to the pointer itself.

I see no difference. If an operation can be applied to the pointer
then it is an operation on the pointer, then pointer is a subtype.

>> Not every object can be accessed through a pointer.
>
>Correct for the usual definition of pointer on typical hardware.
>
>> Your definition is inconsistent with that.
>
>No.

?

>> If I did not define an access type, then I lose subtyping relation?
>
>Not exactly. If you are not using a pointer or reference to an object,
>then you are simply using the object itself.

Unlike C++, Ada can class-wide objects on the stack. So one can have
dispatch even for "objects itself":

declare
   X : A'Class := Read;
begin
   Foo (X); -- This dispatches

>Then you know its actual
>most-derived type, and its full set of available operations. If you
>invoke an operation of one of its base classes, then when the compiler
>calls that method, it will pass in a pointer to the base subobject and
>then you are back in pointer-land. In C++, you get your pointers for
>free :-)
>
>> If the object is a bit in a packed array, then it is no more object?
>
>Correct. In fact, the C++ standard library specifies a specialization
>for vector<bool> that works that way, giving sub-byte access. This is
>universally considered to be a mistake. The reason to consider such
>bits as second-class citizens is for simplicity of implementation. You
>could force the definition of bit-level pointers, and classes that took
>only four bits of space and so forth, but that doesn't map neatly onto
>typical hardware, so the C and C++ approach is not to do that. If it
>messes up someone's abstract ideas, too bad.

The source of the problem above is not abstract ideas, but rather lack
of them. Which leads to two very non-abstract mistakes:

1. OO has something to do with pointers and references
2. The language (C++) has no by-copy in out parameters

>> Integer is a type. It is no matter whether it is primitive or not. To
>> be "practical", your theory should work for all types.
>
>I don't have a theory. If I write code that does operations on an
>integer, the compiler generates assembly language that does the
>work.

OK, but one should have a theory to develop a language and a compiler
for it. Even C++ is based on some theory (I suppose on a wrong one
(:-))

>> X * Ptr = 0;
>> Ptr->Foo ();
>
>There are semantic restrictions on pointers that make the above illegal.

Even better, should this mean that your definition involves program
semantics? It would be indeed very "practical" to have same code
either having subtypes or not depending on the program application
area!

>I can quote C++ standardese at you about when a pointer is derefernceable,
>but I don't see what that has to do with anything.
>
>> But not for your theory. FORTRAN-IV does no type checks. So you may
>> call, but the result is nonsense. May call /= substitutable.
>
>That's nice. Why am I supposed to care about FORTRAN? I don't have a
>theory. I haven't defined substitutable.

Thus your definition is limited by some number of chosen languages. I
suppose the set includes C++. Which language else?

>> I didn't say that. I said that the idea that a type could be defined
>> by a set of operations used in some [generic] body, is a bad one, and
>> then it contradics to DbC, separating interface and implementation and
>> number of other principles considered valuable for software
>> development.
>
>That's a matter of opinion. The clear utility of this approach in C++
>is an argument against your claim. I don't use DbC, it's not clear to
>me that meaningful contracts can be specified for complex tasks, and
>I don't care at all about abstract theories of how to program. I think
>that contracts have exactly the same problems as correctness proofs and
>similar ideas, namely that the statement of what you want is exactly as
>complex as the problem you're trying to solve, and therefore is exactly
>as likely to be incorrect as the program itself.

Fairly enough.

>> Huh, I remeber people claiming that it is tedious to declare an object
>
>In C++ there would also be the additional complexity of defining how
>a set of operations could be defined, because of all the overloading
>and implicit conversion rules. A simple "a + b" can mean a large number
>of different things depending oon the types involved. Whether that's
>good or bad, it is nevertheless an additional obstacle which prevents
>such "operation contracts" (C++ gurus call them "concept checks") from
>being required.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Is pointer to other type a type?

Yes.

> what does it mean to be a subtype of a pointer object

To the extent that it means anything at all, it reflects
the subtyping of class types. But generally, nothing.

> two very non-abstract mistakes:
> 1. OO has something to do with pointers and references
> 2. The language (C++) has no by-copy in out parameters

They are mistakes in your view, not in mine. I don't think
anything more productive will come out of this exchange.

Re: Anybody in US using ADA ? One silly idea..

[Amir Yantimirov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<mevu3v04int4alno6fms6llom6vnhlaq0i@4ax.com>...
> I didn't say that. I said that the idea that a type could be defined
> by a set of operations used in some [generic] body, is a bad one, and
> then it contradics to DbC, separating interface and implementation and
> number of other principles considered valuable for software
> development.

Agreed with that. I always see 'class X' in template specification as sort of
forward declaration. :)

One of my paragraphs: http://www174.pair.com/yamir/programming/interfaces.htm
is written directly from your discussion.

And I agreed with Hyman Rosen in a sense that C++ is perfectly consistent in it's
behaviour here.

Amir Yantimirov

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 03 Feb 2003 21:46:53 -0800, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:

>Dmitry A. Kazakov fed this fish to the penguins on Monday 03 February 
>2003 08:12 am:
>
>> it mean "may call". In FORTRAN-IV you may call a function passing
>> INTEGER*4 instead of REAL.*4!
>>
>        Every FORTRAN compiler I've worked with will give incorrect results if 
>you do that -- the internal representation of the passed integer does 
>not match that of the expected real.

Yes, this is what I meant. FORTRAN-IV did not check types, it allowed
to call everything for anything.

>        Now... practically all FORTRAN compilers supply overloaded definitions 
>for the /intrinsic/ functions, so for them you can safely pass such 
>types. The return value is not a factor as FORTRAN will implicitly 
>convert types to the highest format within the equation, and convert 
>down in needed for the assignment to the final result variable.

It is no more that FORTRAN given us by heavens! (:-))

>        User defined functions do NOT support such overloading.
> 
>> It is much simplier just to say an instance of B is substitutable for
>> a parameter where A is required. With further clarification what
>> "substitutable" means.
>>
>        My paraphrase: "An instance of B supports the full defined /interface/ 
>of A, allowing it to be used where ever an A is valid."

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

Re: Anybody in US using ADA ? One silly idea..

[Colin Paul Gloster]

Timestamped Mon, 03 Feb 2003 10:59:39 +0100,
news:2b9s3vo3bbnaikqd6d4jpppfflfq2kbgfu@4ax.com by
Dmitry A. Kazakov <mailbox@Dmitry-Kazakov.De> contains:

"On Fri, 31 Jan 2003 12:11:03 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

[..]
>[..] You claim that there is benefit                         
>in requiring that types support unused operations. I                           
>don't see what that benefit is, or where you cut off                           
>the infinite list of possible operations that a type                           
>could conceivably support.                                                     
                                                                                
If you define a type, say, "field". Then you should implement all               
operations of the field."

Yes.

"Otherwise, it is not a field, but a group or           
something else."

Yes.

"So the users of your type would have no delusions               
about it. If it has interface of a group, why to present it as field?"

Indeed. And why if it has operations you do not need, are you
defining this type and using it?

"It is just DbC. Ada gives an example of this approach: when you derive
from an abstract type, the derived non-abstract type has to implement           
all abstract operations, no matter whether some of them will never be           
used. Failure to do that is a *compile-time* error. Same thing with             
C++ templates produces a "valid" program! (Ada generics are safer in            
this respect)"

Having unused procedures (of unknown quality) is not safe.

Timestamped Mon, 03 Feb 2003 17:12:24 +0100,
news:lats3vchsfmpaqiid539c8l7q0293eelcf@4ax.com by
Dmitry A. Kazakov has:

"On Mon, 03 Feb 2003 08:26:33 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

[..]

>You then                                                                       
>claim that this implicit interface needs to be augmented                       
>with operations that the procedure doesn't need, and then                      
>that types upon which the procedure operates need to have                      
>these useless operations, and that this somehow achieves                       
>safety! I am just baffled.                                                     
                                                                                
They are not useless, they constitute the type. [..]"

There are not used therefore they are useless.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On 04 Feb 2003 10:10:25 GMT, Colin_Paul_Gloster@ACM.org (Colin Paul
Gloster) wrote:

>Timestamped Mon, 03 Feb 2003 10:59:39 +0100,
>news:2b9s3vo3bbnaikqd6d4jpppfflfq2kbgfu@4ax.com by
>Dmitry A. Kazakov <mailbox@Dmitry-Kazakov.De> contains:
>
>"On Fri, 31 Jan 2003 12:11:03 -0500, Hyman Rosen <hyrosen@mail.com>
>wrote:
>
>[..]
>>[..] You claim that there is benefit                         
>>in requiring that types support unused operations. I                           
>>don't see what that benefit is, or where you cut off                           
>>the infinite list of possible operations that a type                           
>>could conceivably support.                                                     
>                                                                                
>If you define a type, say, "field". Then you should implement all               
>operations of the field."
>
>Yes.
>
>"Otherwise, it is not a field, but a group or           
>something else."
>
>Yes.
>
>"So the users of your type would have no delusions               
>about it. If it has interface of a group, why to present it as field?"
>
>Indeed. And why if it has operations you do not need, are you
>defining this type and using it?
>
>"It is just DbC. Ada gives an example of this approach: when you derive
>from an abstract type, the derived non-abstract type has to implement           
>all abstract operations, no matter whether some of them will never be           
>used. Failure to do that is a *compile-time* error. Same thing with             
>C++ templates produces a "valid" program! (Ada generics are safer in            
>this respect)"
>
>Having unused procedures (of unknown quality) is not safe.

Any procedure of unknown quality is unsafe. A fact that a procedure is
called somewhere will not make it more or less safe. However using
stronger preconditions than necessary [i.e. requiring a type to be a
field, where just a group would be OK] is indeed a bad design and in
the end unsafe.

>Timestamped Mon, 03 Feb 2003 17:12:24 +0100,
>news:lats3vchsfmpaqiid539c8l7q0293eelcf@4ax.com by
>Dmitry A. Kazakov has:
>
>"On Mon, 03 Feb 2003 08:26:33 -0500, Hyman Rosen <hyrosen@mail.com>
>wrote:
>
>[..]
>
>>You then                                                                       
>>claim that this implicit interface needs to be augmented                       
>>with operations that the procedure doesn't need, and then                      
>>that types upon which the procedure operates need to have                      
>>these useless operations, and that this somehow achieves                       
>>safety! I am just baffled.                                                     
>                                                                                
>They are not useless, they constitute the type. [..]"
>
>There are not used therefore they are useless.

Do you remember the last time you used Arccoth? Is it useless? Should
an Ada compiler implement it as exp, because the program I am writing
at the moment does not use it?

Useless for a particular program /= useless for any possible program.

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

Re: Anybody in US using ADA ? One silly idea..

[Colin Paul Gloster]

In news:e2ev3vop3gm2gi7q3m0k3eunsluf0i4v95@4ax.com , Dmitry A. Kazakov
wrote:
"Any procedure of unknown quality is unsafe. A fact that a procedure is
called somewhere will not make it more or less safe. [..]"

Inventing a datatype when you are writing/designing a program and using
just some of its procedures (which you have just invented) does not make
them safe, but you are more likely to notice if they are incorrect than
the unused procedures.
  
"[..]
>There are not used therefore they are useless.

Do you remember the last time you used Arccoth? Is it useless? Should
an Ada compiler implement it as exp, because the program I am writing
at the moment does not use it?"

Irrelevant. I am not advocating inventing datatypes whose subprograms I
know I will definitely not all use for the problem I am trying to solve,
but which I might use in a future program.

"Useless for a particular program /= useless for any possible program."

Agreed. But if some of the subprograms are never ever used, they were a
waste of effort.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On 04 Feb 2003 14:33:31 GMT, Colin_Paul_Gloster@ACM.org (Colin Paul
Gloster) wrote:

>In news:e2ev3vop3gm2gi7q3m0k3eunsluf0i4v95@4ax.com , Dmitry A. Kazakov
>wrote:
>"Any procedure of unknown quality is unsafe. A fact that a procedure is
>called somewhere will not make it more or less safe. [..]"
>
>Inventing a datatype when you are writing/designing a program and using
>just some of its procedures (which you have just invented) does not make
>them safe, but you are more likely to notice if they are incorrect than
>the unused procedures.
>  
>"[..]
>>There are not used therefore they are useless.
>
>Do you remember the last time you used Arccoth? Is it useless? Should
>an Ada compiler implement it as exp, because the program I am writing
>at the moment does not use it?"
>
>Irrelevant. I am not advocating inventing datatypes whose subprograms I
>know I will definitely not all use for the problem I am trying to solve,
>but which I might use in a future program.
>
>"Useless for a particular program /= useless for any possible program."
>
>Agreed. But if some of the subprograms are never ever used, they were a
>waste of effort.

Yes, but the problem is that we never know for sure. So it is always
better to stay on the safe side. If the type represents some
well-known thing, then it is better to fully implement it.
Alternatively, [what I actually always wished to see in Ada], one
could make this type abstract and implement only a part of the
operations [which you will definitely use]. Then you would derive from
it an non-abstract type and disallow all the operations you do not
want. So the type will explicitly indicate the fact that some
operations are not supported.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> If the type represents some well-known thing,
 > then it is better to fully implement it.

Again. I am not building a type but an operation.
If I am building a vector template, the things that
it holds are of type "thing that can be held in a
vector". Fully implementing it menas that it has the
things needed for being held in a vector.

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Do you remember the last time you used Arccoth? Is it useless? Should
> an Ada compiler implement it as exp, because the program I am writing
> at the moment does not use it?
> 
> Useless for a particular program /= useless for any possible program.

I repeat - I am writing a procedure, not a type. That procedure takes
a parameter, and the procedure requires that the parameter supports a
certain set of operations. You want me to force that parameter to have
more operations than the procedure needs. I *still* don't understand
why. To answer your question, I have never created a type that was
required to have an Arccoth operation. I would be annoyed if, for
example, the vector class template that I use required that the type
of the held object must support Arccoth. This does not make the
Arccoth operation useless.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 04 Feb 2003 10:10:24 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Do you remember the last time you used Arccoth? Is it useless? Should
>> an Ada compiler implement it as exp, because the program I am writing
>> at the moment does not use it?
>> 
>> Useless for a particular program /= useless for any possible program.
>
>I repeat - I am writing a procedure, not a type. That procedure takes
>a parameter, and the procedure requires that the parameter supports a
>certain set of operations.

That's called precondition. However the above statement is partially
incomplete and partially wrong. It is incomplete, because it should be
"the procedure takes a parameter of the type X". It is wrong, because
parameters support no operations. It is the type X which has a set of
operations, which can be applied to parameters of the type.

Returning to the precondition,

to require a subset of operations of X <= to require X.

So your precondition is automatically satisfied by the requirement
that the parameter is of X.

>You want me to force that parameter to have
>more operations than the procedure needs.

The parameter can be used in the operations of its type. No more no
less. It is irrelevant which particular operations or values of the
type the procedure uses.

>I *still* don't understand why.

>To answer your question, I have never created a type that was
>required to have an Arccoth operation. I would be annoyed if, for
>example, the vector class template that I use required that the type
>of the held object must support Arccoth. This does not make the
>Arccoth operation useless.

Right, unused operations are still useful.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
>>I repeat - I am writing a procedure, not a type. That procedure takes
>>a parameter, and the procedure requires that the parameter supports a
>>certain set of operations.
> 
> That's called precondition.

Again, not in the same sense that most people use for this term.
When I've seen precondition used, it's always referred to a
runtime property of the object, such as "> 5" or "is sorted".

> It is incomplete, because it should be
> "the procedure takes a parameter of the type X".

But I am writing a generic procedure, so the procedure does not
specify the type of its parameter in any way other than by a
"placeholder" type name.

> It is wrong, because parameters support no operations.
 > It is the type X which has a set of operations, which
 > can be applied to parameters of the type.

I find this to be a completely vacuous distinction.

> to require a subset of operations of X <= to require X.
> So your precondition is automatically satisfied by the requirement
> that the parameter is of X.

You seem to refuse to face the fact that there is no "X" other than
as a placeholder name. There is no "subset of operations of X", and
there is no "set of operations of X" other than that specified by
the implementation of the procedure. When the generic is instantiated
with an actual type, the compiler compares the set of operations
required by the procedure with the set of operations supported by the
type, and if they conform, the instantiation succeeds. If they do not,
the compiler issues an error message and fails to compile the code.

> Right, unused operations are still useful.

So you are saying that the vector *should* require that any object
type that it can hold must support an Arccoth operation? You are
making absolutely no sense.

Re: Anybody in US using ADA ? One silly idea..

[AG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:h96l3vsrtf76akihqdu61r9edeav442eig@4ax.com...
> On Fri, 31 Jan 2003 10:02:15 -0500, Hyman Rosen <hyrosen@mail.com>
> wrote:

> >Why? Since you're converting, what possible relevance is there
> >to requiring that the operation be present in both types?
>
> I do not want flawed implicit type conversions. I want sub- and
> supertyping. If an implementation of sub-/supertyping is based on some
> conversions, I do not care.
>
> >> Ada does this.
> >
> >Really? It does convert-in/convert-out of different types?
> >I've never seen that before. Can you show me sample code?
>
> procedure Query (X : in out Float);
>   -- The initial value is used as a default
> ...
>    I : Integer := 10;
> begin
>    Query (Float (I));

A bit of an unfortunate example that. A quick twiddle of the code
produced this:

with ada.text_io;

procedure tes is

procedure Query (X : in out Float) is

begin

x := x - 0.5;

end;

I : Integer := 10;

begin

Query (Float (I));

ada.text_io.put_line(integer'image(i));

end;



The output is "10" of course which isn't surprising

but seems to sort of contradict the example's purpose.

Not much point in having a conversion like that ...

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 3 Feb 2003 23:04:39 -0800, "AG" <ang@xtra.co.nz> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:h96l3vsrtf76akihqdu61r9edeav442eig@4ax.com...
>> On Fri, 31 Jan 2003 10:02:15 -0500, Hyman Rosen <hyrosen@mail.com>
>> wrote:
>
>> >Why? Since you're converting, what possible relevance is there
>> >to requiring that the operation be present in both types?
>>
>> I do not want flawed implicit type conversions. I want sub- and
>> supertyping. If an implementation of sub-/supertyping is based on some
>> conversions, I do not care.
>>
>> >> Ada does this.
>> >
>> >Really? It does convert-in/convert-out of different types?
>> >I've never seen that before. Can you show me sample code?
>>
>> procedure Query (X : in out Float);
>>   -- The initial value is used as a default
>> ...
>>    I : Integer := 10;
>> begin
>>    Query (Float (I));
>
>A bit of an unfortunate example that. A quick twiddle of the code
>produced this:
>
>with ada.text_io;
>
>procedure tes is
>
>procedure Query (X : in out Float) is
>
>begin
>
>x := x - 0.5;
>
>end;
>
>I : Integer := 10;
>
>begin
>
>Query (Float (I));
>
>ada.text_io.put_line(integer'image(i));
>
>end;
>
>The output is "10" of course which isn't surprising
>but seems to sort of contradict the example's purpose.
>Not much point in having a conversion like that ...

The purpose of the example was only to show that Ada indeed have
convert-copy-in-copy-out-convert.

What your example shows is that in case of specialization (integers is
a subset), one will always have potential problems with
out-parameters. But technicaly there is no much difference between:

subtype Positive is Float 0.0...Float'Last;

and

subtype Integer is Float with only whole values; -- Not Ada!

In both cases there is no ideal way to define the backward conversion.
Sometimes raising Constraint_Error is OK. Sometimes rounding is
better. [For example, when coordinates of graphical objects have to be
mapped to pixels.]

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

Re: Anybody in US using ADA ? One silly idea..

[AG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:r4ns3vsbjo61opm62v8ugcogk4s96tiogs@4ax.com...

> What your example shows is that in case of specialization (integers is
> a subset), one will always have potential problems with
> out-parameters. But technicaly there is no much difference between:
>
> subtype Positive is Float 0.0...Float'Last;
>
> and
>
> subtype Integer is Float with only whole values; -- Not Ada!
>
> In both cases there is no ideal way to define the backward conversion.

Well, the difference between the two is that, in the first case,
you only introduce a scalar range restriction. That is, any valid
value of float in this range is also a valid value for positive if
derived in this way. This is not the case for the second definition
(and I suspect that's exactly the reason it's not Ada).

The backward conversion in the first case only needs to check
the range and raise an exception or whatever handling is
appropiate if the final result is out of range (you can even ignore
intermediates - maybe). No other properties of the type are
involved so everything withing that range should be ok.

 In the second case, the backward conversion is pretty much
doomed unless you are using it in a very specialized case and
implementation that knows how to handle that. In which case
it becomes quite a bit more than a simple subtype since it
would have to have lots of additional logic about rounding,
redefining operations that no longer make sense etc etc.

> Sometimes raising Constraint_Error is OK. Sometimes rounding is
> better. [For example, when coordinates of graphical objects have to be
> mapped to pixels.]
>
> ---
> Regards,
> Dmitry Kazakov
> www.dmitry-kazakov.de

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Tue, 4 Feb 2003 20:38:41 -0800, "AG" <ang@xtra.co.nz> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:r4ns3vsbjo61opm62v8ugcogk4s96tiogs@4ax.com...
>
>> What your example shows is that in case of specialization (integers is
>> a subset), one will always have potential problems with
>> out-parameters. But technicaly there is no much difference between:
>>
>> subtype Positive is Float 0.0...Float'Last;
>>
>> and
>>
>> subtype Integer is Float with only whole values; -- Not Ada!
>>
>> In both cases there is no ideal way to define the backward conversion.
>
>Well, the difference between the two is that, in the first case,
>you only introduce a scalar range restriction. That is, any valid
>value of float in this range is also a valid value for positive if
>derived in this way. This is not the case for the second definition
>(and I suspect that's exactly the reason it's not Ada).
>
>The backward conversion in the first case only needs to check
>the range and raise an exception or whatever handling is
>appropiate if the final result is out of range (you can even ignore
>intermediates - maybe). No other properties of the type are
>involved so everything withing that range should be ok.
>
> In the second case, the backward conversion is pretty much
>doomed unless you are using it in a very specialized case and
>implementation that knows how to handle that. In which case
>it becomes quite a bit more than a simple subtype since it
>would have to have lots of additional logic about rounding,
>redefining operations that no longer make sense etc etc.

I did not mean here that Integer is Standard.Integer. I meant just a
Float subtype called Integer (having Float representation as Ada
requires), with the constraint imposed not by a range, but by
requirement to be whole. In this case the backward conversion is as
straightforward as range check, i.e. check if whole, if not, raise
Constraint_Error. A similar example:

type Day is (Su, Mo, Tu, We, Th, Fr, Sa);
subtype Weekend is Day (Su, Sa);  -- This also not Ada

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

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Wed, 29 Jan 2003 10:44:27 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> That's the whole point. We want to inherit from Ellipse (non-abstract)
>> some of its methods, but we do not want to inherit the representation
>> (two doubles).
>
>I don't understand what you are trying to accomplish.
>If you want to inherit method implementation, how can
>this not be tied to object representation?

Why should it be? When you do fabs (-100), do you care whether -100
has same represenation as a double?

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> On Wed, 29 Jan 2003 10:44:27 -0500, Hyman Rosen <hyrosen@mail.com>
> wrote:
>>If you want to inherit method implementation, how can
>>this not be tied to object representation?
> 
> Why should it be? When you do fabs (-100), do you care whether -100
> has same represenation as a double?

When I *implement* fabs, I most certainly care about the
data representation!

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Thu, 30 Jan 2003 10:01:18 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> On Wed, 29 Jan 2003 10:44:27 -0500, Hyman Rosen <hyrosen@mail.com>
>> wrote:
>>>If you want to inherit method implementation, how can
>>>this not be tied to object representation?
>> 
>> Why should it be? When you do fabs (-100), do you care whether -100
>> has same represenation as a double?
>
>When I *implement* fabs, I most certainly care about the
>data representation!

But you don't. It is already here. You just reuse it, because int is
to some extent a subtype of double.

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

Re: Anybody in US using ADA ? One silly idea..

[Stephen Leake]

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

> On Thu, 30 Jan 2003 10:01:18 -0500, Hyman Rosen <hyrosen@mail.com>
> wrote:
> 
> >Dmitry A. Kazakov wrote:
> >> On Wed, 29 Jan 2003 10:44:27 -0500, Hyman Rosen <hyrosen@mail.com>
> >> wrote:
> >>>If you want to inherit method implementation, how can
> >>>this not be tied to object representation?
> >> 
> >> Why should it be? When you do fabs (-100), do you care whether -100
> >> has same represenation as a double?
> >
> >When I *implement* fabs, I most certainly care about the
> >data representation!
> 
> But you don't. It is already here. You just reuse it, because int is
> to some extent a subtype of double.

He said "implement", not "reuse". Please don't confuse the issue.

To _implement_ fabs, you need to know the format of a floating point
number, so you know which bit to flip.

To _implement_ "area" for a circle, you need to know whether it is a
special case of ellipse (so the 'radius' is named 'minor_axis') or is
a separate type (so the 'radius' is named 'radius'). 

Perhaps you can show some code that demonstrates what you are talking
about. 

-- 
-- Stephe

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On 30 Jan 2003 12:12:01 -0500, Stephen Leake
<Stephen.A.Leake@nasa.gov> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On Thu, 30 Jan 2003 10:01:18 -0500, Hyman Rosen <hyrosen@mail.com>
>> wrote:
>> 
>> >Dmitry A. Kazakov wrote:
>> >> On Wed, 29 Jan 2003 10:44:27 -0500, Hyman Rosen <hyrosen@mail.com>
>> >> wrote:
>> >>>If you want to inherit method implementation, how can
>> >>>this not be tied to object representation?
>> >> 
>> >> Why should it be? When you do fabs (-100), do you care whether -100
>> >> has same represenation as a double?
>> >
>> >When I *implement* fabs, I most certainly care about the
>> >data representation!
>> 
>> But you don't. It is already here. You just reuse it, because int is
>> to some extent a subtype of double.
>
>He said "implement", not "reuse". Please don't confuse the issue.

But in my example it was not implementation, but reuse. fabs is
defined on double.

>To _implement_ fabs, you need to know the format of a floating point
>number, so you know which bit to flip.

[ In fact no, because fabs can be implemented in terms of other
operations ]

>To _implement_ "area" for a circle, you need to know whether it is a
>special case of ellipse (so the 'radius' is named 'minor_axis') or is
>a separate type (so the 'radius' is named 'radius'). 

I can *either* implement Circle.Area *or* inherit (so, reuse) it from
Ellipse. In the latter case I have to know nothing, because Circle is
substitutable in Ellipse.Area.

>Perhaps you can show some code that demonstrates what you are talking
>about. 

The question was: do we [programmers] need to know the representation
when we inherit a method?

The answer is NO. [Of course, the way the compiler implements
inheritance of a method depends on the representations of both types,
but the programmer should not care about it.]

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> The question was: do we [programmers] need to know the representation
> when we inherit a method? The answer is NO.

If you are also inheriting the representation, correct.
If you are not, then the answer is YES.

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But you don't. It is already here.

But someone does.

> You just reuse it, because int is to some extent a subtype of double.

No, because int is convertible to double.

Besides you, I haven't heard anyone else
who would consider that to be subtyping.
Indeed, any time I encounter such type
lattices they always seem enshrouded in
confusion.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Thu, 30 Jan 2003 13:01:17 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> But you don't. It is already here.
>
>But someone does.
>
>> You just reuse it, because int is to some extent a subtype of double.
>
>No, because int is convertible to double.
>
>Besides you, I haven't heard anyone else
>who would consider that to be subtyping.
>Indeed, any time I encounter such type
>lattices they always seem enshrouded in
>confusion.

There is no agreement on definition of subtyping. Most widely used is
LSP-subtyping defined in terms of substitutability. In the spirit of
this definition int is an in-subtype of double, because int is
substitutable for double in in-mode [as my example with fabs shows].
Further, the compiler makes this substitution automatically (no matter
how), so one can say that int inherits, imports [whatsoever] fabs from
double.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> In the spirit of this definition int is an in-subtype of double

No, it is not, assuming the universe of allowed operations on
doubles. The compiler converts the int to a double, but the int
itself is not a double. As I have been saying in my other messages,
in the conventional OO view, a subtype is simultaneously its own
type and all of its base types, and no conversion is required when
viewing it as a base type. This is manifestly not the case for int
and double.

You persist in using your own definitions for these terms,
which will cause confusion for people who are not immersed
in this thread. Most importantly, Ada, C++, and Java don't
share your view, so people familiar with those languages
and unfamiliar with you will not kknow what's going on.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Fri, 31 Jan 2003 10:11:44 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> In the spirit of this definition int is an in-subtype of double
>
>No, it is not, assuming the universe of allowed operations on
>doubles. The compiler converts the int to a double, but the int
>itself is not a double.

Do you know, an integer is definitely a real number. So you should
clarify whether you are talking about mathematical objects or their
computer models. Note also that the same mathematical (or any other
object) can be modelled by many different ways in the same program.
This why the representation of a particular type should be no issue,
when subtyping is considered.

>As I have been saying in my other messages,
>in the conventional OO view, a subtype is simultaneously its own
>type and all of its base types, and no conversion is required when
>viewing it as a base type. This is manifestly not the case for int
>and double.

There is no conventional view on this issue. But if you want to see
objects with several types, OK, substitute everywhere "most specific
type" for "type". And you will again have *different* [most specific]
types.

>You persist in using your own definitions for these terms,
>which will cause confusion for people who are not immersed
>in this thread. Most importantly, Ada, C++, and Java don't
>share your view, so people familiar with those languages
>and unfamiliar with you will not kknow what's going on.

ARM: 3.2 Types and Subtypes:

"A type is characterized by a set of values, and a set of primitive
operations which implement the fundamental aspects of its semantics.
An object of a given type is a run-time entity that contains (has) a
value of the type."

However I see no sense in appealing to authority. If in your view to
say that an object has a type is not feasible, then please, show why.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Do you know, an integer is definitely a real number. So you should
> clarify whether you are talking about mathematical objects or their
> computer models.

Computer models. As I said, the main mistake of OO is confusing
the computer objects with the things they are partially modelling.

> This why the representation of a particular type should be no issue,
> when subtyping is considered.

Perhaps for your concept of subtyping, but not for mine.
If you want Ada-style view conversions, that does not have
anything to do with subtyping, just interconvertability.
To quote the Ada RM:
     "In a view conversion for an untagged type, the target type
      shall be convertible (back) to the operand type."

> However I see no sense in appealing to authority. If in your view to
> say that an object has a type is not feasible, then please, show why.

I should apologize for my unfamiliarity with Ada. An Ada subtype
is a restricted subset of its parent type. But the conventional
OO term subtype used for derived types is not such a restriction,
and indeed Ada calls that a derived type, not a subtype.

Anyway, I don't say that an object doesn't have a type, but that
it can simultaneously have many types. Applying the Ada definition
works perfectly well in this context. If my object is simultaneously
an A and a B and a C, then it is a run-time entity which contains a
value of the set of values of A, and a value of the set of values of
B, and a value of the set of values of C.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Fri, 31 Jan 2003 12:25:16 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Do you know, an integer is definitely a real number. So you should
>> clarify whether you are talking about mathematical objects or their
>> computer models.
>
>Computer models. As I said, the main mistake of OO is confusing
>the computer objects with the things they are partially modelling.

People make mistakes. It is a result of trying to find a philosophy
behind OO.

>> This why the representation of a particular type should be no issue,
>> when subtyping is considered.
>
>Perhaps for your concept of subtyping, but not for mine.

But why? Why do you want to fix reperesentations, instead of letting a
programmer to say what he wants. Note, I am not against inheriting
representations when it is feasible, but sometimes it is not.

>If you want Ada-style view conversions, that does not have
>anything to do with subtyping, just interconvertability.
>To quote the Ada RM:
>     "In a view conversion for an untagged type, the target type
>      shall be convertible (back) to the operand type."
>
>> However I see no sense in appealing to authority. If in your view to
>> say that an object has a type is not feasible, then please, show why.
>
>I should apologize for my unfamiliarity with Ada. An Ada subtype
>is a restricted subset of its parent type.

[+ having exactly same representation as the parent]

>But the conventional
>OO term subtype used for derived types is not such a restriction,
>and indeed Ada calls that a derived type, not a subtype.

Yes, but in my why all this is same thing. Whether I write

subtype X is Y <constraint>;

or

type X is new Y with <extension>;

I produce a new type Y substitutable for X. How do we call it is no
matter. Also no matter is how the substitutability is ensured: either
by preserving the representation, or by inheriting the representation
or by replacing the representation.

Observe similarity in how new methods are constructed. You can

1. inherit a method as-is [same representation]
2. extend a method (constructors, destructors in C++, aggregates in
Ada) [extended representation]
3. override a method [replace representation]

Isn't it strange, that 3 is available for methods, but not for data?

>Anyway, I don't say that an object doesn't have a type, but that
>it can simultaneously have many types. Applying the Ada definition
>works perfectly well in this context. If my object is simultaneously
>an A and a B and a C, then it is a run-time entity which contains a
>value of the set of values of A, and a value of the set of values of
>B, and a value of the set of values of C.

Consider a simplier approach. An object has exactly one [specific]
type. Either A, B or C. If you want an object looking as if it had
several specific types, then its type is none of them. Its type is a
*set* of types {A, B, C}. This is *another* type and its
representation may differ form one of A, B, C. For example it may
consist of a type tag to distinguish which specific object it mimics
right now + the specific object value. In Ada such types are called
class-wide. One could pack the tag into the specific objects (as C++
does), but this would conceptually change nothing. I can always say
that a given object as a type [exactly one].

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Yes, but in my why all this is same thing. Whether I write
> subtype X is Y <constraint>;
> or
> type X is new Y with <extension>;
> I produce a new type Y substitutable for X.

As your view conversion example showed, in the subtype case
we don't have a substitution but a two-way conversion. It
reminds me of school; the derived type is like a teacher who
has gone to graduate school and has come back with new degrees
while the subtype is like a substitute who fills in but doesn't
know very much.

> Isn't it strange, that 3 is available for methods, but not for data?

I still don't understand how you propose to inherit method
implementations while changing data representations.

> Consider a simplier approach.

I understand other approaches are possible, but as I keep saying,
those are not the approaches used in the conventional languages
which support OO, namely Ada, Java, C++, and probably Eiffel.
Ada experts do often use a style where an object containing
subobjects of type A, B, and C takes on the role of A, B, or C
as needed, in order to simulate multiple inheritance. Maybe you
can use something like that to do what you want?

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Hyman Rosen wrote:
> I still don't understand how you propose to inherit method
> implementations while changing data representations.

Oh, wait, I guess I do understand. It's the conversion thing
again. The method will operate on the original representation
with convert-in/convert-out taking care of the new one. This
is DK-inheritance of methods, which apply to DK-subtypes :-)

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 03 Feb 2003 09:40:29 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Hyman Rosen wrote:
>> I still don't understand how you propose to inherit method
>> implementations while changing data representations.
>
>Oh, wait, I guess I do understand. It's the conversion thing
>again. The method will operate on the original representation
>with convert-in/convert-out taking care of the new one. This
>is DK-inheritance of methods, which apply to DK-subtypes :-)

Yea! (:-))

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

Re: Anybody in US using ADA ? One silly idea..

[AG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:qb6l3vglt4ur5svph1dn11o7dfmp8gl8c5@4ax.com...
> On Fri, 31 Jan 2003 10:11:44 -0500, Hyman Rosen <hyrosen@mail.com>
> wrote:
>
> >No, it is not, assuming the universe of allowed operations on
> >doubles. The compiler converts the int to a double, but the int
> >itself is not a double.
>
> Do you know, an integer is definitely a real number.

You sure? How about a simple theorem that any two distinct
real numbers have another real number between them? Either
this theorem doesn't hold (and the whole math goes out
the window) or the integers are most definitely not reals.

Which will it be?

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Mon, 3 Feb 2003 22:34:42 -0800, "AG" <ang@xtra.co.nz> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:qb6l3vglt4ur5svph1dn11o7dfmp8gl8c5@4ax.com...
>> On Fri, 31 Jan 2003 10:11:44 -0500, Hyman Rosen <hyrosen@mail.com>
>> wrote:
>>
>> >No, it is not, assuming the universe of allowed operations on
>> >doubles. The compiler converts the int to a double, but the int
>> >itself is not a double.
>>
>> Do you know, an integer is definitely a real number.
>
>You sure? How about a simple theorem that any two distinct
>real numbers have another real number between them? Either
>this theorem doesn't hold (and the whole math goes out
>the window) or the integers are most definitely not reals.

Exactly. There are two different statements:

1. The set of integers is a subset of the set of reals.
2. The set of the statements valid for the set of integers is a subset
of the statements valid for the set of reals.

1. does not imply 2. Moreover, 2 is false.

One could also put it otherwise:

1a. integer is a real
2a. integers is not reals => Integer is not a LSP-subtype of Float.

N.B. Float is also not a LSP-subtype of real, and there cannot be
such. However in most cases it is not an issue. Similarly, there might
be contexts where Integer could be considered as a subtype of Float.

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

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<gqiv2vgsto8tm9mbi0flii4vr594ui06fo@4ax.com>...
> On 21 Jan 2003 10:55:36 -0800, kcline17@hotmail.com (Kevin Cline)
> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<ga3q2vkds5akg0iaommdaniqp3ubo293pl@4ax.com>...
> >> On Tue, 21 Jan 2003 02:10:37 GMT, "Hillel Y. Sims"
> >> <usenet@phatbasset.com> wrote:
> >> 
> >> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> >> >news:b0e5vu$ognn6$1@ID-77047.news.dfncis.de...
> >> >> Hillel Y. Sims wrote:
> >> >>
>  [templated C++ sort() is faster than qsort()]
> >> >>
> >> >> This is a wrong comparison. A correct one would be an instance of a
>  generic
> >> >> subroutine vs. an inlined subroutine and, note, when the type is
>  statically
> >> >> known.
> >> >
> >> >sort<int>() vs. sort_ints()? In that case the performance should really be
> >> >exactly the same (since as you say, it really *is* to a large extent just a
> >> >bunch of text substitution :-). The benefit is that you don't need to
> >> >rewrite or copy/paste the code over and over for each unique type, the
> >> >compiler does it automatically (while maintaining full type safety, unlike
> >> >dumb macros) -- and better yet, when you fix a bug in the generic version,
> >> >it is immediately fixed for all instantiations automatically (vs.
> >> >sort_ints(), sort_floats(), sort_strings(), sort_xyz())
> >> 
> >> This is an advantage of generics over blind preprocessing. The problem
> >> is whether same can be achieved without both.
> >> 
> >> Consider class-wide sort written for all arrays derived from some
> >> abstract array of comparable elements. If that sort is inlined, then
> >> then compiler theoretically would have all necessary information to
> >> make code as efficient as generic sort could. Presently it is
> >> impossible in both Ada and C++.
> >
> >But then to be sortable the element type would have be derived from
> >some "Comparable" base type.  And to be stored in a hash table,
> >they would have to be derived from a "Hashable" base type.  And to be
> >used with some generic mathematical algorithm they would have to
> >be derived from an "Arithmetic" base type...
> 
> Yes of course. Derived here means only "implements interface of". It
> is also an advantage over generics, because with templates you never
> know if the actual type is "Hashable", until you instantiate all
> functions using all methods of "Hashable". And even so, nobody can say
> whether these methods really comprise a "Hashable" type or they just 
> have similar names and the profiles appropriate to go through the
> compiler.

This would prevent the instantiation of generics on any built-in 
types, or on any type defined in a library.

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> If not possible, then it is not a case where generics may be applied. My 
> point is, anywhere generics work, the specific type can be tacked down.

That doesn't seem correct to me. With generics, I can declare a container
that holds a specific type, and then pas sthat container around to other
(generic) routines, and they all know the type of the container's contents.

Without generics, all I have is a container that holds some base type. How
is the compiler to know that this container holds only a certain specific
type of object?

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> If not possible, then it is not a case where generics may be applied. My
>> point is, anywhere generics work, the specific type can be tacked down.
> 
> That doesn't seem correct to me. With generics, I can declare a container
> that holds a specific type, and then pas sthat container around to other
> (generic) routines, and they all know the type of the container's
> contents.
> 
> Without generics, all I have is a container that holds some base type. How
> is the compiler to know that this container holds only a certain specific
> type of object?

I see your point. Well, this is another story. I meant containers of 
class-wide objects. What you meant is the containers of specific types like 
arrays are. Though it looks like a simplier problem, it is unsolvable in 
the way I proposed. Here generics or built-in container types are the only 
options. Anyway array types solve this for one particular case without 
generics. Maybe, there is a more general way to deal with the containers of 
all kinds without generics. I do not know.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Here generics or built-in container types are the only options.

Well, yes, that's what we've been trying to tell you :-)

> Anyway array types solve this for one particular  case without generics.

Well, the genericity is there, it's just that the compiler does it for
you without you having to specify it yourself.

> Maybe, there is a more general way to deal with the containers of 
> all kinds without generics. I do not know.

The way it's handled in Java is to hide away the container inside a
class, then cut-and-paste code that does a cast to the desired type
whenever an object is extracted from the container. Horrible.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

On Sun, 19 Jan 2003 14:13:17 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Here generics or built-in container types are the only options.
>
>Well, yes, that's what we've been trying to tell you :-)
>
>> Anyway array types solve this for one particular  case without generics.
>
>Well, the genericity is there, it's just that the compiler does it for
>you without you having to specify it yourself.

Generics cannot solve the problem of related containers. The compiler
could treat arrays of characters as a subtype of arrays of
wide-characters. With generic it is impossible.

>> Maybe, there is a more general way to deal with the containers of 
>> all kinds without generics. I do not know.
>
>The way it's handled in Java is to hide away the container inside a
>class, then cut-and-paste code that does a cast to the desired type
>whenever an object is extracted from the container. Horrible.

I didn't mean that (:-)) There is an automated cut-and-paste called
generics.

However, if we could tie the tag of the element with the container's
tag, we could solve the problem of specific containers, by deriving a
new container type *statically* constrained by the element type. In
this case the compiler would know the type of the elements.

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

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Dmitry A. Kazakov wrote:
>  What's the use of a variation over
> a type set if you are unable to specify an element of the set?

I forgot to add that an additional benefit of generics is
type-safety, enforced at compile-time. Such as the Unit code.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>>  What's the use of a variation over
>> a type set if you are unable to specify an element of the set?
> 
> I forgot to add that an additional benefit of generics is
> type-safety, enforced at compile-time. Such as the Unit code.

Hey, in Ada everything is type-safe! (:-))

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

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

"Dmitry A. Kazakov" wrote:

> They are not, up to some limit. But the problem is whether the language
> gives you an opportunity to define new numeric types without the
> restrictions you do not need and close enough to the theoretical
> performance limit for the remaining restrictions. Ada almost can this.
> [Almost, because one cannot make a private type "numeric" for the
> compiler.]

In fact, I have a generic package, for creating generic formal package
parameters that looks like this:

         generic
             type Item is private;
             with function "+" (L, R : Item) return Item is <>;
             with function "-" (L, R : Item) return Item is <>;
             with function "*" (L, R : Item) return Item is <>;
             with function "/" (L, R : Item) return Item is <>;
             with function "=" (L, R : Item) return Boolean is <>;
             with function "<" (L, R : Item) return Boolean is <>;
             with function ">" (L, R : Item) return Boolean is <>;
             with function "<=" (L, R : Item) return Boolean is <>;
             with function ">=" (L, R : Item) return Boolean is <>;
             with function Zero_Equivalent return Item;
             -- with some additional generic formal subprogram parameters
       package Generic_Operators is end Generic_Operators;

This can be used in some other package as a generic formal package
parameter.

      generic
          with package Operators is new Generic_Operators<>;
      package Generic_Statistics is

          -- Any data type here

     end Generic_Statistics;

I published an article with the details for this in an old issue of
Ada Letters.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Richard Riehle wrote:

> "Dmitry A. Kazakov" wrote:
> 
>> They are not, up to some limit. But the problem is whether the language
>> gives you an opportunity to define new numeric types without the
>> restrictions you do not need and close enough to the theoretical
>> performance limit for the remaining restrictions. Ada almost can this.
>> [Almost, because one cannot make a private type "numeric" for the
>> compiler.]
> 
> In fact, I have a generic package, for creating generic formal package
> parameters that looks like this:
> 
>          generic
>              type Item is private;
>              with function "+" (L, R : Item) return Item is <>;
>              with function "-" (L, R : Item) return Item is <>;
>              with function "*" (L, R : Item) return Item is <>;
>              with function "/" (L, R : Item) return Item is <>;
>              with function "=" (L, R : Item) return Boolean is <>;
>              with function "<" (L, R : Item) return Boolean is <>;
>              with function ">" (L, R : Item) return Boolean is <>;
>              with function "<=" (L, R : Item) return Boolean is <>;
>              with function ">=" (L, R : Item) return Boolean is <>;
>              with function Zero_Equivalent return Item;
>              -- with some additional generic formal subprogram parameters
>        package Generic_Operators is end Generic_Operators;
> 
> This can be used in some other package as a generic formal package
> parameter.
> 
>       generic
>           with package Operators is new Generic_Operators<>;
>       package Generic_Statistics is
> 
>           -- Any data type here
> 
>      end Generic_Statistics;
> 
> I published an article with the details for this in an old issue of
> Ada Letters.

BTW, did you compare

generic
   with package Operators is new Generic_Operators <>;
package Generic_Statistics is ...

with a child package variant:

generic
package Generic_Operators.Generic_Statistics is ...

It would be interesting to do it in depth.

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

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

"Dmitry A. Kazakov" wrote:

> BTW, did you compare
>
> generic
>    with package Operators is new Generic_Operators <>;
> package Generic_Statistics is ...
>
> with a child package variant:
>
> generic
> package Generic_Operators.Generic_Statistics is ...
>
> It would be interesting to do it in depth.

I'm sure it would be interesting.   However, it changes nothing
with regard to the valuable contribution of generics as one
approach to software reuse.

Bertrand Meyer's observations, in his early paper about
genericity versus inheritance have always made sense to
me.   The two approaches have their own unique benefits.
Sometimes a design is best as a generic component.  Other
times, inheritance is that proper choice.

In these times, inheritance and genericity are no longer the
only choices.   True delegation, as represented by the Ada
keyword, requeue, is another excellent choice.   Child
library units open the door to Aspect_Oriented Programming
in Ada.  Also, Child Library Units make it easier to decompose
a set of methods into specifications that more closely correspond
to high-cohesion.

The object model is just beginning to open itself to a broader
range of collaboration options.   Newer language designs, that
is newer than C++, Ada, Java, or C#, are being developed to
more easily accomodate this broader range of options.   At
present, Ada is pretty good, but it will eventually become as
obsolete as I believe C++ already is.

Even though something is obsolete, people will continue to use
it.   This will be true of Jovial, Ada, C++, and even PL/I.  Yet,
the new range of options demonstrated by the new language
designs will slowly find their way into day-to-day practice.
Some of the features of these languages will come from C++,
some from Ada, and some from other languages.   Perhaps,
someone will adopt the EVALUATE statement from COBOL
in one of these new language designs.

The COBOL EVLUATE statement is one of the most powerful
and linguistically consistent statements ever designed for any
programming language, yet only COBOL has it.   Even so, COBOL
falls far far short of being the ideal programming language.

I don't expect to see the perfect programming language in my
lifetime.   The tone has been set for designing such a language,
but few have accomplished it so far.  Also, as long as those
who have learned one language take a xenophobic attitude
toward any other language that comes on the scene, we will
likely make very little progress.

So, at present, those of us who do write computer programs can
benefit from knowing more than one language and being able to
use each of them for the job where they seem appropriate.  The
DoD tried, and failed, to introduce a single-language policy into
their software projects.   Very likely other such attempts, by
anyone, will also fail.  Even IBM, when it still owned the computer
industry, could not force everyone to adopt PL/I.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[tmoran]

There's an interesting article "On Type Systems for Object-Oriented
Database Programming Languages" in the current ACM Computing Surveys.

Re: Anybody in US using ADA ? One silly idea..

[Larry Kilgallen]

In article <iPCV9.2441$c6.2445@bos-service2.ext.raytheon.com>, Wes Groleau <wesgroleau@despammed.com> writes:
> 
>> Didn't Lisp suffer from a parentheses shortage? I always thought that one
>> could write Lisp faster with one additional input device: left parenthese
>> and right parenthese foot pedals.
> 
> Ooh, Repetitive Stress Injuries in the calf muscles!

Oh, coding errors when a left-footed person has interchanged the pedals.

Re: Anybody in US using ADA ? One silly idea..

[Robert A Duff]

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

> Hyman Rosen wrote:
> 
> > Dmitry A. Kazakov wrote:
> >> I agree. As I said, it is a long way to go to get rid of generics.
> > 
> > And as I said, I have no idea why you would want to.
> 
> I think I explained why.

You explained why, but I didn't see any explanation of what you would
like to do instead.

Clearly, I should be able to write a "stack" abstraction (or other data
structure) that takes any type as element.  And I shouldn't have to
write it more than once.  And I should be able to constrain any
particular stack to have a particular element type, with this type
checked at compile time.  (Or, I can use a class-wide type as the
element, if I want any type in a class.)

I'd be interested to know if you have something in mind that meets these
criteria.  Tagged types in Ada (or the corresponding feature in most
other languages) don't give you the compile-time checking.

It seems to me that if the feature is not generics or templates,
then it would at least have to share some properties with those
features.

- Bob

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Hyman Rosen wrote:
>> 
>> > Dmitry A. Kazakov wrote:
>> >> I agree. As I said, it is a long way to go to get rid of generics.
>> > 
>> > And as I said, I have no idea why you would want to.
>> 
>> I think I explained why.
> 
> You explained why, but I didn't see any explanation of what you would
> like to do instead.

You are the first who asks. (:-))

> Clearly, I should be able to write a "stack" abstraction (or other data
> structure) that takes any type as element.  And I shouldn't have to
> write it more than once.  And I should be able to constrain any
> particular stack to have a particular element type, with this type
> checked at compile time.  (Or, I can use a class-wide type as the
> element, if I want any type in a class.)
> 
> I'd be interested to know if you have something in mind that meets these
> criteria.  Tagged types in Ada (or the corresponding feature in most
> other languages) don't give you the compile-time checking.
> 
> It seems to me that if the feature is not generics or templates,
> then it would at least have to share some properties with those
> features.

OK, here is my program of how containers could be made non-generic. I 
haven't worked out all details and I do not even know if it is possible. 
This is a program, not a solution or proposal for Ada2005.
---

If we consider stack (container) then the first question is what is the 
class of types which can be used with it. We want to

1. have an ability to specify the class as a type
2. have it open (extensible)
3. clone the class (typed containers)

The minimal requirement is an ability to copy the element (sort of "type X 
is private").

   type Element is abstract tagged null record;

Here the first deviation from Ada comes. All types have to be tagged [in the 
sense of existing T'Class] and there should be a way to explicity say that 
a type has [or has to have] copy-constructor:

   type Element is abstract;
   ?function? (Source : Element) return Element is abstract;

The stack could be defined as an array of Element'Class. It is impossible in 
Ada for many reasons, but the major is that the size of Element'Class is 
unknown. A thinkable way could be to make a constrant for it a discriminant 
of the array. Clearly there should be a way to bind Element and Stack as an 
array type and its element are bound. Frankly, I do not know yet.

   type Stack (?) is private;
   procedure Push (...);

That multiple inheritance is inevitable is clear. We definitely want no more 
problems like with Root_Stream_Type.

Now if we want a new type to be used with the stack, we just derive it from 
Stack'Element as a subtype.

The crucial point is what to do with already existing types. There is a 
solution for this. The language should allow not only subtyping, but also 
supertyping. Let we want to put Integer into the stack. Then we could 
create a new "bridge" type which is *both* a subtype of Stack'Element and a 
supertype of Integer. This would have an effect of making Integer a subtype 
of Element. By the way this feature would also solve many other problems.

This also should mean that deriving should no more determine the 
representation of the new type, if not explicitly specified.

Typed (=>compile-time checkable) containers should be no problem if Element 
and Stack are bound. One could use sort of "type X is new Y;" to clone them 
into a new pair and then derive from new Stack'Element.

Performance should not be an issue, if Push and Pop are inlined and types 
(=tags) are statically known. So it should be as efficient as generics are. 
However this also requires some rework. The language should require [if 
programmer wants] absence of discriminants and tags in specific objects 
(statically known constraints). I belive it is already the case for array 
bounds, correct me if I am wrong.

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

Re: Anybody in US using ADA ? One silly idea..

[Robert I. Eachus]

As I read through this thread, I noticed widespread ignorance on both 
sides of the way Ada generics actually work.  This is not surprising, as 
the essential magic is "hidden" in plain sight in what seems like a 
textual substitution shorthand.  But as anyone who actually implements 
Ada generics can tell you, it is anything but textual substitution.

Ada generics have four places where binding of parameters occurs.  At 
the point of the generic declaration, any bindings that occur are 
compile time bindings with respect to names, and can be to static or 
dynamic values:

generic function Foo(X: in Integer := Read) return Integer is...

The second set of bindings occurs in the body.  Although it is possible 
for the binding in the body of a generic to be to a different instance 
of a name than in the specification, good programming practice strongly 
deprecates that possibility.  However, it is common for new names to be 
visible in the body, and to be used.

The third set of bindings occurs at the point of instantiation.  This is 
where the generic parameters are bound.  A classic example of using this 
binding occurs with sorts:

     generic
        type Element is private;
        type Element_Array is array (Integer range <>) of Element;
        function ">" (L,R: Element) return Boolean;
     procedure Sort(EA: in out Element_Array);

Now an instantiation of Sort passing "<" instead of ">" will sort in 
descending instead of ascending order.  Of course for convenience, the 
specification above is normally written as:

     generic
        type Element is private;
        type Element_Array is array (Integer range <>) of Element;
        function ">" (L,R: Element) return Boolean is <>;
     procedure Sort(EA: in out Element_Array);

The 'is <>' allows the function ">" to be defaulted and left out of the 
instantiation.  This is where the magic--or snakepit--occurs, depending 
on whether you are a user or implementor.  Instead of 'is <>' I could 
have written 'is Standard.">"' and insured that the default would be to 
the predefined greater than operation for Integer.

But with the 'is <>', I get the ">" function for Integer visible at the 
point of instantiation.  This can be in a nested call, and the binding 
can actually be to some ">" in a (run-time) enclosing declarative part. 
  In other words, implementing the 'is <>' notation correctly requires 
support for upward closures.  But there is worse (from an implementors 
point of view) to come.

The fourth point of binding is at the call.  This is where the names of 
the formal parameters are bound to the actuals.  But notice that the 
environment of the call need not be that of instantiation, in fact, 
quite often it is not.  This means that if you try to implement Ada 
using displays, generics sometimes require passing multiple displays as 
implicit parameters.  (Ouch!  Ask Randy Brukardt for details, he has 
actually implemented it.)

Should you use this Lisp style richness of closures when programming in 
Ada?  I have found very few cases where the power was worth the 
documentation effort to make sure any maintainers understood what was 
going on.  The one exception has been in displaying appropriate error 
messages during debugging of parsers. ;-)

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

"Robert I. Eachus" wrote:

> Robert,

In your haste to provide an example, you have done what I so
often do.   Note the syntax error in your generic formal parameters.
The function ">" should be,

        with function ">" (L, R : element) return Boolean;

>      generic
>         type Element is private;
>         type Element_Array is array (Integer range <>) of Element;
>         function ">" (L,R: Element) return Boolean;
>      procedure Sort(EA: in out Element_Array);

>
>      generic
>         type Element is private;
>         type Element_Array is array (Integer range <>) of Element;
>         function ">" (L,R: Element) return Boolean is <>;
>      procedure Sort(EA: in out Element_Array);

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

> .....  A classic example of using this
> binding occurs with sorts:
> 
>     [snip]
 >
 >     generic
 >        type Element is private;
 >        type Element_Array is array (Integer range <>) of Element;
 >        function ">" (L,R: Element) return Boolean is <>;
 >     procedure Sort(EA: in out Element_Array);
 >
 > The 'is <>' allows the function ">" to be defaulted and left out of the
 > instantiation.  This is where the magic--or snakepit--occurs, depending
 > on whether you are a user or implementor.  Instead of 'is <>' I could
 > have written 'is Standard.">"' and ensured that the default would be to
 > the predefined greater than operation for Integer.

Well, almost.  You'd have to change "private" to "range <>"
to avoid a message like:
   Standard.">" has no definition that matches
   function ">" (L, R : Element) return Boolean [RM_95 8.5.4(4)]

> 
> Now an instantiation of Sort passing "<" instead of ">" will sort in 
> descending instead of ascending order.  Of course for convenience, the 
> specification above is normally written as:
> 
> But with the 'is <>', I get the ">" function for Integer visible at the 
> point of instantiation.  This can be in a nested call, and the binding 
> can actually be to some ">" in a (run-time) enclosing declarative part. 
>  In other words, implementing the 'is <>' notation correctly requires 
> support for upward closures.  But there is worse (from an implementors 
> point of view) to come.
> 
> The fourth point of binding is at the call.  This is where the names of 
> the formal parameters are bound to the actuals.  But notice that the 
> environment of the call need not be that of instantiation, in fact, 
> quite often it is not.  This means that if you try to implement Ada 
> using displays, generics sometimes require passing multiple displays as 
> implicit parameters.  (Ouch!  Ask Randy Brukardt for details, he has 
> actually implemented it.)
> 
> Should you use this Lisp style richness of closures when programming in 
> Ada?  I have found very few cases where the power was worth the 
> documentation effort to make sure any maintainers understood what was 
> going on.  The one exception has been in displaying appropriate error 
> messages during debugging of parsers. ;-)
> 

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Robert I. Eachus wrote:
> This means that if you try to implement Ada using displays,
 > generics sometimes require passing multiple displays as
> implicit parameters.

Is this any different than if the subprogram was not generic?
That is, suppose I just wrote a subprogram instead of an
instantiation:
     type Element_Array is array(Integer range <>) of Element;
     procedure Sort(EA: in out Element_Array) is
     begin
         -- uses EA(i) > EA(j)
     end
and then I pass a pointer to Sort to another procedure.
Doesn't the same sort of thing have to be done as for the
generic?

Re: Anybody in US using ADA ? One silly idea..

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Is this any different than if the subprogram was not generic?
> That is, suppose I just wrote a subprogram instead of an
> instantiation:
>      type Element_Array is array(Integer range <>) of Element;
>      procedure Sort(EA: in out Element_Array) is
>      begin
>          -- uses EA(i) > EA(j)
>      end
> and then I pass a pointer to Sort to another procedure.
> Doesn't the same sort of thing have to be done as for the
> generic?

No, because you can't pass a nested procedure to a less-nested
procedure.  So in a display implementation, you can always pass just the
address of the code.  In a static-link implementation, you can pass just
the address of the code for unnested procedures, and for procedures
nested one level deep, but you need a static link for deeper ones.

- Bob

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Robert A Duff wrote:
> No, because you can't pass a nested procedure to a less-nested
> procedure.

So you can instantiate a generic procedure and pass its address
to a less-nested procedure, even though the generic uses procedures
defined at a more-nested level?

Re: Anybody in US using ADA ? One silly idea..

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > No, because you can't pass a nested procedure to a less-nested
> > procedure.
> 
> So you can instantiate a generic procedure and pass its address
> to a less-nested procedure, even though the generic uses procedures
> defined at a more-nested level?

No.

You can pass a nested procedure to a less-nested generic during
instantiation.  You cannot pass the 'Access of a nested procedure to a
less-nested procedure.

generic
    with procedure Action(Item: Element);
procedure Iterate(X: Data_Structure);
-- Calls Action once for each Item in the data structure.

function Count(X: Data_Structure) return Natural is
    Result: Natural := 0;

    procedure Incr_Result(Item: Element) is
    begin
        Result := Result + 1;
    end;
    procedure Iter is new Iterate(Incr_Result);
begin
    Iter(X);
    return Result;
end Count;

The above works fine (barring typos -- I didn't compile it).
But if you try to do the same thing using access-to-procedure,
it won't work:

type Action_Proc is access procedure(Item: Element);
procedure Iterate(X: Data_Structure; Action: Action_Proc);

function Count(X: Data_Structure) return Natural is
    Result: Natural := 0;

    procedure Incr_Result(Item: Element) is
    begin
        Result := Result + 1;
    end;
begin
    Iterate(X, Incr_Result'Access); -- Illegal!
    return Result;
end Count;

- Bob

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Robert A Duff wrote:
> You can pass a nested procedure to a less-nested generic during
> instantiation.  You cannot pass the 'Access of a nested procedure to a
> less-nested procedure.

This makes perfect sense to me. In my naive, C++ style of thinking
about generics, I see the instantiation as doing textual substitution
at that point, and so while the generic itself has been declared at a
less nested level, its instantiation is not. I don't think of the
instantiation as "passing" the parameters.

But I guess the idea is that the generic can also pull in names from
its own context that would be different from the names that would be
found if the code was just written in place at the instantiation point,
and those can be local functions as well, and that's where some of the
complexity sets in.

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

The debate over generics versus inheritance is quite old.   Bertrand
Meyer wrote an essay on this which he included in his book, "Object
Oriented Software Construction."   The general conclusion was that
genericity could be emulated with inheritance, but inheritance could
not be emulated with genericity.

For some the objective of both concepts is software reuse.  I seen that
as a short-sighted view, but it is certainly one valid objective.

Ada has taken this a little further.  We have genericity, inheritance,
and child library units.  All three are useful tools when used for the
correct purpose.  All three provide a powerful combination of
approaches to software reuse.   Randy Brukhardt has correctly
noted that Ada /= GNAT.   Many compilers, one that I recall quite
well was TLD Ada, did not use full code expansion for generics.

Some have suggested the C++ model for generics is slightly better
than that in Ada.  I respectfully suggest that the improved flexibility
also results in a degradation of reliability.   But reliability has been
widely deprecated as less important that ease of development.

Ada generics, as well as Eiffel and C++ generics, do make the
creation of extensible containers more sensible.   In my experience,
combining genericity with inheritance in Ada is quite useful.  It
is also helpful that we can dispatch on the result of a function
when designing such containers.

Child library units have turned out to be more powerful than I
originally expected.   I now use the package body to implement
only the declarations in the specification.   All supporting
code within a body is now promoted to a child library unit.
This has provided support for creating aspects, something we
could not do easily with Ada 83, and something I see as more
challenging in C++ than in Ada (though not impossible).   As
as consequence, I see Ada as quite friendly to the new model
of Aspect-Oriented Programming, while still enforcing a
strong model of encapsulation.

Any tool, used unwisely, is a fool's tool.   Genericity, when used
intelligently, continues to be a valuable component of the Ada
language.  The addition of generic formal package parameters
in Ada 95 has proven to be an excellent addition, even though
a great many programmers are confused by it because the ALRM
does not provide a simple and fully coded example.  I do provide
such a example in "Ada Distilled."

I just returned from presenting a two week software engineering
seminar in Asia.   I used Ada to demonstrate my programming
examples.   The students, none of whom had seen Ada before,
found the examples easy to read, understand, and ask questions
about.  If I had been using C++ for a similar audience, one that
had never seen C++ before, I suspect I would have had a
classroom full of confused students.   Even my example using
an Ada generic component was easy to follow for these students,
even though English was not their native language.

Some of them plan to download GNAT and experiment with
Ada.  Everyone of them agreed that C++ is so confusing that
they spend a huge amount of time correcting errors that they
wish had been caught by the compiler.   Many had already
rejected C++ in favor of Java, Python, and other languages
because they found C++ so difficult.

Ada can be made accessible to new students.   We simply need
to learn how to present what the students need when they need
it, and to show them simple solutions they can use to work out
their own problems.

Richard Riehle

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Richard Riehle wrote:
> Some have suggested the C++ model for generics is slightly better
> than that in Ada.  I respectfully suggest that the improved flexibility
> also results in a degradation of reliability.

Since generics are "expanded" at compile-time, you cannot mean the
usual things that reliability means with respect to C++, such as
indexing out of array bounds, or using bad pointers, or overflowing
arithmetic. So I assume that you mean instead that the C++ model
makes it more difficult to see, at the point of use, exactly which
piece of code is being invoked.

As I recall, it was exactly this concern which led to the tragic lack
of pointers to functions in Ada83. I suppose some lessons need to be
learned over and over again.

Re: Anybody in US using ADA ? One silly idea..

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:

:  Oberon.NET, which is very new, has generics.

of a different sort.

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

> 1. Generics are static. You cannot have an object or dynamic-link library of 
> generics.
> 
> 1.a. This kills code reuse at run-time.

Weakens it, but does not "kill" it.
I can instantiate a generic at run-time.
And that generic can instantiate another
generic or give actuals to another generic.

Where is the body code for the following instantiations?

-- Admittedly, this is a pretty unlikely scenario!
procedure Demo (First : Natural) is

    type Weird_Num is range First .. Last_Function (First);

    type Weird_Record is
      record
        Field_That    : .....;
        Did_Not       : Weird_Num;
        Exist_Before  : .....;
      end record;

    This_Is_It : Weird_Record;

    package Temporary is new Wierd_Thing (Weird_Num, Weird_Record);

    function Make_Weird is
        new Oddball (Weird_Num, Temporary.Weird_Function);

begin
    ....; -- Generate the contents of This_Is_It.

    Ada.Text_IO.Put_Line (Temporary.Image_Of (Make_Weird (This_Is_It));

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<av6hla$cggao$1@ID-77047.news.dfncis.de>...
> Kevin Cline wrote:
> 
> > Today, the features that Ada provides have little value
> > compared with the features that C++ provides and Ada lacks:
> > the STL, automatic template function instantiation,
> 
> Generics in any form is an illness of programming languages.
> 
> > smooth integration of user-defined and primitive datatypes,
> 
> Why do you think C++ is better in that respect? 

Because all operations applicable to C++ fundamental types can be made
to work for user-defined types.  Ada's fundamental types have
attributes, but those attributes can not be provided for user-defined
types.  This makes generic programming in Ada more difficult than
generic programming in C++.


> C++ OO model is badly flawed 
> as compared with Ada's one. In any case both Ada and C++ have primitive 
> types separated from user-defined types by a fire wall. The difference is 
> that Ada's design potentially allows to mend this, while in C++ it is 
> beyond repair.

You need to substantiate this claim; I have found the opposite to be
true.

> 
> > and bindings to every API in existence.
> 
> That's not language fault. 

I didn't say that it was a language flaw.  But it makes Ada more
difficult
to integrate with existing APIs.

> This can be addressed to any language except C. 

> Even C++ suffers from that: you might need 'extern "C" {}' to call most of 
> API functions. 

Generally I don't have to supply "extern C ... " because the most
header
files handle the problem.  Even if they don't, I can simply say:

extern "C" {
#include "someAPI.h"
}

rather than redeclaring every one of the functions needed.

Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov]

Kevin Cline wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:<av6hla$cggao$1@ID-77047.news.dfncis.de>...
>> Kevin Cline wrote:
>> 
>> > Today, the features that Ada provides have little value
>> > compared with the features that C++ provides and Ada lacks:
>> > the STL, automatic template function instantiation,
>> 
>> Generics in any form is an illness of programming languages.
>> 
>> > smooth integration of user-defined and primitive datatypes,
>> 
>> Why do you think C++ is better in that respect?
> 
> Because all operations applicable to C++ fundamental types can be made
> to work for user-defined types.  Ada's fundamental types have
> attributes, but those attributes can not be provided for user-defined
> types.

Some of them, to be correct. There are overridable attributes. Note also 
that Ada offers much more "standard" operations than C++. I agree that 
every of them has to be a primitive overridable operation, but the burden 
of Ada 83 is heavy. Then some of things are difficult to make. Consider 
aggregates. Can C++ override them? Consider indefinite types. Does C++ have 
them? Consider short circuit operations. In C++ you can override it but you 
loose its property.

> This makes generic programming in Ada more difficult than
> generic programming in C++.

I disagree. Generic programming is not equal to programming with generics. 
It is programming for type sets. Ada's class-wide types are much more 
consistent and powerful that flawed C++ OO model.

>> C++ OO model is badly flawed
>> as compared with Ada's one. In any case both Ada and C++ have primitive
>> types separated from user-defined types by a fire wall. The difference is
>> that Ada's design potentially allows to mend this, while in C++ it is
>> beyond repair.
> 
> You need to substantiate this claim; I have found the opposite to be
> true.

1. C++ does not distingush a specific type from a types set. 
2. In C++ you can dispatch on exactly one parameter
3. The dispatching parameter cannot be result. So all functions are 
contravariant
4. In C++ you cannot return a class-wide parameter otherwise than through a 
pointer
5. Because of 1. there is no way to deal with ALL types in same way. For 
instance, int is not a class and will never be one.
6. Because of 2. you cannot implement binary operations properly

>> > and bindings to every API in existence.
>> 
>> That's not language fault.
> 
> I didn't say that it was a language flaw.  But it makes Ada more
> difficult
> to integrate with existing APIs.
> 
>> This can be addressed to any language except C.
> 
>> Even C++ suffers from that: you might need 'extern "C" {}' to call most
>> of API functions.
> 
> Generally I don't have to supply "extern C ... " because the most
> header
> files handle the problem.  Even if they don't, I can simply say:
> 
> extern "C" {
> #include "someAPI.h"
> }
> 
> rather than redeclaring every one of the functions needed.

Really? And what about stdcall vs. cdecl? Parameter passing conventions 
could be well different from what extern "C" does.

I would agree with you, should you say: many API are written in C which 
allows a smooth integration into a C program provided that the compiler and 
linker are of same vendor as API, or a sort of standard was involved. Then 
because MS is a monopolist and all poor programmers have to use MS VC++, 
then ...

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

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

>>>smooth integration of user-defined and primitive datatypes,
>>
>>Why do you think C++ is better in that respect? 
> 
> Because all operations applicable to C++ fundamental types can be made
> to work for user-defined types.  Ada's fundamental types have
> attributes, but those attributes can not be provided for user-defined
> types.  This makes generic programming in Ada more difficult than
> generic programming in C++.

I don't know C++ very well, but this complaint
about Ada is true--at least partially.  I do
understand C and Java, so I'll risk interpolating
to C++ ....

Does C++ have subtypes and derived types?  The lack
of such in Java is really a pain.  And these DO inherit
attributes from parent types.  But I wish I could
define things like 'First and 'Last when I create a
private type for which they are meaningful.
It would also be nice to be able to redefine 'Size
for an access type or record containing an access type.
But these are minor issues.

Re: Anybody in US using ADA ? One silly idea..

[James S. Rogers]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:YRhS9.215$Z74.921@dfw-service2.ext.raytheon.com...
>
> I don't know C++ very well, but this complaint
> about Ada is true--at least partially.  I do
> understand C and Java, so I'll risk interpolating
> to C++ ....
>
> Does C++ have subtypes and derived types?  The lack

Not in the Ada sense.
C++, supporting OOP, does allow you to create your own classes
and inherit from those classes. It does not allow you to create your
own primitive types or derive directly from primitive types.

C++ does not support anything like
type Voltages is digits 15 range -4.0..40.;
type Strange is new Integer range -123..1024;

Nor does it support anything like
subtype Natural is Integer range 0..Integer'Last;

> of such in Java is really a pain.  And these DO inherit
> attributes from parent types.  But I wish I could
> define things like 'First and 'Last when I create a
> private type for which they are meaningful.

Of course, 'First and 'Last imply a range. Ranges imply
discrete values. How would you describe the range for
a type that is not discrete? This would imply the ability to
define discontinuous ranges. Although that ability seems
convenient for the programmer, I have no idea how it could
be implemented by the compiler writer in an efficient and
general manner.

> It would also be nice to be able to redefine 'Size
> for an access type or record containing an access type.
> But these are minor issues.

Defining 'Size for an access type would require a consistent
implementation of access types across all compilers. Remember
that an access type need not be implemented as a pointer.
Ada makes a strong distinction between an access type and a
value of type System.Address.

Jim Rogers

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

> Of course, 'First and 'Last imply a range. Ranges imply
> discrete values. How would you describe the range for
> a type that is not discrete? This would imply the ability to
> define discontinuous ranges. Although that ability seems
> convenient for the programmer, I have no idea how it could
> be implemented by the compiler writer in an efficient and
> general manner.

The compiler writer would not need to implement it.
Just the ability for the USER to define it.  The
application is a type that conceptually has a range,
but is for some reason private.

>>It would also be nice to be able to redefine 'Size
>>for an access type or record containing an access type.
> 
> Defining 'Size for an access type would require a consistent
> implementation of access types across all compilers. Remember

No, the USER wants to redefine it so that it is somehow
related to the value pointed to.  The implementation is
irrelevant.  It's to would support the abstraction,
not the implementation.

But, I repeat, these are _minor_ issues.

Re: Anybody in US using ADA ? One silly idea..

[David C. Hoos]

----- Original Message ----- 
From: "James S. Rogers" <jimmaureenrogers@worldnet.att.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, January 06, 2003 11:26 AM
Subject: Re: Anybody in US using ADA ? One silly idea..


<snip>
> Of course, 'First and 'Last imply a range. Ranges imply
> discrete values. How would you describe the range for
> a type that is not discrete?
Did you mean "scalar" where you said discrete?
<snip>

Re: Anybody in US using ADA ? One silly idea..

[James S. Rogers]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.1041964863.13971.comp.lang.ada@ada.eu.org...
>
> ----- Original Message -----
> From: "James S. Rogers" <jimmaureenrogers@worldnet.att.net>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: Monday, January 06, 2003 11:26 AM
> Subject: Re: Anybody in US using ADA ? One silly idea..
>
>
> <snip>
> > Of course, 'First and 'Last imply a range. Ranges imply
> > discrete values. How would you describe the range for
> > a type that is not discrete?
> Did you mean "scalar" where you said discrete?

Yes, thank you.

Jim Rogers

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Wes Groleau wrote:
> Does C++ have subtypes and derived types?

No. The only thing of this type available is
class inheritance.

 > But I wish I could
> define things like 'First and 'Last when I create a
> private type for which they are meaningful.

In C++, you can set up arbitrary "attributes" of this
sort by using a technique called traits. You define a
class template, and then specialize it for your type.
Whether to have a common fallback value or not is up
to you. Eg.,

template<typename T> struct DoesIt;
struct Dog;
struct Cat;
struct AEIOU;
template<> struct DoesIt<Dog> { enum { Howl = 1, Yowl = 0, Vowel = 0 }; };
template<> struct DoesIt<Cat> { enum { Howl = 0, Yowl = 1, Vowel = 0 }; };
template<> struct DoesIt<AEIOU> { enum { Howl = 0, Yowl = 0, Vowel = 1 }; };

Re: Anybody in US using ADA ? One silly idea..

[Wes Groleau]

>  > But I wish I could
>> define things like 'First and 'Last when I create a
>> private type for which they are meaningful.
> 
> In C++, you can set up arbitrary "attributes" of this
> sort by using a technique called traits. You define a

I'm not interested in "arbitrary" attributes.
I'm interesting in creating an abstraction that
has the attributes of being some kind of "number"
but is still user-defined.  In Ada and C++, we
can overload operators so that the abstraction
is supported.  But if we have a legitimate reason
to "hide" the implementation with "private" we
give up the ability to query the attributes.

Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen]

Wes Groleau wrote:
> I'm not interested in "arbitrary" attributes.
> I'm interesting in creating an abstraction that
> has the attributes of being some kind of "number"
> but is still user-defined.


Well, "arbitrary" includes your case.

> But if we have a legitimate reason
> to "hide" the implementation with "private" we
> give up the ability to query the attributes.

Not in C++.

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

Kevin Cline wrote:
> With no access to subprogram types, attaching Ada-83 subprograms to
> widget callbacks was a real puzzle for me.  At the time I was doing

Damn near every compiler realised that fairly early on, and provided a 
(non-standard) way to do that, documented in Appendex F (if I remember 
correctly). However, 1988 is before my time, so I don't know if it 
counts as "fairly early on".


> near the quality of the free GNU C compiler.  Within a week of
> starting
> to program in Ada I found legal code that one or the other compiler
> rejected.  

That's hardly anything you wouldn't have to deal with using C though. I 
believe there *was* a C standard in 88, but you wouldn't have known it 
to look at the compilers available. The same goes today for C++. The 
most commonly used C++ compiler today (MSVC++ 6.0) is just barely over 
60% compliant, which means its barely more of a C++ compiler than not. I 
can tell you from sad experience that trying anything more than the most 
basic of the STL examples in Stroustrup's book will fail miserably with it.


> work.  But most
> of the problems with C were solved by the introduction of C++.

Having worked with both, I'd say that is just true. However, 60% less of 
C's language-induced problems is not near enough. Plus, C++ adds several 
new ones of its own, and even makes some of C's existing problems far 
worse. (eg: Now unexpected implicit type casts can happen with *any* 
type, not just the numeric ones)

> Today, the features that Ada provides have little value
> compared with the features that C++ provides and Ada lacks:
> the STL, automatic template function instantiation, smooth

I'd agree a bit with that. However, MSVC++ 6 doesn't really have this 
feature either. A large amount of the compilers that do have it, do it 
differently from each other. That effectively means you can't count on 
it in portable code. That's why rule #1 in the Mozilla C++ portability 
guide is "Don't use C++ templates". (see 
http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)


> integration of user-defined and primitive datatypes, and
> bindings to every API in existence.

I don't really consider this an issue. Bindings to anything that has a C 
interface are almost trivial to generate.

Re: Anybody in US using ADA ? One silly idea..

[Hillel Y. Sims]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:wmFR9.111225$Y86.101474@news2.central.cox.net...
>That's why rule #1 in the Mozilla C++ portability
> guide is "Don't use C++ templates". (see
> http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)
>

Why should anyone care about coding guidelines from a failed project though?
:-)

hys

--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

Hillel Y. Sims wrote:
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:wmFR9.111225$Y86.101474@news2.central.cox.net...
> 
>>That's why rule #1 in the Mozilla C++ portability
>>guide is "Don't use C++ templates". (see
>>http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)
>>
> 
> 
> Why should anyone care about coding guidelines from a failed project though?
> :-)

A good point, but I'm not sure how it relates to Mozilla. I've been 
using it for my main browser for over a year now, and personally think 
its about the best thing since sliced bread.

If you don't have the latest alpha with the baesean spam filtering, you 
are really missing out too. I get about 10-20 spams a day at this 
address, since I don't believe in email address munging. That's *after* 
the filtering my ISP does which catches about 40 a day (I'm *not* 
joking. My ISP caught 37 for January 3). But I almost never have to look 
at a spam any more. I think in the last week Mozilla let about 2 slip 
through, and hit one false positive.

Re: Anybody in US using ADA ? One silly idea..

[faust]

 Ted Dennison <dennison@telepath.com> ,  emitted these fragments:

>If you don't have the latest alpha with the baesean spam filtering, you 
>are really missing out too. I get about 10-20 spams a day at this 
>address, since I don't believe in email address munging. That's *after* 
>the filtering my ISP does which catches about 40 a day (I'm *not* 
>joking. My ISP caught 37 for January 3). But I almost never have to look 
>at a spam any more. I think in the last week Mozilla let about 2 slip 
>through, and hit one false positive.

Old technology.

Try Gnus with adaptive scoring.

-- 
natsu-gusa ya     / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones          / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

faust <urfaust@optushome.com.au> wrote in message news:<dg8r1v04moq9bq8skl49lg5bepqbid2i0g@4ax.com>...
> Ted Dennison <dennison@telepath.com> ,  emitted these fragments:
> 
> >If you don't have the latest alpha with the baesean spam filtering, you 

> Old technology.
> 
> Try Gnus with adaptive scoring.

(Chortle) Errr, no. That feature has been in Gnus since at least
version 5.3. That makes it at *least* 6 years old. The copyright in
the lisp source file for it dates back to '95, which indicates it may
be as much as 8 years old. Either way, I'm guessing it wasn't a new
idea back then either.

The Bayesian(sorry for the bad spellings before) method is, in part, a
*reaction* to the percieved problems with the various scoring methods.
I'm not closed-minded enough to think "old technology" is nessecarily
inferior. Hey, if it works for you, then great! But the fact is that
adaptive scoring is the "older technology".

I'd ask that anyone who feels impelled to go on about how inferior one
method is to the other (even against some useless yardstick like age)
at least learn a *little* about both methods first. I know that's not
traditional for Usenet posters, but I'm going to ask anyway.

Re: Anybody in US using ADA ? One silly idea..

[faust]

 dennison@telepath.com (Ted Dennison) ,  emitted these fragments:

 
 
>The Bayesian(sorry for the bad spellings before) method is, in part, a
>*reaction* to the percieved problems with the various scoring methods.

Thomas Bayes was born in 1702.
He pioneered what is now referred to as Bayesian statistics and
Bayesian inference.

Paul Graham's spamfilter is just an application of three century old
techniques.

http://www.paulgraham.com/spam.html

-- 
natsu-gusa ya     / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones          / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

faust wrote:
>  dennison@telepath.com (Ted Dennison) ,  emitted these fragments:
>>The Bayesian(sorry for the bad spellings before) method is, in part, a
>>*reaction* to the percieved problems with the various scoring methods.
> 
> 
> Thomas Bayes was born in 1702.
> He pioneered what is now referred to as Bayesian statistics and
> Bayesian inference.
> 
> Paul Graham's spamfilter is just an application of three century old
> techniques.


You know, your right! Also, all of Bayes' work is really ultimately 
built on the work done by Euclid and the other ancient Greek 
mathematicians. When you look at it that way, Paul Graham's spamfilter 
is really just an application of two *millenia* old techniques. I can't 
believe I even considered using software that old!

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

Ted Dennison wrote:
> built on the work done by Euclid and the other ancient Greek 
> mathematicians. When you look at it that way, Paul Graham's spamfilter 
> is really just an application of two *millenia* old techniques. I can't 
Whoops! My bad. Its actually 2 and a half millenia old...

Re: Anybody in US using ADA ? One silly idea..

[Kevin Cline]

Ted Dennison <dennison@telepath.com> wrote in message news:<wmFR9.111225$Y86.101474@news2.central.cox.net>...
> Kevin Cline wrote:
> > With no access to subprogram types, attaching Ada-83 subprograms to
> > widget callbacks was a real puzzle for me.  At the time I was doing
> 
> Damn near every compiler realised that fairly early on, and provided a 
> (non-standard) way to do that, documented in Appendex F (if I remember 
> correctly). However, 1988 is before my time, so I don't know if it 
> counts as "fairly early on".
> 
> 
> > near the quality of the free GNU C compiler.  Within a week of
> > starting
> > to program in Ada I found legal code that one or the other compiler
> > rejected.  
> 
> That's hardly anything you wouldn't have to deal with using C though. I 
> believe there *was* a C standard in 88, but you wouldn't have known it 
> to look at the compilers available. The same goes today for C++. The 
> most commonly used C++ compiler today (MSVC++ 6.0) is just barely over 
> 60% compliant, which means its barely more of a C++ compiler than not. I 
> can tell you from sad experience that trying anything more than the most 
> basic of the STL examples in Stroustrup's book will fail miserably with it.
> 
> 
> > work.  But most
> > of the problems with C were solved by the introduction of C++.
> 
> Having worked with both, I'd say that is just true. However, 60% less of 
> C's language-induced problems is not near enough. Plus, C++ adds several 
> new ones of its own, and even makes some of C's existing problems far 
> worse. (eg: Now unexpected implicit type casts can happen with *any* 
> type, not just the numeric ones)
> 
> > Today, the features that Ada provides have little value
> > compared with the features that C++ provides and Ada lacks:
> > the STL, automatic template function instantiation, smooth
> 
> I'd agree a bit with that. However, MSVC++ 6 doesn't really have this 
> feature either. A large amount of the compilers that do have it, do it 
> differently from each other. That effectively means you can't count on 
> it in portable code. That's why rule #1 in the Mozilla C++ portability 
> guide is "Don't use C++ templates". (see 
> http://www.mozilla.org/hacking/portable-cpp.htmll#dont_use_templates)

That document is now almost five years old.  Two years before that I
was working on template code that compiled on HP/UX, IBM AIX, Solaris,
and MSVC 5.0.  Today most template code is portable, except for a
couple of
features not implemented by MSVC 6.0.  I think that Microsoft Ada 
supports an even smaller subset of the Ada language.
 
> > integration of user-defined and primitive datatypes, and
> > bindings to every API in existence.
> 
> I don't really consider this an issue. Bindings to anything that has a C 
> interface are almost trivial to generate.

Do you mean they can be generated automatically?

Re: Anybody in US using ADA ? One silly idea..

[Ted Dennison]

Kevin Cline wrote:
 >That document is now almost five years old.  Two years before that I
...and yet is still linked to on the main programming page. That's 
becase nothing in there has needed changing. That is *still* the policy 
at Mozilla.

> and MSVC 5.0.  Today most template code is portable, except for a
> couple of
> features not implemented by MSVC 6.0.  

More than a couple. None of the function generators work at all (try 
using a "for all" or "for each" template to insert something into or 
delete something from a container based on a predicate, which is pretty 
much what they were created for. It doesn't work.), and automatic 
instantiation doesn't work except in trivial cases. Large portions of 
boost are unusable too. Lots of the stuff that *is* usable requires you 
to manually specify the template parameters (because its 
auto-instantiation sucks). The only way you could possibly make any 
reasonably complicated template code "portable" is with conditional 
compliation, or by going out of your way to use the least-common 
denominator. With 2 or 3 platforms that you know about ahead of time you 
might be able to do that. Mozilla has to work with so many different 
sucky C++ compilers that the least common denominator is no templates at 
all.


> I think that Microsoft Ada 
> supports an even smaller subset of the Ada language.

That's a very good way of describing Microsoft C++ too. :-)

>>I don't really consider this an issue. Bindings to anything that has a C 
>>interface are almost trivial to generate.
> 
> 
> Do you mean they can be generated automatically?

Well...yes there are such generators about, but no, that's not what I 
meant. I typically prefer to create my *own* bindings by hand, and have 
no compunction about doing so, even when good bindings are already 
available. That's what I mean by "almost trivial". Its about the same 
amount of work as writing external funtion prototypes in C.

Re: Anybody in US using ADA ? One silly idea..

[Bill Findlay]

On 3/1/03 01:05, in article ujn2va.go3.ln@beastie.ix.netcom.com, "Dennis Lee
Bieber" <wlfraed@ix.netcom.com> wrote:

>       Well, keeping concurrent with Ada's period, we could go to last names:
> Byron (and thence to friends of the family -- Shelley).
> 
I don't think poets are macho enough.
We need something really violent, like names of famous prizefighters, or
extreme weather events (Tornado? Cyclone? Hurricane?).

>       Pity Frankenstein is the name of the "doctor" and not the proper name
> of the monster... Then again, being built from odd parts is more the
> domain of PL/1, is it not?
> 
8-)

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

Re: Anybody in US using ADA ? One silly idea..

[faust]

 Dennis Lee Bieber <wlfraed@ix.netcom.com> ,  emitted these fragments:

>Byron (and thence to friends of the family -- Shelley).

Too wimpy.

-- 
natsu-gusa ya     / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones          / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

RE: Anybody in US using ADA ? One silly idea..

[Robert C. Leif]

This is what Microsoft would do. All one needs to do is to employ XML syntax
and Ada semantics. It will be both very verbose and sexy. If we model it
after SPARK, we can hype it as a new marvel of software engineering. A good
name would be XML#. 
Bob Leif
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]
On Behalf Of Warren W. Gay VE3WWG
Sent: Thursday, January 02, 2003 9:57 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Anybody in US using ADA ? One silly idea..

Marin David Condic wrote:
> I believe Pratt & Whitney is still using Ada for engine controls. At least
> some of them. As one who is working on the engines for the JSF, I can tell
> you that those controls are still in Ada - for the time being. (Don't know
> what will happen when they go into full scale development.)
> 
> Its a shame to see that many in the DoD arena are abandoning Ada because
> "Everybody else is using C++". In this area, Ada does not tend to suffer
so
> much from lack of large libraries or other development enhancers since
> hardware is often custom built and/or software development is not the long
> pole in the tent. Here Ada's faster development time and reduced defect
> characteristics can truly stand out. I'm afraid I don't know how to
overcome
> the "follow the crowd" mentality here. ...

Maybe what needs to be done is to form a brand new committee, to design
a spashy new language that basically implements the same features, with
similar syntax (but not too obviously). Then give it a splashy new name
after a popular young female (no programmer experience required), and
call it something like "Shania". Make sure it gets included in .Net, and
have the Universities preach about it and.. world domination!

;-)

Just a thought.

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

Re: Anybody in US using ADA ? One silly idea..

[Marin David Condic]

It might not hurt to start over again with a new name and a new language
that patterned itself on Ada - just to get away from the negative
impressions and bad press. But if all we've got is another language, it
won't do any better. It has to offer the developer something he can't get
elsewhere and it has to address a real need that's not being satisfied. I
think "Reliability" etc. are all good points, but any language or language
revision needs to consider what will help get it adopted by a larger crowd -
and "Reliability" just isn't cutting it.

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

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

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

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3E147D79.2070703@cogeco.ca...
>
> Maybe what needs to be done is to form a brand new committee, to design
> a spashy new language that basically implements the same features, with
> similar syntax (but not too obviously). Then give it a splashy new name
> after a popular young female (no programmer experience required), and
> call it something like "Shania". Make sure it gets included in .Net, and
> have the Universities preach about it and.. world domination!
>
> ;-)
>
> Just a thought.
>
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

Re: Anybody in US using ADA ? One silly idea..

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> It might not hurt to start over again with a new name and a new language
> that patterned itself on Ada - just to get away from the negative
> impressions and bad press. But if all we've got is another language, it
> won't do any better. It has to offer the developer something he can't get
> elsewhere and it has to address a real need that's not being satisfied. I
> think "Reliability" etc. are all good points, but any language or language
> revision needs to consider what will help get it adopted by a larger crowd -
> and "Reliability" just isn't cutting it.
> 
> MDC

While I just finished harping on library/binding support in an earlier
post in reply to you, I just realized something reading this reply. Java
has had (at least initially) the same binding/library challenges that
Ada95 has in the current general purpose world. Yet everyone and their
grandmother has come out with bindings to databases etc. to make Java
work within an application framework with great enthusiasm.

Q. So why is the enthusiasm so different for Ada, than it is/has been
    for Java?

The overwhelming difference (I think) is simply that Java is new and is
seen as (or was) "cutting edge". Ada is seen simply as "old and big".

You don't find Borland (for example) thrilled about selling support
for Ada, but they might be enthused over selling Java support.

Could there be more substance to the "new" suggestion after all?

Maybe the Ada way must distance itself from:

   - the Military association
   - the US assocation(?)
   - the committee association
   - the being "old" asociation
   - the being "big and clumsy" association

and maybe it just needs to be resold as :

   - the latest new computer science theory of "reliable computing"
     (even though the solution was well understood in ages past ;-)

Just like in science where the theory is often not well accepted
until the author of it passes away, we may need to have Ada
reborn to have it gain acceptance.  ;-)

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

Re: Anybody in US using ADA ? One silly idea..

[Marin David Condic]

Sure, there are a lot of "impression" issues, but lets look at what it was
that Sun did right with Java.

They spent a truckload of money advertizing Java when it first came out so
that people had a favorable impression of it and a willingness to look at
it.

They actually made some improvements over C/C++ that eliminated some of the
worst syntactic & semantic problems.

They provided truckloads of library code that leveraged development of GUI
based applications.

They promised and mostly delivered the ability to develop on one platform
and run on many.

They made the compiler available for the cost of a download so that anybody
could play the game.

They targeted a market with a real need (Internet apps) that wasn't being
addressed well by other languages.

In other words, they made it easy and desirable for people to try Java and
they delivered real development leverage over its nearest competitor. They
found a real need out there and filled it.

Ada *could* do the same, but not by trying to play a "me too" game or by
trying to be all things to all developers. Find a market with a real need
and start giving them real advantages and I think you'd see that market
start to move to Ada.

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

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

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

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3E15D2E2.9040807@cogeco.ca...
>
> While I just finished harping on library/binding support in an earlier
> post in reply to you, I just realized something reading this reply. Java
> has had (at least initially) the same binding/library challenges that
> Ada95 has in the current general purpose world. Yet everyone and their
> grandmother has come out with bindings to databases etc. to make Java
> work within an application framework with great enthusiasm.
>
> Q. So why is the enthusiasm so different for Ada, than it is/has been
>     for Java?
>
> The overwhelming difference (I think) is simply that Java is new and is
> seen as (or was) "cutting edge". Ada is seen simply as "old and big".
>
> You don't find Borland (for example) thrilled about selling support
> for Ada, but they might be enthused over selling Java support.
>
> Could there be more substance to the "new" suggestion after all?
>
> Maybe the Ada way must distance itself from:
>
>    - the Military association
>    - the US assocation(?)
>    - the committee association
>    - the being "old" asociation
>    - the being "big and clumsy" association
>
> and maybe it just needs to be resold as :
>
>    - the latest new computer science theory of "reliable computing"
>      (even though the solution was well understood in ages past ;-)
>
> Just like in science where the theory is often not well accepted
> until the author of it passes away, we may need to have Ada
> reborn to have it gain acceptance.  ;-)
>
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

Re: Anybody in US using ADA ? One silly idea..

[Richard Riehle]

Marin David Condic wrote:

> It might not hurt to start over again with a new name and a new language
> that patterned itself on Ada

When Ada 95 came on the scene, I suggested to quite a few people
that we call it "Tucker."   Someone suggested that this was too
reminiscent of the failed automobile of the 1950's, which was too
far ahead of its time to be appreciated, The Tucker.

Richard Riehle